Conferences for Remote Developers

I posted a quick note on ruby.social that got some notice and a few folks pinged me.

If you work remotely, going to a conference with a large number of other remote coworkers is a great way to build and refresh in-person relationships. I got to talk in person with 20+ coworkers who were previously only Slack icons and discuss technology and project decisions with the CEO in person. If you work remotely, it is worth finding these IRL touch points from time to time.

I wanted to add some more thoughts, but it gets long on a thread, so moving to a blog post.

Conferences for Remote Developers (long version)

It has been a few years since I visited many Ruby conferences. Attending the most recent RailsWorld was a reminder of some of their value.

• I work remotely, so it was a really great way to connect with co-workers, as my employer, Shopify, was the city sponsor in Toronto. This meant that hundreds of employees, both remote and local, attended pre-events, conferences, and outside-of-conference meetings. 
• It was a reminder that these are real people, many of whom I have seen only through GitHub icons, PRs, and issues for years.
• It is fun to have a user of an open-source library I maintain find me and chat about how much they enjoy the project and how they are using it in unique ways.
• It is fun to see some speakers’ growth over the years. One of the speakers at the conference gave a keynote talk; I also happened to be in attendance years ago when she gave her very first conference talk. Another easy giving their final talk after ten years of conference talks.

Talking about the work others do and how we use it inspired us to write and discuss how to use these tools and help share which tools are valuable to our work. We should also try to share more of the work we do that isn’t public or shared and could be interesting to the community. Non-private things that are locked away for no particular reason are closed source code.

I hope to make a few more posts about some of the tools we use in the coming months. I will also revisit my open source repos, respond to issues, and update them, ensuring they are all tested and work well with the latest Rails releases. Finally, I will clean up and get my current side project back online so I can share some of the fun things I play around with when learning.

All of that is to say that the conference did exactly what it should have. It inspired me and made me happy to be a part of the Ruby community, and it was great to put faces and real people to the great work I have been enjoying and following along with online for years.

Rails World 2024 Summary

As usual, DHH kicked things off with his keynote address, setting the theme for many of the more detailed follow-up talks.

Keynote tl;dr; DHH wants folks to have a fast onramp but be proud to learn and dig into the details. Driving home, a new tag line from “Hello World” to “IPO” was repeated throughout many of the talks and is clearly a theme.

What is Rails going for?

Many great Rails companies have been around and are still growing,  but Rails lost some of the newcomer momentum and is trying to get that back. As Rails became more complex and built more complexity into the base system, it became much harder to set up a brand new app, deploy it, and reliably use all of the features out of the box. Generally, we need a managed DB and Redis out of the box, along with multiple processes for job workers and grinding small single deployments (cheap Heroku dynos) to a halt.

Rails is investing in ensuring out of the box, all the initial solutions can start with extremely simple to-manage defaults that can deploy to single boxes without hassle, and using the same code can scale to much larger databases or purpose-built technologies like Memcache and Redis. Many of the talks filled in the details.

• Solid Queue revisits Action Bobs, building out and active job adapter using a data base backed queue that can ship at a starting point with an sqlite DB.
• This was a great talk and also gets into some very cool new DB  features like skip lock where modern DBs can unlock extremely performant queuing solutions
• Solid Cache, another option for Rails.cache and again brand new simple apps can start with sqlite, early scaling can share the production DB, and this scales all the way up to very large distributed shared caches using collections of multiple DBs.
• Solid Cable, action cable on the DB starting with sqlite for new apps.

So what does this mean after Rails new? You can start out with 4 DBs that are each single SQLlite files. As you grow in usage you can start to migrate each of those to the best fit for your needs. Also, please don’t underestimate how much it can scale on modern multi-core and SSD hardware.

Rails World 2024 Theme

The theme was clear and then sprinkled with talks on how this useful Rails as a one-person framework can make it easy for a single dev or small team to get a lot of leverage. Speaker justin-searls, giving his final Rails talk, showed how to build low code but very modern feeling apps with low maintenance costs. Diving into optimizing performance, profiling, and how to write fast Ruby with less allocations.

Not all talks were only about the technology as Eileen Uchitelle reminds us how many of the largest and oldest Rails apps have struggled either with microservices or componentizing a modular monolith. Pointing out, rightly in my opinion, that neither solves what is a people problem, not a tech problem. The problem comes from prioritizing features and new code over good maintenance, refactoring, and constantly driving to improve code quality. Also, we often have folks not trained in rails writing a significant amount of code on a team without others familiar with rails, and companies don’t incentivize training and maintenance, often giving promotions to new high-visibility projects vs reducing toil and simplicity.

While the talks were good, the best part for me was seeing and chatting with many developers I interact with online and contributing to projects I use, contribute to, and learn from. It was great to meet @jhawthorn and tell them about how I started using their new profiler vernier (please check it out and see how it can finally untangle performance issues across threads), asking the author of Solid cache about how it may work with a particular architecture setup, or even discussing with colleges if we can perhaps open source some libraries that might help push the community ahead a bit further as folks are facing similar challenges as we see internally.

It was great meeting old friends and talking to some new friends at Rails World. Thanks to everyone who helped make it a nice event.