Noel Rappin Writes Here

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.