Welcome to my PinkLetter. A short, weekly, technology-agnostic, and pink newsletter where we cultivate timeless skills about web development.
My Ramblings This Week
How do you generate a random string? Put a first year Computer Science student in Vim and ask them to save and exit.
Ahem...
Have you ever heard the following quote?
Everybody has a plan until they get punched in the face.
Mike Tyson
On Monday, I pulled a ticket and got excited. It wasn't another bug or a fire to extinguish. It was a brand new feature!
"Hell yeah, I'm going to TDD the shit out of it," I told myself. My brain skipped ahead and started sending test cases to my fingers. I fired up the editor, and...
I got punched in the face.
I was looking at the worst spaghetti legacy mess ever with two choices: edit and pray (without testing) or doing the right (annoying) thing.
For a second, I abandoned myself in the comfort of writing a hack and calling it a day. Except, the pain down the line would have become insufferable. That code has both high churn and complexity: it's a ticking bomb. I better started defusing it.
But how to TDD such a mess? It's straightforward to test-first a green field scenario. Here, I was constrained by the current legacy logic, and the only way to know what to do was to do it.
Years ago, Przemek showed me a trick that stayed with me forever.
First, spike some code. Regardless of how wrong, we all have a mental model of how code works. In this phase, we want to test our assumptions, understand where and what code to change, and how to inject the new code.
Second, spike some more code. When code is that bad, the first spike won't do it. Keep iterating until you understand it well and it works.
Third, deploy... Nope, please don't do that.
Third, save the diff in a file (git diff > ~/path/to/spike.diff), and remove the spike (git checkout -- .). This is painful, but you are in a much better place now: you know what to code
Fourth, TDD the diff back.
I lost count of how many times this trick saved my ass!
Elsewhere on the Web
Saving a Tree in Postgres Using LTREE by Pat Shaughnessy
LTREE allows me to save, query on and manipulate trees or hierarchical data structures using a relational database table. As we’ll see, using LTREE I can count leaves, cut off branches, and climb up and down trees easily - all using SQL right inside my application’s existing Postgres database!
(Riccardo: Damn, this would have been excellent in a previous project of mine. Be sure to check out the entire series and the official docs.)
Free Course On Functional Programming in Haskell by Nikos Vaggalis
Videos from an introductory course by Professor Graham Hutton from the University of Nottingham have been made freely available on YouTube. Designed for first year Computer Science students, they teach the basic principles of functional programming using Haskell.
(Riccardo: I learned Haskell reading Programming in Haskell by Graham Hutton. I'm glad to see the it's available in video now.)
PureScript by Example by Phil Freeman
PureScript is a small strongly, statically typed programming language with expressive types, written in and inspired by Haskell, and compiling to Javascript.
Functional programming in JavaScript has seen quite a lot of popularity recently, but large-scale application development is hindered by the lack of a disciplined environment in which to write code. PureScript aims to solve that problem by bringing the power of strongly-typed functional programming to the world of JavaScript development.
This book will show you how to get started with the PureScript programming language, from the basics (setting up a development environment) to the advanced.
(Riccardo: I was baptized into hardcore functional programming by this book. It was probably not the most gentle introduction—it took me months to finish, but it taught me a ton.)