We had a massive projector for participants to show off their work. The HDMI connection was… shit. Sorry, there's no better way to put it. It worked for about 30 seconds and then displayed a green screen. We replaced the HDMI cable. We swapped between a dozen dongles. We tried Linux, Mac, and Windows. In a last ditch attempt at getting it working, we even turned it off then on again.

Nothing.

This was serious. What were we going to do?

Next to the HDMI port was a visualiser. The sort where you can put your papers on to show them to the whole class.

So…

Look, if it's stupid but it works; it's not stupid!

There were some great talks about the scale of the problem - both in terms of the number of properties which need improving and the cost of retrofitting. A bunch of teams showed off some impressive demos which aimed to tackle the issues.

My demo was reasonably simple and (I thought) quite effective. It displayed a satellite view of a street in the local area. By clicking on rooftops, virtual solar panels are added to properties. Click a button and it shows your community how much CO₂ they will save, and how much money they will make.

The demo worked (phew!) and received good feedback. For something built in a couple of hours, I'm pretty pleased with it. The way it works is...

• Draw an interactive map using Leaflet.
• Use ESRI's satellite images.
• A bit of JavaScript to detect click and draw a cool solar panel icon.
• The EU has a great and free API for calculating solar irradiance. So this sends a request for each panel giving its latitude and longitude.
  • TODO! At the moment, it assumes all panels face south. A future version should let each icon be rotated to the correct degree.
  • TODO! Each icon represents 4kWp of solar. A future version should let each panel size be defined individually.
• Use CORS Anywhere because making JS requests is hard now.
• Do maths to work out the total installed capacity.
• Do maths to calculate the CO₂ value.
  • TODO! This is calculated as 0.256 Kg/kWh. I found that figure on a website. Might not be accurate for the UK.
• Do maths to calculate the cost savings.
  • TODO! It assumes 50% export at £0.25/kWh and 50% reduction in use at £0.50/kWh. That should be adjustable.
• Display a link encouraging people to sign up
  • TODO! Make the link go somewhere.
  • TODO! Display the cost to install - with suitable discounts for bulk buy.
  • TODO! Draw some pretty graphs
• Uses Picnic CSS to make it look pretty.

It is a rough and ready demo, but it does work!

The code is freely available on GitHub if you want to build something more useful with it.

You have 3 minutes to convince the judges - or your peers - that you've built something brilliant. How do you do that?

One Hundred and Eighty Seconds. It is not a lot of time. So here are my top 3 tips for succeeding at a demo.

Show the thing

This is the most important one. You need to show what you built. Demonstrate the thing that it does and what's clever about it.

The audience gets death-by-powerpoint every day at work. A good demo won't bombard them with slides.

Even worse, is a presenter who spends all the time talking about the problem, discusses their build environment in great detail, then runs out of time to do the actual demo.

I've literally seen someone spend two and a half minutes talking about why they hate Heroku and how they swapped to AWS - only to realise they have no time to show anything.

Here's my brief guide to showing the thing:

• Take 10 seconds at the start to explain the premise behind your app as simply as possible.
  • "I wanted to build an X, using Y, to fix Z."
  • That's really all you need to say. Your demo should fill in the gaps.
• Show the happy-path through the app. No one cares if your demo does password validation.
  • "When you open the app / website it shows you a thing. When you click on the thing, it does this clever thing."
• At this point, you can talk about the technology.
  • "It uses BlipSoft's AI library to talk to Funkenstien's middleware layer. We built a converter to recalcify the bytes."
• Show one or two other clever bits.
  • If the user uploads a picture of a cat, the interface dynamically changes to be cat themed!"
• Don't tell people what doesn't work.
  • If it can't handle photos of dogs, or if it crashes on a Tuesday, or if it only works on landscape Android phones running a bodged firmware... so what? This is a quick hacky demo. You don't need to martyr yourself.
• Have a definite ending.
  • "Thank you for watching! Any questions?"

And, you do need to demo something. Some PowerPoint slides are not a demo.

Keep to time.

This is also the most important tip. If you run over time, you're being rude to the audience and to the other presenters. The judges will not thank you for it.

You have a limited time - and that should be fine. You shouldn't build something in a weekend that takes more than a few minutes to demo.

Actively work to make your product quick to use. In these days of engagement metrics, it's hard to remember that your user probably doesn't want to spend much time using your product.

Here's a bad example I saw recently. The team had built a nifty AI demo which looked at a photo and gave back useful information. They'd built this into a chat-bot. And that's where things went wrong.

The demo they gave looked like this:

Bot: Hi! I'm Botso! Your vision companion! What's your name?

The presenter then typed "Hi Botso, I'm Jane. Nice to meet you."

Bot: Great to meet you too, JANE. Would you like to upload a photo?

The presenter then typed "Yes I would."

Bot: Cool, JANE. Your photo must be smaller than 4MB and be JPEG. Is that OK?

The presenter then typed "I only have a PNG."

Bot: Never mind JANE, I'll convert it. Click here to upload

All of that preamble might be good in a production app - but for a demo you can skip straight to the good stuff.

Rehearse.

So how do you succeed at the first two points? The same way you get to Carnegie Hall.

About two hours before the demo, stop coding. If you add anything new now, I guarantee you're going to break something.

Start a timer on your phone, turn the phone over, then give the demo. You have to actually speak the words aloud - not just in your head. Click through the thing you're demoing. When you reach the end, flip your phone over again and see how long it took. My guess is your idea of 3 minutes is different to the stopwatch's idea.

Work out what you can trim from your demo? Do you really need to explain your git branching strategy? Can your demo already be logged in rather than waiting for a 2FA SMS? Will the audience care about something you spent ages on?

If anything is seriously broken with your demo, fix it. But remove the temptation to add any new code or to change any of the outputs.

Go to the room where presentations will be taking place. Is there a stage? Is there a microphone? Does the WiFi work there?

In the half hour before the presentation, you and your team should run through your presentation repeatedly.

Stand up while you rehearse. Practice passing the microphone to each other. What will you do if a bit of the demo fails? Are you consistently finishing in under 3 minutes?

Isn't this a bit much?

Yes, possibly. I'm a bit obsessive about good demos. Brilliant technology is often hidden because of a crap demo.

Communicating ideas is an important skill. If your app cures cancer, but you spend 3 minutes talking about how hard a specific API is to use, no one will understand its importance.

If you only take one piece of advice from this blog post - just rehearse your demo a few times before going on stage. I see too many presenters who are genuinely shocked at how quick 180 seconds go by.

Your hacks are amazing - and you deserve to show them off in their best light.

I was delighted to get a ticket to NHS Hack Day. This is a quick post about the event, and what I learned.

What's the point of a hackday?

There were three common reactions from people when I said a bunch of geeks were going to an NHS Hack.

1. Ah! But the real problem is [some incredibly complicated thing] - please can you fix that?
2. OMG! Don't build anything fun! Isn't the NHS too important for that?
3. WTF? Are you using private patient data in your hacking?!

To answer these points in order

1. No. A weekend hack is suitable for building a sketch of something which might be useful. We can't fix systemic issues overnight.
2. No. Hackdays are about fun. Sometimes building something silly is the best way to demonstrate a point. We can only explore through creative play.
3. No. No one had access to private data. There are some public APIs which give things like waiting times, and prescription levels, but nothing sensitive.

We need to get better at explaining what the aims of a hackday are.

What worked

This was such a well organised event! Even had plenty of vegan food! Strong WiFi, decent seating and desks, and plug sockets everywhere.

Some of the hacks demonstrated were incredible. Everything from computer vision to online forms.

But, the best thing? The wide range of people! Need an epidemiologist? She's right over there! Want an API developer? Here's a couple! A great mix of ages, genders, skills, and backgrounds. It felt really well curated.

What didn't

Not much to complain about, so here's some constructive criticism. All minor points.

• Make the 2nd day shorter. The event wrapped up at about 17:30. That's a little late on a Sunday, especially when people have work or school the next day.
• Food was great, but the only thing to drink was coffee or tea. Luckily there was a supermarket nearby for some fruit juice and fizzy pop.
• Because the teams were all in little rooms, it was hard to mix ideas and seek help. While big rooms are noisy, it does give you a chance to shout out "anyone here know Python" and get some help if you need it.

Result

We came second!

Olaolu Oloyede

@OlaoluOloyede1

Great two days @NHSHackDay integrating NHS API with voice assistant. Amazing work #TeamAlexaSkillshd 🥈2nd place🥈 #nhshd
@Nikki_Kahllon @jonathantelfer @edent @amcunningham @JoRWinter @MikeMonteithDev @DomenicoCorapi pic.x.com/9aqya9f6iy

---

Winning a set of EXCLUSIVE t-shirts!

We developed an Alexa skill which could answer questions about hospitals like "what's the waiting time", "is there car parking", and "what rating is the hospital". Additionally, it could also answer questions about prescription charges.

All the code is on GitHub.

It was really hard to keep our demo short. We also had to resist the urge to add more and more features. When there is only 3 minutes to show off what you've learned, you've got to really concentrate on what it is you want to show off.

Anyway, huge thanks to everyone who attended and the organisers for making such an incredible weekend.

These rules were thrashed out at the Oxford January Games Jam. I think it is original - but there are literally thousands of card games, so it is hard to tell!

As I've mentioned before, I love collaborative games. I'd much rather help my friends than beat them.

This game is deliberately designed to be simple. I get confused with some card games where everyone has a different role, and there are dozens of actions in each turn.

This card game has difficulty settings! You can add or remove certain rules depending on the cognitive ability of your group.

Quick Game

Each player lays a card down in a 5x5 grid. Once a winning poker hand is placed down, that player may discard those cards.

Aim

To work as a team and remove all the cards from play.

Players

The game scales from 1 to 52 players.

Equipment

A standard deck of playing cards.

Rules (Co-operative)

Divide the cards equally between all players.

Cards are laid face down in front of the players. They draw cards unseen from the top of their hand.

Player 1 is the player who wishes to go first.

Player 1 places a card face up on the table. For example:

The next Player places a card face up on the table, either to the left, right, above or below the existing card.

Play continues with players placing cards face up in a grid.

When a player places a card which completes a sequence, they may remove all those cards from the grid and place them in the discard pile.

The game ends when players have no cards in their hands.

Sequences

A reminder, it is the player who places the card down who decides whether or not to remove the cards from the grid.

Sequences must involve cards which are touching each other.

Valid sequences are similar to those of poker. With two exceptions - straights and flushes can be more than 5 cards long.

The order of this list is not important. Removing cards from play is all that counts.

• Two of a kind (A pair with the same value. Example Q♦ Q♠)
• Two Pair (Example A♦ A♠ 7♠ 7♦)
• Three of a kind (Three cards of the same value. Example 9♦ 9♣ 9♥)
• Full house (A pair and a three. Example A♦ A♠ 7♠ 7♣ 7♦)
• Four of a kind (Four cards of the same value. Example 8♦ 8♠ 8♣ 8♥)
• Flush (All of the same suit. Example A♦ 3♦ 9♦ 6♦ J♦)
• Straight (All consecutive values. Example A♦ 2♠ 3♠ 4♣ 5♦)

Flushes and Straights

As in traditional poker, a Flush or a Straight has a minimum of 5 cards.

Unlike traditional poker, there is no maximum of the number of cards in your sequence.

Straights may start or end with an Ace. They may not have an Ace in the middle.

For example, this is an invalid sequence: J♥ Q♣ K♥ A♣ 2♥

Proximity

A sequence is a set of cards which a next to each other.

That is, an unbroken chain in a horizontal or vertical direction.

This is one of the areas where you set the difficulty.

Difficulty Settings

You will need to agree on these optional rules before game play starts. Or after, if you like arguments.

Cards aren't laid in a grid - but only horizontally.

For an extra challenge, cards can only be laid in one direction - for example always to the left of the existing cards.

Sequence can be diagonal.

Sequences can be multi-directional.

For example, this Straight has vertical and horizontal components.

Competitive Play

Play proceeds as above.

When a player completes a sequence, they place the cards onto their personal discard pile.

Once no more sequences can be removed, the remaining cards are added to the discard pile of the player with the smallest pile.

The winner is the person with the largest discard pile.

This encourages players to engage in tactics!

Gameplay report

It's pretty good! Playing the horizontal variant is a good introduction to the sorts of tactics which can be used.

The one thing lacking is the idea of a common enemy for the team to fight. There's a nice element of "The Weakest Link" - whereby players can choose to "bank" the score by removing cards from the table.

So, have a play - and let me know how you get on.

I attended the Oxford Games Jam with one very specific aim in mind - help create a game where people had to work together as a team. It's a hard mindset to get into - almost all games are competitive. But with the help of an amazing team, and the frank feedback of several play-testers, I think we created something fun and original(ish).

This game is Open Source! We released the code and rules under the MIT licence, any additional artwork will be Creative Commons.

Get started at https://github.com/OxfordHackspace/CaveTeam - and please let us know what you think!

Here's one of our hand-made prototypes of our Roguelike game - CAVE TEAM:

As a team, you have to move from the "Start" tile, to the "Exit" tile. Teamwork is important, some tiles will require more than one player to successfully pass. It is impossible to win the game by yourself - but you may have to sacrifice some of the players in order to escape.

The map of the caves is a hexagonal grid - in homage to many classic games. Boards are procedurally generated - team member Thomas Kiley wrote a Python script to create valid boards

Here's a typical cave board:

All players start, unsurprisingly, on the "start" tile. In order to move to a new tile, the player tells the team which tile they're attempting to clear, and then rolls a single 🎲.

If they defeat the tile (that is, roll higher than the number on the tile) the tile is flipped over and the path is clear.

If they fail to clear the tile, there is a cave-in. The tile is removed from the board and the way is blocked.

Some tiles are impossible for a single player to clear - they will need the help of other players. A player can ask for assistance from any player adjacent to the tile they wish to clear.

In the demo version, we used white counters to represent a clear path - and red tiles to represent a cave in. But what are those mysterious green tiles, I hear you ask?

SLIME!

Lurking in the cave is luminous green slime. A deadly, mindless mould creeping though the board.

Every few turns (more on that later!) the slime gets a chance to roll the dice. If the slime is next to a tile with the same number as the dice, that tile is consumed. Any player on that tile is eaten alive, and removed from the game. Slime cannot get through a cave in - you will notice in the above board, players have managed to create a small defensive wall in the hope of protecting themselves.

The slime's advance is both relentless and random. In some games it won't bother you, in others it will consume you and the exit before you're partway across the board.

Once the slime hits the clear path, it will always advance, regardless of the score on the dice.

Nick Brett

@nickdbrett

Early prototyping at #janjam17 pic.x.com/DsnvOHUaHg

---

Thresholds

This is where things get a little complicated. In order to make the game exciting, we need to have the slime move rapidly - but it also needs to be balanced with the number of players.

Every time the dice is rolled, we add its score to the Slime Counter. Once the counter reaches a score of (Number of players * 3) it is time to roll the dice for the Slime's move.

We want the slime to happen fairly regularly, but not predictably. If players are lucky enough to roll low numbers, the Slime will not advance - but the players may not be able to get through the tiles that they need.

This adds an element of risk to the game. You might want three of your team to help you defeat a particularly hard tile - but that brings with it a greater risk of the Slime advancing.

Escape

In order to escape, a player has to be adjacent to the Exit tile and roll a score of the threshold or above. This will require help from your team. Each player adjacent to the exit tile can help, and they all escape if the roll is successful.

But what if all the players aren't by the exit? You have a choice - do you wait for your team and risk Death By Slime? Do some of you escape and leave the others to perish? Can you split your team?

Team Play

Your team might decide to send scouting parties in different directions - hoping to clear paths before the slime gets there. Or, you can stick together and blast through tiles all the while risking the slime speeding up to get you.

Perhaps you'll deliberately sacrifice players, or die heroically together.

One of the features of Roguelike games is rapid death. It is entirely possible that a cave becomes impenetrable after just a few turns. The majority of your team may die shortly before the end. You might be unlucky with your rolls and block yourself in.

No matter! Sweep the board clear and start again! The game is fairly rapid, generally taking around 20 minutes for a team of four to escape.

Terence Eden is on Mastodon

@edent

#JanJam17 pic.x.com/NnV0nccGCM

---

Variations and Rule Tuning

We played through the game half-a-dozen times - sometimes radically altering the rules to see if it improved the game.

How characters move has a massive impact on the game. Originally we had players roll for every move - even if they were going along a clear path. That makes the game too hard.

Then we said that players could move anywhere along a clear path for free - and only roll if they wanted to clear a tile. That makes it too easy.

We settled on being able to move one tile along the path for free. The next move - whether to a clear tile or a numbered tile - must be rolled for.

In some variants, the slime moves to all consecutive tiles of the same number.

Let's take this board as an example.

If the Slime rolled a five, the 5 tile next to the Slime would be consumed - as would the 5 tile adjacent to the consumed tile. The other 5 remains unaffected.

If a two were rolled... Youch!

Players which have escaped - should they be able to help rescue players stuck inside the cave?

Pieces

Because the event was taking place in the Oxford Hackspace, we were able to 3D print some playing pieces.

We used David Hagemann's incredible "Low Poly Fantasy Tabletop" pieces.

Pieces had to be reasonably small so that that several players can fit on one tile.

Play it!

This game is Open Source! We released the code and rules under the MIT licence, any additional artwork will be Creative Commons.

Get started at https://github.com/OxfordHackspace/CaveTeam - and please let us know what you think!

Credits

This game was built with with ❤ and 😘 by (in alphabetical order)

• Jamie Bayne
• Nick Brett
• Terence Eden
• Thomas Kiley
• Jamie Lokier
• And all the play testers at the January Games Jam.
• Special thanks to Simon Roth for organising the event.

Conference goers could attend lectures, visit exhibitor stands, and come discuss their needs with a group of friendly hackers. We were somewhere between a curiosity ("what are hackers doing here?!?!?") and a magic circle ("Could you create..."). It made for a fun and educational day.

We were giving two overarching challenges for the 6 hour event:

• Communications Challenge - how to address the needs of medical workers in remote areas with poor connectivity?
• Diagnostics Challenge - can small, cheap, portable diagnostics kit be created which can revolutionise extreme medicine?

My hardware skills are limited - so I teamed up with Max Shelley to create a wonderful little project.

Introducing Tell Tales

Here's what Max and I (mostly Max!) came up with.

• Children, and those with low literacy skills, would benefit from simple story-books to help explain basic medical concepts ("Washing your hands is important", "Why you need an injection", etc.)
• Create a platform where people can create their own storybooks, adding text and artwork.
• Auto-generate PDFs which can be easily read on simple devices - or printed off and distributed.

Great! But not everyone speaks the same language - and not everyone can read. So here's what I coded up.

• Crowd-source translations of the stories. Allow people to add translations into their own languages. I used the superb CrowdIn service which also has a Bing powered machine-translation feature.
• Allow people to add MP3 recordings of them reading the stories aloud.
• Create a Twilio service which would play back the recordings over a regular phone call.

In the end, it more-or-less worked. We were able to create storybooks and export them as PDFs, we could auto-translate them into multiple languages, if you rang a telephone number you could have a TTS bot read out the story - not bad for a few hours hacking!

Winning!

Well, we didn't win - but some of my code did! My erstwhile colleague Sam Machin came up with a rather nifty idea - people in developing countries often don't keep track of identifying information such as birthdays, ID numbers, or formal names; therefore is it possible to create a simple facial-recognition app which will allow a clinician to match up a person with their medical records? (Let's ignore the practical and ethical concerns of biometric data here - it's a quick hack.)

Terence Eden is on Mastodon

@edent

Watching @sammachin demo Eigenfaces for the Extreme Medicine Hackday. pic.x.com/tvnt2642uw

---

Regular readers will remember I've written about using OpenCV to build facial recognition databases. All the code is open sourced on GitHub, so I talked Sam through the basics. He built a brilliant app and, quite rightly, his demo won the challenge!

Final Thoughts

Being paid to be part of an interesting hackathon sounds close to perfection - and, in the end, it really was an enjoyable event.

A few things could have gone better - I'll give you the same list as I gave the organisers.

• Sort out IP concerns before the event. The Digiotology gang were very good on this - as paid workers we had to ensure that our code was committed to their GitHub repository and given an open licence. As a result, all the hacks are open sourced on GitHub.
• Ah, but which OSI Licence? I settled on MIT, but it may have made sense to have some clarity on it.
• Let people "meet" before the event - we had a conference call and a participants Slack channel. That seemed to work very well and helped get ideas flowing. People have to be careful not to get too stuck to their idea - the best results happen when people put ego aside and offer their skills to others.
• Better diversity. While there were a range of hardware and software skills available, we could have done with a bit more design, UI, graphics, hackers around.
• Better diversity. Disappointingly, there was an over-abundance of men. I know that Open Source has a poor record of excluding people who can't work for free - but this was a paid gig. That said, not everyone has the sort of job which lets you take off random days to work for yourself. A knotty problem to be sure.
• Better participation from the medical professionals. We did spend some time with doctors, nurses, professors and the like as they came round to see what we were working on. It would have been great to have a professional working with each team - or at least hanging around so we could fact check our assumptions with them.

Overall, it was a great experience. I got to try out some new technology, meet interesting people, and work on a challenge slightly more useful than most Silicon Valley Startups. The organisers got to see a range of new ideas, and participants were able to experience the JFDI nature of quick hacks.

If you're interested in a curated hack for your event, contact Digitology and tell them I sent you.

I'd like to discuss the hack our team created and how the event differed (in a positive way) from other hack days I've been to.

The Event

On arrival at the Radcliffe Observatory Quarter, I was automatically assigned to a team. I think this is a great model for hackdays. To often, I find, anti-social nerds struggle to form teams - or they team up with people they came with - or non-hackers are left adrift without any technical help. The organisers had made sure that each team of four had at least one hacker, with the rest being made up of linguists, scholars, Shakespearean experts etc.

The first half of the day was a lecture! This isn't something I've experienced at a hackday before. Usually there an intro talk, someone thanks the sponsors, then everybody get cracking! Instead, we heard entertaining talks from Pip Willcox and Dr Emma Smith about the history of Shakespeare's First Folio - how it had arrived at Oxford, been lost, returned, and then digitised via crowd funding. Knowing the incredible provenance helped me feel closer to the data we would be working on.

We then had James Cummings talk us through the XML versions of the text, carefully explaining the somewhat esoteric TEI-C structure. He also gave us a huge data dump. We were given direct access to 2GB of high quality scans of the folio, a zip of all the XML they had available, and direct links to other useful bits of data. We were even encouraged to submit changes via GitHub. Much better organised than some hackdays where the advice is "just Google it."

Rather than getting lost in a vast sea of data, we were all told to work on a single play - Hamlet. Again, this was a sensible decision on the part of the organisers. I think we probably would have struggled if we were left to choose our own play.

Because of the layout of the rooms, there wasn't any real collaboration between the teams. With only a few hours in which to hack, this wasn't a serious problem, but did reduce those little sparks of creative cross-fertilisation you often get at these events.

Of particular interest to me was the gender ratio. Hackdays are usually male dominated affairs. This was decidedly the opposite with a F:M ratio of about 2:1! I don't know if the organisers did anything specific to achieve this, or whether it's a natural consequence of a "Humanities" event. Either way, it's a solid reminder to other event organisers that it can be done!

Our Hack - Too Many "To Be"s

Our team included... Sarah Ellis - the Head of Digital Development at Royal Shakespeare Company, Thomas Jo Johansen, Dr Erin Sullivan a Lecturer and Fellow at Birmingham's Shakespeare Institute, Michelle Morton also of the RSC, and me.

As with all good hacks, we went down several dead-ends before setting on something workable. Here are the ideas, in case you want to try them yourself!

• Sentiment analysis of the text. Rejected because the corpus contains the original archaic spellings - e.g. "loue" for "love".
• Multimedia collage. Can we extract tweets, videos, images, animated gifs, etc to match each line of the text? We couldn't find an automated way to do this, and our manual efforts were a bit disappointing.
• Correcting transcription errors in the text. A bit dull - but the data are on GitHub if you want to do it!
• How much time do characters stay on stage? The text has metadata to indicate stage directions, entrances, and exits - but it rarely indicates who has left. This could make for a nice animated visualisation and would also help improve the XML.
• How does this 1st Folio scan differ from others? Can we average out the scans to see what unique features each one has?

Finally, we settled on a somewhat avant-garde sound piece. We were discussing placing links in the XML pointing directly at sound or video files - for example Richard Burton's Hamlet. The problem is, most recordings are taken from the modern text. And most modern products inevitably cut some of the text.

One thing we could be sure of, is that no-one in their right mind would cut "To Be Or Not To Be".

What are the different ways of performing that famous soliloquy? Is Richard Burton's performance notably different from, say, David Tennant's? Who is the best actor for the role? How many different ways can it be interpreted? What if you played every recording to "To Be" all at once?

The result? Noise! Glorious noise! Magnificent noise!

We ripped the audio of Burton, Tennant, William Shatner, amateurs on YouTube, women singing with a ukulele, and a dozen more. We trimmed the audio in Audacity, and used HTML5's audio element to play them all simultaneously. In the browser we were able to mix them - changing the volume on the fly, fading in and out, starting and stopping the performances.

Listening to several speakers at once is incredibly disorienting. As you start picking out one or two voices, you begin to understand the wild variance with which people perform. Take a listen to Richard Burton, David Tennant, and Kenneth Brannagh performing at the same time.

Ok, that's three classically trained actors wringing every last drop of melancholy out of it. Even still, fascinating to hear how they approach it. Let's now hear it sung by Courtney Welbon and performed by Paul Scofield.

For students coming to Shakespeare for the first time, it can often feel like there is only one way to perform Shakespeare. That it's a fixed point from which there can be no deviation. Nothing could be further from the truth! We can play it as a rap, as a Greek Chorus, as a man, a woman, or any variation that pleases us.

It also calls into question our notion of "perfection". Many of the other hacks during the event were quantitative in nature - breaking down the text, extracting semantic meaning, adding metadata, analysing the work. Our is, I hope you'll agree, qualitative. Which is the "best" Hamlet? What makes the perfect performance? After listening to dozens of recording, I'm fairly confident I can tell a good performance from bad - but when they're mixed together it becomes less clear. Perhaps I like the sung "slings and arrows" and the spoken "outrageous fortune".

We can take this further. Splicing in recordings so that Burton's 1964 Hamlet is performing against Julia Stiles in 2000's film of Hamlet.

Taking It Further

Putting aside the tricky issue of copyright, everyone felt that it was a unique and interesting way to examine the works. For schools, it allows you to show that it isn't just dusty old men wandering around a stage. For actors, it's a resource to inspire you to take a performance in a different direction.

The Shakespearean HackFest was a hugely entertaining and a great success. Thanks to Kerri Russell and all the organisers for an amazing day and a fascinating set of data.

You can access the digital edition of the Bodleian's First Folio - and edit it on GitHub.

Wow! What a way to reinvigorate the European tech scene. All that cash is sure to filter its way down into the economy. Viva la trickle-down economics!

Or, not so much.

Earlier last week, I was asked if I would mentor teams in a start-up hackathon - partly backed by Google. That, in itself, is nothing too unusual. I'm often asked by start-ups, early stage companies, and big business to advise on a range of things. They find my knowledge and expertise valuable and are happy to pay for my time.

It's a rewarding relationship. Companies take exciting steps into the unknown (for them) and I get a wodge of cash. Happy days!

The hackathon in question was for three days in London. The organisers contacted me directly, saying they wanted someone to mentor the teams involved, give them advice on their products, and generally encourage them. I replied with what I thought was a fairly reasonable quote - considering it was a long weekend's work out of town.

"Oh no!" Came the reply, "We can't afford to pay you!"

This was, to say the least, unexpected. The event is backed by Google for Entrepreneurs. The judges are another VC firm. These are wealthy companies. Which, of course, makes it all the more curious that they charge participants to attend... Ah well, that's their business.

Here's the thing. I attempt to give back as much as I can to the community. I open source much of my work, I donate time and money to charities, I teach kids to code, I participate in hackdays, and speak at BarCamps. Sadly, I can't always work for free and I have to charge for my time - especially when it's at the behest of multi-national corporations.

I explained this to the organisers, "We only need you for a few hours each day!" they pleaded.

That's all well and good, but it costs me at least £30 a day to get into London and takes two hours each way - even just for a couple of hours' work. So three days of mentoring is going to cost me at least £100 once I factor in travel and food - not to mention that my weekend is basically screwed.

So, let me get this straight... A billion dollar corporation, with a hundred million dollars in VC money - plus sundry other VCs - want three days of my time to mentor teams who they hope will turn in to billion dollar investments and they don't even want to pay my fricking travel expenses?

Now, I'm sure that they've routed everything via non-profits, utilised good-natured volunteers, and arranged everything to appeal to starry-eyed kids looking for a big break. But so what?

Forget that noise.

Kids Today

When you're starting out in an industry, it's probably a wise investment to give your time for free. It's great to get a name for yourself, build up contacts, and learn from the best.

It's also fun to be merely associated with big name companies. To tell your friends / family that you spent the day hacking at $MegaCorp and they loved your work is pretty damn intoxicating.

Having hackers learn your API in return for beer and pizza is a fairly equitable exchange, as far as these things go.

If you want to get involved in the technology scene, volunteering to run or help out at an event is a brilliant way to get your face known. You'll learn a huge amount about event management, meet thousands of people, and help your community.

Again, selling your time and effort in return for a free ticket to a high quality event is a good deal if you're new to the scene.

But when you start inviting professionals to attend in a professional capacity, the dynamic changes. You wouldn't ask the caterers to provide free food, or a networking team provide WiFi for free, or a venue to simply rent their premises for nothing.

Professionals don't need "exposure". Professionals don't get a vicarious thrill from being associated with Google. Professionals don't actually enjoy commuting on their personal time. Professionals do need to pay their mortgages and feed their families.

As a community, I completely believe it is right and proper to help each other. I also believe that we should refuse to devalue our labour to the point of penury for companies which can easily afford us.

If Google, or any other company, wants to hire skilled individuals to provide a service - it's simply unacceptable for them to plead poverty. If they ask you , may I politely suggest that you remind them that:

"A fair day's wages for a fair day's work": it is as just a demand as governed men ever made of governing. It is the everlasting right of man. Thomas Carlyle - Past and Present (1843)

I've just come back from an amazing BlueLightCamp 2014 - held in the splendid offices of the Ordnance Survey.

Themed unconferences are nothing new - but I think this was one of the first that I've been to focussed on such a vital topic - the Emergency Services.

You can read a full write up of all the sessions on the official blog, or you can read Ben Proctor's take on the day.

Here are my scattered thoughts, interspersed with tweets from the event.

999

It's funny how little the basic 999 / 112 service has evolved from the caller's perspective. Is there any way it can be made more useful to the caller, dispatch, and the arriving teams?

Terence Eden is on Mastodon

@edent

You can send SMS to 999 - emergencysms.org.uk
Why can't we send MMS and video?
Majority of emergency calls are from mobile.
#Ukblc14

---

Video and images is thought to be a great, practical way to assess a situation before the police / ambulance / fire crews get there. The immediate fear is that people will send in pre-recorded video (possibly from TV shows) in an attempt to scam operators. There needs to be a guarantee the video is live and - if possible - a way to communicate back to the person filming.

Even more challenging - it has to be cross platform and quick. Downloading apps isn't easy in an emergency situation.

I showed off a demo of WebRTC which can do live video from the phone's browser.

There was some suggestion that footage - as well as being useful in court - could also be a revenue generating front. Although that's not without its issues.

Terence Eden is on Mastodon

@edent

If you send a video of a disaster to 999, and Sky News want to buy it - who gets the money? Revenue share? Pure fund raising? #Ukblc14

---

The texting of 999 is mostly used by those with hearing impairments. But there's a crazy situation at play

Terence Eden is on Mastodon

@edent

You can send SMS to 999 - emergencysms.org.uk
Why can't we send MMS and video?
Majority of emergency calls are from mobile.
#Ukblc14

---

Pesky People

@peskypeople

Replying to @edent@edent Yup but 999sms involves hearing person at textrelay calling 999 for #deaf person lots of texts takes 20mins+ to complete #ukblc14

---

Amanda from Pesky People is working on better ways for Deaf people to communicate in an emergency.

Wearables

How do you feel about cops wearing cameras? Does Google Glass present too large a barrier between service provider and citizen?

BlueLightCamp

@BlueLightCamp

Drawing by @DrawnalismMatt at #ukblc14 on "Wearables", capturing some of the topics discussed. pic.x.com/l1alykqgmh

---

Terence Eden is on Mastodon

@edent

Me wearing @thelab_uk's Google Glass.
How would the public react to emergency services using wearables?
#Ukblc14 pic.x.com/pie5nhfzmk

---

FJ!! https://tech.lgbt/@fj

@fj

Replying to @edent@edent @thelab_uk It would be very scary for people with issues keeping up in society like elderly. Too new.

---

Quantified Self toys like FitBit are also useful for monitoring the general health of the workforce. They can also be used to detect elevated heart rates, and other things which could be very helpful in realising if a worker is in danger.

Ultimately, emergency services workers take their own phones with them on calls - it won't be long before Glass (or its generic equivalent) will be sneaking its way into the ranks.

Drawnalism

The day was illustrated by the fabulous Drawnalism.

Terence Eden is on Mastodon

@edent

Love this artwork from @Drawnalism
#drones #ukBlc14 pic.x.com/zvr6pkzcua

---

Rapid Innovation

I ran a workshop on Rapid Innovation, and how we practice it here in The Lab. There's a great write up on the BlueLightCamp blog.

The essence of my message was that:

• JFDI is a valid strategy.
• If you can't get a prototype working in 6 weeks, you won't get anything done in 6 months.
• Ask forgiveness (and a little bit of permission).
• Show your wider team that you're experimenting. Let them know that it's ok for them to try new things.
• Be open with your failures. People can't learn from your mistakes if you bury them.
• Innovate in the open. We built a 3D printer in the main entrance of our HQ precisely to get people asking "Why are you doing that?"

Drones!

Drones are a reality. The technology is now at a price where reliable drones can be used for surveillance, rescue, and intelligence gathering.

As a demonstration, Simon Orr flew his drone for us all to see.

As well as the regulatory issues - don't fly them near nuclear power plants - we are going to have to contend with multiple drones sharing the same airspace.

Hacking

Ultimately, I didn't use any police data in my hack - but I was able to get some open data from the Environment Agency tweeting :-)

UK Flood Forecast

@FloodForecast
Automated

#ukBLC14 The flood forecast for tomorrow is.... pic.x.com/mkkxvtgqng

---

Final Thoughts

Brilliant day, fantastically organised, gorgeous building, well catered, and some very stimulating conversation. I'm already looking forward to #UKBLC15!

We know the earth is about to be bombarded with solar flares and magnetic storms of varying ferocity on July 4th, 5th and 6th 2014, by which time the infrastructure of the energy and communications networks will have been completely decimated across the entire planet.

You have 48 hours to best prepare the human race for survival, through the chaos, and on to a successful future. After which time there will be no electricity and no electronic technologies available.

That's such a cool idea for a hackathon! It got me thinking what I would do in that situation.

Well, obviously, printing out survival manuals and important parts of Wikipedia would be a good way to prep. Ok, but what do you do when that printed copy gets damaged or destroyed? How do you print out another one?

LET'S BUILD A PRINTING PRESS!

I have the square-root of naff-all experience in building a letter press, so I thought I'd do some experiments before attending the hackday and making an idiot of myself :-)

Firstly, I created a spreadsheet containing capital letters, numbers, and punctuation. No chance of Unicode - this barely covers ASCII!

The end result looks something like this:

The font is OCR-A - so that future computers can read our printed documents more easily.

The thick black borders give us nice separation when printing out.

Finally, the image is flipped horizontally.

I used png23d to convert the image into an .STL file

png23d -v -f surface -t 0 -l 32 -w 100 -d 5 -O 1 -o stl Letters.png Letters.stl

That ensures the black is "don't print", the white is the highest physical print point, and the greys are proportional in between.

After a few failed attempts, things started to take shape...

Leading to this lovely collection of letters:

As you can see - a few of them moved during printing, so it might be an idea to print it as a single bed and then snap the letters out.

You can download the .STL file from Thingiverse.

To Do

I'm not usually a fan of massive preparation before a hackday - but given the time involved in printing out these test pieces (3 hours including warm-up / down) I thought it prudent to experiment.

Still to do at the actual event (and do come along to help!)

• Build scaffolds / trays for the letters to fit into.
• Create ink. (Blueberries? Beetroot? Soot? How?!)
• Actually put ink on the letters, then paper, then see if it works :-)
• Work out how many of each letter is needed.
• How small / large should they be to cover a sheet of A6?
• Which fonts look best?
• Are they durable enough? How much physical impact can they take?
• Would it be better to create individual stamps rather than sets of letters?

Lots of work to do! Hope to see many of you at End Of The World Hack on 4 - 6 July 2014.

Rather than hack on any of the provided datasets, I wanted to work on an interesting way to present all the security flaws I had found in Government websites.

I teamed up with Mark, Marcello, and Orlando - together we created "Corkr - Plugging the Government's Digital Holes"

We were looking for different and interesting ways to visualise the data. Interactive infographics, space-trees, leader boards, top-trumps - all classic staples of hackdays.

In the end, we thought what would be the most visually impressive would be to present the sites on a map. That way we could show the scale of the problems - and let local authorities know where they needed to target.

It's hard to quantify just how bad the bugs are - is a single SQL Injection worse than two XSS flaws, for example - so we settled on just doing a raw count. Marcello and Orlando were able to convert the wpscan results files into JSON - which made doing the calculations a lot easier.

Mark, our graphics / UI guy came up with a really strong design to help showcase just how bad some of the problems are. We decided against revealing the nature of the vulnerabilities and instead went for a traffic light system.

Using OpenStreetMap and LeafletJS meant it was incredibly easy to create lush looking maps which were zoomable. Adding markers to specific locations was also really easy.

Where In The Country Is A Website?

Some websites have a defined geographic location - a tiny Parish Council's website can reasonably be centred on a map.

The WHOIS data for *.gov.uk sites is not standardised. Very few of the sites spat out a Post Code when queried. Going to each website and looking for a "contact us" link was just too much work for a hackday - so we cheated!

Google has a pretty good API for getting the geographic location from a search query. So I manually converted all the domain names into something Google could use. For example "10downingstreet.gov.uk" became "10 downing street" (used as an example - it's not a vulnerable site).

Here's the PHP code:

$location = $argv[1];
$json = file_get_contents('https://maps.googleapis.com/maps/api/geocode/json?address='.$location.',%20uk&sensor=false');
$obj = json_decode($json, true);
echo $obj["results"][0]["geometry"]["location"]["lat"] . ", " . $obj["results"][0]["geometry"]["location"]["lng"];

Now, obviously that requires a lot of copying and pasting. Luckily, Linux makes it very easy to automatically copy the output of a script onto the clipboard:

php -e locate.php West%20Byfleet | xclip -sel clip

And then we created a master JSON file which tallied up the number of flaws, where the sites were, and what they were named.

And then we did the same for the NHS sites!

In the end, due to time constraints, we only managed to get around 200 .gov.uk sites and 150 .nhs.uk sites.

And so, on very little sleep, we demo'd it...

The Competition

As ever with Rewired State, the standard of hacks was incredibly high. They ranged from the silly (dating MPs) to the serious (statistical comparisons of local areas). We presented towards the end, and were painfully aware of just how tough this was going to be. When you're up against a physicist using LIDAR calculated height data to infer shadow mapping and Pseudo-facial recognition using photoresistors, you know you're competing against the very best in the UK.

I am delighted to say that we were one of the four winners!

Rewired State

@rewiredstate

And the winners are corkr, alertin time, dataforce and shadow mapping!

---

Elliot Hughes

@ElliotJH

#nhtg14 Corkr was one truly awesome hack, final winner

---

Dan Palmer

@danpalmer

Last but not least, Corkr, the government web security audit, was great. Really good to highlight security! #NHTG14

---

Steve U

@Steve_Upton

.@edent, @marcelloseri, @M6_D6 and @orliesaurus built a leaderboard of .gov vulnerabilities hacks.rewiredstate.org/events/nationa… pic.x.com/kry2iz0td8

---

Julia Higginbottom

@gabysslave

And the final winner is Corkr #nhtg14

---

Some Thoughts On The Day

It was an absolutely amazing weekend. The food was good - and healthy - there was a wide range of people and some top notch government people there to talk with.

It might have been nice to have a bit more of a formal "what are people working on" session at the start. With 80ish hackers it may have taken some time, but it would have helped people introduce themselves and recruit for teams. All in all, a minor concern.

Prizes. I've written before about the corrupting influence of big money prizes. Luckily, the prizes on offer at #NHTG14 weren't jewel encrusted! About £30 - £40 worth of tech - plus some O’Reilly books. Just the right sort of level - not so extravagant that people would be gutted to lose, but expensive enough to make you go "Ooooh! What a lovely treat!".

Of course, the real value is in the taking part. And that's not just hokum; it really is.

Stef

@stef

Such polished, thought through hacks. Hack-for-the-prize-money hackathons? Ha! I’d take a book and a cheer from my peers every time! #nhtg14

---

Terence Eden is on Mastodon

@edent

Replying to @stef@stef damn straight. It's not about the prizes - it's about being around & taking inspiration from people doing *their* best.

---

For me, I think the real prize is making the government take notice and fix their broken sites. I think that is slowly happening - but a bit more on that later.

Congratulations to all the teams who took part - and many thanks to the judges for their impeccable taste.

Are the houses representative of the people in terms of gender diversity? Are the Labour Party younger than the Conservatives? Are the parties in the Lords particularly dissimilar?

You can play with the hack or watch a video demonstration.

• Each bubble represents a political party
• The size of the bubble represents how many members they have
• The Y-Axis (Vertical) represents the average age of MPs / Lords
• The X-Axis (horizontal) represents how gender balanced the parties are

(As you can tell, the hack was heavily inspired by Hans Rosling)

Data

A quick word about the data we used.

The (beta) APIs had some reasonably good documentation - although the examples could have been better. It seemed to assume that a user was already intimately familiar with the (sometimes arcane) principles of Parliament.

It also only spat out XML, so that needed to be converted to JSON.

The main issue we had was with the quality of the data. Let's look at two examples.

First, Linda Perham (picked solely because she's a mate of my mum!)

{
  "FullTitle": "Linda Perham MP",
  "DateOfBirth": "1947-06-29T00:00:00",
  "DateOfDeath": {
    "-xsi:nil": "true",
  },
  "Gender": "F",
  "Party": {
    "-Id": "15",
    "#text": "Labour"
  },
  "House": "Commons",
  "MemberFrom": "Ilford North",
  "HouseStartDate": "1997-05-01T00:00:00",
  "HouseEndDate": "2005-05-05T00:00:00",
  "CurrentStatus": {
    "-IsActive": "False",
    "StartDate": {
      "-xsi:nil": "true",
    }
  }
},

That's pretty comprehensive. We can see when she joined, left, her age, that she's still alive, and who she represents.

Now, let's take George Galloway who has had an... interesting... Parliamentary career.

{
  "FullTitle": "Mr George Galloway MP",
  "DateOfBirth": "1954-08-16T00:00:00",
  "DateOfDeath": {
    "-xsi:nil": "true",
  },
  "Gender": "M",
  "Party": {
    "-Id": "26",
    "#text": "Respect"
  },
  "House": "Commons",
  "MemberFrom": "Bradford West",
  "HouseStartDate": "2012-03-30T00:00:00",
  "HouseEndDate": {
    "-xsi:nil": "true",
  },
  "CurrentStatus": {
    "-Id": "0",
    "-IsActive": "True",
    "Name": "Current Member",
    "StartDate": "2007-10-31T00:00:00"
  }
},

All we have is his current status. It doesn't mention his previous life as a Labour MP, nor does it mention that he was the Respect MP of Bethnal Green in 2005.

For MPs who have subsequently gone to the House of Lords, the data is also unhelpful.

Betty Boothroyd was a Labour MP (for two different constituencies), then became The Speaker of the House of Commons, then went to the House of Lords. This is all the information we have on her.

{
  "FullTitle": "The Rt Hon. the Baroness Boothroyd OM",
  "DateOfBirth": "1929-10-08T00:00:00",
  "DateOfDeath": {
    "-xsi:nil": "true",
  },
  "Gender": "F",
  "Party": {
    "-Id": "6",
    "#text": "Crossbench"
  },
  "House": "Lords",
  "MemberFrom": "Life peer",
  "HouseStartDate": "2001-01-15T00:00:00",
  "HouseEndDate": {
    "-xsi:nil": "true",
  },
  "CurrentStatus": {
    "-Id": "0",
    "-IsActive": "True",
    "Name": "Current Member",
    "StartDate": "2001-01-15T00:00:00"
  }
}

There's also a significant lack of historical data. There are some Lords & MPs in the dataset who were in Parliament in the 1940s - but only a few. It would be great to have a comprehensive record of, say, the last 100 years.

There needs to be a better representation of when a member has "changed" - whether that's affiliation, leaving and then returning, being elevated, changing constituency, or even gender. (Although, as far as I'm aware, there have been no Trans MPs. Nor any MPs with non ASCII characters in their name.)

The data represents a very monochromatic view of the world.

For examining broad trends, it was sufficient for a hackday. We had tried scraping Wikipedia to get full details of every election, but that was a bit beyond us (over 1000 people for every election, plus by-elections, for the last 50 years.)

What We Found

I was particularly surprised by how little gender diversity there is. 50% of the population is female, yet the Labour Party have roughly 33% women MPs. Caroline Lucas is the sole (female) representative of the Green Party - which doesn't quite balance out the entirely male Bishops in the House of Lords.

In our data, you can see the big jump after the 1997 election - where the number female MPs doubled.

Labour are consistently older than the Tories. That was completely against my expectations.

So, play with the hack and see what you notice.

Thanks

As well as my amazing team mates Max Bye and John Sandall, I must thank the team from Rewired State; they put on a storming hackathon. There was plenty of interesting data, a good mix of people, healthy food and drink (as well as the obligatory pizza).

While it would have been lovely to hold the event in Parliament - I appreciate that a hoard of geeks turning up with a panoply of dodgy electronics may not have best pleased the Serjeant-at-Arms. So The Hub Westminster was a fine substitute.

Special mention to Alex Blandford who was very helpful at explaining the data and helping us navigate through the peculiarities of the system.

Finally, massive thanks to the Speaker for this fine certificate.

Apparently it was some kind of recipe / shopping / mash up thing called Whisk. Sounded good. Sounded familiar. Then I remembered this from CadburyHack

Cadbury UK

@CadburyUK

Best use of APIs at #CadburyHack - Whisk team for their recipes mashup pic.x.com/e9ztkuy3

---

Now, I didn't see either the TV show or the final presentation at the Hack Day. For all I know, they're two completely separate apps. Indeed, quoth The Hodge

Dom Hodgson

@TheHodge

@girlgeeks @edent bit of research tbh, I think they did build the app at the hack daybut using the data and backend of foodient.com

---

That last link points at http://www.foodient.com/ - a site co-founded by Nick Holzherr.

So, at the very least, the app was built off a back end that the team were intimately familiar with having created it.

I asked Nick, about it, and he cleared things up.

Nick Holzherr

@nickholzherr

Replying to @edent@edent We used @whiskapp APIs for recipes (and stated that) but app (Olympic event party organising) was 100% original. Hope you liked it.

---

Now, the CadburyHack event had a top prize of £10,000. That's a hell of an incentive.

I wouldn't have been surprised if people had pre-built components, or even developed entire apps - I did some prep for my app.

But it just doesn't feel... sporting. Building a hack on top of your own product seems to me to be against the spirit of a hackday. But perhaps I'm just bitter that I didn't win!

How Much Is Too Much?

I suppose that the Platonic Ideal of a hackday is that one attends as a blank slate, sees the technology on offer, form a team with people you've never met, hack all through the night, and produce something groundbreaking.

That never happens. Most people have at least half an idea of what they want to build, they team up with their friends, re-use components they've build previously, and hack with an eye on the prize categories. "Doesn't seem to be much competition for best use of Erlang!"

Take, for example. my Android Theremin. I can honestly say that I didn't write a single line of code - or do any research on the Android sound APIs - until the second morning of the hackday. I didn't reuse any code that I'd previously written either. However, the idea had been buzzing around in my head for a month or so. I'd watch Theremin videos, and looked at the science behind them just to keep the idea percolating.

Is that too much prep?

My CadburyHack was a different affair:

The Twitter and FourSquare code were originally written by me for other projects - so I reused them (Yay for Object Oriented Programming!). I'd used XPath before to scrape a site - so adapting it for Cadbury's wasn't hard. The barcode scanning integration was ripped out of an existing project. Even the template from the page and the font embedding code was recycled.

Is there a difference between code you've previously written and code you've plundered from some Open Source project? Is there a difference between your prior knowledge of coding, and what you pick up on the day? Is there a difference between building on an API you've used a hundred times, and one you've only just seen?

Hackdays are fun. The prizes are a nice bonus. But, ultimately it's about showing off and proving yourself within a limited time in front of a crowd. If you "cheat" you're really only cheating yourself out of the pride of hacking something original.

Still, whether the prize is a new phone, or ten grand, then incentive to bend the spirit of a hackday is strong.

Or am I just making a fuss over nothing?

The Wifi just about held up. Although I think it's fundamentally impossible to provide decent connectivity to 200+ people. Especially when they're geeks.

Dan Benton

@dogsbodyorg

It's people like @edent that break conference Wi-Fi ;-) #ota12 pic.x.com/dl2fibfi

---

Which, in turn, lead to this:

Terence Eden is on Mastodon

@edent

My data usage at #ota12 may have been a bit excessive... twitpic.com/9s35rx

---

As per my post of two years ago, I tried to encourage people to record video or audio of the talks they were in. It was a reasonable success. We captured several great sessions, but others have been lost to the æther.

I honestly believe that BarCamps, unconferences, and hack-days are part of our culture and should be preserved. There's a selfish element in that I want to see the talks that I missed - but more than that, I want to ensure that what we're doing isn't lost forever.

So, here are my thoughts (and videos) of the day.

Everything You Know About QR Codes is WRONG!🔗

The devilishly handsome Terence Eden gave one of his excellent talks upon the subject of QR codes.

I was really pleased with how this went, a packed room and lots of great questions. Thanks to Craig Heath for videoing it.

Responsive Web Design - the Specs Behind the Sex🔗

Bruce Lawson talked through some of the issues with RWD especially when it comes to adaptive images.

My thoughts on the subject are still developing, but I think that it ought to be the server / CDN which adapts the images, rather than the handset relying on JavaScript and CSS. I've two primary reasons for this,

1. There are billions of phones already on the market which don't support CSS or JS sufficiently to handle this. There's no realistic way to upgrade their browser.
2. Programmers and web designers are lazy. I don't believe that the more complex mark-up will be used, nor that they will generate several different images.

A Means to Interact: A Guided Tour of Arts Programming Platforms🔗

I must confess, I misread the subject of this talk - I thought it would be about artistic APIs. Instead, it was a fascinating talk about different ways to create graphics programatically. Becky Stewart stepped us through the pros and cons of each platform and showed us how they worked. I love interactive sessions - so coding along was great fun. She wisely distributed Windows, Mac, and Linux versions of the SDKs on memory stick so we wouldn't spend half the session downloading them.

Mobile Websites Can Have Nice Fonts Too🔗

I'm a bit of a philistine when it comes to fonts. I have the vague feeling they're important, but I don't really know why - nor how to implement them on a website. Laura Kalbag to the rescue then!

After the session, I was talking to my friend Saqib (who is blind) about fonts. He wanted a better understanding of how they affected the reading of text. I realised that fonts are like the background music in a film. It's the music which makes Star Wars as much as the dialogue and special effects. Imagine watching a Schindler's List with a jaunty comedy score - it would completely destroy the meaning of the film. As well as readability, picking a font changes the emotional engagement that a reader has with your text.

TheLab: Demo Cool Things!🔗

I say! Those chaps from O2's TheLab are rather clever, aren't they? Just goes to show what a bit of ingenuity can do when applied to a telco. We saw a demo which tracked which country people were in based on whether their phone was roaming, HashBlue which backs up your text messages and provides an API to access them, and O2 Connect which routes your calls over WiFi if you're out of signal. Evidently lots of smart thinking going on in Slough!

Connecting Microcontrollers to the Cloud🔗

The guys from Vodafone were showing off mbed. It's a micro-controller similar to the Arduino. The idea is that you can rapidly prototype sensor data, send it via a data or SMS connection and do other cool stuff with it. The session I attended went into the C code behind it (which was a little over my head) as well as demoing practical uses for it. It's great to see kit electronics like this and the Raspberry Pi become popular - hopefully it will make hardware more accessible.

An Illustrated History of Computation🔗

What a delightful session! Professor Bernie Cohen took us through a history of computing, mixed with personal anecdotes, and live algorithm solving. He seems to know a thing or two - I predict the lad'll go far!

ePatient 101: An Introduction to the Asymmetrical World of Technology and Healthcare🔗

Mark Kramer (AKA Mamk) joined us via a dodgy Skype connection from the US, where he has just finished being treated for cancer. Fuck cancer. Seriously, fuck it. Mark was talking about the disparity between the technology which the medical profession has access to versus that of their patients. Doctors may have MRI machines - but they're often stuck with handwritten notes, or ancient PCs. Patients have more CPU power in their phones than a whole office full of medical staff.

Hacking

Over The Air is where geeks come to play. Some of the inventions on display were simply marvellous. I think there were 39 hacks presented - I'm going to highlight the ones I thought were exceptional.

Sam Machin built a tool to allow you to send tweets via a DNS lookup! As he said during his introduction:

Without going into too much detail, you do a lookup on my-message-is-this.example.com, when the server receives the NS, it tweets on your behalf. So, as long as you can do a DNS request - even if the response is blocked - you can tweet. Amazing!

Tom Hume built an app which lets you post your call history on Facebook. It's not as creepy as it sounds! Remember "poking"? Well, a phone call is a private poke, in essence. So, your friends can see that you called X to wish them happy birthday.

Jatrobot was the scariest looking hack I'd seen! Herx The Vampire Slayer! The team had built a modern farming tool. It measured soil moisture, weather, gps, and a bunch of other stuff via mbed - then reported it all back via Android.

Finally, my hack! This was the first time I'd entered a hack at OTA and I was unusually nervous!

I took inspiration from Ariel Waldman's mesmerising keynote about creating accessible interfaces to science. I was reminded of the Music of the Spheres (not the Doctor Who episode!) - which is the idea that the movement of the planets and celestial bodies can be thought of as a musical arrangement. We can also tune in to the background radiation of the universe and turn that into music. My phone doesn't have a gamma ray detector - but it does have a solar radiation sensor - the Lux Meter! It also has a proximity sensor - so it can tell how far away my hand is from the screen.

So, I created an ersatz Theremin! Having created a musical instrument (despite having no musical talent) I set about composing a work to be played via the medium of light.

I'm chuffed to say it worked really well and the crowd seemed to like it!

Christian Payne

@Documentally

Still liking @edent’s ‘Music of the Geeks’ on his android theremin. Beautiful. :) #OTA12

---

Hadley Beeman

@hadleybeeman

Replying to @edent@edent got his Android to play music in response to hand waving & dancing in front of it. Great use of lux sensor & proximity sensor. #ota12

---

Grant Kemp

@ukdatageek

Replying to @edent@edent playing the music of the geeks. #ota12 pic.x.com/wos7nayj

---

Craig Heath

@heathcr

#OTA12 @edent brings house down with smartphone music performance art :-)

---

Duncan Cragg

@duncancragg

Things I liked @overtheair: @edent's theremin app, @edent's QR code talk, Bernie Cohen's computing history, @emabolo's HTML5 & AppFire..

---

Terence Eden is on Mastodon

@edent

#OTA12 rather nervous about presenting my hack. Never performed music in public before.

---

littlepurplegoth

@HelenArmfield

Replying to @edent@edent was fantastic... Want! (theremin 'proper' is my instrument on The List!)

---

The app won one of the awards for Best Android App and was crowned Best In Show! Utterly gobsmacked, truly humbled, and over-excited to receive a Galaxy Nexus and a Raspberry Pi.

You can download the theremin and read all about the technology behind it.

Massive thanks to Dan, Maggie, Matt, and all the others involved in the highlight of the mobile geek calendar.

I cannot wait for next year!

Perhaps it's different in his part of the world, but over here, hackdays are fun!

All the hackathon / hackdays I've been to are, essentially, Scrapheap Challenge⁰ for software people.

The last hackday I went to was about people learning, playing, relaxing, building, tinkering, bodging, faking, and innovating.

All without a design document, manager, brand police, or scrum master. And here's the thing - no one was expecting quality software. No one was expecting amazing things. No marketing guys (that's me!) thought "I wonder how we can leverage the synergies of the cross-cultural blahblahblahblahblahblah..."

And yet... Quality software got made. Innovation happened. Very little of it had usability, security, and scalability baked into it. But just like an artist's sketch can become a masterwork, or a film-maker's short can be developed into a blockbuster, the kernels of great software was laid down.

I don't know how many managers or marketing guys actually attend hackathons usually, but if they'd attened the one I went to at the weekend, they would have taken away a very important lesson.

Every team had to present what they'd built. Some had fully working software, others had prototypes, a few had a series of screenshots.

One team came up and showed their project plan! Seriously! All they had was a bit of paper showing the roles they were assigned, the plan for what each person was to do, a few vauge user flow diagrams, and no software.

It was plain to see that a hackday isn't how good software gets made. It's not even the ideal way to make software.

It's just a way to make software. The inventions on Scrapheap Challenge would never be released to the public after a weekend with a blow-torch - and yet some of the software built at the hackday was useful and ready to be released the next day.

With all the tools available to the competent programmer, it's now incredibly easy to write useful, scalable, high quality, innovative, beautiful, creative, playful, and helpful software in a weekend.

Or, you can just build a text to speech service which randomly calls your phone and says rude words to you.

Hackdays are about fun.