Dan Q
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]
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.
…
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.
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?
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.
Here’s the crux of it: if you’re –
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.
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!
Opera 12 has been released, and brought with it a handful of new features. But there’s also been a feature removed – a little-known feature that allowed power users to have the web address appear in the title bar of the browser. I guess that the development team decided that, because the title bar is rarely seen nowadays (the space in which a title once occupied has for a long while now been used as a tab strip, in the style that Google Chrome and Mozilla Firefox eventually copied), this feature wasn’t needed.
But for users of the KeePass Password Safe, this has the knock-on effect of crippling the ability for this security tool to automatically type passwords and other form data into web pages, forcing users to take the long-winded route of manually copy-pasting them each time.
To fix this problem, I’ve released the KeePass for Opera browser extension. It’s ludicrously simple: it injects a bit of Javascript (originally by Jean François) into every page you visit, which then appends the URL of the page to the title bar. This allows KeePass to detect what site you’re on, so the usual Global Auto-Type command (typically Left Ctrl + Alt + A) will work as normal.
[button link=”https://addons.opera.com/en-gb/extensions/details/keepass-auto-type/” align=”right” size=”medium” caption=”KeePass for Opera”]Install[/button]
Download KeePass for Opera (browser extension)
Open in Opera to install.
Further reading:
I’ve mentioned KeePass a few times before. See:
Looking Back
On this day in 2004 I handed in my dissertation, contributing towards my BEng in Software Engineering. The topic of my dissertation was the Three Rings project, then in its first incarnation, a web application originally designed to help university Nightlines to run their services.
I’d originally started developing the project early in the previous academic year, before I’d re-arranged how I was going to finish my course: Three Rings celebrates its tenth birthday this year. This might be considered to have given me a head start over my peers, but in actual fact it just meant that I had even more to write-up at the end. Alongside my work at SmartData a few days a week (and sometimes at weekends), that meant that I’d been pretty damn busy.
I’d celebrated hitting 10,000 words – half of the amount that I estimated that I’d need – but little did I know that my work would eventually weigh in at over 30,000 words, and well over the word limit! In the final days, I scrambled to cut back on text and shunt entire chapters into the appendices (A through J), where they’d be exempt, while a team of volunteers helped to proofread everything I’d done so far.
Finally, I was done, and I could relax. Well: right up until I discovered that I was supposed to have printed and bound two copies, and I had to run around a busy and crowded campus to get another copy run off at short notice.
Looking Forward
Three Rings went from strength to strength, as I discussed in an earlier “on this day”. When Bryn came on board and offered to write programs to convert Three Rings 1 data into Three Rings 2 data, in 2006, he borrowed my dissertation as a reference. After he forgot that he still had it, he finally returned it last month.
Later still in 2009, Ruth expanded Three Rings as part of her Masters dissertation, in a monumental effort to add much-needed features at the same time as getting herself a degree. After handing it in and undergoing her defense (which went better than she expected), she got a first.
Today, Three Rings continues to eat a lot of my time, and now supports tens of thousands of volunteers at hundreds of different helplines and other charities, including virtually every Nightline and the majority of all Samaritans branches.
It’s grown even larger than I ever imagined, back in those early days. I often tell people that it started as a dissertation project, because it’s simpler than the truth: that it started a year or two before that, and provided a lot of benefit to a few Nightlines, and it was just convenient that I was able to use it as a part of my degree because otherwise I probably wouldn’t have had time to make it into what it became. Just like I’m fortunate now to have the input of such talented people as I have, over the last few years, because I couldn’t alone make it into the world-class service that it’s becoming.
This blog post is part of the On This Day series, in which Dan periodically looks back on years gone by.
As I indicated in my last blog post, my new blog theme has a “pop up” Dan in the upper-left corner. Assuming that you’re not using Internet Explorer, then when you move your mouse cursor over it, my head will “duck” back behind the bar below it.
This is all done without any Javascript whatsoever: it’s pure CSS. Here’s how it’s done:
<div class="sixteen columns">
<div id="dans-creepy-head"></div>
<h1 id="site-title" class="graphic">
<a href="/" title="Scatmania">Scatmania</a>
</h1>
<span class="site-desc graphic">
The adventures and thoughts of "Scatman" Dan Q
</span>
</div>
The HTML for the header itself is pretty simple: there’s a container (the big blue bar) which contains, among other things, a <div> with the id "dans-creepy-head". That’s what we’ll be working with. Here’s the main CSS:
#dans-creepy-head {
position: absolute;
top: -24px;
left: 15px;
width: 123px;
height: 133px;
background: url(/dans-creepy-head.png) top left no-repeat;
transition: all 800ms;
-o-transition: all 800ms;
-webkit-transition: all 800ms;
-moz-transition: all 800ms;
}
#dans-creepy-head:hover {
top: 100px;
height: 60px;
}
The CSS sets a size, position, and background image to the <div>, in what is probably a familiar way. A :hover selector changes the style to increase the distance from the top of the container (from -24px to 100px) and to decrease the height, cropping the image (from 133px to 60px – this was necessary in this case to prevent the bottom of the image from escaping out from underneath the masking bar that it’s supposed to be “hiding behind”). With just that code, you’d have a perfectly workable “duck”, but with a jerky, one-step animation.
The transition directive (and browser-specific prefix versions -o-transition, -webkit-transition, and -moz-transition, for compatability) are what makes the magic happen. This element specifies that any ("all") style is changed on this element (whether via CSS directives, as in this case, or by a change of class or properties by a Javascript function), that a transition effect will be applied to those changes. My use of "all" is a lazy catch-all – I could have specified the individual properties ( top and height) that I was interested in changing, and even put different periods on each, but I’ll leave it to you to learn about CSS3 transition options for yourself. The 800ms is the duration of the transition: in my case, 0.8 seconds.
html.ie #dans-creepy-head:hover {
top: -24px;
height: 133px;
}
@media (max-width: 780px) {
#dans-creepy-head {
display: none;
}
}
I apply some CSS to prevent the :hover effect from taking place in Internet Explorer, which doesn’t support transitions. The "ie" class is applied to the <html> tag using Paul Irish’s technique, so it’s easy to detect and handle IE users without loading separate stylesheet files for them. And finally, in order to fit with my newly-responsive design, I make the pop-up head disappear when the window is under 780px wide (at which point there’d be a risk of it colliding with the title).
That’s all there is to it! A few lines of CSS, and you’ve got an animation that degrades gracefully. You could equally-well apply transformations to links (how about making them fade in or out, or change the position of their background image?) or, with a little Javascript, to your tabstrips and drop-down menus.
Looking Back
On this day in 2011 I launched FreeDeedPoll.org.uk, a site that tries to make it as easy as possible for British citizens to change their names (and have those new names accepted as being legally-recognised).
The thing that people often don’t realise is that, as a British citizen, you have the right to be known by pretty-much any name you like. You don’t need a solicitor to change your name. You don’t even need any money. You can just start using it. A deed poll, which you can make all by yourself for free, is just a piece of paper on which you write a promise that you consider your “new” name to be your primary moniker, and not your “old” one.
Over the last year, almost 3,000 deed polls have been generated using the site, including ones for my partner Ruth (who opted to keep her maiden name as a middle name after she got married) and my friend Jen (who now has among the coolest – and most hippyish – collection of names I’ve ever seen). As to how many of the other thousands of deed polls have actually been used, I simply don’t know: as a commitment to privacy, no logs are kept of the names people enter onto the form, so for all I know there are 2,000 all the same and 998 “blank” submissions.
Looking Forward
I’ve become a minor Internet guru on the topic of name changes, it turns out. The other week, a transgendered stranger contacted me via the “chat to Dan” link, to ask about the legal aspects of their (slightly more-complex than most) case for changing their name. And because I’m a fan of helping people, I did a little research with them in order to find the answers. I felt the need to keep stressing that IANAL, but I’m pretty sure I managed to help, anyway.
And over the New Year, when there were a few days of downtime for the site (I was part of an exodus of domains from my SOPA-supporing previous registrar, and they made the process difficult), I received messages from people asking when it would be back up again, so it’s obviously getting some use.
Most recently, a few days ago, a stranger emailed me asking for advice on the legal issues in changing the names of his children. After doing the necessary research, I’m now thinking of expanding the site to make this easier, too.
A strange feeling for me has been that this project is, and has been for the last year, “finished”. I’m not very good at finishing technical projects: one of the biggest and most important things that I’ve worked on – Three Rings – is now in its tenth year and shows no sign of being “finished”. So it feels odd to have developed a website that’s complete, done and dusted, and probably won’t require more than a modicum of maintenance over the coming decades to keep it running.
It’s good, though, that I’ve been able to help people with something about which far too many are underinformed. It gives me a warm fuzzy feeling, and I like it.
To mark the ocassion, I’ve updated the open-source version of the tool so that it works “out of the box”: it now includes all of the (free) fonts you need to get started, and can be used without setting up reCAPTCHA if you like. For more information about the history of the project, see my project page about it.
This blog post is part of the On This Day series, in which Dan periodically looks back on years gone by.
Looking Back
On this day in 2003 I first juggled with flaming clubs! But first, let’s back up to when I very first learned to juggle. One night, back in about 1998, I had a dream. And in that dream, I could juggle.
I’d always been a big believer in following my dreams, sometimes in a quite literal sense: once I dreamed that I’d been writing a Perl computer program to calculate the frequency pattern of consecutive months which both have a Friday 13th in them. Upon waking, I quickly typed out what I could remember of the code, and it worked, so it turns out that I really can claim to be able to program in my sleep.
In this case, though, I got up and tried to juggle… and couldn’t! So, in order that nobody could ever accuse me of not “following my dreams,” I opted to learn!
About three hours later, my mother received a phone call from me.
“Help!” I said, “I think I’m going to die of vitamin C poisoning! How much do I have to have before it becomes fatal?”
“What?” she asked, “What’s happened?”
“Well: you know how I’m a big believer in following my dreams.”
“Yeah,” she said, sighing.
“Well… I dreamed that I could juggle, so I’ve spent all morning trying to learn how to. But I’m not very good at it.”
“Okay… but what’s that got to do with vitamin C?”
“Well: I don’t own any juggling balls, so I tried to find something to use as a substitute. The only thing I could find was this sack of oranges.”
“I think I can see where you’re going wrong,” she said, sarcastically, “You’re supposed to juggle with your hands, Dan… not with your mouth.”
“I am juggling with my hands! Well; trying to, anyway. But I’m not very good. So I keep dropping the oranges. And after a few drops they start to rupture and burst, and I can’t stand to waste them, so I eat them. I’ve eaten quite a lot of oranges, now, and I’m starting to feel sick.”
I wasn’t overdosing on vitamin C, it turns out – that takes a quite monumental dose; perhaps more than can be orally ingested in naturally-occuring forms – but was simply suffering from indigestion brought on as a result of eating lots and lots of oranges, and bending over repeatedly to pick up dropped balls. My mother, who had herself learned to juggle when she was young, was able to give me two valuable tips to get me started:
I became a perfectly competent juggler quite quickly, and made a pest of myself in many a supermarket, juggling the produce.
So: fast forward five years to 2003, when Kit, Claire, Paul, Bryn and I decided to have a fire on the beach, at Aberystwyth. We’d… acquired… a large solid wooden desk and some pallets, and we set them up and ignited them and lounged around drinking beer. After a little while, a young couple came along: she was swinging flaming poi around, and he was juggling flaming clubs!
I asked if I could have a go with his flaming clubs. “Have you ever juggled flaming clubs before?” he asked. “I’ve never even juggled clubs before,” I replied. He offered to extinguish them for me, first, but I insisted on the “full experience.” I’d learn faster if there existed the threat of excruciating pain every time I fucked up, surely. Right?
Juggling clubs, it turns out, is a little harder than juggling balls. Flaming clubs, even more so, because you really can’t get away with touching the “wrong” end. Flaming clubs at night, after a few drinks, is particularly foolhardy, because all you can see is the flaming end, and you have to work backwards in your mind to interpret where the “catching end” of the stick must be, based on the movement of the burning bit. In short: I got a few minor singes.
But I went home that night with the fire still burning in my eyes, like a spark in my mind. I couldn’t stop talking about it: I’d been bitten by the flaming-clubs-bug.
Looking Forward
I ordered myself a set of flaming clubs as soon as I could justify the cost, and, after a couple of unlit attempts in the street outside my house, took them to our next beach party a few days later. That’s when I learned what really makes flaming clubs dangerous: it’s not the bit that’s on fire, but the aluminium rod that connects the wick to the handle. Touching the flaming wick; well – that’ll singe a little, but it won’t leave a burn so long as you pull away quickly. But after they’ve been lit for a while – even if they’ve since been put out – touching the alumium pole will easily leave a nasty blister.
Still: I learned quickly, and was still regularly flinging them around (and teaching others) at barbecues many years later.
Once, a Nightline training ended up being held at an unusual location, and the other trainers and I were concerned that the trainees might not be able to find it. So we advertised on the email with the directions to the training room that trainees who can’t find it should “introduce themselves to the man juggling fire outside the students union”, who would point them in the right direction: and so I stood there, throwing clubs around, looking for lost people all morning. Which would have worked fine if it weren’t for the fact that I got an audience, and it became quite hard to discreetly pick out the Nightline trainees from the students who were just being amused by my juggling antics.
Nowadays, I don’t find much time for juggling. I keep my balls to-hand (so to speak) and sometimes toss them about while I’m waiting for my computer to catch up with me, but it’s been a long while since I got my clubs out and lit them up. Maybe I’ll find an excuse sometime soon.
This blog post is part of the On This Day series, in which Dan periodically looks back on years gone by.
Ruby, a programming language of which I’m quite fond, is well-known for it’s readability and ease of comprehension, among about thirty-seven other wonderful features.
I rediscovered quite how readable the language is when I genuinely ended up writing the following method last week:
# On saving, updates the #Shift counters if the #ExperienceLevel of this
# #Volunteer has been changed
def update_counters_if_experience_level_changed
update_counters if experience_level_changed?
end
For the benefit of those of you who aren’t programmers, I’ll point out that which is obvious to those of us who are: the body of the method (that’s the line that’s indented) is almost identical to the method name (the line that starts with “def”).
This is the equivalent of going to WikiHow and looking up the article on, say, How to Make a Tie Dyed Cake, only to discover that the text of the article simply says, “Choose what colours you want, and then make a cake in those colours”… and you understand perfectly and go and make the cake, because you’ve got that good an understanding. In this metaphor, you’re the Ruby interpreter, by the way. And the cake is delicious.
Okay, I cheated a little: the
experience_level_changed? method was provided for me by the Rails framework. And I had to write the
update_counters method myself (although it, too, contains only one line of code in its body). But the point is still the same: writing Ruby, and thinking in a Rubyish way,
produces beautifully readable, logical code.
I talk a lot. If you don’t want to listen to me ramble, and you’re just looking for the free deed poll generator, click here.
After Claire and I changed our names back in 2007, I actually took the time to do a little research into deeds poll (or, more-specifically in this case, deeds of change of name). It turns out that we did it the wrong way. We paid a company to do all of the paperwork for us, and – while it wasn’t terribly expensive – but it wasn’t free, and “free” is exactly how much it ought to cost.
In the intervening years I’ve helped several friends to change their names via deeds poll (yes, “deeds poll” is the correct plural), and I’ve learned more and more about why the whole process should be simpler and cheaper than many people would have you believe.
A deed poll, by definition, is nothing more than a promise signed by one person (it’s not even a contract – it’s got little more weight than a New Year’s resolution), on paper which has straight edges. That’s what the word “poll” actually means: that the paper has straight edges. Why? Because back then, a contract would typically be cut into two on an irregular line, so that when the two halves came together it would be clear that they were originally part of the same document – an anti-forgery measure. A deed poll, because it’s signed only by one person, doesn’t need to be separated like this, and so it has straight edges.
That means that’s it’s perfectly legitimate for you to write, on the back of a napkin, “I have given up my name [former name] and have adopted for all purposes the name [new name]. Signed as a deed on [date] as [former name] and [new name]. Witnessed by [witnesses signature(s)].”
The problem comes when you send that napkin off to the Inland Revenue, or the DVLA, or the Passport Office, and they send it back and laugh. You see, it helps a hell of a lot if your deed poll looks sort-of official. You ought to put some work into making it look nice, because that makes a world of difference when you ask people to believe it. That’s not to say that they won’t laugh at you anyway – the Passport Office certainly laughed at me – but at least they’ll accept your name change if it has an air of authority and is covered with all of the most-relevant legalese.
Behind the dozens of scam artists who’ll charge you £10, £20, £30, or even more to produce you an “official” deed poll (tip: there’s no such thing), there are one or two “free” services, too. But even the best of these has problems: the site is riddled with advertisements, the document isn’t produced instantly, you’re limited in how many deed polls you can generate, and – perhaps worst of all – you have to give them your email address in order to get the password to open the documents they give you. What gives?
So I’ve made my own. It’s completely free to use and it’s available at freedeedpoll.org.uk: so what are you waiting for – go and change your name! Oh, and it’s also open-source, so if you want to see how it works (or even make your own version), you can.
Why? Well: I don’t like feeling like I’ve been scammed out of money, so if I can help just one person change their name for free who might otherwise have been conned into paying for something that they didn’t need: well, then I’ve won. So change your name or help your friends and family to, on me, or just download my code and learn a little bit about Ruby, Sinatra, and Prawn (the technologies that power the site). What’re you waiting for?
They just gosub without return. That is, of course, a joke (with all due apologies to those of you to whom it means nothing), but there’s a kernel of truth in the saying. In their own way, programmers are like authors or artists in that their work can easily outlive them, and their unique and distinct style can be found in their creations: and in that created by those that learn from or imitate them.
This morning I was working on some legacy Perl code that holds together a part of a client’s web site. In particular, I was refactoring the code that displays dates and times in an appropriate format, as part of an effort to simplify the code after fixing a bug that would, under some unusual conditions, use the “pm” suffix for morning times (e.g. 11pm, when it means 11am). Under normal circumstances this would have been a simpler job than it was, but this particular piece of software has been passed from developer to developer, and (until it came into my hands) I’m pretty sure that none of them took the time to understand what their predecessors had done. Several different stylistic and semantic styles are used in the code, and several different solutions are used for the same problem, depending on who was in charge at any given time. In short, the code’s a mess, but the client is on a tight budget and can generally only afford to pay for the minimum amount of work, and not for the sweeping overhaul that the system so badly needs.
I came across a particular line of code, today (evidence, perhaps, of a previous developer looking into a related issue to the one with which I was tasked):
$leu_something .= $hour . " - " . $amorpm;
Even without the developer’s name embedded within the variable name, I could have told you who wrote this code because of its distinct style. Even this single line has a defining appearance of its own, to the trained eye. To illustrate this, consider that the line could equally have been written in any of the following ways (among hundreds of others, without even looking at the optional space characters and interchangeable types of quotation marks used), and would have functioned identically:
$leu_something = $leu_something .= $hour . " - " . $amorpm;
$leu_something .= "${hour} - ${amorpm}";
$leu_something = join($leu_something, $hour, " - ", $amorpm);
$leu_something .= sprintf('%s - %s', $hour, $amorpm);
Some of these methods have specific advantages or disadvantages, but all have the exact same fundamental meaning meaning. However, even from a glance I could tell that this code belonged to the former developer named Leu (and not any of the other developers whose names I’ve seen in the project) because of the style in which he chose to write it.
Non-programmers often fail to understand why I describe programming as being as much an art as a science. The work of a programmer has been compared to the work of a poet, and I agree with this sentiment. Even merely on a superficial level, both computer code and poetry:
Not only that, program code can be beautiful. I’ve examined code before that’s made me smile, or laugh, or that has saddened me, or that has inspired me. I shan’t argue that it’s on a par with the standard of spoken-language poetry: but then, programming languages are not designed to appeal to the pathos, and are at a natural disadvantage. Sometimes the comments for a piece of code can in themselves carry a beauty, too: or they can serve simply to help the reader comprehend a piece of code, in the same way as one can sometimes find guidance in the interpretation of a poem from somebody else’s research.
However, it’s possible to say things with code that one simply can’t convey in the same way, using a spoken language. To prove this point, I’ve composed a short haiku in the medium of the Ruby programming language. For this purpose, I’m defining a haiku as a poem whose lines contain 5, 7, and 5 syllables, respectively. It’s an existentially nihilistic piece called Grind:
def grind(age = 0)
die if age == 78
grind(age + 1); end
Vocalised, it would be read as follows:
Def grind: age equals zero,
Die if age equals seventy-eight,
Grind (age plus one); end.
I enjoy the subtlety its use of recursion to reinforce the idea that every year of your life gives you a bigger burden to carry (and a larger amount of memory consumed). This subtlety does not adequately translate to a spoken language.
The line of code I showed you earlier, though, is neither interesting nor remarkable, in itself. What makes it interesting to me is that it persisted – until today, when I removed it – in this piece of software. The author, Leu, died several years ago. But there will exist software that he wrote, being read again and again by tireless machines on a daily basis, for years to come.
I wonder how long the code I write today will live.
This morning, I got an instant message from a programmer who’s getting deeply into their Ajax recently. The conversation went something like this (I paraphrase and dramatise at least a little):
Morning! I need to manipulate a JSON feed so that [this JSON parser] will recognise it.
Here’s what I get out of the JSON feed right now:
<?xml version="1.0" encoding="UTF-8"?> <module-slots type="array"> <module-slot> <title>Module3</title> ...
“Umm…” I began, not quite sure how to break this news, “That’s XML, not JSON.”
“Is that a problem?” comes the reply.