Recent Posts - Page 3

Today marks the launch of On Rails, a new podcast produced by the Rails Foundation and hosted by yours truly.

We’ve recorded the first batch of episodes, and Episode 1 is out now: Rosa Gutiérrez on Solid Queue.

The show dives into technical decision-making in the Ruby on Rails world. Not the shiny trend of the week… but the real conversations teams are having about how to scale, what trade-offs to make, and what long-term maintainability actually looks like.

You’ll hear from developers running real apps. Some are building internal tools. Others work on products you’ve probably used. A few are out there blogging and tweeting… but many are too deep in the day-to-day to stop and write about it. They’re just doing the work — shipping, fixing, refactoring, and figuring it out as they go.

The idea for On Rails started with those hallway conversations at conferences. The ones that don’t make it into keynotes or blog posts. It grew out of the calls I have with clients at Planet Argon. And, of course, out of years of hosting Maintainable.fm.

You’d think that after recording over 200 episodes of Maintainable, I wouldn’t be so nervous to hit record on something new… but here we are. New show jitters are real.

We’re approaching this podcast with depth and focus. Fewer episodes. Longer interviews. Conversations that aim to surface lessons learned…and the thinking behind the decisions that shape real systems.

If you’re a Rails fan, I hope you’ll give it a listen. If subscribing is your thing, you know what to do. And if you’ve got a story worth sharing — I’d love to hear from you.

🎧 Listen to Episode 1: Rosa Gutiérrez: Solid Queue

🌐 Browse all episodes: podcast.rubyonrails.org

📢 Official announcement: Ruby on Rails blog

Backstory

Earlier this year, I dusted off this blog — which I started back in 2005 — and found myself reflecting on Maintainable, the podcast I’ve hosted for the past few years about long-term software health.

At the same time, I was toying with the idea of spinning off something more Rails-focused. A show that could spotlight the kinds of conversations I was already having…with clients, with other devs, and in those casual, between-session moments at conferences.

Right around then, Amanda from the Rails Foundation reached out with a prompt:

“A podcast of Rails devs talking about the nitty gritty technical decisions they’ve made along the way.”

…which aligned nicely with what I had been ruminating on. The timing was perfect and we decided to make it happen.

One of the early shifts for me was adapting to a more collaborative production process. I’ve been running Planet Argon for more than two decades — and I’m used to moving quickly, often without needing to pitch or workshop ideas with others. But with On Rails, I’ve had the opportunity to work closely with Amanda, the Foundation, and DHH. They’ve all taken an active interest in shaping the vision, the guests, and the format.

Another early challenge? The first round of guests were pitched to me — which meant jumping into the deep end with folks I hadn’t already spoken with. That raised the bar for prep. On Maintainable, I’ve occasionally relied on some degree of improvisation. Here, I knew I’d need to come in more prepared…and that’s been a good thing.

So On Rails was born.

I’ll still be hosting Maintainable (though likely on a slower cadence). And I’m excited to run both of these shows side by side — each with their own tone and focus.

Hope you get a chance to give it a listen.

Drowning in technical debt?

It doesn’t have to be this way.

Back in September at Rails World 2024, I shared what I’ve learned from helping teams tack their way out of trouble—less theory, more battle-tested strategies. Lessons from Planet Argon’s clients, Maintainable.fm guests, and real-world Rails teams.

Have 25 minutes? Watch it here:

Your future self (and your app) will thank you.

More of my talks and panels are collected on my speaking page.

As a consultant, I’ve looked over a shitload (how many? probably ~150-200) over the last 12 1/2 years in the Ruby on Rails community. I haven’t worked on most of them, but I do get invited to look over, review, audit, and provide feedback on a lot of those.

Over on the Planet Argon blog I’ve shared my quick hit list of a few initial things that I look for when looking over an existing code base.

Read Ruby on Rails Code Audits: 8 Steps to Review Your App

A few months ago, I wrote an article on Medium about my experience of starting Oh My Zsh. Thought I’d share it for the few lingering readers over here, too.

d’Oh My Zsh: How I unexpectedly built a monster of an open source project

The 2016 Rails Hosting community survey results are in. One of the numbers that I’m tickled with joy about? 84% of Rails developers said they’d prefer to use PostgreSQL.

We won!

Check out all the survey results at http://rails-hosting.com/

If you’ve not taken the 2016 Rails hosting survey, please do so at http://rails-hosting.com/

Tom Stuart posted up an excellent article on Automatic Differentiation in Ruby with links to his talk slides and video.

David was kind enough to put together a demonstration of how to take advantage of Action Cable in Rails 5.

In the video he puts together a small chat application.

Yesterday, I found out that Ezra Zygmuntowicz had passed away.

Ezra and I first met in the #Caboose family. The first time we got to spend time together, in person, was at RailsConf 2006.

(photo credit: Jarkko Laine)

A few weeks later, he emailed me to ask about getting a job here at Planet Argon. We couldn’t afford him so he continued to pursue other paths… and a month later was helping found EngineYard.

(…one of those things that I still find myself asking, “what if we could have?”)

Back when Planet Argon had a hosting department, Ezra and I collaborated on various deployment best-practice projects. He was always helping our team figure out how to make deployment easier. Some of us might remember his famous nginx configuration (the closest version I could find). He was an active contributor in the Ruby on Rails Deployment group that I started. He was always around to help the community.

Ezra always seemed to find time for the community… whether on mailing lists, at conferences, commenting on our blogs, or chatting over IRC.

When Ezra and his family moved to Portland, we made several half-assed attempts to schedule time to catch up again in person. It never happened and our interactions were limited to keeping up on Facebook

His passing is a great loss to our community.

To his friends and family, I am sorry for your loss.

To his son, (should you ever discover this), your father helped pave the way for hundreds of thousands (if not millions?) of software developers around the globe—whether they know it or not. He was constantly looking for innovative ways to solve problems. His talks at conferences were always fascinating… and the rest of us would sit back and think, “where does he come up with these ideas?!”

He was a trailblazer.

He will be missed.

Thank you for everything, Ezra.

Update: If you would like to contribute to the memorial fund for Ezra’s son, Ryland, please visit this campaign on indigogo.

Attention all Ruby on Rails Developers… you have six days to complete the 2014 Rails Hosting Survey.

All of the results will be shared with the community. Consider this your civic duty of the day. :-)

http://rails-hosting.com

Recently, I found reading an article by Paul Venezia titled, Fatal abstraction: A bottom-up view of high-level languages, where—if you read between the lines—you can see that Paul just found himself waking up from a coma and it’s no longer 2004.

“I may have questioned Perl’s future now and then, and Perl certainly doesn’t have the presence it once enjoyed, but the strength of Perl has always been its flexibility. You can do pretty much anything with Perl, and you can do it in a wide variety of ways. Perl’s core revolves around the idea that there’s always more than one way to do it. In fact, there may be dozens of ways to do it. PHP shares a similar trait in that it gives you a large set of tools and leaves the construction up to you.

Ruby, and especially Rails, is the opposite, and Python definitely leans more in that direction. Essentially, it’s the difference between building a chair from raw lumber and assembling one from IKEA. This isn’t to say there’s anything wrong with assembling from parts, and clearly Ruby and Python are very capable and strong languages. However, they’re not my cup of tea.”

Admittedly, perhaps I’ve been in drinking the “kool-aid” for far too long, but I thought this tired argument has run it’s course.

I take huge offense to comparing Ruby on Rails to IKEA furniture. It’s far easier to build a web application with Ruby on Rails than it is to build an IKEA bookshelf

“When it comes right down to it, I need to know exactly what my code is doing. I’m going to keep an open mind and spend more time on the other side of the fence in the short term. Perhaps I’ll be won over, but it won’t be easy. Trust issues are complicated.”

Paul, I completely understand where you’re coming from. It sounds like you’re dealing with similar trust issues that I had nearly a decade ago. Trust me, it will be okay.

Ruby on Rails isn’t magic. Behind the curtain you’ll find a collection of object-oriented code written in one of the most readable languages in existence.

Hello! It’s been two years since Planet Argon last asked the Ruby on Rails community how they were deploying and hosting their applications and we thought it was time to checkin with people.

Until April 30th, you can take the survey here.