A few months ago, Basecamp released Hotwire, their support tools for client-side development using HTML over the wire rather than JSON. These are the generic versions of the tools that power Hey. Hotwire consists of the already released StimulusJS, and Turbo, which is the successor to Turbolinks.
I’m very excited about these tools, and I discuss them at length in Modern Front-End Development With Rails (on sale now)!
It occurred to me that possibly people following me here on Medium that you may not be seeing more recent writing because I’m not publishing here anymore.
You can find me at https://buttondown.email/noelrap — subscribe there for free to get an email newsletter that I update hopefully once a week (probably a little less than that until the books are done). If you want to, you can subscribe for money, in which case you will get some occasional extra content, but honestly, it’s mostly a tip jar right now.
I’ve been writing there about the new Rails Hotwire stuff: Turbo, Stimulus, and I’m also doing a series of posts about Agile and team concepts that I’m calling The Entropy Essays. Plus other random developer and tech related stuff.
I hope you’ll join me there.
20 some-odd years ago, when I was a graduate student, I spent about two years building Mac applications using a language called Prograph.
You’ve likely never heard of it.
I want to explain why I’m still kind of obsessed with it.
I’ve spent a lot of the intervening 20 years explaining to people why it was great. I’ve I’ve been capable of delivering this as a lightning talk at the drop of a hat at any time in the past ten years.
Prograph was a purely visual language — they called it a data flow language. And by visual, I…
These are a director’s notes on my talk “The Developer’s Toolkit”, you can also watch the video here.
It has sources for all the tools mentioned in the talk, and a little commentary that didn’t quite fit in. Hope this is helpful:
I actually switched to ZShell as my prompt using the Oh My Zsh library to install it. ZShell is…
Everybody in the Ruby community says they love pair programming. We often use it as a proxy for the awesomeness of a developer shop. Developer candidates regularly ask me if we pair as part of their attempt to determine if we know what we are doing.
I wish we’d cut that out. Pairing is not a proxy for how good a development shop is.
Pairing is also not, in my experience, a great tool for increasing team productivity and code quality. At least, not without putting a significant amount of effort into structuring the team to take advantage of pairing.
Just this week, RSpec 3.7 was released with support for the Rails system tests added in Rails 5.1.
(If you’d like to read more about system tests and see examples of them in action, my book Rails 5 Test Prescriptions is now avaiable for purchase)
System tests were added to Rails core in Rails 5.1 as the core team’s preferred way to test client-side interactions using Capybara and a browser driver. This is in addition to the Rails core integration tests, which don’t use Capybara, but which do test against server-side generated DOM elements.
Even if you are already using…
This is part of a new series of blog posts expanding on or relating to each episode of the Tech Done Right podcast. There are a couple of links through this post going back to specific parts of the podcast. Leave a comment, or follow us on Twitter.
Podcasts are perhaps not the world’s best medium for talking about code, so I wanted to dive a little deeper into a couple of things that Corey and I discussed.
Corey mentions early on in…
This is the weekly newsletter for the Tech Done Right podcast. If you like this newsletter or have other comments, email me at email@example.com. And tell your friends to subscribe at http://techdoneright.io/newsletter.
The big news in my little corner of the world is the closing of Dev Bootcamp. Many of the original Chicago DBC staff were former coworkers of mine. Here’s Dave Hoover’s photo set from the first couple of years. I have some complicated feelings about the bootcamp movement, which I’m hoping to get to on a future podcast episode (here’s an interesting Twitter thread from Sarah Mei on…
So, I had enough fun with comparing RailsConf to older RailsConfs last year that I thought I’d do it again.
Same rules. There are 20 talk titles listed here, 10 of them are from the 2009 RailsConf in Las Vegas, 10 of them are from the 2017 program in Phoenix next week. I tried to avoid talks that specifically referenced versions or tools that would date them, like “What’s new in Rails 3” and the like. I may have deliberately tried to pick things that were surprising.