Noel Rappin Writes Here

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.

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: General References Small, Sharp, Software Tools by Brian Hogan is still in beta but looks to be a good reference to Unix command line things. Which still can be useful, even if I don’t think they are the be-all and end-all.

Truinboy: https://flic.kr/p/5pkYiv 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.

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) What are System tests? 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 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. This week on the podcast, Corey Haines and I talk about Elm. You should listen to it. 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.

Five Things Give Or Take Two JS I’ve been working in JavaScript on and off basically since JavaScript was invented, I even kind of wrote a book on it, and I still find the current ecosystem kind of bewildering. Ben McCormick wrote a nice essay about Ten Things A Serious JavaScript Developer Should Learn, which is based on a Reddit thread that is maybe a little too much noise-to-signal (shocking, I know).

This is the weekly newsletter for the Tech Done Right podcast. If you like this newsletter or have other comments, email me at techdoneright@tablexi.com. And tell your friends to subscribe at http://techdoneright.io/newsletter. Five Things Give Or Take Two RIP DBC 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.

You probably don’t need an actual ledger to measure the costs and benefits of your tests (This is a sidebar to an email course called Noel Rappin’s Testing Journal that you can sign up for here. It relates to the content of the email course, but didn’t quite fit in. If you like this post, you’ll probably also find the course valuable. You can also hear me discuss similar topics with Justin Searls and Sam Phippen on an episode of the Tech Done Right podcast.

It’s the one and only Slimey Worm from Sesame Street! When you write a new feature using a Test-Driven Development process you start out with a simple test, often creating an instance and calling a method on it: If you are strictly following TDD, you’ll try to write the simplest code that could pass the test, so your first code that passes the test might look like this. The code has no real logic, but it does pass the test, by just returning the expected value as a constant.

You want to avoid abandoned shopping carts. (Photo via LookAfterYourself) My book Take My Money: Accepting Payments on the Web is about — wait for it — accepting payments on the web. Although the thrust of the book is dealing with all the complexity of managing money, we do talk about the user experience of interacting with a payment process. Specifically, the book shows how to set up a shopping cart for users to hold on to items they want to buy.

The Testing Pyramid, from Rails 4 Test Prescriptions It’s time for “Ask A Tester Person”, a game I haven’t played in a long time. I got a question on Twitter (several weeks ago, actually… but better late than never, right? Right?): I am, as a Rails junior, also confused about changes in controller testing I guess that’s technically not a question, but we’ll consider to the question to be “What the hell is up with controller testing in Rails?

This is not exactly what the code in question looked like I had a unique career experience this year. After watching this really quite fantastic RailsConf talk from Katrina Owen, I asked if she’d be interested in doing a full-day refactoring workshop for the Table XI developer team. Katrina agreed, and we decided that she would put together a workshop based on refactoring some of our actual client code. I had just the project in mind, and had her look at some specific examples.

It’s a stream, kind of I was reading the ActiveAdmin docs, as one does, when I read that ActiveAdmin, by default, streams CSV data when you request it from your browser, rather than sending it all in one chunk. This means that the Rails server can start sending the CSV data to the client while the file is still being generated. This can make the response much faster. (True fact, I was reading it for my mega-hot best seller Take My Money: Accepting Payments on The Web.

I love this cover, by the way. My new book, Take My Money: Accepting Payments on the Web, is available today. If you have a Rails application that touches money, this book will help you. I hope that this book will help you build your payment application with less stress and fewer mistakes. Here’s why I wrote it: My favorite books and blog posts to write are the ones that I wish I had been able to read when I was starting a new project.

Yikes! So I was giving my talk at Madison Ruby: Epilogue, or “this really is the last one, we mean it everybody”. Watch the whole talk, about doing HR in small consulting shops. About five minutes in I was making a very incisive point about annual reviews when: Gravity is very effective And suddenly, nobody remembers my incisive point about annual reviews. (Which was, for the record, that editing them for a year is kind of soul-destroying, even if everybody involved is basically nice and good at their jobs.

RSpec has options that will help you see your specs more clearly RSpec is a big library and the way you use it makes a big difference in how efficiently you can run specs. It has a lot of default configuration options that are generated when your application is created, but if your application is older than a few months, it’s likely there are some new and useful configuration options that you might like to add.

All your blocks should have whitespace… After two blog posts where I was very non-doctrinaire about really big topics, today I’m going to be absurdly doctrinaire about something trivial. Yep, it’s The Continuing Adventures of the Person Who Cares A Little Too Much About Whitespace. There are about four things that I do which appear to be different from the work setup of nearly every other developer I’ve ever worked with:

It’s my software stack, with complexity! It’s not an unusual observation that there are two major philosophies about designing Rails applications, sometimes called the “Core” and “Prime” stacks. (Specifically, the name Prime stack comes from Steve Klabnik, though he calls the main stake the “Omakase Stack”, from DHH’s Rails is Omakase post) The Core stack is based on the way the Rails core team recommends Rails should be used, and is how Basecamp uses Rails, at least based on David Heinemeier Hansson’s public descriptions.

The testing cycle goes from red to green to red to green One of Kent Beck’s first articles about unit testing is called Test Infected: Programmers Love Writing Tests. It was written, I think, in 1998. What’s interesting about the Test Infected article is how Kent describes the process: “code a little, test a little, code a little, test a little”. Which is backwards. Or not-backwards, depending on your perspective, but in any case, it’s not the TDD process that Kent would eventually describe in the XP book, among other places.

These knives all have handles The first time I was in a programming debate that used the argument “I want a sharp knife”, my friend was arguing that real programmers wrote C and accessed memory directly. I was arguing for Java as the easier, if less flexible, solution. One generation’s sharp knife is the next generation’s whirling machete blade. The phrase “sharp knife” has been bouncing through the Rails community the last day or so.

This post is about a very small Rails design decision. A Rails design decision that I’ve made over and over without thinking about it. You probably have, too. And then a weird test failure made me think about it. And then it made me overthink it. Let me explain. I like the idea of writing Rails code such that there is minimal logic in ActiveRecord classes, and then writing a lot of tests that don’t need to touch the database, and therefore run fast.

After coming back from RailsConf, I have some tips about speaking at conferences. Which isn’t really a comment on the speakers I saw — I think, overall, the quality of the speakers has improved noticeably over the years — but more along the the lines of tips for people getting started. None of this is a hard-and-fast rule, the most important thing is to speak about something that you find important and interesting, and do so in a way that makes your excitement apparent to the audience.

As you may know, I’m a, shall we say, older programmer, and as such I’ve developed very strong, quasi-rational opinions over details like indentation and parenthesis. I even wrote a Ruby Style Guide once. (I think I even still believe nearly all of it). And while, I’m traditionally a live-and-let live kind of guy, woe unto the person who comes into my codebase and starts moving stuff around. So when a co-worker suggested we add Rubocop to all our projects at Table XI, I was… skeptical.

Looking at it very abstractly, the time a software team spends on a project goes into one of three buckets. Actually writing the correct code. Rewriting code, either because of bugs, miscommunication, or changing requirements. “Process”, by which I mean all the other stuff a team does to share the status of the project with each other. The size of the first bucket is dependent only on the size of the problem itself, although the problem is that it’s hard to predict the contents of that bucket in advance.

Here’s a quiz: I went back to the online program for RailsConf 2008, which was the first one I attended. Here are 20 talk titles. Some are from the 2008 program, some are from the 2016 program. Can you guess which is which? “Your First Legacy Codebase” “Level-up Your ActiveRecord Skills: Learn SQL” “The Rails Boot Process” “3x Rails: Tuning The Framework Internals” “Testing Rails at Scale” “Entrepreneurs on Rails” “Multi-Core Hysteria FUD about CRUD” “Surviving The Big Rewrite: Moving to Rails” “10 Things I Hate About Web Apps” “Crud Doesn’t Have an S: Managing Complex Searching in Rails” “How to Get and Love Your First Rails Job” “Managing Growing Pains: Thinking Big While Being Small” “Can Time-Travel Keep You From Blowing Up The Enterprise?

I’ve seen kind of an uptick of comments recently about how tools such as Haml, Sass, CoffeeScript, and ActiveRecord are supposed to be abstractions but are nothing but a big stack of lies, lies lies! The argument, which I may be oversimplifying, is while that these technologies purport to be helpful abstractions they are in fact just a pretty coat of paint that prevents us from using the full power of the underlying tool.

There’s been some discussion this week about the TSA’s airport security randomizer app, which you probably remember as being that thing being held by a bored TSA agent that would point an arrow left or right to tell you which security line to go to. A freedom of information request determined that the app, written by IBM, cost the government about $47,000. This Article suggests the randomizer was part of a $1.

At our current size, Table XI is in an interesting place. We’re still small enough that everybody can fit in a single room, but large enough that people on different teams don’t always know what everyone else is doing. However, trying to let everybody know what’s going on often leads to problems similar to bad agile standups. Everybody is waiting for their turn to speak; nobody is listening to everybody; everybody is bored.