Sin City Ruby 2024 was one of this year’s Ruby conferences that we, thoughtbot, were excited about. In this post, I will share why.
Jason Swett, the organizer, invited me to be one of the speakers. It was a great opportunity to talk about JavaScript testing for Ruby devs. Spoiler: an extended version of this topic will be presented at RailsConf 2024. Hoping to see you there :)
I am so grateful for the opportunity and for thoughtbot sponsoring my travel. Here are my takeaways and highlights from Sin City Ruby 2024.
Smaller conference, bigger connection
Attending a single-track conference is great: you don’t have to choose any talks. They have been chosen for you already. Oh, did I mention there was no summary of any talks? Surprise! All you had to do was show up and learn from the speakers.
Besides that, in between the talks, you get more time to talk with people in 1:1s. It’s a small group, so you get to recognize almost everyone on the second day. At Sin City Ruby, the connection was instantaneous – we even tried some improv exercises during lunch break.
If you haven’t attended a regional conference yet, make sure to try it out. It’s worth it.
That’s not to say that large conferences aren’t great. Each one is different and valuable in their own way. Try both and see what makes you happy. What’s important is to meet fellow Rubyists and learn from each other – no matter the size of the event.
I also enjoyed the talks not being recorded. It gave the event this feeling of “either you’re here or you aren’t”. No chance to re-watch it later, which makes it a bit special.
Yes, Ruby is alive and thriving
What caught my attention the most was the number of consultants present at the conference. Not only big consultancy agencies, like thoughtbot, Evil Martians, OmbuLabs, and Test Double, but also independent folks.
One way to think about this is: “Wow, so many competitors, that’s bad!”. That’s a limiting way of seeing this.
The way I see it is: lots of people making a living with Ruby in 2024. And we were all there because we are part of a community that always seeks to be and do better: better at coding, at building tools to make us even more productive and happy; better at helping clients, and helping each other.
Isn’t that refreshing?
Despite the recent economic situation we’re in, seeing people making a living and thriving by building businesses with Ruby gives me hope. That’s not to say that some people aren’t being affected by the economy. I also met folks who have been laid off and are still looking for jobs. It’s a tough time and I hope things get better for everyone.
This leads me to mention: that if you know someone looking for a job, connect them with someone who might help them. It doesn’t take too much of your time and it can go a long way.
My favorite Sin City Ruby 2024 talks
I love improving existing codebases. Any discussion about maintaining existing applications, managing tech debt, and keeping large existing applications healthy, makes my heart pump faster.
That’s why I enjoyed Ernesto Tagwerker’s talk, “Stuck in the Tar Pit”. I have seen a version of it online before. This time, Ernesto shared new resources, including this fresh paper from Google called Defining, Measuring, and Managing Technical Debt.
There’s a lot to unpack there but what I liked the most was seeing how Tech Debt is becoming less subjective and more measurable. It gives us a vocabulary and tools to go from “arrgh, this code is bad” to “this is the main tech debt category dragging us down and we can do something about it”.
The paper defines Tech Debt in 10 categories and introduces a framework for teams to assess their technical debt maturity. Quoting the article:
- Teams with a “reactive” approach have no real processes for managing technical debt.
- Teams with a “proactive” approach deliberately identify and track technical debt and make decisions about its urgency and importance relative to other work.
- Teams with a “strategic” approach have a proactive approach to managing technical debt (as in the preceding level) but go further: designating specific champions to improve planning and decision making around technical debt and to identify and address root causes.
- Teams with a “structural” approach are strategic (as in the preceding level) and also take steps to optimize technical debt management locally—embedding technical debt considerations into the developer workflow—and standardize how it is handled across a larger organization.
Ernesto wrote a summary of the paper as well, which I recommend bringing in to discuss with your team. And I mean the whole team, not only developers, but also Product Managers and Team Leads.
As a consultant developer, reading this paper sparked some questions for next time I’m designing a feature, a migration, etc.:
- how would it look like if this migration/feature was to be stopped in the middle?
- how would it look like if one of the experts working on it leaves the team?
- how far away from the latest stable version of this core dependency do we decide to stay at any given moment?
- where are we in the tech maturity level scale? and where do we want to be?
- what code needs to be removed/refactored to give space for this new code?
- is our test suite healthy and ready for more tests to be introduced?
Still on the track of maintaining Rails apps, Vladimir Dementyev talked about the traps almost inevitably all Rails apps will run into. One thing I want to explore more from that talk is using Rails Concerns to place “coherent chunks”. They serve as glue between objects and Active Record. I confess I haven’t used concerns that much in the past, so this caught my curiosity.
I also won a copy of his book, “Layered design for Ruby on Rails applications” where he goes more in-depth on maintaining Rails apps. Interesting tools that were shared:
- erb-lint: a tool to help lint your ERB or HTML files using the included linters or by writing your own.
- store_attribute: an ActiveRecord extension which adds typecasting to store accessors.
Besides these two, I enjoyed the live coding sessions about Mastering Query Performance with Postgres and Active Record, going from Stimulus controllers to React, and the talks about using inheritance and delegated types responsibly.
Thanks, Sin City Ruby(ists)
Thanks, Jason Swett for the invite, and everyone for the great time.
Aaaaand, because we are talking about Sin City Ruby and Jason Swett, check out the podcast interviews Jason has done with me and my managing director, Ran Craycraft.
See you out there in a future conference.
