Automagical port allocation for tests

Ceri Storey wrote “It’s quite common to want to test a net­work ser­vice from the out­side, as if it was being ac­cessed from a cli­ent. Quite of­ten, people will pick a “well-­known” port to use, eg: port 8080 or 8888 for a HTTP ser­vice. But that means that if you leave a stray service process lying around, you’ll need to hunt it…”

By Vinnie kaz (Own work) [CC BY-SA 3.0 (], via Wikimedia Commons

Die-hard Statefully

Ceri Storey wrote “After reading Solving the Water Jug Problem from Die Hard 3 with TLA+ and Hy­po­thesis, I figured it’d be amusing to re­pro­duce it in Rust as diehard-rs, along with its quickcheck lib­rary.”

Argot: a lightweight composable test framework for Go

Matthew Sackman wrote “In a current project we’re writing a number of fairly small REST HTTP servers. There are probably going to be around 10 of these in total so I guess that makes these ‘deci-services’. As part of the testing approach, we wanted to be able to write some end-to-end tests and soak tests, and so went…”


Generating Beatnik code

Tom Parker wrote “Beatnik is an esoteric programming language that’s been recently amusing me (as they occasionally do). The core idea is that words in the source code are interpreted as their Scrabble scores, and those scores then do things (mostly involving messing with a stack). This leads then to the possibility of an alternate form of the language,…”

Theatrum Orbis Terrarum, from Wikipedia

Given When Then

Ian Rogers wrote “There are, of course, a large number of techniques described as being The Way To Do Software Engineering. I’m sure I’ve not come across them all but the ones I know about and use currently include at least: Impact mapping, Pert charts, Gantt charts, Personas, Wardley mapping, Agile, DSDM, MoSCoW, SMART, INVEST and BDD (I’ve…”

Sturmfront auf Doppler-Radar-Schirm, public domain, von

Adventures in TCP latency measurement

Ceri Storey wrote “Re­cently, Google have pub­lished an art­icle on BRR, an al­gorithm that ex­pli­citly meas­ures the round-trip latency and band­width ca­pa­city of the link between two ma­chines (be it in a data­center, or a mo­bile phone) to avoid sending more traffic than is use­ful, causing queues to build up in the net­work that need­lessly in­crease latency. So…”

By John Ficara (This image is from the FEMA Photo Library.) [Public domain], via Wikimedia Commons

Testing as question asking or Hypothesis Driven Development

Ceri Storey wrote “So, my co-worker Ian asks the question “Why bother testing?”. I think that an under-considered question is how we think about testing. I would wager, that a sizable majority of programmers (myself included) will usually learn one or two techniques for testing, and then gravitated towards those same set of answers for most problems. As…”

Thanks to for photo

Programming is not a Performance

Ian Rogers wrote “Programming is more like writing a novel then executing a performance. No I don’t mean the likes of If Hemingway Wrote JavaScript  – I mean, apart from ridiculous job interviews involving a whiteboard and pen  (NB. LShift never does that) coding is very unlikely to be a performance in an instant of time. Usually when…”

By USDAgov [CC BY 2.0 (], via Wikimedia Commons

Elm: Any good?

Tim Band wrote “I love Haskell. But, like many people who love Haskell, I don’t use it for very much. Wouldn’t it be nice to have the nice properties of Haskell (the compiler checks that your code makes sense before you run it, Quickcheck-style testing, pure functions) but produce production-quality Javascript for client-side web programming? The most tantalising…”

Why bother testing?

Ian Rogers wrote “It’d be nice to be able to make a definitive case for the benefits of software tests, but I can’t due to this one question: Is it possible to prove the correctness of a program using tests? The answer is unfortunately “no of course not” and I’ll show why below. But all is not lost…”