A bell'n'whistle toggle through environment variables


The usual way to control a script's behaviour is to provide a config file or command line arguments at startup. Actually, it's also common to modify the script's code, typically after executing it and noticing it's not doing the right thing. Neither of these are very convenient when you are including the script somewhere else. This post is about the third way, its curious advantages, and how it's usually epically bad but sometimes it isn't.

Continue reading A bell'n'whistle toggle through environment variables...

Testing Bash scripts and what is testing even for


An externally facing application is tested before delivery to assure it meets expectations placed in it. Uncle Bob is sternly clear that you're really not doing a good job if you don't have an automated means of doing that. This of course assumes you care about the expectations people place in your software, but (even outside the commercial setting where people try to get others to pay for their work) disputing that assumption is only allowed in what my friend calls a "philosophical free-for-all" - perhaps you are the Rothko of coders demonstrating that software having to do something is just another assumption to be challenged, or another V the cloaked renegade directing an orchestra of humming fans and creaking CPUs.

When you're employed on a large software development project, you gotta write tests, maybe even before you write the code, and then you gotta submit pull requests, and there will be tools checking that you wrote enough tests, and that they pass. In a less hip but equally large environment, like a bank, you still you gotta run tests, and e.g. attach their results in a spreadsheet.

At Expression Atlas, I did some work on the experiment import pipeline. I could choose how many tests to write, and it wasn't typical to write tests, but I believe it's quite neat that I did.

Continue reading Testing Bash scripts and what is testing even for...

Our Enterprise's Finest Software Solutions


There is a big idea out there in the startup world that you should build a Minimum Viable Product, e.g. The Lean Startup tells you to do that. The general principle is to put together an unpolished product that is the core of your idea, presumably get someone to use it, and iterate from there. This is sometimes confused with a prototype or a demo that you put together and show to investors, or only manifests itself with the founders' idea that they need to build something.

Surprisingly, I have encountered very similar strategies during my short but thrilling early career in an investment bank. As teams tried to navigate the complex landscape of random requirements, unclear priorities - my boss's boss's boss actually ordained during a yearly town hall that we should be prioritising stability while delivering on new features - and random interruptions of "we can't deploy software because there's gonna be an announcement by a central bank and lots of trading" or "we can't hire anyone this quarter, because we didn't make enough money in Japan" - anyway, I'm rambling. People still got stuff done, thanks to the MVP principle: do most of what you have to do with the limited means available to you, i.e. the minimum viable effort that still gets you a promotion. I will share a couple of examples: may you find them educative and inspiring.

Continue reading Our Enterprise's Finest Software Solutions...