Don’t video player controls seem dumb?

Desktop and web-based players alike allow the user to jump forwards or backwards by 5 or 10 seconds, or possibly speed up and slow down playback. These controls operate identically no matter what the user is watching – there’s no connection between the content of the video, and the controls.

DVDs were the first format I know of that allowed you to skip via chapters, but even something as basic as those coarse-grained content-aware controls aren’t available in things like YouTube videos today.

Here’s an idea for how to identify the salient points in a video that a user might want to skip to: the good news is that this could all be done automatically, and with very little overhead; I’ll leave the bad news to the end!

One of the main reasons InnoDB is the go-to choice for our MySQL tables is that it supports row-level locking1. This means that as we’re reading from and writing to a table, we don’t need to wait for all the other processes to finish up their work before we can get access to that table.

For larger tables, this ability to have multiple processes working on the same table at the same time is almost essential to get any level of decent performance, for most workloads.

However, we recently ran into a problem where – because of a detail of how InnoDB and MySQL work – we ended up doing table-level locking rather than row-level, with disastrous results.

I stepped through this guide for a Hello World app running on Google Cloud Platform. How quickly can you get something working, and how convenient would it be to use longer-term?

In doing so, I confirmed GCP doesn’t make use of Erlang’s hot code reloading when re-deploying apps, but how important is that?

I’m fortunate to enjoy my job. I hope you do too. Figuring out clever solutions to difficult problems is innately satisfying. However, I’ve always felt a yearning for various hobbies and side projects to augment the gratification I get from my work.

I recently gained some clarity about this yearning: what it is we are looking for, and why it’s important. Hopefully there’s something here that strikes a chord with you, and is of use.

I recently came across a discussion on Reddit concerning take-home tests as part of an interview process. Is it was acceptable for companies to ask candidates to work on a problem in their own time, so that their submitted solution helps decide whether to move forwards to an on-site interview?

The level of antipathy towards take-home tests in that discussion was an enormous surprise. The majority of commenters were not just against the idea, but virulently so, railing against it as another example of unreasonable demands made on candidates. Most people viewed these tests as a waste of time, rude, disrespectful, or a combination of all three. I think there was only one person whose opinion wasn’t negative, and even that was ambivalent at best.

I have been asked to do take-home tests in the past, and did see that if poorly conceived and executed they can be a bad experience for the candidate. However, if they’re approached in a thoughtful and careful way, they’re one of the best tools for effective interviewing. Here’s what I think does—and doesn’t—work.

I’m currently learning Catalan and Spanish, and am reminded every day of the languages’ shared ancestor by how often they share similar (or identical) words.

For example, it’s easy to deduce that introducción (in Spanish) means the same as introducció (in Catalan), or that respuesta and resposta are the same thing.

In fact, when you look at the Spanish and Catalan words next to each other, it seems that the same kinds of transformations crop up again and again: consonants becoming repeated, vowels being dropped off the ends of words, stressed vowels changing in predictable ways, …

Of course, the languages are very different and often use completely distinct words, but it got me thinking: how reliably can we guess a Catalan word from a Spanish one, using just a small set of simple transformations?

The first step of my swamp cooler project is to figure out the construction of the evaporative cooling vessel.

I’d like to use an upturned terracotta pot for the vessel itself, with air entering at the bottom, passing up the inside and out the drainage hole at the top.

Unlike the Cold Pot – which pushes air through a dry aluminium sleeve – I’m trying to maximise the surface area of wet terracotta which the incoming air passes over before emerging from the exhaust.

I was just writing some code which parses a URL in order to extract a piece of the path. When working correctly, the code under test takes a URL something like this: http://site.com/.well-known/pki-validation/4b1706977f59ffe3c1ddf282bbee6f45.txt … and returns just the hash-like part of the path: 4b1706977f59ffe3c1ddf282bbee6f45. Creating factories to effectively test it was surprisingly fiddly! Here are the options I considered and what worked for me – in the hope it’s of some use to you.

It has been hot here recently in Catalunya. Like 40°C and forest-fires-covering-our-patio-in-ash hot.

Luckily, the house is traditionally constructed with extremely thick, solid stone walls which means the worst of the heat doesn’t make it inside – so long as we remember to shut the windows. Even so, a little extra help to keep the temperature down during the day would be very welcome.

Much has been written about the deep cultural significance that orderly queueing holds for the Briton. The opportunities it offers to display impeccable manners – and scowl at interlopers – are so rich that I’ve lost count of the number of serious, extended conversations I’ve had about the do’s and don’ts, the Ps and Qs, of waiting for service.

As a programmer, though, it’s also interesting that there are clear parallels between core data structures found in computer science and the approaches to queueing found around the world.

At Teespring we have quarterly hackathons. We all throw suggestions into a melting-pot of ideas in the run-up to the event, with the most promising, most interesting, and most popular suggestions graduating to be hacked upon by a small team for a couple of days.

At the moment – and for the foreseeable future – the power balance of hiring negotiations favours the engineering candidates rather than with the hiring company. One consequence of this is that any attempt to hurry, strong-arm, or manipulate candidates will likely be ineffective, and could potentially backfire horribly.

This is how I became one such backfire.

I was recently asked:

what’s the worst project you ever worked on?

After a quick scan through my mental graveyard of half-finished, half-assed ideas too embarrassing for me to dignify with a link here, I settled upon my first job out of university.

I was always told to prize gifts that people had put time and effort into. Hoping my SO shared the same view, I decided to make her a little something for her birthday.

Being creatively barren, I attempted plagiarism. I remembered seeing this Kickstarter project ages ago. It’s based on an old parlour game: the idea is to conceal little messages inside a nice-looking block, to be popped out with a pencil when the recipient feels like it.

James Brady

I’m a software engineer by trade and an woodworker for fun. I like hard problems and learning new things with which solve them. I’m learning to speak Catalan. I like hiking in, up, and around vertiginous scenery. I play the trumpet poorly. That is all.

Oristà: a teeny tiny village in Catalunya