Is today recycling day? Or green waste day? Or humble landfill day? Should my food caddy go out? Gosh! Who can keep track? I mean, obviously I could look at my calendar. Or sign up for free SMS alert. Or use push notifications in their app. But where's the fun in that?

"Alexa..."

{
  "uid": "https://example.com/bins/",
  "updateDate": "2017-07-04T00:00:00+01:00",
  "titleText": "Bins",
  "mainText": "Today's bin collection is Green Refuse Bins and Food Caddies",
  "redirectionUrl": "https://www.oxford.gov.uk/homepage/154/find_your_bin_collection_day"
}

https://apps.cloud9technologies.com/oxford/citizenmobile/openapi/addresses?postcode=OX1%203HZ

https://apps.cloud9technologies.com/oxford/citizenmobile/openapi/wastecollections/200004675068

<?php

$wasteURL = "https://apps.cloud9technologies.com/oxford/citizenmobile/openapi/wastecollections/";
$uprn = "";

//  Get the data
$data = file_get_contents($wasteURL . $uprn);

//  Data is in JSON
$json = json_decode($data, true);

//  Strip out unneeded elements
unset($json["WasteCollectionDates"]["UPRN"]);

//  An array to hold the collection information
$collections = array ();

//  Loop through the array
//  Store the data as timestamp=>bins
foreach ($json["WasteCollectionDates"] as $key => $value) {
    $details =  $value["ContainerDescription"];
    $date = strtotime($value["CollectionDate"]);
    if ($collections[$date] != null)
    {
        //  Multiple bins can be collected each day
        $details = " and " . $details;
    }

    //  Ignore empty elements
    if ($date != null)
    {
        $collections[$date] .= $details;
    }
}

//  Date order the array
ksort($collections);
//  Place pointer at the start of array
reset($collections);

//  The array key is a UNIX timestamp
$first_date = key($collections);
$first_bins = $collections[$first_date];

//  Is the next bin collection today, tomorrow, or further in the future?
//  https://stackoverflow.com/a/25623230/1127699
$today = new DateTime(); // This object represents current date/time

$today->setTime( 0, 0, 0 ); // reset time part, to prevent partial comparison

//  Get the timezone as the bins API doesn't return it
$timezone = $today->getTimezone();

//  What is the date of the next bin collection?
$match_date = DateTime::createFromFormat("U", $first_date);
//  Set the timezone based on the local time
$match_date->setTimezone($timezone);
$match_date->setTime( 0, 0, 0 ); // reset time part, to prevent partial comparison

$diff = $today->diff( $match_date );
$diffDays = (integer)$diff->format( "%R%a" ); // Extract days count in interval

$headline = "";

switch( $diffDays ) {
    case 0:
        $headline = "Today's bin collection is " . $first_bins;
        break;
    case +1:
        $headline = "Tomorrow's bin collection is " . $first_bins;
        break;
    default:
        $headline = "The next bin collection is " . $first_bins . " on ". $match_date->format('l');
}

//  Set the correct header for JSON data
header('Content-Type: application/json');
?>{
  "uid": "https://example.com/bins/",
  "updateDate": "<?php echo $today->format(DateTime::ATOM); ?>",
  "titleText": "Bins",
  "mainText": "<?php echo $headline; ?>",
  "redirectionUrl": "https://www.oxford.gov.uk/homepage/154/find_your_bin_collection_day"
}

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.

Terence Eden is on Mastodon

@edent

OMG! Just won the audience vote at the #FameLab final. Thanks guys ☺
#ScienceFTW pic.x.com/bwwqgk7unc

---

If you're thinking of entering a local FameLab competition, please do so! This quick blog post explains my experience with the competition and hopefully helps teach you based on the mistakes I made.

What Is FameLab?🔗

FameLab is a communications competition designed to engage and entertain by breaking down science, technology and engineering concepts into three minute presentations. Contestants from around the world take part armed only with their wits and a few props that they can carry onto stage – the result is an unpredictable, enlightening and exciting way to encourage your curiosity and find out about the latest research.

You get up on stage - just you and the props you can carry - and spend 3 minutes educating a pub full of people about a single aspect of science. Fun!

Here's my performance at the first round :

And here's me at the final :

The heats are, typically, 8-10 people with 2-4 winners. Those winners go on to compete in a regional final. The winners from each regional final go on to the national finals (just like Glee!) and from there - the International Final; competing with the best science communicators from around the world!

Preparation

Choose a subject that you know really well. You'll need not only distil it into 3 minutes, but make it understandable for a lay audience. In each round, you'll need to give a different presentation but on the same topic.

The best advice I can give is to rehearse until you're sick of doing it. You need to be able to hit that 3 minute mark. If you go over - and the audience hears a gong - you look a bit silly.

Ideally, you want to aim for around 2 minutes and 30 seconds. That gives you enough time to pause for laughter and, if you do lose your train of thought, you won't run out of time.

Personally, I don't like writing down a script - I find that the way I talk and write are in two very different styles.

I would strongly encourage you to learn what you want to talk about - but then practice saying it as though you're speaking naturally. Nothing sounds worse than someone just reciting from memory.

Props

OSF Ambassadors

@OSFAmbassadors

Terence Eden, comp. scientist, explaining the fatal flaw in Turing's Enigma was borne of paranoia @OxSciFest #OSF15 pic.x.com/cjlehm9egd

---

Props are fun! They give the audience something tangible to focus on. The winner of the final (not me!) had a great range of balloons, bottles, and buckets for his demonstration.

Be careful of being over complicated - you don't necessarily want to be fiddling with something all the time you're on stage.

If you're making a prop - like I did - practice with it. Practice picking it up and putting it down. Make sure it's not going to break!

Should you want to use my ENIGMA Rotor diagram for a prop, here's a high resolution image for you to print out.

Friends

There's usually an audience vote - it's completely fine to stuff the place full of your mates! Everyone benefits from a lively and friendly audience. And, seeing a few familiar faces in the crowd will help with...

Nerves

It's OK to be nervous. Standing up in front of a pub full of people is a nerve-wracking experience. Breath deeply. Focus on what you want to say. Seriously - keep breathing.

You are going to stumble over your lines - the key is not to let it throw you. Worst case scenario, it's all over in 180 seconds.

Alcohol

Some people think that they are quicker-witted after a glass of wine. Others are utterly convinced that a cheeky pint makes them more vivacious and likeable. This is not the case. You make think you're funnier when you're tipsy - but no one else does.

Yes, I know it's hard to be in a pub only drinking fruit juice - but, honestly, you'll perform better without a beer. Once you've done your three minutes, make sure that your friends have lined up a few glasses of your favourite tipple and then proceed to neck them.

Q&A

Be prepared for some tough questioning from the judges. It's not X-Factor style viciousness - but they will pick you up on any scientific mistakes you made.

One bit of feedback I got was particularly good. In my first talk I'd said "you don't really need to know how this works." That was a mistake. The judges correctly pointed out that I could have said "using Prime Numbers" or "a complex mathematical function" - your audience are intelligent.

Audience

Speaking of the audience... Do feel free to interact with them. I love asking my audience questions and getting them to cheer. It helps show the judges just how well you connect with people. And it probably doesn't hurt your chances with the audience vote!

During the interval, and after the show, I chatted to people in the audience. I was enormously gratified to have one 12 year old girl ask me how she could make an ENIGMA machine with her arduino. I also had a young boy ask what programming languages he should be learning now that he had mastered Scratch.

Finally

Just as I was writing this post, I found out that I hadn't made it through to the final. I'm a little sad - but given the strength of the competition, I'm not surprised.

If there is a FameLab near you, please enter the competition. Spend 3 minutes sharing your passion for science with a room full of people - it's an uplifting and exhilarating experience.

Amy O'Donnell from Oxfam lead a discussion about how the charity is seeking to improve the way that Aid Agencies deal with the data they collect.

Oxfam collects data for many different reasons - sometimes it is incidental (for example the bank account details it needs to make payments), sometime it is deliberate (for example when conducting a survey about how aid is used).

Protecting personal data is often a legal requirement - although if you're a British NGO storing data about people from Philippines on a Cloud service hosted in the USA, knowing which data protection principles to follow is not simple! For Oxfam, protecting personal data is a necessity - the data they deal with often involves ethnicity, corruption, fragility, abuse, and human misery. Every datum could be a weapon in someone else's hand.

Data is like energy; it can never truly be destroyed. At best it can be manipulated until it is hard to reconstruct. This is why data collectors have to be wary about how they create data to ensure that they're not leaving a trail for malicious actors to follow.

How do we make this stuff interesting?

At a high level, most organisations know that keeping personal data private is sacrosanct - but how do they convey the message to those collecting the data and those from whom the data are being collected?

Instilling a sense of responsibility needs to be a priority for agencies. OII researcher Sanna Ojanperä talked about designing research methodologies in such a way that one minimises the amount of "dangerous" data which is available. Two particularly good resources she mentioned were the Research Ethics Guidebook and the free ebook "Ways to Practise Responsible Development Data".

In my opinion, what's just as necessary is ensuring that the people on the ground not only understand why this is important - but have the tools to support them. One young researcher at the event bemoaned the fact that the secure storage service he had to use was far less convenient than Google Drive. It may be less safe, but it's easier.

Who can blame him? Users dislike sub-standard tools. And when a phone (the primary data capture device) offers such effortless access to an easier way of doing things, it is natural that researchers will gravitate to a moderately more convenient method rather than following the strict and restrictive best practices.

Researches also need to understand that nearly everything is data! An excellent example of this is photography. The meta-data in a digital photograph can be used to determine the exact location of where the photo was taken, which direction the photographer was facing, which camera was used, what time the photo was taken, not to mention that the photograph itself contains the ethnicity of the subjects and who they associate with. When a researcher puts a photograph of their subjects up on their Facebook page, they may unwittingly be exposing multiple facets of personal data!

Does an elderly man, who has never used the Internet, fully understand the consequences of having his photo taken? Photos are tiny scraps of paper which live in a book and are rarely seen, aren't they?

This brings us round to the issue of "Informed Consent".

Informed Information

Most research guidelines are explicit in that subjects have to give informed consent. They must understand what data are being collected and to what purpose they will be used. This brings with it several major problems.

What Are Known Unknowns?

Do people who rarely, if ever, use computers fully understand exactly what their information can be used for? Given that data researchers often don't know what they will find, or how research techniques will develop, can they ever truly inform a participant about how the data will be used?

Data Reuse

Suppose, in 30 years time, a researcher wants to use this data set? Do participants have to be contacted again if the use is significantly outside that of the original research? What if the data were successfully pseudo-anonymised? Are we to accept that this data set is now off limits no matter what valuable information it may contain?

Data Sharing

Data does need to be shared sometimes. It could be via a court order, it could be via a reciprocal agreement with another aid agency.

We've all heard tales about private data thrown onto a USB stick and then being lost. Once data are shared with a third party, how much control do you hold over how it is used? What if multiple pseudo-anonymised data sets are gathered and then used to de-anonymise the data?

Withdrawal

Subjects are given the right to withdraw at any time. That's a sensible policy which will hopefully reassure participants who may feel uncomfortable about their data being misused. But withdrawal has its downsides. A user with a pseudo-anonymised data set may be able to correlate changes to the data with known changes to the participant lists.

Convincing your cousin to drop out of the research and you stand a good chance of working out which "anonymous" participant she was.

Does withdrawing from future collection also mean that past data ought to be removed? Participants may think so. That could lead to irreparable destruction of data rendering the research useless.

The Dangers Of Digital

Doing fieldwork with a laptop or a mobile phone has many advantages - near instant analysis for one - but it's not without its problems.

For a start, expensive electronic equipment can be an attractive target for thieves. While they may "only" want your iPhone, they may end up with a cache of highly confidential, unencrypted, personal information!

Asking people to fill in forms using a computer may unfairly skew the demographics of the data. Younger or wealthier people may be over-represented.

Even though mobile data signals penetrate most of the world, their are still large swathes without any coverage. For time sensitive data - or even just backup purposes - this can be a critical impediment.

Most countries with Data Protection laws allow data subjects to request data about themselves. In the UK this is known as a Subject Access Request. Despite the advances in technology, it may not be possible for a remote worker to access such information.

Finally, massive amounts of data available instantly may do more hard then good in the hands of non-professionals. While a village may be able to quickly see data on how aid money is benefiting them, do they have the statistical experience to understand and correctly interpret the data? That may sound patronising, but it is of real concern to people who produce data driven reports - they have to assume a baseline understanding of, say, standard deviations which may not be present in those looking at the data.

The Data Tightrope

Data is power. It can be used for good, or it can be a volatile source of wanton destruction.

Collecting and using data is as much about understand and mitigating risks as it is about physically collecting information.

There is a timeline for data - from pre-life (how should I collect this?) to after-life (can I dispose of this data when I'm done with it?) - every single moment of the data's existence should be carefully considered and controlled.

Do risks mean we shouldn't collect data? No - it is too valuable for that. But researchers have to remember that this isn't their data. Data are like the Goblin forged objects in Harry Potter:

Bill: "To a goblin, the rightful and true master of any object is the maker, not the purchaser. All goblin-made objects are, in goblin eyes, rightfully theirs."

Harry: "But if it was bought —"

Bill: "— then they would consider it rented by the one who had paid the money. They have, however, great difficulty with the idea of goblin-made objects passing from wizard to wizard."

Harry Potter and the Deathly Hallows

As mere custodians of people's data, we have solemn responsibility to ensure that it is used only for good, and treated with the utmost care and respect.

You can read more about Oxfam's policies, and give your feedback, at http://policy-practice.oxfam.org.uk/.

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.