programming – Page 9

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.

DevCamp and DocsCamp 2016 volunteers play Betrayal at the House on the Hill — Semi-cooperative horror-themed board games by candlelight are a motivator for everybody, right?

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!

Geocache GC4EE6C, with accompanying caterpillar and mushroom — The geocaches near DevCamp 2016 were particularly fabulous, though. Like this one – GC4EE6C – part of an Alice In Wonderland-themed series.

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.

Developers marvel at one another's code, etc. — An end-of-day “Show & Tell” session at DevCamp 2016.

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.

Twee2’s logo integrates the ‘branching’ design of Twine adventures with the ‘double-colon’ syntax of Twee.

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)

Get Twee2

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.

Codeship

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?

A "pi pie", from a Pi Day celebration. — Pi goes on forever. Pie, sadly, comes to an end.

Remember in school, when you’ll have learned that the formula to describe a circle (of radius 1) on a cartesian coordinate system is x² + y² = 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 x² + y² < 1, it’s inside, and if x² + y² > 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.

A circle of radius 1 at the intersection of the axes of a cartesian coordinate system. — Think back to your school days. Ever draw a circle like this? Do the words “Cartesian coordinates” ring any bells?

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!

Output of Dan's demonstration of the Monte Carlo method as used to approximate the value of pi. — I wrote some software to do exactly that. Here’s what it looks like – the red points are inside the circle, and the black points are outside.

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.

Computer program that asks if you're a boy or a girl and then says it likes that gender. Photograph copyright Steven Luscher, used under Creative Commons license. — Ignoring the implied gender binary (fair enough) and the resulting inefficiency (why do you need to ask two questions), this is a great example of a simple algorithm.

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.)

Children programming on laptops. Photograph copyright Steven Luscher, used under Creative Commons license. — If the can of Mountain Dew wasn’t clue enough, these children are coding.

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.

A 2-year-old using a MacBook. Photograph copyright Donnie Ray Jones, used under Creative Commons license. — A future computer-literate, or just another computer “user”?

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!

Box One and Box Two stess test — The numbers shown on the screens in this photo, taken during their month-long “stress test”, are fake (they point to N 51° 12.123, W 001° 12.123: that’s not where the cache is).

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.

Visual schematic for You Can't Do It Alone boxes — Each box is operated by a pile of dirt-cheap Chinese-made components, inexpertly soldered together by me.

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).

Harmless Electronic Game Piece, written above Box One, in situ — Given how alarmed people sometimes get when they find sealed black boxes with digital screens, slowly counting down, I decided to include a reassuring note with each box.

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…

Sarah Mei

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.

…

Peter Welch

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?

A hanged man being quartered by his executioner. — The rules of hangman used to be a lot more brutal. Nowadays, very few people die as a result of the game.

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.

A tiny fragment of possible states for the tree of three-letter words, in hangman. — There are billions of possible states of game play, but you can narrow them down quickly with strategic guessing.

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.

The hardest three-letter hangman words: xxv, xxx, wiz, oak, vex, vox, aux, fox, yuk, www... — The hardest three-letter hangman words. “Sly” is particularly… well, sly.

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.

The hardest four-letter hangman words: xxxv, quiz, jazz, zinc, faux, foxy, hazy, jibe, quay, buzz, gibe, guan, huge... — Interestingly, “oaks” is an easier word than “oak” (although it’s still very difficult): the addition of an extra letter to a word does not make it harder, especially when that letter is common.

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.

The hardest five, six, and seven-letter hangman words, including jazzy, quaff, foxed, foxing, queued, favour, vaquero, jazzier, quizzed... — “Hazing foxes, fucking cockily” is not only the title of a highly-inappropriate animated film, but also a series of very challenging Hangman words.

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.

The hardest eight, nine, and ten-letter hangman words, including quizzing, puppyish, picklock, jazziness, pollywogs, cufflinks, humbuggery, juxtaposed, bucketfuls... — Some of the longer words are wonderful, like: dysprosium, semivowel, harrumph, and googolplex.

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?

Craziest Internet Explorer Bug Ever?

As web developers, we’re used to working around the bugs in Microsoft Internet Explorer. The older versions are worst, and I’m certainly glad to not have to write code that works in Internet Explorer 6 (or, increasingly, Internet Explorer 7) any more: even Microsoft are glad to see Internet Explorer 6 dying out, but even IE8 is pretty ropey too. And despite what Microsoft claim, I’m afraid IE9 isn’t really a “modern” browser either (although it is a huge step forwards over its predecessors).

But imagine my surprise when I this week found what I suspect might be a previously undiscovered bug in Internet Explorer 8 and below. Surely they’ve all been found (and some of them even fixed), but now? But no. It takes a very specific set of circumstances for the bug to manifest itself, but it’s not completely unbelievable – I ran into it by accident while refactoring parts of Three Rings.

A completely useless Internet Explorer error message. Thanks, IE.

Here’s the crux of it: if you’re –

Using Internet Explorer 8 or lower, and
You’re on a HTTPS (secure) website, and
You’re downloding one of a specific set of file types: Bitmap files, for example, are a problem, but JPEG files aren’t (Content-Type: image/bmp), and
The web server indicates that the file you’re downloading should be treated as something to be “saved”, rather than something to be viewed in your browser (Content-Disposition: attachment), and
The web server passes a particular header to ask that Internet Explorer does not cache a copy of the file (Cache-Control: no-cache),

Then you’ll see a dialog box like the one shown above. Switching any of the prerequisites in that list out makes the problem go away: even switching the header from a strict “no-cache” to a more-permissive “private” makes all the difference.

I’ve set up a test environment where you can see this for yourself: HTTP version; HTTPS version. The source code of my experiment (PHP) is also available. Of course, if you try it in a functional, normal web browser, it’ll all work fine. But if you’ve got access to a copy of Internet Explorer 8 on some old Windows XP box somewhere (IE8 is the last version of the browser made available for XP), then try it in that and see for yourself what a strange error you get.

Lucy’s Birthday

The other Three Ringers and I are working hard to wrap up Milestone: Jethrik, the latest version of the software. I was optimising some of the older volunteer availability-management code when, by coincidence, I noticed this new bug:

I suppose it’s true: Lucy (who’s an imaginary piece of test data) will celebrate her birthday in 13/1 days. Or 13.0 days, if you prefer. But most humans seem to be happier with their periods of time not expressed as top-heavy fractions, for some reason, so I suppose we’d better fix that one.

They’re busy days for Three Rings, right now, as we’re also making arrangements for our 10th Birthday Conference, next month. Between my Three Rings work, a busy stretch at my day job, voluntary work at Oxford Friend, yet-more-executor-stuff, and three different courses, I don’t have much time for anything else!

But I’m still alive, and I’m sure I’ll have more to say about all of the things I’ve been getting up to sometime. Maybe at half term. Or Christmas!

Update: Squee! We’ve got folders!