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.

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.

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.

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