Noel Rappin Writes Here

Blogs

Okay, This One Is About Stimulus

Previously On Locally Sourced: I wrote about Hotwire and Turbo, the Rails client side New Magic. Then I wrote about them again. I think you are all caught up. I’ve been writing about Hotwire and Turbo, and haven’t said all that much here about Stimulus. Which is a tool that I like so much, that after using it on a project, I literally decided to write a book so I could tell more people about it.

What I Like About Hotwire

Previously On Locally Sourced: I wrote about how to use Hotwire and Turbo. (My Mac keeps wanting to autocorrect that to “Hot-wire” for some unknown reason…). The update to Modern Front-End Development With Rails is ongoing, the book is available for beta purchase if you want the new stuff as soon as we can get it to you. After writing a post a couple of weeks ago explaining how the new Hotwire framework works I want to spend some time explaining what I like about it.

A Brief Hello to Hotwire and Turbo

This week, after some mysterious announcements about “New Magic”, 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. This is also the tool release that has been holding up Modern Front-End Development With Rails, on sale now!

The Road To Legacy

It occurred to me recently that two of the conference talks that I consider the best I’ve ever written never really got a very wide audience, even by the admittedly low standards of my conference talks. And I also wanted to revisit them to see if I can improve the argument. This post comes from a talk called “The Road To Legacy is Paved With Good Intentions”, and here is the original talk video from WindyCityRails 2017.

Technical Writing

I recently gave a workshop about technical writing at Virtual RubyConf 2020. I enjoyed doing that tremendously, because, in case it’s not clear, I could yammer on forever about technical writing in much the same way as I normally yammer on about code, just to a smaller audience. I didn’t get to some of my outline in the workshop, so I’m being a little indulgent and writing it up here. I hope it’s helpful.

Empirically, I Have No Idea

How We Don’t Know What We Know Previously on Locally Sourced. Who can even remember? Sorry, it’s been a while. I’ve been stuck writing two-thirds of posts and not quite wanting to finish them, but if you are reading this, I assume that means that I finally ended this one. In the meantime, I’ve sold a book-shaped object to Pragmatic that will be about Tailwind CSS. It’s part of the Pragmatic Answers line, which means it’ll be short, and it’s what I’m doing to keep me busy until the Stimulus book is releasable.

These <Prime Number> Tools Will Make You a <Superlative> Developer

Look, I said it was a weird trick, not necessarily an effective trick… Every day, it seems, I get a digest from Medium that has a bunch of articles that are all titled “9 VS Code Extensions That Will Change Your Life”. To be completely honest, I read a lot of them, and I actually do find some useful tips. But I want to back up a second and talk about developer tools in general.

Entropy Essays 7: Process and Trust

Trying to Define Undefinable Terms: The Locally Sourced Story Previously on Locally Sourced: I’ve been writing about XP and Agile. Most recently, pair programming. And how I think about technical decisions. I started to write a different essay here, but then I realized that I was sort of depending on having written something like this. So I wrote this. I’ve been writing all these posts about Agile and XP methods and I’ve been talking about process and about trust, but I haven’t defined them in the way I use them and I haven’t talked about how I think they are related.

How I Make Technical Decisions

Maybe it’ll help you out? Previously on Locally Sourced: does anybody read this part? Hi, it’s Noel, how are you? Last time, I wrote about pair programming, and there were a couple of discussions on Twitter (where you can follow me @noelrap) that came down to what would make you choose to have your team do pair programming or how you would evaluate it. I thought it was worth a follow-up…

Entropy Essays 6: Pair Programming

We hope that 1 + 1 = 3 Previously on Locally Sourced: I’ve been doing a lot of these oddly titled posts about XP and Agile practices. Like testing. Or OO. I wrote about inclusion on agile teams. And about team metrics. Next up: pair programming. And even though it sounds a little pretentious to my ears, I really do think this is going somewhere, and I think between the last one and this one, the shape of the argument is starting to make sense to me.

Copyright 2022 Noel Rappin