“Your team is only as good as your weakest reviewer.”
Giving better code reviews
This is a repost promoting content originally published elsewhere. See more things Dan's reposted.
Tag: programming
DRY: Do Repeat Yourself
This is a repost promoting content originally published elsewhere. See more things Dan's reposted.
I am increasingly of the opinion that the general software engineering adage “Don’t Repeat Yourself” does not always apply to web development. Also, I found that web development classes in CS academia are not very realistic. These two problems turn out to have the same root cause: a lack of appreciation of what browsers do…
DevCamp – have we really been doing this for 7 years?
An annual tradition at Three Rings is DevCamp, an event that borrows from the “hackathon” concept and expands it to a week-long code-producing factory for the volunteers of the Three Rings development team. Motivating volunteers is a very different game to motivating paid employees: you can’t offer to pay them more for working harder nor threaten to stop paying them if they don’t work hard enough, so it’s necessary to tap in to whatever it is that drives them to be a volunteer, and help them get more of that out of their volunteering.
At least part of what appeals to all of our developers is a sense of achievement – of producing something that has practical value – as well as of learning new things, applying what they’ve learned, and having a degree of control over the parts of the project they contribute most-directly to. Incidentally, these are the same things that motivate paid developers, too, if a Google search for studies on the subject is to believed. It’s just that employers are rarely able to willing to offer all of those things (and even if they can, you can’t use them to pay your mortgage), so they have to put money on the table too. With my team at Three Rings, I don’t have money to give them, so I have to make up for it with a surplus of those things that developers actually want.
It seems strange to me in hindsight that for the last seven years I’ve spent a week of my year taking leave from my day job in order to work longer, harder, and unpaid for a voluntary project… but that I haven’t yet blogged about it. Over the same timescale I’ve spent about twice as long at DevCamp than I have, for example, skiing, yet I’ve managed to knock out several blog posts on that subject. Part of that might be borne out of the secretive nature of Three Rings, especially in its early days (when involvement with Three Rings pretty-much fingered you as being a Nightline volunteer, which was frowned upon), but nowadays we’ve got a couple of dozen volunteers with backgrounds in a variety of organisations: and many of those of us that ever were Nightliner volunteers have long since graduated and moved-on to other volunteering work besides.
Part of the motivation – one of the perks of being a Three Rings developer – for me at least, is DevCamp itself. Because it’s an opportunity to drop all of my “day job” stuff for a week, go to some beatiful far-flung corner of the country, and (between early-morning geocaching/hiking expeditions and late night drinking tomfoolery) get to spend long days contributing to something awesome. And hanging out with like-minded people while I do so. I like I good hackathon of any variety, but I love me some Three Rings DevCamp!
So yeah: DevCamp is awesome. It’s more than a little different than those days back in 2003 when I wrote all the code and Kit worked hard at distracting me with facts about the laws of Hawaii – for the majority of DevCamp 2016 we had half a dozen developers plus two documentation writers in attendance! – but it’s still fundamentally about the same thing: producing a piece of software that helps about 25,000 volunteers do amazing things and make the world a better place. We’ve collectively given tens, maybe hundreds of thousands of hours of time in developing and supporting it, but that in turn has helped to streamline the organisation of about 16 million person-hours of other volunteering.
So that’s nice.
Oh, and I was delighted that one of my contributions this DevCamp was that I’ve finally gotten around to expanding the functionality of the “gender” property so that there are now more than three options. That’s almost more-exciting than the geocaches. Almost.
Edit: added a missing word in the sentence about how much time our volunteers had given, making it both more-believable and more-impressive.
Twee2 – Interactive Fiction Authoring for Geeks
There’s a wonderful tool for making web-based “choose your own adventure”-type games, called Twine. One of the best things about it is that it’s so accessible: if you wanted to, you could be underway writing your first ever story with it in about 5 minutes from now, without installing anything at all, and when it was done you could publish it on the web and it would just work.
But the problem with Twine is that, in its latest and best versions, you’re trapped into using the Twine IDE. The Twine IDE is an easy-to-use, highly visual, ‘drag-and-drop’ interface for making interactive stories. Which is probably great if you’re into IDEs or if you don’t “know better”… but for those of us who prefer to do our writing in a nice clean, empty text editor like Sublime or TextMate or to script/automate our builds, it’s just frustrating to lose access to the tools we love. Plus, highly-visual IDEs make it notoriously hard to collaborate with other authors on the same work without simply passing it back and forwards between you: unless they’ve been built with this goal in mind, you generally can’t have two people working in the same file at the same time.
Earlier versions of Twine had a command-line tool called Twee that perfectly filled this gap. But the shiny new versions don’t. That’s where I came in.
In that way that people who know me are probably used to by now, I was very-slightly unsatisfied with one aspect of an otherwise fantastic product and decided that the correct course of action was to reimplement it myself. So that’s how, a few weeks ago, I came to release Twee2.
If you’re interested in writing your own “Choose Your Own Adventure”-type interactive fiction, whether for the world or just for friends, but you find user-friendly IDEs like Twine limiting (or you just prefer a good old-fashioned text editor), then give Twee2 a go. I’ve written a simple 2-minute tutorial to get you started, it works on Windows, MacOS, Linux, and just-about everything else, and it’s completely open-source if you’d like to expand or change it yourself.
(there are further discussions about the concept and my tool on Reddit here, here, here and here, and on the Twinery forums here, here and here)
Non-Rails Frameworks in Ruby: Cuba, Sinatra, Padrino, Lotus
This is a repost promoting content originally published elsewhere. See more things Dan's reposted.
It’s common for a Ruby developer to describe themselves as a Rails developer. It’s also common for someone’s entire Ruby experience to be through Rails. Rails began in 2003 by David Heinemeier Hansson, quickly becoming the most popular web framework and also serving as an introduction to Ruby for many developers.
Rails is great. I use it every day for my job, it was my introduction to Ruby, and this is the most fun I’ve ever had as a developer. That being said, there are a number of great framework options out there that aren’t Rails.
This article intends to highlight the differences between Cuba, Sinatra, Padrino, Lotus, and how they compare to or differ from Rails. Let’s have a look at some Non-Rails Frameworks in Ruby.
Calculating Pi (when you’re ill)
So, I’ve not been well lately. And because a few days lying on my back with insufficient mental stimulation is a quick route to insanity for me, I’ve been trying to spend my most-conscious moment doing things that keep my brain ticking over. And that’s how I ended up calculating pi.
Pi (or π) is, of course, the ratio of the circumference of a circle to its diameter, for every circle. You’ll probably have learned it in school as 3.14, 3.142, or 3.14159, unless you were one of those creepy kids who tried to memorise a lot more digits. Over the years, we’ve been able to calculate it to increasing precision, and although there’s no practical or theoretical reason that we need to know it beyond the 32 digits worked out by Ludolph van Ceulen in the 16th Century, it’s still a fascinating topic that attracts research and debate.
Most of the computer-based systems we use today are hard to explain, but there’s a really fun computer-based experimental method that can be used to estimate the value of pi that I’m going to share with you. As I’ve been stuck in bed (and often asleep) for the last few days, I’ve not been able to do much productive work, but I have found myself able to implement an example of how to calculate pi. Recovery like a nerd, am I right?
Remember in school, when you’ll have learned that the formula to describe a circle (of radius 1) on a cartesian coordinate system is x2 + y2 = 1? Well you can work this backwards, too: if you have a point on a grid, (x,y), then you can tell whether it’s inside or outside that circle. If x2 + y2 < 1, it’s inside, and if x2 + y2 > 1, it’s outside. Meanwhile, the difference between the area of a circle and the area of a square that exactly contains it is π/4.
Take those two facts together and you can develop an experimental way to determine pi, called a Monte Carlo method. Take a circle of radius 1 inside a square that exactly contains it. Then randomly choose points within the square. Statistically speaking, these random points have a π/4 chance of occurring within the circle (rather than outside it). So if we take the number of points that lie within the circle, divide that by the total number of points, and then multiply by 4, we should get something that approaches the value of pi. You could even do it by hand!
The software illustration I’ve written is raw JavaScript, HTML, and SVG, and should work in any modern web browser (though it can get a little slow once it’s drawn a few thousand points!). Give it a go, here! When you go to that page, your browser will start drawing dots at random points, colouring them red if the sum of the squares of their coordinates is less than 1, which is the radius of the circle (and the width of the square that encompasses it). As it goes along, it uses the formula I described above to approximate the value of pi. You’ll probably get as far as 3.14 before you get bored, but there’s no reason that this method couldn’t be used to go as far as you like: it’s not the best tool for the job, but it’s super-easy to understand and explain.
Oh, and it’s all completely open-source, so you’re welcome to take it and do with it what you wish. Turn off the graphical output to make it run faster, and see if you can get an accurate approximation to 5 digits of pi! Or slow it down so you can see how the appearance of each and every point affects the calculation. Or adapt it into a teaching tool and show your maths students one way that pi can be derived experimentally. It’s all yours: have fun.
And I’ll update you on my health at some other point.
I THINK there might be a bug in my current development version…
This link was originally posted to /r/MegaMegaMonitor. See more things from Dan's Reddit account.
The original link was: http://i.imgur.com/KxcrKsY.png
An idea to help MegaMen find one another more easily in the big wide world of Reddit. What do you think?
This self-post was originally posted to /r/MegaManlounge. See more things from Dan's Reddit account.
[this post was originally made to a private subreddit]
I love the MegaLounges, and I really love the MegaManLounge. We’re a hugely disparate group of people yet we’ve come together into a wonderful community that I’m proud to be a part of. And I felt like it’d be nice to give something back. But what?
If you’re like me, you love the experience of bumping into another MMLer elsewhere in the Redditverse (or around the Internet in general). I mean, what’d be really awesome is if we could find one another in the real world, but that’s a project for another day. Anyway: my point is that I get a thrill when I spot a fellow MMLer wandering around in Redditland. But oftentimes I don’t look closely at people’s usernames, and I’m sure there must be times that I’ve just overlooked one of you in some long thread in /r/AskReddit or /r/TodayILearned or something. I’d rather know that you were there, my MML brothers and sisters.
So I spent this afternoon putting together a tool that does just that. Here’s a screenshot to show you what I’m talking about.
I’ve written a basic browser plugin that highlights MMLers (and other MegaLounge-like folks) anywhere on Reddit. So the idea is, if you install this plugin, you’ll always know if somebody’s an MMLer or a MegaLounger because they’ll get one or two icons next to their name. In the screenshot – taken on /r/MegaLoungeVenus (the 23rd MegaLounge) you’ll see a snipped of a conversation between our very own /u/love_the_heat and /u/teiu88. /u/love_the_heat has two icons: the first one (obviously) indicates that he’s a MegaMan, and the second one shows that he’s reached MegaLounge level thirty-one (yes, there are quite a lot of MegaLounge levels now). /u/teiu88 only has one icon (he’s not a MegaMan!), showing that he’s at MegaLounge level twenty-three. Note that it’s coloured differently to show that this is the level that I’m looking at right now: this helps because I can see whether people are commenting at their highest lounge level or not, which may factor into my decision about where and when to gild them.
Someday, I’d like to make this available to MegaLoungers in general, but first I’d like to show it off to you, fine MegaMen, and hear what you think. Is this tool useful to anybody? Should I make a production-grade version to share with you all? Or am I solving a problem that nobody actually has?
Just to add: there are several things I’d like to add and questions I’ve not yet answered before I release it to you; notably:
- Right now it identifies members of the Super Secret MegaLounge, which is a violation of the rules of that lounge, so obviously I can’t release it yet. I’d like to find a way to have it identify such people but only to other members of that lounge, but failing that, I need to have it just “skip” that lounge when showing how high somebody’s ascended.
- On which note: what do you think about it identifying MegaMen? If I ever make this tool more-widely available than the MegaManLounge, should the version used by non-MegaManLounge people identify MegaManLounge members, or not? I can see arguments either way, but I will of course go with the will of you fabulous people on this matter.
- I’d like to add tooltips so that people who haven’t got the entire MegaLounge ascension mapped out in their minds can work out what’s what.
- Similarly, I’d like to improve the icons so that they e.g. have gemstones next to the gemstone lounges, planets next to the planetary ones, etc.
- Oh, and I really ought to make it work in more than just Firefox. I’d like it to work in Chrome, at the very least, too. IE can suck it, mind.
What do you think?
tl;dr: I’ve made a browser plugin that makes Reddit look like this, showing people’s highest MegaLounge and MegaManLounge status. Is it a good idea?
Teaching Kids to Code – Why It Matters
The BBC ran a story this week about changes to the National Curriculum that’ll introduce the concepts of computing programming to children at Key Stage 1: that is, between the ages of five and seven. I for one think that this is a very important change, long overdue in our schools. But I don’t feel that way because I think there’ll be a huge market for computer programmers in 13+ years, when these children leave school: rather, I think that learning these programming skills provide – as a secondary benefit – an understanding of technology that kids today lack.
Last year, teacher and geek Marc Scott wrote an excellent blog post entitled Kids Can’t Use Computers… And This Is Why It Should Worry You. In it, he spoke of an argument with a colleague who subscribed to the popular belief that children who use computers are more technically-literate than computer-literate adults. Marc refutes this, retorting that while children today make use of computers more than most adults (and far more than was typical during the childhood of today’s adults), they typically know far less about what Marc calls “how to use a computer”. His article is well worth reading: if you don’t have the time you should make the time, and if you can’t do that then here’s the bottom line: competency with Facebook, YouTube, Minecraft, and even Microsoft Office does not in itself demonstrate an understanding of “how to use a computer”. (Marc has since written a follow-up post which is also worth reading.)
An oft-used analogy is that of the automobile. A hundred years ago, very few people owned cars, but those people that did knew a lot about the maintenance and inner workings of their cars, but today you can get by knowing very little (I’ve had car-owning friends who wouldn’t know how to change to their spare tyre after a puncture, for example). In future, the requirements will be even less: little Annabel might be allowed to ‘drive’ without ever taking a driving test, albeit in a ‘driverless’ computerised car. A similar thing happened with computers: when I was young, few homes had a computer, but in those that did one or more members of the family invariably knew a lot about setting up, configuring, maintaining, and often programming it. Nowadays, most of the everyday tasks that most people do with a computer (Facebook, YouTube, Minecraft, Microsoft Office etc.) don’t need that level of knowledge. But I still think it’s important.
Why? Because understanding computers remains fundamental to getting the most out of them. Many of us now carry powerful general-purpose computers in our pockets (disguised as single-purpose devices like phones) and most of us have access to extremely powerful general-purpose computers in the form of laptops and desktops (but only a handful of us use them in a ‘general purpose’ way; for many people, they’re nothing more than a web browser and a word processor). However, we expect people to be able to understand the issues when we ask them – via their elected officials – to make sweeping decisions that affect all of us: decisions about the censorship of the ‘net (should we do it, and to what extent, and can we expect it to work?) or about the automation of our jobs (is it possible, is it desirable, and what role will that mean for humans?). We expect people to know how to protect themselves from threats like malicious hackers and viruses and online scams, but we give them only a modicum of support (“be careful, and install anti-virus software”), knowing full well that most people don’t have the foundation of understanding to follow that instruction. And increasingly, we expect people to trust that software will work in the way that it’s instructed to without being able to observe any feedback. Unlike your car, where you may know that it’s not working when it doesn’t go (or, alarmingly, doesn’t stop) – how is the average person to know whether their firewall is working? You can find out how fast your car can go by pressing the pedals, but how are you to know what your computer is capable of without a deeper understanding than is commonplace?
A new generation of children tought to think in terms of how computers and their programs actually work – even if they don’t go on to write programs as an adult – has the potential to usher in innovating new ways to use our technology. Just as learning a foreign language, even if you don’t go on to regularly use it, helps make you better at your native language, as well as smarter in other ways (and personally, I think we should be teaching elementary Esperanto – or better yet, Ido – to primary school children in order to improve their linguistic skills generally), learning the fundamentals of programming will give children a far greater awareness about computers in general. They’ll be better-able to understand how they work, and thus why they sometimes don’t do what you expect, and better-equipped to solve problems when they see them. They’ll have the comprehension to explain what they want their computer to be able to do, and to come up with new ideas for ways in which general-purpose computers can be used. And, I’ve no doubt, they’ll be better at expressing logical concepts in mutually-intelligble ways, which improves human communication on the whole.
Let’s teach our kids to be able to understand computers, not just “use” them.
You Can’t Do It Alone!
Hot on the heels of the Oxford Steganography Series, a series of “hidden in plain sight”-themed geocaches I placed earlier this year, I’ve recently placed another geocache – GC591VV – and I think that – conceptually – it might be completely unique.
Spoiler warning: this article contains minor spoilers about Oxford-based geocache GC591VV – “You Can’t Do It Alone”. You won’t find any shortcuts by reading this page, but you might ruin part of the surprise.
The cache’s name is the first clue that there’s something unusual about it, and this theme continues in its description, where it insists that this is a cache that is impossible to find by yourself. Experienced ‘cachers may have come across geocaches that benefit from a second pair of hands: usually to help “bunk you up” to a high spot. Some really clever caches use your “buddy” to press a battery-powered radio doorbell while you “listen” for the cache’s hiding place nearby, or use your friend to stop up the holes in a pipe as you pour water into it (in order to raise a floating cache to the surface). But every single one of these has a “workaround” – a way in which you can do it by yourself, if you’re imaginative enough. I wanted to make a cache that genuinely required two people.
The cache description page repeatedly insists that to solve the cache, you need you and a friend to simultaneously visit two different waypoints. When you and your friend get there, you discover why: at each, I’ve hidden a small electronic device, specially-built for this purpose (and instructions on how to use it). The two devices are a synchronised pair, and each shows on its screen a pair of numbers. To find the location of the cache itself, you need to add the first number on Box One’s screen to the first number on Box Two’s screen… and the second number on Box One’s screen to the second number on Box Two’s screen. But… the numbers change every 15 minutes: and because both boxes are hidden on opposite sides of Oxford, there’s no way to get from one to the other within the narrow window. Truly: you can’t do it alone!
Once the two cachers have each other’s numbers, they can head on to the final coordinates: the actual location of the cache: they can race there, if they like (it’s close-to equidistant from the two points) – though if they’re feeling that competitive, they’ll probably want to agree on some key exchange mechanism by which they can swap numbers without giving the person to speak first a disadvantage: I’ll leave that mathematical exercise for somebody else to solve, though! In any case, I’ve been sure to put two “first to find” prizes into the cache: one for each of the people who worked together to find it.
How does this magic work? Well, it’s reasonably simple, so long as you’re familiar with the conceptual workings of time-based two-factor tokens and the predictability of computer random number generators. I’m offering the source code and support in construction to anybody who successfully finds the cache, in order to try to inspire a new generation of digital caches in Oxfordshire (and further afield!). But the essence of it is an ATmega328 chip acting like an Arduino Nano, hooked up to a clock chip (powered by a long-life lithium “watch battery”) that keeps it in sync with its partner, and – while a switch is pushed – fully-powered by a stack of AA batteries (which provide enough power to do the maths and light up the screen).
The whole package is sealed up inside a custom-built acrylic box (courtesy of RazorLAB, whom I discovered after Rory did a craft project using them), and I’m hoping that they’ll live at least a year before I need to get out there and replace the AA batteries.
This cache represents a huge leap in complexity over anything I’ve placed before, and – I think! – might be completely unique in design, worldwide. I’m really looking forward to seeing what the community make of it! Want to go find it yourself? Start here!
Update (2018): This cache has now been retired. If you’re interested, you can read the source code here.
Programming Is Not Math
This is a repost promoting content originally published elsewhere. See more things Dan's reposted.
When I learned to program, back when dinosaurs walked the earth and the internet had no cats, there was an idea: if you were good at math, you’d be good at programming. I was great at math as a kid, but perhaps because I didn’t like it much, no one steered me towards programming. I…
My Favourite Ruby (am I doing this right?)
This link was originally posted to /r/MegaLoungeRuby. See more things from Dan's Reddit account.
The original link was: https://www.ruby-lang.org/
[this post was originally made to a private subreddit]
Programming Sucks
Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro, you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.”
They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming.
…
The Hardest Hangman
What’s the hardest word to guess, when playing hangman? I’ll come back to that.
Last year, Nick Berry wrote a fantastic blog post about the optimal strategy for Hangman. He showed that the best guesses to make to get your first “hit” in a game of hangman are not the most-commonly occurring letters in written English, because these aren’t the most commonly-occurring letters in individual words. He also showed that the first guesses should be adjusted based on the length of the word (the most common letter in 5-letter words is ‘S’, but the most common letter in 6-letter words is ‘E’). In short: hangman’s a more-complex game than you probably thought it was! I’d like to take his work a step further, and work out which word is the hardest word: that is – assuming you’re playing an optimal strategy, what word takes the most-guesses?
First, though, we need to understand how hangman is perfectly played. Based on the assumption that the “executioner” player is choosing words randomly, and that no clue is given as to the nature of the word, we can determine the best possible move for all possible states of the game by using a data structure known as a tree. Suppose our opponent has chosen a three-letter word, and has drawn three dashes to indicate this. We know from Nick’s article that the best letter to guess is A. And then, if our guess is wrong, the next best letter to guess is E. But what if our first guess is right? Well, then we’ve got an “A” in one or more positions on the board, and we need to work out the next best move: it’s unlikely to be “E” – very few three-letter words have both an “A” and an “E” – and of course what letter we should guess next depends entirely on what positions the letters are in.
What we’re actually doing here is a filtering exercise: of all of the possible letters we could choose, we’re considering what possible results that could have. Then for each of those results, we’re considering what guesses we could make next, and so on. At each stage, we compare all of the possible moves to a dictionary of all possible words, and filter out all of the words it can’t be: after our first guess in the diagram above, if we guess “A” and the board now shows “_ A _”, then we know that of the 600+ three-letter words in the English language, we’re dealing with one of only about 134. We further refine our guess by playing the odds: of those words, more of them have a “C” in than any other letter, so that’s our second guess. If it has a C in, that limits the options further, and we can plan the next guess accordingly. If it doesn’t have a C in, that still provides us with valuable information: we’re now looking for a three-letter word with an A in the second position and no letter C: that cuts it down to 124 words (and our next guess should be ‘T’). This tree-based mechanism for working out the best moves is comparable to that used by other game-playing computers. Hangman is simple enough that it can be “solved” by contemporary computers (like draughts – solved in 2007 – but unlike chess: while modern chess-playing computers can beat humans, it’s still theoretically possible to build future computers that will beat today’s computers).
Now that we can simulate the way that a perfect player would play against a truly-random executioner, we can use this to simulate games of hangman for every possible word (I’m using version 0.7 of this British-English dictionary). In other words, we set up two computer players: the first chooses a word from the dictionary, the second plays “perfectly” to try to guess the word, and we record how many guesses it took. So that’s what I did. Here’s the Ruby code I used. It’s heavily-commented and probably pretty understandable/good learning material, if you’re into that kind of thing. Or if you fancy optimising it, there’s plenty of scope for that too (I knocked it out on a lunch break; don’t expect too much!). Or you could use it as the basis to make a playable hangman game. Go wild.
Running the program, we can see that the hardest three-letter word is “xxv”, which would take 22 guesses (20 of them wrong!) to get. But aside from the roman numeral for 25, I don’t think that “xxv” is actually a word. Perhaps my dictionary’s not very good. “Oak”, though, is definitely a word, and at 20 guesses (17 wrong), it’s easily enough to hang your opponent no matter how many strokes it takes to complete the gallows.
There are more tougher words in the four-letter set, like the devious “quiz”, “jazz”, “zinc”, and “faux”. Pick one of those and your opponent – unless they’ve seen this blog post! – is incredibly unlikely to guess it before they’re swinging from a rope.
As we get into the 5, 6, and 7-letter words you’ll begin to notice a pattern: that the hardest words with any given number of letters get easier the longer they are. That’s kind of what you’d expect, I suppose: if there were a hypothetical word that contained every letter in the alphabet, then nobody would ever fail to (eventually) get it.
When we make a graph of each word length, showing which proportion of the words require a given number of “wrong” guesses (by an optimised player), we discover a “sweet spot” window in which we’ll find all of the words that an optimised player will always fail to guess (assuming that we permit up to 10 incorrect guesses before they’re disqualified). The window seems small for the number of times I remember seeing people actually lose at hangman, which implies to me that human players consistently play sub-optimally, and do not adequately counteract that failing by applying an equal level of “smart”, intuitive play (knowing one’s opponent and their vocabulary, looking for hints in the way the game is presented, etc.).
In case you’re interested, then, here are the theoretically-hardest words to throw at your hangman opponent. While many of the words there feel like they would quite-rightly be difficult, others feel like they’d be easier than their ranking would imply: this is probably because they contain unusual numbers of vowels or vowels in unusual-but-telling positions, which humans (with their habit, inefficient under normal circumstances, of guessing an extended series of vowels to begin with) might be faster to guess than a computer.
| Word | Guesses taken | “Wrong” guesses needed |
|---|---|---|
| quiz | 24 | 20 |
| jazz | 22 | 19 |
| jazzy | 22 | 18 |
| quaff | 22 | 18 |
| zinc | 21 | 17 |
| oak | 20 | 17 |
| vex | 20 | 17 |
| vox | 20 | 17 |
| foxing | 22 | 16 |
| foxed | 21 | 16 |
| queued | 20 | 16 |
| fuzzy | 20 | 16 |
| quay | 20 | 16 |
| pinup | 20 | 16 |
| fox | 19 | 16 |
| yuk | 19 | 16 |
| vaquero | 22 | 15 |
| jazzier | 21 | 15 |
| quizzed | 21 | 15 |
| hazing | 21 | 15 |
| favour | 21 | 15 |
| yoking | 21 | 15 |
| quays | 20 | 15 |
| quark | 20 | 15 |
| joked | 20 | 15 |
| guyed | 20 | 15 |
| foyer | 20 | 15 |
| bumph | 20 | 15 |
| huge | 19 | 15 |
| quip | 19 | 15 |
| gibe | 19 | 15 |
| rump | 19 | 15 |
| guan | 19 | 15 |
| quizzed | 19 | 15 |
| oaks | 19 | 15 |
| murk | 19 | 15 |
| fezzes | 19 | 15 |
| yuck | 19 | 15 |
| keno | 19 | 15 |
| kazoo | 19 | 15 |
|
Download a longer list
(there’s plenty more which you’d expect to “win” with) |
||
If you use this to give you an edge in your next game, let me know how it works out for you!
Update – 8 March 2019: fixed a broken link and improved the layout of the page.
New Volunteers for Three Rings
Hot on the heels of our long weekend in Jersey, and right after the live deployment of Three Rings‘ Milestone: Krypton, came another trip away: I’ve spent very little time in Oxford, lately! This time around, though, it was an experimental new activity that we’ve inserted into the Three Rings calendar: Dev Training.
The format wasn’t unfamiliar: something that we’ve done before, to great success, is to take our dedicated volunteer programmers away on a “Code Week”: getting everybody together in one
place, on one network, and working 10-14 hour days, hammering out code to help streamline charity rota management. Sort-of like a LAN party, except instead of games, we do
work. The principle of Code Week is to turn volunteer developers, for a short and intense burst, in to machines that turn sugar into software. If you get enough talented people
around enough computers, with enough snacks, you can make miracles happen.
In recent years, Three Rings has expanded significantly. The test team has exploded; the support team now has to have a rota of their own in order to keep track of who’s working when; and – at long last – the development team was growing, too. New developers, we decided, needed an intensive session of hands-on training before they’d be set loose on real, production code… so we took the principles of Code Week, and turned it into a boot camp for our new volunteers!
Recruiting new developers has always been hard for us, for a couple of reasons. The first reason is that we’ve always exclusively recruited from people who use the system. The thinking is that if you’re already a volunteer at, say, a helpline or a community library or a fireboat-turned-floating-museum or any of the other organisations that use Three Rings, then you already understand why what we do is important and valuable, and why volunteer work is the key to making it all happen. That’s the bit of volunteering that’s hardest to ‘teach’, so the thinking is that by making it a prerequisite, we’re always moving in the right direction – putting volunteering first in our minds. But unfortunately, the pool of people who can program computers to a satisfactory standard is already pretty slim (and the crossover between geeks and volunteers is, perhaps, not so large as you might like)… this makes recruitment for the development team pretty hard.
A second difficulty is that Three Rings is a hard project to get involved with, as a newbie. Changing decisions in development convention, a mess of inter-related (though thankfully not inter-depedent) components, and a sprawling codebase make getting started as a developer more than a little intimidating. Couple that with all of the things our developers need to know and understand before they get started (MVC, RoR, TDD, HTML, CSS, SQL, DiD… and that’s just the acronyms!), and you’ve got a learning curve that’s close to vertical. Our efforts to integrate new developers without a formal training program had met with limited success, because almost nobody already has the exact set of skills we’re looking for: that’s how we knew it was time to make Dev Training Weekend a reality.
We’d recruited three new potential developers: Mike, Rich, and Chris. As fits our pattern, all are current or former volunteers from organisations that use Three Rings. One of them had been part of our hard-working support team for a long time, and the other two were more-new to Three Rings in general. Ruth and I ran a series of workshops covering Ruby, Rails, Test-Driven Development, Security, and so on, alternated between stretches of supervised “hands-on” programming, tackling genuine Three Rings bugs and feature requests. We felt that it was important that the new developers got the experience of making a real difference, right from the second or the third day, they’d all made commits against the trunk (under the careful review of a senior developer, of course).
We were quite pleased to discover that all three of them took a particular interest early on in different parts of the system. Of course, we made sure that each got a full and well-rounded education, but we found that they were all most-interested in different areas of the system (Comms, Stats, Rota, etc.), and different layers of development (database, business logic, user interface, etc.). It’s nice to see people enthused about the system, and it’s infectious: talking with some of these new developers about what they’d like to contribute has really helped to inspire me to take a fresh look at some of the bits that I’m responsible for, too.
It was great to be able to do this in person. The Three Rings team – now about a dozen of us in the core team, with several dozen more among our testers – is increasingly geographically disparate, and rather than face-to-face communication we spend a lot of our time talking to each other via instant messengers, email, and through the comments and commit-messages of our ticketing and source control systems! But there’s nothing quite like being able to spend a (long, hard) day sat side-by-side with a fellow coder, cracking through some infernal bug or another and talking about what you’re doing (and what you expect to achieve with it) as you go.
I didn’t personally get as much code written as I’d have liked. But I was pleased to have been able to support three new developers, who’ll go on to collectively achieve more than I ever will. It’s strange to look back at the early 2000s, when it was just me writing Three Rings (and Kit testing/documenting most of it: or, at least, distracting me with facts about Hawaii while I was trying to write the original Wiki feature!). Nowadays Three Rings is a bigger (and more-important) system than ever before, supporting tens of thousands of volunteers at hundreds of voluntary organisations spanning five time zones.
I’ve said before how much it blows my mind that what began in my bedroom over a decade ago has become so critical, and has done so much good for so many people. And it’s still true today: every time I think about it, it sends my head spinning. If that’s what it’s done in the last ten years, what’ll it do in the next ten?