Anthony Bailey

PuzzlehuntingEnjoyed a puzzlehunt (competing teams race to solve...

Sat, 18 Jul 2015 15:47:41 +0100

Puzzlehunting

Enjoyed a puzzlehunt (competing teams race to solve a themed set of logic puzzles) today. The hunt was one internal to Amazon, so I can’t really point inside it, but it was pretty good.

Anyway, I promised the team I’d share one particularly baroque but enjoyable puzzle I’d encountered before. Blog post because public is always better.

To overgeneralize, the art of puzzle composition is to end up with a solving path that delights the solver. It should always be possible to make definite solving progress (so you don’t have to explore parallel paths and backtrack the ones that don’t work out, and you can tell quickly if you made a mistake), and you should have a sense as to where that progress might be made - but, some steps should require a bit of novel thinking.

This Nikoli Octathlon by Palmer (”mellow melon”) Melbane is beautiful in that regard. The interplay of eight (actually twelve, since four of them are themselves twins) different puzzle types meant that almost every step involved a bit of invention, and it kept me challenged but never stuck throughout. I loved it, hence sharing.

Nested tic-tac-toe is neat. This “Math with Bad...

Sat, 29 Jun 2013 15:24:38 +0100

Nested tic-tac-toe is neat.

This “Math with Bad Drawings” post is a good overview.

This playable version at Khan Academy is fun, and pleasantly open if you want to mess with the code.

Charles Nutter on predictably shaped dynamic types

Sat, 11 May 2013 14:44:35 +0100

On Languages, VMs, Optimization, and the Way of the World

He reckons to allow a runtime to be efficient: “types don’t have to be statically declared, but they need to be statically defined. Most popular dynamic languages do neither, but all they really need to do is the latter.”

As per my comment there, I wonder whether it could be useful for a collection of objects in a dynamic language to be able to signal to the runtime “OK, I promise that we’re done being unpredictable. You can start making assumptions about our shape now.”

Because, it seems many of the benefits of monkeying with a dynamically typed language come early in the run, at the point you set everything up; they enable nicer embedded DSLs, more expressive configuration. Then there comes a point where you could say “freeze”.

Why literate programming failed: stories and encapsulation

Sun, 05 May 2013 14:19:58 +0100

Reading a related question re putting tests inline with code on Ars Technica, discussion got onto why Knuth’s literate programming technique (“LP”) never gained popularity.

The cost is complexity, so the question reduces to why the real-world value of benefits of LP weren’t as much as expected.

My take: LP is about documenting code as a narrative story with a beginning and an end. It was invented when describing procedural code, before encapsulated objects were the norm.

Telling the tale of one algorithm is easy enough, but it takes artistry to do the same for a composed system. It is like describing a country by interweaving little stories about its citizens. They give writing awards to people who do that well.

Something analogous holds for story threads and parallel processes.

Lastly, the code that needs the best documentation is that with the most external users: frameworks and libraries. As well as tending on the non-procedural and parallel, in these cases most readers don’t even want the whole story. A big picture overview is helpful, but the main need is modular documentation for the features of interest right now.

Hypertext documentation is easy to generate, but compelling hypertext novels are really hard to write.

(Disclaimer: I still haven’t ever read Tex: The Program. But even if Knuth pulled it off, most of us don’t write as well as he does.)

(Background: my PhD thesis was about literate formalizations of mathematical proofs, and these days I work on relatively large software systems.)

Funniest xkcd in a long while.

Wed, 13 Mar 2013 21:37:41 +0000

Funniest xkcd in a long while.

But the change, how strange

Mon, 21 Jan 2013 21:06:00 +0000

A few well-known songs originally in a minor key undergo a forced major:

http://vimeo.com/majorscaledtv

A few notes so that this isn’t just a linky reblog.

I seemed to find these enjoyable for their own sake as well as acts of reinterpretation. But I must be fooling myself, because in the case when I didn’t know the original (Metallica, yes I know I should feel shame) then the transformed version seemed pretty dull and pointless.

I like this stuff because it makes me question how complex a transformation needs to be in order to have highly creative value independent of that of the original ingredients. I get a surprisingly low answer. I realize that in this case there are a few choices latent in the process (keys can be a little fuzzy) but this is basically “have a simple idea + choose original art well” (much like straightfoward “X vs Y” collages or “Garfield Minus Garfield” style transformations.) I don’t care that the transformation process itself is hard work - effort in art is unimportant to me. But the very simple creative act still seems very worthwhile. Within our rights-encumbered remix culture, this issue seems relevant.

Lastly, although setting the transformed song against the original video adds a little something, isn’t it odd that you pretty much have to publish an audio experiment like this on a video site? Neither e.g. SoundCloud nor MySpace really work as channels.

http://gilesbowkett.blogspot.co.uk/2012/12/github-vs-skyrim.html

Sat, 08 Dec 2012 18:14:24 +0000

http://gilesbowkett.blogspot.co.uk/2012/12/github-vs-skyrim.html:

Exploring two ongoing but conflicting themes in evolving workplace dynamics.

“Modern fantasy role-playing video games feature incredible gamified to-do lists. […] it’s great training for project management […] I’m not sure how to reconcile Shirky’s very compelling arguments or GitHub’s wonderful success with the sheer, dimwitted enjoyment I get out of being told repeatedly to go over there and kill another orc. Again. […] If there is any future to ideas like gamifying the workplace, it’s in some merger of elements from GitHub and Skyrim, but I’m still not sure which elements, or in which proportion.”

An analogy for software development? When I saw this image of a...

Sun, 25 Mar 2012 22:48:00 +0100

An analogy for software development?

When I saw this image of a set of 3D-printed set of adapter bricks with a snarky acronym to make various well-loved construction brick systems interoperable, somehow it reminded me of the most useful code that I write.

One case for queues

Thu, 06 Oct 2011 01:36:36 +0100

Ted Dzubia recently posted The Case Against Queues. I have to grant him that, like anything else, queues can be over/misused, so probably they are being in some parts. Film at 11. (I would say that re useful metrics to alarm on, the time between a message arriving on a queue and it being acked as processed is typically easy to measure and to set sensible thresholds for.)

In an Google+ discussion of the post the argument has been advanced that queues should be avoided wherever possible; that they cause more problems than they solve. My limited experience is the other way; I’m working on systems where I’m finding them to be a highly valuable abstraction and where I’m not seeing significant cost. I thought the discussion would benefit from more examples, so I present here one case where I’ve found them very useful.

Suppose there are two systems, which I’ll call Truths and Consequences. They maintain state in related domains, but are decoupled - probably owned by different teams - and they model their domains in sufficiently different ways that working out the consequences of truths requires some code to crunch. It could take quite a long time to recalculate all consequences of all truths, but we can usually comfortably keep up with recalculating consequences as truths change, and we don’t want to ignore the consequences of any truths.

Truths and Consequences communicate through a queue with typical robustness properties such as At-Least-Once delivery. When the truth about some named thing (say “cats”, or “dogs”) changes, Truths publishes a message containing that name onto a queue. Note that the message doesn’t say “the truth about cats is that they are all gray”, but rather “the truth about cats has changed”. When Consequences consumes the message, it asks for the current Truth about the named thing, updates relevant consequences, and acks the message. For any given set of truths, calculating their consequences (and hence, processing a message) is of course idempotent.

Of course the queue decouples the two systems so that you can change truths without waiting to hear about the consequences - hell, Consequences can drop off the network for a while as far as Truths cares, and in a halfway decent framework the queue works as a resilient store out-of-the-box. These are the kind of reasons why we introduced the abstraction in the first place. But there are other nice properties of this system too.

For example, suppose occasionally a new truth appears that we can’t currently calculate the consequences of. Maybe there’s a disastrous edge-case that crashes the calculation (“dog.getNose().smell() throws NullPointerException”), or maybe the truth breaks some assumptions that the calculation has used (“uh, what? dog.getHead() returned an array??”) The “dogs” message is poisonous and Consequences can’t currently handle it. So it nacks the message, prompting it to be moved from the original queue to an associated dead-letter queue (DLQ). After the Consequences system has been updated to deal with the new situation, it can have another go at consuming such messages, which were sitting on the DLQ in the mean time. Another possibility is that Truths realizes they were talking nonsense, and changes their mind back to something sane. In that case the Consequences system doesn’t need any update, it just reconsumes the message; when it asks for the truth about “dogs” it finds that they have just the one head again and all is well.

Another example: for some set of things, the truths are unchanged, but Consequences is updated to fix a mistake in the existing calculation, or to extend it with a useful new consequence to calculate. Publish messages naming all the relevant things, and the new calculation will be applied. Is it going to take a while and we don’t want to interrupt business as usual? Put these messages on a lower priority “backfill” queue that is only consumed when the regular one is empty. Are some of the things more important than others? Order the messages on the backfill queue to reflect that. Similar approaches apply when truths about a large new set of things become available and need backfilled.

A last example: during an era of uncertainty, truth about some set of things becomes very volatile, swinging back and forth faster than the consequences can be calculated and recalculated, filling up the queue with a backlog of messages naming the same things over and over. Just introduce some plumbling that dedupes the pending messages by name - because we always calculate consequences based on the current truth, not the historic one.

Note that either system can take responsibility for the queue and work to redrive DLQs and reprioritize messages - typically it depends on which role cares most about the relationship. If Truths wants to be heard, it can own the queue; if Consequences needs to know the truth, vice versa. In the system I work on right now, we play both these roles in relationships with various other teams.

One, Two, Testing

Tue, 04 Oct 2011 22:54:50 +0100

The first official DLC for Portal 2 came out today. It’s a new Co-op campaign.

Now this kind of play is probably great fun, but I still haven’t managed to play the co-operative campaign that originally came with the game. Because, you know, you have to be organized enough to dovetail the windows in your packed social schedules and all that.

So I was kind of hoping for a new set of Valve-quality Portal 2 single-player maps.

It’s OK though, because instead the Internets sent me a new set of better-than-Valve-quality Portal 1 single-player maps: Try Anything Twice by HMW. I spent around four hours on Sunday playing through this masterpiece.

Try Anything Twice is very much to my tastes. There are no very tricky moves, and fairly few halfway tricky ones - instead it’s all about the puzzles. Said puzzles are very well-paced; I was consistently stretched but never got totally stuck.

There’s a nice central concept/conceit: you solve each of the five maps twice, the second time around with some minor changes to the situation which demand major changes to your solution.

The level architecture and engineering is beautiful, with chambers rearranging themselves like something out of, well, Portal 2.

Lastly there are a few new game mechanics with great art and execution. The element introduced for the second try of the last chamber gives rise to the most mind-bendingly enjoyable puzzles I’ve seen in any Portal context.

Better than any other Portal mod I’ve played. Download it.

Forcing functions that are better than comments

Fri, 16 Sep 2011 21:51:14 +0100

A recent thread at work discussed the value (or otherwise) of comments in code. I think comments on anything owned and used by a small team are usually a code smell.

One of the excuses offered for comments was that if you wrote e.g. JavaDoc for some code, then that forces you to think about the details of the code’s behavior and the way that it presents itself to clients; and that such thinking catches edge cases, and prompts redesign all the way from minor naming tweaks through to major simplifications.

I agree completely that the forcing function of explicitly expressing one’s intent has that value. And it’s a really significant value. But tests do it better than comments without any of the “eventual inconsistency” downsides.

This is old news. But then I noticed a pattern I thought worth posting:

One genuine usefulness of comments can be in providing the “why” instead of the “what”: to give the motivation for behavior rather than simply a description. And making motivation explicit is as valuable to a developer as making descriptions explicit is. It analogously exposes gaps in thinking, and prompts re-aiming toward equally valuable goals that are easier to hit.

Tests are only good for expressing descriptions, not motivations. So here they can’t play the same role of a superior substitute forcing function to comments. You know what can though? Talking with your pair.

Google Plus minus writes

Fri, 16 Sep 2011 21:08:54 +0100

Google+ finally began to roll-out an API. Yay! But, it is read-only. Boo!

I write my stuff here, in a space (i.e. under a domain name) that I own.

Some people have chosen to follow me on Google+ and from this I conclude they may want to read what I write. The obvious way to link the resources is to post a link on Google+ each time that I write something here. I was hoping for a Google+ API that allowed writes, so that this could be automated. Oh well. Guess I’ll copy and paste manually when I remember too.

Not that I write enough for this to be a big deal for me or for anyone else. But it does disappoint me. Perhaps Google+ really is intended to be a big walled garden within which you rent a plot where you plant your thoughts - but if I wanted that silly silo model, I’d be on Facebook.

Google Identity

Thu, 28 Jul 2011 00:22:56 +0100

These are some thoughts in response to a post by Pavlos on Google+, on Google+. (They are posted here on my blog in order to be consistent with their content! Consider this a trackback. Hmmm, whatever happened to trackback?)

I have three things to say here.

First, whatever Google’s worthy plans may be re other long-term benefits of having well-defined identities in this new space, we should not forget that real names, tied to real addresses, are worth more to a company whose primary business is advertising. Pavlos, I expect you are cognizant of this, but I didn’t see it in your posts yet.

Second, anyone who believes in the value of having an online identity and who then gives a commercial company ownership of their main identity page is taking quite a risk. Google has previously been mostly on the side of light re supporting technologies (such as OpenID) that do this stuff right: which is, to let you define your identity provider somewhere that you control, so you can migrate identity providers if required. (Register a domain name. Delegate everything that speaks canonically about you online - email, blog, profile - via resources accessed under that domain name.) I really hope Google+ makes supporting this approach a priority too.

Lastly, with regards to both to my second point and to Pavlos’ third (re those who require anonymity) - this service is brand new. A lot of the features we are after are allegedly simply on the to-do list. So we should wait and see.

http://martinfowler.com/articles/lmax.html

Wed, 13 Jul 2011 00:44:15 +0100

http://martinfowler.com/articles/lmax.html:

Great write-up of a fascinating - nay, disruptive - architecture for applications that handle a very large number of highly interdependent requests - event-driven, tuned to processor caches, and pushing all the concurrency out to the edges.

Who is ready to make some science?

Mon, 30 May 2011 23:43:00 +0100

When Portal 2 came out, I had grand plans for a detailed post discussing the game, the multi-stage ARG that surrounded the launch, the plans for DLC, and lastly my thoughts on whether the less clinical look of the game would get in the way of homebrew levels.

Skip to the end… no, it has not. Wish there had been another two scenes in the middle act of the game? Install this Sphere of Roundness / Old Faithful level pair created by mapper Lobster. Beautiful puzzles!

Oh yeah, I keep meaning to organize playing through the co-op. Anyone up for that?

Update: the maps that won the first Portal 2 Thinking With Portals contest are of a similarly high quality.

What would Feynman do? - Fabulous Adventures In Coding

Wed, 16 Feb 2011 00:21:00 +0000

What would Feynman do? - Fabulous Adventures In Coding:

I’m not sure this totally disproves the value of interview questions that provoke thinking outside the box, but I found this to be a very funny dismantling of the well-known “three lamps and three switches” puzzle.

Mixing a Modern web presence

Thu, 03 Feb 2011 21:45:13 +0000

Under the banner of Miss Fitz-Poste Modern Mixers, my partner Julie and her friend/cofounder Emily (henceforth, “the Fitz-Postes”) for about a year have been running a mostly monthly vintage-themed event: a new-fangled take on the old-fashioned concept of a social mixer.

The exact content varies with the theme but this Sunday afternoon’s Hello to Berlin will do as an example: three burlesque performers, a band, DJ and compere, shopping from four craft stalls, hair and m akeovers, silly games with prizes, and other bits and pieces. They are genuinely great affairs I’m unashamed to push at my readership because your cooler significant other gets it straight away even if you don’t, and in any case you get to laugh at what I wear on the door.

Other than manning said door, my main contribution is to enable their online presence. The website is a zero budget affair, static pages hosted off the side of a slice I was already renting. The visual design is technically sound but that’s the nicest thing anyone is likely to say about it something under my direct management. To mitigate that, apart from core static copy served directly from the slice, the structural approach is to embed and aggregate content which is hosted elsewhere and created/managed by the Fitz-Postes. As much for my own diary as anything, I’ll describe the current arrangement.

We host photos at PicasaWeb (embedding tag-driven slideshows within our site pages) and videos at YouTube. Any substantial written content, especially if it has potential long-term value, is created as blog posts. The blog is hosted on Blogger but to avoid tight coupling that would impede migration, we reference it as and serve it from a CNAME we control. The content is syndicated via a feed to the social spaces most of our regular punters use to follow us day-to-day: an almost pointless MySpace, an obligatory Twitter, and by far the most popular current portal Facebook. The Fitz-Postes’ update with shorter notes and talk to punters very frequently on Facebook, which I think is appropriate for this immediately valuable but more ephemeral stuff, and has a much lower activation energy - which is important, because more updates is better business.

And finishing up said business: tickets are sold as PayPal items, and email is implemented in a similar fashion to the blog: permanent public addresses under the modernmixers.co.uk domain are backed with mail accounts hosted elsewhere, currently Gmail. (The Fitz-Postes use theit Google accounts to co-ordinate more admin through Google Docs, unsurprisingly.)

Decloaked

Tue, 25 Jan 2011 02:01:00 +0000

The last time I updated here, I said I was journeying off into the desert. More than three months since, if I had readers I didn’t know they’d probably be a bit worried about me.

No, the trip was only a week as planned. A similarly brief description: the sheer scale of the landscape (mountains en route, then sands as far as the eye can see) was vastly impressive. I got to ride a camel through what was technically a sandstorm. I hung out with very friendly hosts and a weird mix of nice-on-average visitors circling a middle-class artistic hippie locus, although there was far too much deference to native musical and spiritual authenticity. (I judge modern clubs better at trance rhythms, and the music that gave me shivers of joy was Without Why on my MP3 player in the airport.)

Whilst deserting, I also got to enjoy the practicalities of a cloaking device: a long hooded covering formally called a burnous. It’s particularly well-suited to the soft places of Morocco: quite light, warm when need be, a shelter against sand and wind, and a keeper of personal space.

Back here, I already regularly wore the cloak as a dressing-gown around the house. Then I visited my parents in London over Christmas; wanting to minimize what I carried, I tried it as my outdoor coat. And at the start of this year my regular furry black coat went away for repairs, so I wore the cloak around town for a couple of weeks.

I really quite liked it. Warm and light as previously noted, it is also great for my regular extra thirty minutes of sleep in the back of the 43 bus during my commute out to South Queensferry, and it didn’t take me too long to learn how to not trip on it. But it gives off very loud pretentious goth vibes, whilst I’m a quiet and dispassionate goth who does not seek to provoke the staring or the cries of “hey, Aragorn”.

So now that my furry coat is relined and returned, I have disengaged the cloaking device. Ironically, said coat itself wants to be worn by a 70’s rock-star even further removed from my character; I guess I learned to forge my signature coat long enough ago that this ceased to worry me.

Desertion

Tue, 05 Oct 2010 10:06:49 +0100

A quick note that I’m out the country and offline for about a week. Mostly at the edge of a Moroccan desert, back Wednesday 13th.

http://cspangled.blogspot.com/2010/09/better-way-of-logging.html

Sun, 26 Sep 2010 00:14:09 +0100

http://cspangled.blogspot.com/2010/09/better-way-of-logging.html:

After a few months away, Albert has returned to log much wisdom at level INFO.