Noel Rappin Writes Here

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.