Noel Rappin Writes Here

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.

Some thoughts about my new laptop about two weeks in, which I gather I’m supposed to hate, but which so far I persist in kind of liking. I think it’s a little bit about expectations and what’s being replaced. So I got the higher-end 13 inch MacBook Pro, with the touch strip, with a bigger SSD, but without the chip upgrades. It’s replacing a 2012 15 inch MBP that was definitely showing its age, with a screen that ghosts and dwindling battery life.

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.

I noticed that I didn’t have a copy of the Boring Software Manifesto on my own site, so here’s the original version from 2007 (yikes!) and a video version from 2013. Several years ago, I coined the phrase The Boring Software Development Process, in response to a former employer where project management really didn’t think anything was happening unless we were trying to solve seven crises simultaneously. The manifesto goes like this:

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.

I haven’t written about my writing setup, tools, things like that in a while, and I’ve got some show and tell. Here’s my current mobile writing setup – really, my preferred writing setup if I’m not coding or otherwise doing something that requires a full operating system. That’s an iPad Air 2, the Logitech Keys-To-Go keyboard, and a Kanex plastic stand that you can only kind of see. Why do I like this setup:

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.

The Week of Me A couple of quick things. The Web Payment book is out for 50% review, which means that the draft is about half complete, and about a dozen or so people, including the publisher, will be the first readers (well, I guess it got an editorial review at the ⅓ mark). This is a little terrifying. I did a quick breakfast talk this week on trust and projects.

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.

This week’s things are a little late because of thing one. Quick me update: I did post one item to Medium this week, about how I learned to love Rubocop. Read it, won’t you? Thing One: RailsConf RailsConf was this week, and despite what I might have said last week, it really does feel different in 2016 than 2008. I’ll post some specific talk recommendations when the videos are posted. Well, there’s one talk up already Justin Searls posted his own recording, and what was ostensibly a talk about Rails 5 and RSpec becomes something more interesting about maturity in tools and where we go from there.

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.

Five For 4/29 Okay, I really am doing this for a second week in a row, even though it’s a bit late. The week in me: The web payments book is continuing slowly. Currently, I’m writing about how to set up administrative users, which I’m convinced that most people are penny-wise and pound-foolish about. (“It’s the admin users, we can train them”, yeah, I’ve said it too). I also did a medium post about agile, communication, and the like, which doesn’t seem to have gotten out there much, but you should probably read it anyway.

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.

Let’s try something new this week. At least new for me. If, by new, you mean, “haven’t done it in few years”. Five Things From, listened to, or encountered that I want to pass along. The “five” is more of a guideline than a rule. We’ll see how long this keeps up: First, A Word From Our Sponsor That’s me, I’m the sponsor. This week’s Medium post is a comparison between my first RailsConf in 2008 and this years’ through the simple expedient of making you guess which talk titles come from which year.

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.

This week’s Medium post is In Defense of Pretty Lies. It’s about all our favorite pretty, lying tools, like Haml, or ActiveRecord, and why I love them anyway.

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.

I really did want to get this done sooner, but I didn’t. See part one for the other books I liked in 2015. Consider this the books I really liked. You could call it a top ten, but there’s more than 10. But still, my absolute favorite books of 2015, alphabetically by title. Ancillary Mercy, by Ann Leckie In trilogies, first books get to have all the fun. The first book is where you get the full thrill of discovery, of learning about a new thing.

Thanks to the literally one person who encouraged this list last year, I’m presenting the 2015 list of books I liked. Last year, I split between Fantasy Books I Liked and SF Books I Liked. This year, the split didn’t work out evenly, so I have “Books I Liked”, and “Books I Liked Even More”. Here’s the first batch: “Books I Liked in 2015”. First, the Books I Liked. Well, not all of them, but especially the ones I thought I could write an interesting paragraph about.