Noel Rappin Writes Here

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!

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.

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.

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.

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.

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.

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…

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.

Or Why is a Software Team Like A Shortstop Previously on Locally Sourced: I’ve been writing these Entropy Essays about Agile and XP practices. Here’s the most recent one. You can see the rest here. Tell all your friends and colleagues to subscribe. One of the great things about writing this newsletter is that it’s forced me to think some ideas through in more structured ways than I might have if I was just talking to myself in my own head.

It’s hard to predict… Previously on Locally Sourced: Well, we’ve been talking about the history of Rails and JavaScript: part 1, part 2, and part 3, and we’ve finally caught up to the present time, so I guess it’s time to talk about the future. Also, my Rails and JavaScript book is still on sale. You might want to buy it. This is all a little speculative, based on the are changes that have been made to Turbolinks and Stimulus that are clearly in use in Hey.

The Webpackening Previously on Locally Sourced: Rails came out and let people do Ajax, when Ajax was a thing. Then Ajax was less of a thing and Rails let people write CoffeeScript, and use Sprockets. Also, I wrote a book on Modern Front-End Programming with Rails, which is relevant to this edition. The Rails 5 and 6 releases have had a few big JavaScript components, with one more presumably imminent. With Rails API and Webpacker, Rails made a big move toward allowing better interoperability with the JavaScript ecosystem.

UJS, CoffeeScript and Sprockets, oh my. Previously on Locally Sourced: I wrote about the early years of Rails and JavaScript. Which made it to Ruby Weekly. Also, my Rails and JavaScript book is still on sale. A quick program note: If you’ve liked the Entropy Essays, I’m doing a virtual Chicago Ruby Meetup on July 7th at 6:00 Central Daylight Time. It’s being streamed via zoom, and you can sign up here.

You got your Rails in my JavaScript… Previously on Locally Sourced: Well, in 2005 I came across a cool web framework called Ruby on Rails. More recently, I wrote a book about integrating Rails and front-end tools. If you want, you could buy it. Today, I thought I’d go back to the beginning… Over the fifteen or so years that Rails has been around, the relationship between Rails and client-side JavaScript has gone in many different directions.

Or: Trust Goes Every Which Way, And Makes Agile Work Previously on Locally Sourced: I attempted to justify all this agile stuff. Before that, more agile stuff. Also, I have a book out, and good marketing practices would suggest I mention that from time to time. This time around, I’m worried that all these words won’t help make the central point: Everybody on a software team should feel included and safe in their work because it’s the right thing to do.

I mean, really… Previously on Locally Sourced: I wrote about an XP practice. Then I wrote about it some more. Then I wrote about a different XP practice. Then I wrote about it some more. (Okay, it’s a bit of a stretch, but a domain metaphor was an XP practice, and OO modeling went hand in hand.) In any case, with more about Agile and XP coming up, I thought it was time for some self-justification.

Maybe more about the past than you needed to know? Previously on Locally Sourced: I wrote about kinds of object-oriented design. Before that, I asked why you hired that test. I didn’t exactly set out to write 1300 words on the history of OO design, but I pulled out some old books and got nostalgic. Tune in next week for more on Agile, communication, and inclusion. As I was writing the last post, I started skimming through a couple of my Object-Oriented textbooks from the mid-90s.

Who doesn’t love a taxonomy? Previously on Locally Sourced: We talked about test speed, and we asked why you hired that test? If you like this kind of thing, tell a friend or colleague. One thing that I see a lot in online discussion of programming styles is the idea that Object-Oriented Programming is just one thing that you either do, or don’t do. I think that’s reductive, and not just because different languages encourage different structures in objects.

Previously On Locally Sourced: The Entropy Essays are a series of essays about how programming practices inspired by Extreme Programming such as testing, pair programing, and object-oriented design play out on modern web projects. The first one was about test speed. And eventually we’ll get to why they are called Entropy Essays. I want you to stop for a second and think: “why are you writing this test?” Not “why are you writing tests in general?

Yes, I really do need 700 LEGO bricks in order to flip that light switch… Program note: This essay is timed to the release of the draft-complete beta of Modern Front-End Programming with Rails. They won’t all be about the book, promise. (There will be one or two more about the book). There will be more Entropy Essays in the future about testing, object-oriented design, pairing, and so on… Something interesting happened as I was finishing up the book.

Speed matters. But not precisely. There are only two things that matter when thinking about the speed of your automated tests: How fast can you run the relevant set of tests to let the tests be helpful in development? How fast can you run a complete, green build for deploy? We’re talking about the first one in this essay. In development, you want to be able to run the tests you are writing and a subset of tests that are most likely to break based on your changes.

About, oh, eight or nine years ago, I decided I needed a personal website. On the theory that I didn’t want to become a full-time personal website wrangler, I decided to put the site on Squarespace. Squarespace was a great service, and a very well thought out set of tools but over time, it’s become less well suited for my (admittedly minimal) needs: Squarespace costs some money. When I started this site, it was at least theoretically a portal to self-published books.

Books That Made Me Happy 2019 Here’s big old book list for 2019. I did something very weird and nerdy this year. Rather than group the books by type, I just rank them. (I actually kind of rank them every year, but I don’t normally use the ranking in this post because I don’t want it to seem like a competition). To be extra nerdy, what I did this year was write a short program that randomly picked two books and asked me to compare them, and repeated that over and over, then did various math things to convert all those comparisons into a score and then a ranking.