Noel Rappin Writes Here

2016/05

The Boring Software Manifesto

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:

Sharp Knives and Safe Handles

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 love my Mobile Writing Setup

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:

RSpec and Rails Are Mocking Me

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.

This Week In Stuff I Really Want You To Look At: May 16, 2016

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.

Speaker Notes

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.

RailsConf 2016 and other things to look at this week

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.

How I Learned To Love Rubocop

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.



Copyright 2024 Noel Rappin

All opinions and thoughts expressed or shared in this article or post are my own and are independent of and should not be attributed to my current employer, Chime Financial, Inc., or its subsidiaries.