2016/04
Five Things: April 29, 2016
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.
Taking Small Steps
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.
Five Things From: The Week of April 22, 2016
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.
RailsConf 2008 vs 2016
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?
In Defense of Pretty Lies
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.
On Medium: A defense of Pretty Lies
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.
The End Result Is Not The Cost
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.