For some reason, identifier schemes that are global unique, coordination-free, somewhat humanely-representable, and efficiently indexed by databases are a thing I really like. Universally Unique Lexicographically Sortable Identifier (ulid, for humans) is one of those things. Implementations available for dozens of languages! They look like this: 01ARZ3NDEKTSV4RRFFQ69G5FAV. Paul Ford’s website is twenty years old. For… Continue reading Code minutiae, October 23, 2017
Category: Technology
You must be this tall to ride the services
If I were trying to convince myself to extract a (micro)service, today, I’d do it like this. First I’d have a conversation with myself: you are making tactical changes slightly easier at the expense of making strategic changes quite hard; is that really the trade-off you’re after? you must have the operational acumen to provision… Continue reading You must be this tall to ride the services
How methodical and quality might keep up with fast and loose
I’ve previously thought that a developer moving fast and coding loose will always outpace a developer moving methodically and intentionally. Cynically stated, someone making a mess will always make more mess than someone else can clean up or produce offsetting code of The Quality. I’ve recently had luck changing my mindset to “make The Quality… Continue reading How methodical and quality might keep up with fast and loose
One step closer to a good pipeline operator for Ruby
I’ve previously yearned for something like Elm and Elixir’s |> operator in Ruby. Turns out, this clever bit of concision is in Ruby 2.5: object.yield_self {|x| block } → an_object # Yields self to the block and returns the result of the block. class Object def yield_self yield(self) end end I would prefer then or… Continue reading One step closer to a good pipeline operator for Ruby
Strange Loop 2017
I was lucky enough to attend Strange Loop this year. I described the conference to friends as a gathering of minds interested in programming esoterica. The talks I attended were appropriately varied: from very academic slides to illustrated hero’s journeys, from using decomposed mushrooms to create materials to programming GPUs, from JavaScript to Ruby. Gotcha,… Continue reading Strange Loop 2017
exa in 30 seconds
What is it? exa is ls reimagined for modern times, in Rust. And more colorfully. It is nifty, but not life-changing. I mostly still use ls, because muscle memory is strong and its basically the only mildly friendly thing about Unix. How do I do boring old ls things? Spoiler alert: basically the same. ls… Continue reading exa in 30 seconds
Generalization and specialization: more of column A, a little less of column B
Now, I attempt to write in the style of a tweetstorm. But about code. For my website. Not for tweets. For a long time, we have been embracing specialization. It’s taken for granted even more than capitalism. But maybe not as much as the sun rising in the morning From specialization comes modularization, inheritance, microservices,… Continue reading Generalization and specialization: more of column A, a little less of column B
The loungification of luxury cars
High-end luxury cars are starting to resemble first-class airport lounges and it’s bothering me. The Porsche Panamera has a dang tray table. Just about every German luxury car has the option to put an LCD screen on the back of the front seats, for entertainment. Who puts $100k+ down on a car so that someone… Continue reading The loungification of luxury cars
Categorizing and understanding magical code
Sometimes, programmers like to disparage “magical code”. They say magical code is causing their bugs, magical code is offensive to use, magical code is harder to understand, we should try to write “less magical” code. “Wait, what’s magic?”, I hear you say. That’s what I’m here to talk about! (Warning: this post contains an above-average… Continue reading Categorizing and understanding magical code
Untitled
Bias to small, digestible review requests. When possible, try to break down your large refactor into smaller, easier to reason about changes, which can be reviewed in sequence (or better still, orthogonally). When your review request gets bigger than about 400 lines of code, ask yourself if it can be compartmentalized. If everyone is efficient at reviewing code as it is published, there’s no advantage to batching small changes together, and there are distinct disadvantages. The most dangerous outcome of a large review request is that reviewers are unable to sustain focus over many lines, and the code isn’t reviewed well or at all.
This has made code review of big features way more plausible on my current team. Large work is organized into epic branches which have review branches which are individually reviewed. This makes the final merge and review way more tractable.
Your description should tell the story of your change. It should not be an automated list of commits. Instead, you should talk about why you’re making the change, what problem you’re solving, what code you changed, what classes you introduced, how you tested it. The description should tell the reviewers what specific pieces of the change they should take extra care in reviewing.
This is a good start for a style guide ala git commits!
