Kicking off a new year of recordings with a new Ruby AI Podcast episode discussing:
- Ruby's 30-year evolution and the quiet release of Ruby 4
- AI agents vs collaborative workflows
- Productivity gains vs AI-generated "slop"
- Open source incentives in an AI-driven world
- Not hype-heavy, more reflective and practical.
We explore the tension between two cultures: the traditional craftsmanship ethos (clean, refactored code) and the "just regenerate it" mindset of younger AI-native developers. Obie Fernandez argues this might be less about losing skills and more about redefining them.
At Doximity, we go to great lengths to ensure the quality of our products aligns with the standards physicians require. Across various industries, Large Language Models (LLMs) have become the backbone of numerous applications, driving advancements in everything from natural language processing to automated content creation. As we continue to develop products that make use of these LLMs, the need for rigorous and comprehensive evaluation of their outputs has never been more critical. Strap in as we explore the process for evaluating our Doximity GPT product, Doximity’s HIPAA-compliant medical writing assistant, focusing on the importance of using "ground truths" to establish baseline metrics and the relative performance of contender models.
I would like to thank everyone for such a lively discussion! It has been a joy reading through and feeling the sentiment ebb and flow in that traditional HN fashion
For those curious and inquisitive minds out there, this article was intended to provoke emotion, fuel your creative soul, and pull you in to the Ruby source code. The precursor to this article was one I wrote on how IRB works and many of it's features. I had accidentally stumbled upon this "samples" directory and like many here wondered _why_ it is there and _what purpose_ was it serving. While many of the examples are a bit dated, they all make use of the standard library in various ways, and many make use of Ruby in ways _I_ hadn't seen before. Even if you don't care for the examples themselves, I hope to leave you with ample reading material to explore those unfamiliar crevices of Ruby.
As many have shouted, there are quite a few pain points in the Ruby language documentation, best practices, discoverability, and onboarding of new comers. This is an incredible time to be a part of this community and make this language as enjoyable to learn as it is to write.
As one of the maintainers of git-reflow, I understand the controversy over squash-merges. Personally, on all the projects I've worked on with this workflow, I have yet to find any drawbacks when needing to use git-blame; although is not to say that there is no value in maintaining a full history nor that it is our way or the highway. We like to keep all changes in context of a feature.
We have worked in environments that promote rebasing of feature branches, and while that may work well, it can lead to holes in the history of the review process due to the need to force-push.
That said, we are nearing a stabilized core API and have plans to allow for more flexibility in the process. If you are interested in following our ideas behind this, feel free to follow the issue we have open: https://github.com/reenhanced/gitreflow/issues/53
From the README: "On your first install, you'll need to setup your Github credentials. These are used only to get an oauth token that's stored in your global git config. We use the Github credentials so we can create pull requests from the command line."
- Ruby's 30-year evolution and the quiet release of Ruby 4 - AI agents vs collaborative workflows - Productivity gains vs AI-generated "slop" - Open source incentives in an AI-driven world - Not hype-heavy, more reflective and practical.
--- Before this episode, we asked a harder question: "Is AI actually real? Or just cosplay?" with Evan Phoenix https://www.therubyaipodcast.com/2388930/episodes/18457774-r...