Hotwiring Rails Newsletter - August 2022
01 Aug 2022This newsletter went out via email to the Hotwiring Rails subscriber list, but I know that not everyone wants another email cluttering up their inbox. For those folks, I’ll always publish the full content of the newletter here too, so you can get all the content with none of the emails.
Thoughts or feedback on how I can make this newsletter more valuable? Have something you’d like to include in next month’s edition? Send me an email, or find me on Twitter.
Table of contents
- Articles and guides
- New and interesting PRs and releases
- My recent writing
- The best things I read recently
Articles and guides
Fly Reactive Rails by Julian Rubisch
Julian dives deep into how he deploys reactive Rails applications on Fly.io. Fly takes (a lot) more work to get an application deployed compared to Heroku and Render, but for the right type of application, there are major benefits.
Read the article on minthesize.com
Vite-lizing Rails by Vladimir Dementyev
Keeping up with the front end bundling world is exhausting, but Vite is worth taking a look at, especially if you’re considering making a switch from Webpacker to the new cssbundling/jsbundling options added to Rails 7. Vite is a nice alternative to esbuild if you want a more full-featured option with glob imports, HMR, and live reload ready to go (almost) out of the box. You can get there with esbuild, but it requires a bit more work and the developer experience is not quite as nice.
Vladimir’s write up on migrating a Rails app to Vite is very straightforward and, as a nice bonus, it includes a look at his Docker setup for Vite, if you’re into that sort of thing.
Using Turbo Streams with Kredis by Mansa Keïta
This is a quick, interesting look at using Turbo Stream broadcasts without a backing ActiveRecord model. Kredis + a PORO gets the job done as Mansa builds a simple counter app that stays in sync across browsers, even when updates are triggered from the Rails console.
My favorite tip here is using Turbo::StreamsChannel to broadcast directly to a channel, which is a nice power move for Streams users.
Booleans don’t exist in Ruby by Mike Burns
Mike takes us on a fun trip to answer the question of whether or not Ruby has booleans. Does Ruby have booleans? As Mike says, “That’s a question for you and Ruby to answer together.”
Explore the depths of Ruby’s boolean implementation on thoughtbot.com
Video | Subdomain Routing in Rails by CJ Avila
This video from CJ shows you how to use subdomain constraints to handle subdomain routing in Rails. This is an area that can get tricky, especially if you’ve never needed to think much about dealing with subdomains while developing locally. CJ’s thorough look at how it works (and live trouble shooting) is a good introduction to the problem.
Galaxy Brain CSS Tricks with Hotwire and Rails by Matt Swanson
This article has a few simple, effective tips for leveraging CSS to clean up your Rails code. Each tip is bite sized, general purpose, and easy to apply to your own code. Note that a few are Tailwind specific, but not all. The highlight for me isn’t a CSS tip specifically, but instead a plea to stop interpolating CSS classes in your views by using Rails’ tag and class_name helpers instead.
5 minutes in this article will probably send you away with something new to add to your bag of tricks.
Video | Naming things: rails new by Joel Drapper and Kasper Timm Hansen
Naming Things is a neat new addition to Rails-land from Joel. In the inaugural episode, he pairs with Kasper on designing and building out a bit of an event scheduling application.
As a viewer, you’re listening in on their pairing session as they think through the design of the application and start piecing together some of the code — I really enjoyed hearing two very talented Rails devs talk through problems together. Getting that kind of view of how other folks work is neat, IMO.
New and interesting PRs and releases
Turbo has a new 7.2 release in beta, and there are some really big changes that I was not expecting to see get merged. Some highlights:
Allow Turbo Streams with GET (with an important follow up PR): This is a huge change that should eliminate the need for clunky, Turbo Frame workarounds for responding to GET requests with a Turbo Stream action. There are immediate, obvious applications here improving the DX of building search interfaces and pagination with Turbo.
Support custom rendering in turbo events: This PR came in last year and wasn’t picked up but has gotten a refresh for the 7.2 release. The changes here make it easier to extend Turbo to work with third party libraries like morphdom.
On the other side of the Hotwire stack, Stimulus also has a new release in the works with support for new action options plus support for custom action options merged into the main branch.
I’m excited to see such big changes coming for both Turbo and Stimulus — both projects are growing in popularity and the ongoing development is a great sign of the long term health of the Hotwire stack.
My recent writing
Along with taking a break from this newsletter, I took a break from blogging for the last few months, but I’m off the break and back to writing. In July, I focused on non-tutorial writing so these two pieces might be a little different than what you’re used to. I’ll be back to tutorial writing this month.
Rails is back isn’t enough: Some thoughts on the scarcity of junior level positions in certain parts of the Rails world, and what that scarcity means for the health of Rails on very long time scales. Twitter thought this was a Good One.
Writing effective coding tutorials: I read a lot more articles about Rails than what I include in this newsletter. A lot more. Many of them are great technically, but very hard to get value from.
In this (extremely niche) article, I compiled a few of the common mistakes I see engineers make when writing coding tutorials, along with simple ways to fix those mistakes and deliver a better end product to readers.
The best things I read recently
I’m job searching right now, and so I’ve spent a lot of time thinking about (and retelling) the time I spent building the engineering and product org at my last company. I told a very small piece of that story in Rails is back isn’t enough, linked above.
Expanding a bit on the story of my time at that company: My extremely small team (1 engineer, 0 designers, me as PM + eng in one) was tasked with building an entirely new product adjacent to our existing product. The existing, established product had a long queue of planned work needed to keep our edge in the market. This wasn’t a great plan, in retrospect.
Taking on an entirely new product without a dedicated team to build it was a bad idea. We needed to choose one product, or we needed to add enough resources to execute well on both products at the same time. Instead, the company chose to try to do both without adding enough resources. As a result, the new product suffered from half-baked ideas and a lack of vision because the business continued to put most of its energy into the existing, established product. That product paid the bills, so the math was easy.
This seems like a simple lesson in retrospect, but I see these sorts of poor strategic decisions made all the time — chasing new opportunities without consolidating existing wins, spreading focus across multiple initiatives because narrowing focus is scary, or individuals with 100 ideas, each of which gets 1% of their energy. Companies try to implement things like EOS to combat this focus problem, but ultimately it takes courage and conviction to hold the line when facing constant distractions. Organizational management models only get you so far.
That was a very long introduction to this article from Meta’s CTO, Andrew Bosworth, on ruthless prioritization. Aptly titled “Half staffed is unstaffed” it distills many of the thoughts I’ve had on this recently, and is worth a read if you are thinking about how to allocate your resources (personally, or for a team) more effectively.
At the organizational level the best solution I have found is to always staff from the inside out. You must fully fund the core and if you can’t do that then shut it all down. If you have space beyond that you can continue to fund things fully, one at a time, in accordance with your portfolio of goals. When you can’t fully staff another team then you stop.
Until next time
It is nice to be back with all ~500 of you after a couple of months away! In case you missed it, Rails conf talks are up on YouTube and there is a new Ruby podcast that you might enjoy.
If you enjoyed this newsletter, send me a note and let me know or share it with a friend who might enjoy it too.
PS — I’m actively looking for a new full-time role (remote, in the US).
I’m most interested in product or engineering leadership roles at early stage companies, but I’ll happily consider IC roles in product or engineering on kind teams doing interesting work. You can reply to this email or find me on Twitter if you know of an opportunity that might be a match.
You can find my odd work history on LinkedIn.
As always, thanks for reading!