Companies like InfinaDeck make the headlines in tech news from time to time, normally following the release of a shiny new machine that adds physical phenomena (such as haptics or walking) to existing VR experiences. This approach is great, and likely the direction that VR experiences are headed in the future, but mainly because users of the technology don't have existing infrastructure that can be adapted for VR.
But what if you do already have a £12 million set of actuators? The Galactica ride at Alton Towers is a virtual reality roller coaster, where riders traverse the 2,700ft track whilst wearing VR headsets. This results in a roller coaster that's unlike any other. The ride is themed as a spaceship flight which uses wormholes (totally not modelled as stargates) to visit several different planets millions of light years away.
I really enjoyed my trip on Galactica, but it did highlight some amusing problems that arise when you take the VR to the physical simulator, instead of the other way around. Samsung VR headsets, for instance, were not designed to offer the buttery smooth response times that are required when the headset itself (as opposed to the in-game camera) is moving at 75km/h. Similar problems arise with the headset straps, which struggle to keep the goggles in place when users hit 3.5g during the ride's loops and turns.
Still, these are necessary evils when fitting a roller coaster with VR, without designing an entirely new bespoke (and therefore hella expensive) system from scratch. But even with better technology in the headsets, the on-rails nature of the roller coaster really limits the type of experiences you can create with it.
What I would be interested to see done, is a VR coaster experience designed around fear. The singular most terrifying experience I've had in VR was when I hacked Mirror's Edge to use the Oculus Rift. During a mission I mistimed a jump and fell off the side of a skyscraper. On the way down, with the ground rushing up to meet me, and the wind whistling by my ears, I felt something akin to true fear. The whole concept of the roller coasters centres around this type of experience (and exploiting these kinds of fears), so here's to hoping that one day we get a ride that targets specific fears, like the fear of falling.
(as an aside, am I the only one who found it really weird having wind blowing in my face whilst I was ostensibly in space?)
07/02/2018
Capture the Flag: A Primer
Note: this article was written in June 2017
It's true that cyber security related courses and certifications are becoming more popular. But it will take a long time to build and develop a workforce of the size that is needed, both globally and in the UK. For less experienced employers the broadness of the field and lack of universal certifications can make it difficult to get what they want. That these certifications are practical in nature undoubtedly increases their appeal to organisations, but very few of them reflect the adversarial nature of the security game in reality. Static questions, like those you'll find on the CIISP exam, won't adapt and fight back. A real attacker will.
So with a number of years before the industry slows its growth and begins to mature, and a disconnect between the nature of certifications and reality, what's the best way for employers to fill the security related positions they have now?
Perhaps better thought of as competitive security, challenges require a combination of problem solving and technical prowess to solve. Competitions vary from groups attacking and defending infrastructure to individuals solving small puzzles. Any topic is fair game: cryptography, forensics and reverse engineering are favourites, but it's not unknown to see participants tackling phishing emails or physical locks. Knowing how to use the industry standard tools required to solve these problems is a valuable skill in itself. Hands-on experience cements good practice - you can be told WEP secured networks are bad, but breaking one in 5 minutes with Aircrack really drives it home.
CTFs thrive because they focus on the thrill of solving problems, which means that there's plenty of discussion about solutions. This environment fosters learning and collaboration, with newcomers being encouraged to grow rather than being put off due to inexperience. And it's easy to forget that while these skills are obviously applicable to a career in cyber security, knowing how the bad guys get in is beneficial for developers, managers, and other IT roles as well.
In this way, the downtime between competition rounds acts like an informal interview process - sponsors are able to see how candidates work and highlight their own offerings, while students are given the opportunity to ask questions about life in the industry. It represents a low-cost, high-impact way to engage with students who may miss schemes buried in the usual deluge of marketing material given to soon-to-be graduates.
On the international stage, the Atlantic Council runs a yearly cyber security policy competition - Cyber 9/12. Taking place in Geneva, Washington, and Sydney, it simulates the day after a cyber crisis. Participants are given a briefing from which they must develop policy options that are judged by a panel of diplomats, industry practitioners, and military personnel. The real-world application is clear - this year's scenario depicted ransomware attacks on hospitals and public transport a month before the NHS and Deutsche Bahn fell victim to the Wannacry attack.
For companies, being part of CTF events (either alone or in collaboration) presents a golden opportunity for recruitment, PR, and outreach. Active involvement in hands-on cyber security events can also sharpen your own technicians' skills, drawing on their experiences to craft devious challenges. And for students? It's certainly more exciting than the traditional interview process.
A lack of skills
For a number of years technology firms have been complaining about facing problems hiring enough security staff. The Financial Times reports a similar story - on average cyber security jobs are harder to fill than other roles, something which is only going to get worse as demand for experts grows faster than supply. According to industry association ISC squared two thirds of UK companies do not have enough information security personnel to meet their needs, with the global shortfall in cyber security experts predicted to rise to over 1.8 million by 2022 . As events like the recent WannaCry attack continue to raise the profile of cyber security in the public consciousness, an increasing number of businesses are going to find themselves facing a problem without a solution.It's true that cyber security related courses and certifications are becoming more popular. But it will take a long time to build and develop a workforce of the size that is needed, both globally and in the UK. For less experienced employers the broadness of the field and lack of universal certifications can make it difficult to get what they want. That these certifications are practical in nature undoubtedly increases their appeal to organisations, but very few of them reflect the adversarial nature of the security game in reality. Static questions, like those you'll find on the CIISP exam, won't adapt and fight back. A real attacker will.
So with a number of years before the industry slows its growth and begins to mature, and a disconnect between the nature of certifications and reality, what's the best way for employers to fill the security related positions they have now?
Introducing Capture the Flag
Penetration testing, offensive security, ethical hacking - all terms you've doubtless heard before. Capture the Flag (CTF) may not be, but it takes the above and moves away from a production setting while adding a competitive spin. The CTF scene has taken off in the UK over the past few years: across the country hundreds of students regularly get together to take part in cyber security themed competitions, with Cyber Security Challenge UK (CSCUK) coordinating the majority of the nation's events. The online community is even larger; international events take place every week, open to both teams and individuals (see ctftime.org).Perhaps better thought of as competitive security, challenges require a combination of problem solving and technical prowess to solve. Competitions vary from groups attacking and defending infrastructure to individuals solving small puzzles. Any topic is fair game: cryptography, forensics and reverse engineering are favourites, but it's not unknown to see participants tackling phishing emails or physical locks. Knowing how to use the industry standard tools required to solve these problems is a valuable skill in itself. Hands-on experience cements good practice - you can be told WEP secured networks are bad, but breaking one in 5 minutes with Aircrack really drives it home.
CTFs thrive because they focus on the thrill of solving problems, which means that there's plenty of discussion about solutions. This environment fosters learning and collaboration, with newcomers being encouraged to grow rather than being put off due to inexperience. And it's easy to forget that while these skills are obviously applicable to a career in cyber security, knowing how the bad guys get in is beneficial for developers, managers, and other IT roles as well.
The New Infosec Interview
CTFs represent a unique opportunity for employers to directly connect with the best and the brightest when it comes to cyber security skills. As the introduction to this article suggests, the benefits of competitive security are not limited to those competing. Many companies are already waking up to the opportunity; CSCUK alone has 35 sponsors and 41 affiliates. Because participants attend events out of a passion for computer security, many are actively looking for jobs or internships and are only too happy to be approached by employers looking for talent.In this way, the downtime between competition rounds acts like an informal interview process - sponsors are able to see how candidates work and highlight their own offerings, while students are given the opportunity to ask questions about life in the industry. It represents a low-cost, high-impact way to engage with students who may miss schemes buried in the usual deluge of marketing material given to soon-to-be graduates.
Beyond Technical Skills
One would be forgiven for thinking that CTFs are focused solely on technical knowledge. While there are rewards for the most technically adept, competition organisers are looking for more than just hard skills. Students advancing to the CSCUK Face to Face (F2F) events must show maturity and leadership. These events have a dress code and the atmosphere is more of professionals at work than hooded teenagers staring at screens in their bedrooms.On the international stage, the Atlantic Council runs a yearly cyber security policy competition - Cyber 9/12. Taking place in Geneva, Washington, and Sydney, it simulates the day after a cyber crisis. Participants are given a briefing from which they must develop policy options that are judged by a panel of diplomats, industry practitioners, and military personnel. The real-world application is clear - this year's scenario depicted ransomware attacks on hospitals and public transport a month before the NHS and Deutsche Bahn fell victim to the Wannacry attack.
In Summary
All indications point to the continued growth of the competitive security scene. Students are seeing cyber security as an increasingly accessible and fulfilling career path. Changes to the national curriculum also promise to engage upcoming generations with computing.For companies, being part of CTF events (either alone or in collaboration) presents a golden opportunity for recruitment, PR, and outreach. Active involvement in hands-on cyber security events can also sharpen your own technicians' skills, drawing on their experiences to craft devious challenges. And for students? It's certainly more exciting than the traditional interview process.
CTF Events: Where to Get Started
- CSCUK Face to Face: Taking place four times a year, F2F events pit the best players from CSCUK's online games against fiendish scenarios devised by cyber security organisations. Those impressing the judges are invited onto a prestigious yearly `Masterclass' event, and are open to anyone 16 or over not currently employed in a cyber security role. See cybersecuritychallenge.org.uk/competitions for more information on all CSCUK events.
- CyberCenturion: For younger competitors CSCUK run the CyberCenturion program for teams aged 12-18. The battle lasts for three rounds, culminating in a national final.
- CyberGames: Aimed at schools, CyberGames is a one day event run by CSCUK similar to the face to face competitions mentioned above. In addition to engaging pupils it also offers resources and training to teachers.
- Inter-ACE: Students at any of the 13 universities identified as Academic Centres of Excellence in Cyber Security Research can enter this yearly event at the University of Cambridge. The university also runs the Cambridge to Cambridge contest in collaboration with MIT. See https://inter-ace.org and http://cambridge2cambridge.csail.mit.edu.
- Cyber 9/12: For those wanting a less technical focus the Atlantic Council runs Cyber 9/12, a two day event hosted at the Geneva Centre for Security Policy. Participants must develop policy solutions and pitch them to practitioners, diplomats, and NATO personnel. See http://www.atlanticcouncil.org/programs/brent-scowcroft-center/cyber-statecraft/cyber-9-12.
18/11/2017
Cyber Security Challenge UK Masterclass
This week saw the 7th CSC Masterclass take place at BT's headquarters in London, and I was luck enough to have earned a place amongst the finalists after the PGI face to Face earlier in the year.
The competition was headed up by BT, but the National Crime Agency had organised the first challenges for Sunday evening. We had been recruited by international shipping company Fast Freight Limited to gather evidence about a recent intrusion into the company's systems, allegedly by the ex-CISO John Smith.
We had a tip-off that an anonymous source had some dirt on Smith, so we headed out into the streets of London to make the exchange. While we were sitting on a park bench at the rendevouz point, a man came up to us and started asking for directions to St Pauls. While we were talking, he passed us a USB stick underneath the map he was holding. The game was on.
At this point the bad guys were on to us, and we had to try and escape our tail as we made our way across the city to meet another contact. Unfortunately for us, those surveilling us were NCA officers who were (surprise surprise) rather good at their jobs. We thought that we had done a good enough job, changing jackets, splitting up, and ducking down side streets, and yet they were still photographing us. Despite the fact that they never let us out of their sight, we had no real idea who had been assigned to follow us.
After collecting the information from the source we headed back towards the hotel where we were staying, we loitered around the Tower Hill monument for a while. Mid-skulk we were interrupted by a police officer who told us that there had been reports of people dealing drugs in the area. Uh oh. At this point the copper began to search us, and just as my brain arrived at the conclusion that something wasn't right I saw my teammate drop the USB stick into the offered evidence bag. At this point the "policeman" books it off into the night, never to be seen again...
The technical part of the competition wasn't anything special, but the other things around it were what made the event special. Airbus had set up a robot arm to represent the freight part of Fast Freight Ltd., and when we got hacked by the BT red team a klaxon proceeded to go off, followed by the robot arm demolishing our little shipping containers and dancing. Finally, on Tuesday afternoon we had compiled enough evidence relating to Mr Smith to take the fight from the forensics lab to the courtroom. BT had brought in a group of Barristers to make the whole scene come alive. This was great until they started to cross examine us, and like the surveillance officers they were rather good at their job!
Overall, the challenge was a lot of fun, due largely to the fact that they paid so much attention to the details around the technical core that every CTF has. From the clandestine romp around London to the Raspberry Pi we found glued to the underside of our team's table, at every turn we had to think like people who really were investigating an insider threat. And that, in the end, was what made the three days we spent in London something really special.
The competition was headed up by BT, but the National Crime Agency had organised the first challenges for Sunday evening. We had been recruited by international shipping company Fast Freight Limited to gather evidence about a recent intrusion into the company's systems, allegedly by the ex-CISO John Smith.
We had a tip-off that an anonymous source had some dirt on Smith, so we headed out into the streets of London to make the exchange. While we were sitting on a park bench at the rendevouz point, a man came up to us and started asking for directions to St Pauls. While we were talking, he passed us a USB stick underneath the map he was holding. The game was on.
At this point the bad guys were on to us, and we had to try and escape our tail as we made our way across the city to meet another contact. Unfortunately for us, those surveilling us were NCA officers who were (surprise surprise) rather good at their jobs. We thought that we had done a good enough job, changing jackets, splitting up, and ducking down side streets, and yet they were still photographing us. Despite the fact that they never let us out of their sight, we had no real idea who had been assigned to follow us.
The technical part of the competition wasn't anything special, but the other things around it were what made the event special. Airbus had set up a robot arm to represent the freight part of Fast Freight Ltd., and when we got hacked by the BT red team a klaxon proceeded to go off, followed by the robot arm demolishing our little shipping containers and dancing. Finally, on Tuesday afternoon we had compiled enough evidence relating to Mr Smith to take the fight from the forensics lab to the courtroom. BT had brought in a group of Barristers to make the whole scene come alive. This was great until they started to cross examine us, and like the surveillance officers they were rather good at their job!
Overall, the challenge was a lot of fun, due largely to the fact that they paid so much attention to the details around the technical core that every CTF has. From the clandestine romp around London to the Raspberry Pi we found glued to the underside of our team's table, at every turn we had to think like people who really were investigating an insider threat. And that, in the end, was what made the three days we spent in London something really special.
22/10/2017
A big MisCALculation
The theme for this week's CompSoc social was esolangs, which gave me the opportunity to do something that I've been meaning to do for a few years now: write a program in INTERCAL.
INTERCAL is designed on the basis that a person whose work is incomprehensible is held in high esteem. The sort of work where you're boss appears, asks what you are doing, and then nods slowly whilst going "uh huh".
So Toby and I set about making a program which would print out the CompSoc logo using Os and Xs:
OXOX
XXXO
OXOO
OXXO
Seems easy, right?
This is relevant because output characters can be thought of occupying the reverse of this tape. That is to say that that the output head (which is thankfully seperate from the input head) can only move to the left in descending order of charcter codes (so from Z back to A). The task of printing characters thus becomes the task of describing the movements of the output head along the tape.
This isn't too bad until you realise that because the output head moves from right to left, it reads the binary of the characters it encounters from most significant bit to least significant bit. If the head is moved to position 108, presumably because the user was attempting to print an 'l', the output head will read the binary representation of 'l' backwards. In this way 0110 1100 becomes 0011 0110, which is in fact '6'. As you might imagine, this quickly becomes confusing! Printing subsequent characters will need to take into account that the head is now starting from an offset of 108 instead of 0.
Each line of INTERCAL must start with either PLEASE, DO, or PLEASE DO. These can be used interchangably in order to improve program aesthetics. It is worth noting that a program which is too impolite will not compile. This line allocates the array that we are going to use to hold the program output, and assigns it a length of 20.
2. PLEASE DO ,1 SUB #1 <- #14
Set the first subindex (SUB) of the array to 14. This represents a shift of 14 places to the left of the zero starting index of the output tape, which is ASCII character 242 (256-14), which is 1111 0010 (‗). This is read as 0100 1111, which is character 79, which is the 'O' that we want. Be careful not to use PLEASE too liberally, as the compiler will refuse to compile any overly polite programs as it gets suspicious.
3. DO ,1 SUB #2 <- #216
The next character of the output needs to be X, which is charcter 0101 1000 (88). This means we need to move to character 0001 1010 (26), which is the substitute character (␚). Because the output head is already at character 242 the offset we need is thus 242-26 which is 216 (remember that we can only move the head to the left).
...
4. PLEASE READ OUT ,1
Next we have the program read out the contents of the array by making the output head follow the pattern we stored in the array.
5. PLEASE GIVE UP
Then the program gives up. At this point, I suggest you do too.
Check out the code on Github.
INTERCAL is designed on the basis that a person whose work is incomprehensible is held in high esteem. The sort of work where you're boss appears, asks what you are doing, and then nods slowly whilst going "uh huh".
So Toby and I set about making a program which would print out the CompSoc logo using Os and Xs:
OXOX
XXXO
OXOO
OXXO
Seems easy, right?
How printing in INTERCAL works
Intercal processes input on a cyclical tape that has one cell representing each of the 256 extended ASCII characters. The tape head begins at zero when the program starts, and can only move left.This is relevant because output characters can be thought of occupying the reverse of this tape. That is to say that that the output head (which is thankfully seperate from the input head) can only move to the left in descending order of charcter codes (so from Z back to A). The task of printing characters thus becomes the task of describing the movements of the output head along the tape.
This isn't too bad until you realise that because the output head moves from right to left, it reads the binary of the characters it encounters from most significant bit to least significant bit. If the head is moved to position 108, presumably because the user was attempting to print an 'l', the output head will read the binary representation of 'l' backwards. In this way 0110 1100 becomes 0011 0110, which is in fact '6'. As you might imagine, this quickly becomes confusing! Printing subsequent characters will need to take into account that the head is now starting from an offset of 108 instead of 0.
Annotated snippets
1. DO ,1 <- #20Each line of INTERCAL must start with either PLEASE, DO, or PLEASE DO. These can be used interchangably in order to improve program aesthetics. It is worth noting that a program which is too impolite will not compile. This line allocates the array that we are going to use to hold the program output, and assigns it a length of 20.
2. PLEASE DO ,1 SUB #1 <- #14
Set the first subindex (SUB) of the array to 14. This represents a shift of 14 places to the left of the zero starting index of the output tape, which is ASCII character 242 (256-14), which is 1111 0010 (‗). This is read as 0100 1111, which is character 79, which is the 'O' that we want. Be careful not to use PLEASE too liberally, as the compiler will refuse to compile any overly polite programs as it gets suspicious.
3. DO ,1 SUB #2 <- #216
The next character of the output needs to be X, which is charcter 0101 1000 (88). This means we need to move to character 0001 1010 (26), which is the substitute character (␚). Because the output head is already at character 242 the offset we need is thus 242-26 which is 216 (remember that we can only move the head to the left).
...
4. PLEASE READ OUT ,1
Next we have the program read out the contents of the array by making the output head follow the pattern we stored in the array.
5. PLEASE GIVE UP
Then the program gives up. At this point, I suggest you do too.
Check out the code on Github.
17/09/2017
Hellblade: Senua's Sacrifice
Hellblade: Senua's Sacrifice is a deeply unsettling exploration of psychosis, grief, and death. Self-published by Ninja Theory, who have previously released Devil May Cry, Enslaved, and Heavenly Sword, the game is part of a wider effort by the studio to champion "independent AAA" games.
Not played the game before? Here is my advice:
- Don't play unless you can play with headphones. They really make the game the experience that it is, and you can only experience it for the first time once.
- Make sure you aren't distracted while playing. At first I was being interrupted by pings and buzzes from my phone and the GOG overlay, and it really drags you out of the experience.
- Stop reading articles about Hellblade :P Seriously, the game will be better the less you know in advance.
With that said, here's the rest of the article :D
I. Visuals
The first thing that hits you when you start playing Hellblade is that this game is a looker. For reference, all of the pictures in this post are screenshots I took. Ninja theory evidently noticed this too, as the game comes with an in-depth photo mode that lets you pause the action and line up screenshots. The attention to detail on Senua is astonishing, and is backed up by an impressive performance by Melina Juergens (even though the script doesn't require her to exhibit a huge range).Senua's Sacrifice makes great use of filters layered over the top of the game. They take the already dark world and twist it into a true hellscape. The more intense sections of the story, such as escaping from the beast, are characterised by smothering overlays that lead to a disorienting sensory overload.
One thing that I did notice while I was playing Hellblade was that occasionally the animation would dip down into the uncanny valley. Particularly in the earlier sections of the game Senua's eyes would take on a distinctly inhuman look, but this is something that goes away as the story progresses. Occasionally I also had issues where the camera would clip through walls (particularly on spiral staircases), and the detailing on objects like torches is jarringly low-res. All little niggles, but they stand out when the other visual work is near perfect.
II. Audio
But to build the atmosphere required for a story such as Hellblade's, you need more than an environment that just looks oppressive. The game makes use of binaural audio to make it feel like the voices that haunt Senua's existence are in your head too (the furies). They accompany you throughout the game, and are fickle companions. Sure, sometimes they encourage you. They tell you that you're strong enough and that you can get through the trials ahead. But those same voices will quickly shift to messages of despair and hopelessness. More than a few times I started to second guess myself as I was trying to solve puzzles, the furies telling me that I was going the wrong way. That I was being too slow. That I couldn't see the obvious solution.
Ninja Theory have also done something really clever here to bring the uneasiness levels to something unlike any other game I've played. Everything from the soft pops of the whispering voices to the pitter-patter of rain and crackling of fire is an ASMR trigger. The reason why you feel like your spine is tingling in Hellblade is because it actually is. The game made my skin crawl in a way that was overwhelming at points, and makes the game draining and emotionally exhausting in a way that's rare for AAA action games. That and the flawless voice acting in this game really draws you in to the experience - the cast deserve credit for a job well done.
The game takes several opportunities to play with sensory deprivation. There is a section during the game where Senua is effectively blind, and has to use sound to navigate, and another where making noise is what attracts the attention of the monsters. These both work really well because of the tight audio, and are all the more fraught because you're only afforded hazy outlines of what's lurking in the dark. By forcing you to make use of previously ignored audio cues the game puts a new spin on familiar environments and mechanics.
The game takes several opportunities to play with sensory deprivation. There is a section during the game where Senua is effectively blind, and has to use sound to navigate, and another where making noise is what attracts the attention of the monsters. These both work really well because of the tight audio, and are all the more fraught because you're only afforded hazy outlines of what's lurking in the dark. By forcing you to make use of previously ignored audio cues the game puts a new spin on familiar environments and mechanics.
III. Gameplay
Gameplay falls broadly into two categories: combat and puzzle solving. The former feels a little out of place, not really serving any narrative purpose except to reinforce Senua's identity as a warrior. But it's what Ninja Theory are good at, and fights have a weight to them that is both very satisfying and somewhat grotesque. The focus mechanic helps to break things up during combat, and partners well with the adaptive difficulty to make sure that fighting feels fraught but not impossible. As an aside, I really like the idea of the game altering the difficulty level behind the scenes - much closer to Left 4 Dead's AI director than Modern Warfare's condescending prompts that suggest you're not part of the intended audience of the game.
Puzzle solving is centred around the fact that Senua sees the world differently, and is strongly tied in to the overarching narrative surrounding her psychosis. This was always going to be a tricky one to get right - make it too easy and it feels throwaway and token, but make it too hard and you risk drawing people out of the immersion as they traipse back and forth looking for an obscure clue. Overall I felt that the puzzles were pitched about right; the visual overlays and level design made it clear where you needed to be to progress, but stopped short of giving you any information on how to actually find a solution.
The gameplay also portrays a more nuanced view of Senua's physical capabilities. Unlike the protagonists of similar games she's strong but not bulky, and panics a little the first times she has to negotiate a high beam in a way that gave me a little bit of vertigo. Plus, when Senua is hurt in combat, this is reflected in the gameplay mechanics. She can't move as fast, and the player has to adapt how they play in order to beat what are more dangerous foes now that she can't dodge and parry at her usual pace.
The gameplay also portrays a more nuanced view of Senua's physical capabilities. Unlike the protagonists of similar games she's strong but not bulky, and panics a little the first times she has to negotiate a high beam in a way that gave me a little bit of vertigo. Plus, when Senua is hurt in combat, this is reflected in the gameplay mechanics. She can't move as fast, and the player has to adapt how they play in order to beat what are more dangerous foes now that she can't dodge and parry at her usual pace.
IV. Story
The story takes a while to become interesting. I guess this isn't so bad, as you spend the first few levels getting the hang of the mechanics and settling into the world, but it would have been nicer to have felt a bit more involved during the earlier sections. Put another way, I felt like was watching Senua's story for a while before I really began playing it. The shift probably occurs when the game stops recounting episodes from the past and begins focusing on the Senua of the present.
The second half of the game builds on the paranoia and uncertainty that Senua experiences as a result of events from her past. Characters and voices shift as the story progresses, leaving you in a world where what's true begins to stop mattering as you discover that real, physical threats make up the minority of the dangers you have to face. As mentioned above, Senua's condition is presented as something that makes her see the world differently, and forces you to capitalise on this in order to make progress. Having to rely on this hazy view of reality only feeds the sense of paranoia built by the narrative.
The second half of the game builds on the paranoia and uncertainty that Senua experiences as a result of events from her past. Characters and voices shift as the story progresses, leaving you in a world where what's true begins to stop mattering as you discover that real, physical threats make up the minority of the dangers you have to face. As mentioned above, Senua's condition is presented as something that makes her see the world differently, and forces you to capitalise on this in order to make progress. Having to rely on this hazy view of reality only feeds the sense of paranoia built by the narrative.
The game plays with this by telling you during the first few levels that every time you fail, the dark rot will spread up Senua's arm until eventually it will reach her head and consume her. The threat of permadeath hangs over you during the game and adds to the general anxiety induced by the atmosphere and the furies. But there is no permadeath. You become paranoid after believing something the game told you which isn't true. It's a startling way of getting players into Senua's mindset, and helps you to understand that what she's experiencing is real for her in a way that is hard to do for psychotic hallucinations where you know that something is imagined.
To wrap up, this game is something special (it reminds me a lot of Spec Ops: The Line in the way the story plays out). Easily one of the most unsettling experiences I've had in a while, and I hope that future horror experiences take note of the more novel techniques used in Hellblade. It's also really exciting to see a mainstream game tackle the portrayal of a mental health condition well. Senua's psychosis is not the sole thing that defines her: in her own words, she has other stories to tell.
28/04/2017
Cyber catastrophe - like a normal catastrophe, but with more cyber?
Last week I was in one of three Oxford teams which traveled to the Geneva Center for Security Policy last week to take part in a cyber policy competition against 21 other teams from around the world. Each team was sent an intelligence brief before the competition, from which they had to prepare a briefing outlining their policy suggestions to an assembled task force. The exercise was an attempt to simulate challenges that face decision makers during a crisis. The competition was tough, with colonels and diplomats heading up teams from military academies and schools of governance and policy. After seeing how seriously the other teams were, our own delegation (coached by the first professor we could grab on the afternoon of the deadline) seemed lackluster in comparison.
After each presentation, teams had to answer questions from the judges before being scored for the round. Two of our teams managed to rank high enough and made it through to the second round on day two, whilst the third was left to enjoy Geneva in the sunshine. While they were catching up on sleep, the advancing teams were given a new briefing at 20:00, asked to prepare a new presentation. The catch was that instead of having two weeks to prepare a new briefing, this time we had until 07:00 the next morning. Cue a long night trying to prepare a set of policy alternatives that would get us through to the final on Friday afternoon.
Unfortunately neither of the qualifying Oxford teams made it through to the final, which was eventually won by the home team from the Geneva Center for Security Policy. One thing that we we missing was a strong media strategy across the board. As one of the judges rightly pointed out - media isn't optional in a crisis situation. Secondly, teamwork is key; teams going into Cyber 9/12 that hadn't worked together before were at a serious disadvantage when the going got tough. Another strategy the winning teams employed was drawing a clear line between policies which considered the unfolding events a criminal incident, and those that escalated it to a matter of national security.
Overall the event was really insightful, and I'm glad I made the most of the opportunities I had around the presentations and keynotes to ask the assembled experts how best to become more involved in the policy sphere. We'll be back in Geneva next year for certain, and maybe then we can bring the trophy home to Oxford.
26/02/2017
Competitive Securiwhat?
Competitive Security - apparently that's a thing. Otherwise known as Capture the Flag (CTF), these events pit teams against each other in an attempt to compromise systems and solve challenges. After taking part in a few, here are some observations I've made.
1) Being comfortable with Linux is half the battle
The problems that you have to solve during a CTF will be hard, and the last thing you want interrupting your thought process is five minutes of fumbling while you try and remember how to compile something with GCC. This is something that comes with practice, so make sure you spend some time after each event going over the things that you were embarrassed you couldn't do! Using Linux on a daily or semi-regular basis is the best way to proactively build up these skills outside of competitions; you'll find that over time the number of non-standard tasks you need to do builds up until eventually you'll be navigating the command line with more confidence.
2) Competitions are not the place to learn new skills
They're great places to highlight the things you need to work on, and you will pick up tips and tricks, but it's unreasonable to expect to come away from an event knowing how to use a tool or technique that you didn't know when you arrived that morning. One way to mitigate this is to corner people you want to learn from during breaks or after the close of play. This way you can still make use of them as teachers without it getting in the way of what you're there for - the competition. As above, make a note of what you struggled with so you can get some practice before the next event, and don't start googling C++ hello world tutorials or asking the network guru about WiFi frequency bands when there are puzzles to solve.
3) The 10X factor
Excusing the slightly cheesy name given to it by a company I interned for, this refers to the idea that it's normally better to sacrifice some of your own productivity in order to keep your team working at full efficiency. Everyone in the team should be roughly aware of what each member is working on - if people are starting to drift, call a huddle or go around and get everyone up to speed. If you don't you'll just end up wasting effort when you forget to tell the network specialist that you also connected to the VPN and they end up spending half an hour defending your operation from this new adversary who's running Kali. Doubling up and working in pairs can help to reduce typos and silly gotchas, but more than two people round a keyboard can end up with the situation where everyone thinks someone else is paying attention.
I feel like there should be something here about having fun, but that's probably unnecessary...
01/11/2016
Gaze into the IRIS
After playing around with/doing research with a pair of the department's quadcopters as part of my masters dissertation, getting my own drone seemed like a good idea. The problem is that commercially available drones cost a lot of money - the low spec Parrot AR 2.0 model that Warwick lent us costs about £200 (and was even more at the time it was released). There is an alternative though, which is to make your own!
Step one was creating the frame. I found a set of designs for the IRIS+ by 3D robotics and sent one copy of each component to the Radcliffe Science Library (RSL) here at Oxford, and 24 hours of printing later (5 days real time) the first parts were ready. It took another 13 hours before the whole frame was ready, but the whole shell only cost £47. The only problem with this approach is that there's no component list to go with the IRIS; the only thing you have to go on is general advice and a list of suggestions from the MiniFactory comments.
3D printers work by extruding a small stream of plastic about 0.1mm thick, in layers that get built up over time. The plastic used here was polylactic acid, refered to as PLA, which melts at around 200 degrees and is biodegradable. Annoyingly, this method of layering up from the base of the printer means that printing curved or otherwise non-flat surfaces is difficult. One way to solve the problem (and the method that the RSL use) is to print a flat surface anyway and then layer supports up to the point where you actually want to print. On a smaller model this isn't so bad, but removing all of this excess material from the drone case was an arduous task. In an improvement from my previous rockets project, recourse to plasters was only required once!
Normally hidden from consumers, the inner workings of the average quadcopter are quite interesting. To be able to hover in mid air, opposite pairs of rotors must spin in the same direction, with adjacent rotors rotating in contrary directions. But while this makes hovering easy, it makes turning harder - increasing power to the clockwise motors will turn the drone in one direction, and vice versa for the counter clockwise motors. Banking and moving is achieved in a similar fashion but with adjacent motors instead of opposite ones.
Things get even more involved when you move to actual electronics. Each of the four motors must be connected to an electronic speed control (ESC) unit which is responsible for using a low power control signal to alter the speed of the motors using larger currents. This type of setup would normally require two separate batteries, which is not ideal when every gram counts. Battery eliminator circuits (BEC) solve this problem by allowing one power input from the battery to power both low voltage control and high voltage motor circuits, as well as prioritising control circuits in the event of power loss. The last thing you want when the battery goes is complete loss of control! In practise, most ESC units have built in BECs.
Next we get to the brains of the operation: the flight controller. This component is responsible for turning high level commands from the remote control into voltage changes at the ESCs. The controller also has to keep the aircraft stable through gusts of wind and other types of tilt by making slight adjustments to the motor speeds (informed by its gyroscope and accelerometers). Eventually I'd like to write my own flight controller, but making high frequency real time adjustments on what would probably end up being a Raspberry Pi is tricky. For now I'm sticking to something that's more likely to work first time.
The goal with the build was to make everything as modular as possible so that it would be possible to swap out components in the future, either for upgrades or to reuse kit in other builds. Coming in part two: putting the frame and electronics together!
Step one was creating the frame. I found a set of designs for the IRIS+ by 3D robotics and sent one copy of each component to the Radcliffe Science Library (RSL) here at Oxford, and 24 hours of printing later (5 days real time) the first parts were ready. It took another 13 hours before the whole frame was ready, but the whole shell only cost £47. The only problem with this approach is that there's no component list to go with the IRIS; the only thing you have to go on is general advice and a list of suggestions from the MiniFactory comments.
3D printers work by extruding a small stream of plastic about 0.1mm thick, in layers that get built up over time. The plastic used here was polylactic acid, refered to as PLA, which melts at around 200 degrees and is biodegradable. Annoyingly, this method of layering up from the base of the printer means that printing curved or otherwise non-flat surfaces is difficult. One way to solve the problem (and the method that the RSL use) is to print a flat surface anyway and then layer supports up to the point where you actually want to print. On a smaller model this isn't so bad, but removing all of this excess material from the drone case was an arduous task. In an improvement from my previous rockets project, recourse to plasters was only required once!
Normally hidden from consumers, the inner workings of the average quadcopter are quite interesting. To be able to hover in mid air, opposite pairs of rotors must spin in the same direction, with adjacent rotors rotating in contrary directions. But while this makes hovering easy, it makes turning harder - increasing power to the clockwise motors will turn the drone in one direction, and vice versa for the counter clockwise motors. Banking and moving is achieved in a similar fashion but with adjacent motors instead of opposite ones.
Things get even more involved when you move to actual electronics. Each of the four motors must be connected to an electronic speed control (ESC) unit which is responsible for using a low power control signal to alter the speed of the motors using larger currents. This type of setup would normally require two separate batteries, which is not ideal when every gram counts. Battery eliminator circuits (BEC) solve this problem by allowing one power input from the battery to power both low voltage control and high voltage motor circuits, as well as prioritising control circuits in the event of power loss. The last thing you want when the battery goes is complete loss of control! In practise, most ESC units have built in BECs.
Next we get to the brains of the operation: the flight controller. This component is responsible for turning high level commands from the remote control into voltage changes at the ESCs. The controller also has to keep the aircraft stable through gusts of wind and other types of tilt by making slight adjustments to the motor speeds (informed by its gyroscope and accelerometers). Eventually I'd like to write my own flight controller, but making high frequency real time adjustments on what would probably end up being a Raspberry Pi is tricky. For now I'm sticking to something that's more likely to work first time.
The goal with the build was to make everything as modular as possible so that it would be possible to swap out components in the future, either for upgrades or to reuse kit in other builds. Coming in part two: putting the frame and electronics together!
23/10/2016
The First Thinkpad
On holiday recently I had the opportunity to take a look around some of the places in the bay area which have played key roles in the history of computing. Despite the fact that most of the developments when it comes to what we now consider 'the computer' have happened in the last 100 years, scientists and inventors have been making progress in the field for over two millennia.
Anyway, there's not much more to show - otherwise this just becomes holiday snaps of a museum. Just remember that beyond being interesting, history can be a valuable guide when forging something new. Although a bit hackneyed, the well known George Santayana quote still applies:
As with most fields, most of the advancements beyond the few well known breakthroughs remain confined to the realms of obscurity. Now that I've committed to computer science as a pursuit, it was fascinating to be able to look into the past and be inspired by the pioneers who paved the way for the technology of today.
One of the things that stood out for me was one of the original think pads in the Computer History Museum. So many times, someone made a decision or said something that went on to be far more popular or influential than could ever have been imagined. What started out as a prompt on a notebook now adorns millions of laptops worldwide. Email is another prime example of something growing out of all proportion (for better or for worse).
Those who cannot remember the past are condemned to repeat it
24/07/2016
A font of knowledge
One of the projects which I had lined up for the lull after exams were over was to make a font. It's nice to go behind the scenes of something that everyone takes for granted, and unless someone somewhere has done a really bad job, never notices. Typography is important though, having an impact on how easy a text is to read, as well as shaping the way in which we think about what we're reading. The font that I'm creating has more of a script/handwritten style than the more commonly used ones, but it seemed like an easier starting point for a beginner.
The main tool involved for this project was FontForge, a free and open source font editor. At a basic level, the task is simple - create a glyph for each letter - right? The first thing that becomes apparent is that this means drawing a lot of glyphs. Obvious though it may seem, I hadn't done the calculation beforehand: 26 lower case, 26 upper case, 10 numerals, and about 30 bits of punctuation. So before you even consider multilingual support (another 10 or so marks and 50 anchor points) you need to create around 90 characters. And the second realisation follows the first, as soon as you get down to drawing your first letter - there's a lot to think about beyond just the shape of the letter.
Because each glyph is composed of a series of lines and Bezier curves (curves which are defined by two endpoints and a polynomial equation), you need to take the picture of the letterform in your head and replicate it in FontForge. So far so good, but what about serifs (the small lines attached to the ends of lines in some fonts), and the weight of each part of the letter? Many letters which appear to be equally weighted, such as the vertical and horizontal bars in a capital H, are not, because the letters look odd to the eye when balanced. Similarly with positioning. The dot of a lowercase i is slightly off-centre to offset the serif on the top of the stem (obviously not the case in a sans-serif font!)
Then we come to proportions and spacing. The shape and size of most of the letter shapes is often derived from others with similar forms. For example, the glyph for b is created from the stem of the i character combined with the bowl of the o character, and the shape and slant of the e also comes from that of the o. These relationships are key to making a font seem coherent, so that all of the characters feel like they have come from the same font. On a similar note, the feel is always more important here than precise values. Having characters which are not exactly symmetrical or evenly weighted will often look more pleasing to the eye than their mathematically perfect counterparts. Next, we have spacing. The letters above are equally spaced, and you can see that it looks off. The size and weight of the different glyphs has a lot to do with how close together they should be, as well as how symmetrical they are (An o will often have more balanced left and right spaces than an h, for instance). One can also 'kern' pairs of letters (or sets of letters) to make more precise adjustments to the spacing. This can often be seen after capital letters, such as where the a in Ta is adjusted to fit under the horizontal stroke of the T.
As with any project like this, there are endless tweaks and adjustments that you feel you need to make, and calling a font done is something you rarely feel happy doing. At some point I'll come back and finish off the more obscure punctuation glyphs and add some ligatures, but that's for another post!
The main tool involved for this project was FontForge, a free and open source font editor. At a basic level, the task is simple - create a glyph for each letter - right? The first thing that becomes apparent is that this means drawing a lot of glyphs. Obvious though it may seem, I hadn't done the calculation beforehand: 26 lower case, 26 upper case, 10 numerals, and about 30 bits of punctuation. So before you even consider multilingual support (another 10 or so marks and 50 anchor points) you need to create around 90 characters. And the second realisation follows the first, as soon as you get down to drawing your first letter - there's a lot to think about beyond just the shape of the letter.
Because each glyph is composed of a series of lines and Bezier curves (curves which are defined by two endpoints and a polynomial equation), you need to take the picture of the letterform in your head and replicate it in FontForge. So far so good, but what about serifs (the small lines attached to the ends of lines in some fonts), and the weight of each part of the letter? Many letters which appear to be equally weighted, such as the vertical and horizontal bars in a capital H, are not, because the letters look odd to the eye when balanced. Similarly with positioning. The dot of a lowercase i is slightly off-centre to offset the serif on the top of the stem (obviously not the case in a sans-serif font!)
Then we come to proportions and spacing. The shape and size of most of the letter shapes is often derived from others with similar forms. For example, the glyph for b is created from the stem of the i character combined with the bowl of the o character, and the shape and slant of the e also comes from that of the o. These relationships are key to making a font seem coherent, so that all of the characters feel like they have come from the same font. On a similar note, the feel is always more important here than precise values. Having characters which are not exactly symmetrical or evenly weighted will often look more pleasing to the eye than their mathematically perfect counterparts. Next, we have spacing. The letters above are equally spaced, and you can see that it looks off. The size and weight of the different glyphs has a lot to do with how close together they should be, as well as how symmetrical they are (An o will often have more balanced left and right spaces than an h, for instance). One can also 'kern' pairs of letters (or sets of letters) to make more precise adjustments to the spacing. This can often be seen after capital letters, such as where the a in Ta is adjusted to fit under the horizontal stroke of the T.
As with any project like this, there are endless tweaks and adjustments that you feel you need to make, and calling a font done is something you rarely feel happy doing. At some point I'll come back and finish off the more obscure punctuation glyphs and add some ligatures, but that's for another post!
19/04/2016
What the Hell Even is a Pueblo?
Pueblo is a board game game that was published by Ravensburger in 2002. It was designed by Michael Kiesling and Wolfgang Kramer. What follows is a short analysis of the strategies that emerge whilst playing the game. Unfortunately, if you have never played the game, this is probably inaccessible as it doesn't include a rundown on how to play to put things into context.
Put another way, the chieftain bunches up the players such that the scores appear closer than they are before the final pass is taken into account. Each player, regardless of their skill feels like they can win at this point, which is an amazing achievement on the part of the designers. The finals scores will still reflect the skill of the players, and everyone is happy. All in all this is an excellent game, and I hope this short analysis begins to cover some of the deeper strategies that emerge during play.
Building - Initial Exposure:
Building has a number of intricacies, and mostly comes down to a tradeoff between the immediate cost of placing a block against the expected discount in points accrued over the course of the game. Lets start with the former. The immediate cost of placing a block largely comes down to where the chieftain currently is on the board. If he is likely to visit incriminating squares soon then this cost will be high. If you can move him on your turn such that it is impossible for him to give you points in the next turn cycle, this cost may be lower or zero. To an extent this also depends on your next piece, in as much as being able to block a particularly egregious brick on your next turn (before a visit from the chieftain) may make it the optimal long term play.Building - Long Term Exposure:
Moving on to the expected discount over the course of a game, this metric asks the question of how many points you expect to expose each time the chieftain visits over the duration of the game. By way of an example, consider the first block placed at the start of the game. While the initial cost is high (see above), it is almost certain that the block placed next turn by your opponent will cover up one or more of its faces. In fact, by the time you get to place your next coloured block it may be completely hidden from the prying eyes of the chieftain. This is what makes a first turn play in the centre better than a similar one at the edge of the board. It also takes into account the remaining duration of the game. The first block on level one receives more weighting here than the first block placed on level three by virtue of the fact that the game only has a few turns left (compounded by the final check by the chieftain). The increase in points awarded as the pueblo gets taller has the nice effect of making later turns important (because they matter more than early ones) without making the first levels feel pointless.
Block Placement Order:
The way that the blocks are available to place has a few interesting properties. Initially, new players tend to fall into the trap of placing beige blocks first, in the belief that covering up exposed block faces sooner will benefit them. Then comes the realisation after their first game that this strategy falls down when they come to the final turn of the game and there are no good placement spots left. Now they do not have an opportunity to correct this inevitable bad placement and the game punishes this by having the chieftain make his final circuit. The next time they play they exclusively use their coloured blocks first, which is *almost* always correct. One fact that players often tend to realise after a few times playing the game is that being the first player to place on a new level is advantageous. For the price of a few points while your block is exposed, everyone else has to place around you and cover up the block you placed. What doesn't click is the connection between this and block placement order. Maybe it *is* optimal to place a common block this turn so that next turn, when the current level is all filled out, one can place the first block on the next level. It may well feel sub-par but the last places on levels one and two are often at the edges, which can never be covered up, as opposed to those at the beginning of a new level.
The Chieftain:
Oft mentioned in the above paragraphs, the chieftain is one of the more interesting game mechanics. I say he - it feels odd to have a gendered blob of molded plastic - but that is how the instruction manual refers to him/it/*whatever*. Anyway, by making it the players choice how far to advance him it introduces a whole extra game theory aspect to the turn cycle. The "If I move him here then the next player moves him there because they are trying to beat another opponent" lines are interesting and introduce a nice element of unknowable information which keeps the game fresh after a few plays. What really makes the chieftain stand out, however, is the fact that he is an amazing catch up mechanic. Think about it - by letting players choose who to screw over, the player in the lead will almost certainly accrue more points than if the chieftain had been moved by a die roll. That said, he doesn't actually impact the game in a meaningful way (the difference he makes is rarely enough to swing a victory), but he is a very visible way for players to feel like they can even the score.Put another way, the chieftain bunches up the players such that the scores appear closer than they are before the final pass is taken into account. Each player, regardless of their skill feels like they can win at this point, which is an amazing achievement on the part of the designers. The finals scores will still reflect the skill of the players, and everyone is happy. All in all this is an excellent game, and I hope this short analysis begins to cover some of the deeper strategies that emerge during play.
18/04/2016
The Bottom of the Stack
As with all the best things in life, this all started with a crazy idea that was initially dismissed out of hand. While I was in a fervor planning for FOSDEM this year I did a quick check to see if there were any conferences in the UK that I might be able to go to (my student budget didn't allow for another international trip). I worked with PHP for two of my previous internships, and used it as the base for my most used personal projects (pizza-get and music-get), so seeing that PHP had a conference in the UK was exciting. But there was a problem. A problem to the tune of £300 in the form of an entry fee.
Eventually I found that PHP UK were offering diversity scholarships for the conference, to the tune of travel, accommodation, and the entry fee. That sounds great, but I was pretty certain that I wasn't going to get one, especially as a student when the conference is aimed at professional developers. Well, turns out that if you don't ask you don't get.
Fast forward to February, and I'm on the way to a campaign reception at the Chiswell Street dining rooms with the other scholarship awardees and conference presenters - not only was I at the conference, but I had a unique opportunity to network with some of the best minds of the PHP world! After an insightful evening of wine, food, and excellent advice it was time to retire to the apartment I was staying in for the duration of the event with my roommate (another student awarded a scholarship).
Some of the main track conference talks blew me away. Compared to what I had been to before - FOSDEM and an 'unplugged' conference by RSAC - this was a big budget event. This also meant that there were some talks which one might not expect at a tech conference. There were talks about diversity in the industry, impostor syndrome, and mentoring. These are all really important subjects, and ones which nigh impossible to pick up from a book. I think more conferences should have these types of 'soft' talks (In fact, thinking back to RSAC unplugged the best session by far was Alexis Conran of the Real Hustle describing the psychology of scamming and deception, and not the ones by various heads of cyber security/research).
Aside from being harder to learn, these topics are the ones which get left out (in academia anyway, it was better when I was at a startup) in favour of technical skills. The thing is, I know how to find out about tech stuff - I can use Google to help me figure out that I can use Docker to ship my app - but I'm far less likely to google why it is that all my colleagues seem to know more than me and how on earth I got through the hiring process without them seeing through my fraud. Wait, did I just say that out loud?
To wrap up, I'm incredibly grateful to PHP UK for giving me this opportunity. I didn't think it would be possible to make people feel included in a community of 700 where, to be honest, we had very little in common. But it's worked! One of the conditions on receiving the scholarship was that I pay it forward one day, and you know what? I will. After the conference it dawned on me that one day I'll be able to provide the same eye opening experience to someone, and that's incredible. And also thanks to my mentors this time around, so I guess it's self perpetuating.
(I mentioned RSAC Unplugged a bit here, so I had to include the awesome picture they made of all the conference talks)
Eventually I found that PHP UK were offering diversity scholarships for the conference, to the tune of travel, accommodation, and the entry fee. That sounds great, but I was pretty certain that I wasn't going to get one, especially as a student when the conference is aimed at professional developers. Well, turns out that if you don't ask you don't get.
Fast forward to February, and I'm on the way to a campaign reception at the Chiswell Street dining rooms with the other scholarship awardees and conference presenters - not only was I at the conference, but I had a unique opportunity to network with some of the best minds of the PHP world! After an insightful evening of wine, food, and excellent advice it was time to retire to the apartment I was staying in for the duration of the event with my roommate (another student awarded a scholarship).
Some of the main track conference talks blew me away. Compared to what I had been to before - FOSDEM and an 'unplugged' conference by RSAC - this was a big budget event. This also meant that there were some talks which one might not expect at a tech conference. There were talks about diversity in the industry, impostor syndrome, and mentoring. These are all really important subjects, and ones which nigh impossible to pick up from a book. I think more conferences should have these types of 'soft' talks (In fact, thinking back to RSAC unplugged the best session by far was Alexis Conran of the Real Hustle describing the psychology of scamming and deception, and not the ones by various heads of cyber security/research).
Aside from being harder to learn, these topics are the ones which get left out (in academia anyway, it was better when I was at a startup) in favour of technical skills. The thing is, I know how to find out about tech stuff - I can use Google to help me figure out that I can use Docker to ship my app - but I'm far less likely to google why it is that all my colleagues seem to know more than me and how on earth I got through the hiring process without them seeing through my fraud. Wait, did I just say that out loud?
To wrap up, I'm incredibly grateful to PHP UK for giving me this opportunity. I didn't think it would be possible to make people feel included in a community of 700 where, to be honest, we had very little in common. But it's worked! One of the conditions on receiving the scholarship was that I pay it forward one day, and you know what? I will. After the conference it dawned on me that one day I'll be able to provide the same eye opening experience to someone, and that's incredible. And also thanks to my mentors this time around, so I guess it's self perpetuating.
(I mentioned RSAC Unplugged a bit here, so I had to include the awesome picture they made of all the conference talks)
10/04/2016
It's Not Rocket Science
This week SpaceX landed an rocket on a barge, and filmed it with a drone. The next day it occurred to me: my friend has a rocket, and I have a drone. If it's good enough for Elon Musk, it's good enough for me! Keen not to anger campus security any more than we had to (after recently crashing said drone onto the roof of the Zeeman building), Hersall Common was chosen as the launch site instead of one of the fields at the university.
The first obstacle encountered was the weather, with one launch aborted due to high winds and rain. The second came in the form of two important life lessons:
1) Super Glue does not fuck around
2) Do not volunteer to hold rocket parts while someone else Super Glues them
Luckily the abandoned launch gave me some time to reflect on poor life choices and a sudden lack of skin on my fingertips.
The next day brought fairer weather, so we headed back out to the common with our now fully assembled rocket. Cue us realising that we hadn't attached the nose cone and parachute to the body tube and another half hour of shenanigans with superglue. Finally, we could launch. I didn't realise until this point just how much having an electric ignition system adds to the whole experience. It really felt like we were playing with something dangerous.
There was quite a lot of wind on the common which meant we had to angle the guide rail at about 15° in order to have the rocket go something resembling upwards. It also meant that the drone was grounded. Craft #1 was small and light, weighing in at 42.5g with an A8-3 motor weighing 16.2g providing an average of 8 Newtons of thrust (9.7 peak). That's 0-60 mph in 0.2 seconds (not counting air resistance).
Rocket #2 was a bit heavier (62.4g), with the same motor. Evidence suggests that we need something bigger to get a decent launch from it. I think that's an excuse to go out and buy some more explosives.
And finally, here are the videos from the launches!
The first obstacle encountered was the weather, with one launch aborted due to high winds and rain. The second came in the form of two important life lessons:
1) Super Glue does not fuck around
2) Do not volunteer to hold rocket parts while someone else Super Glues them
There was quite a lot of wind on the common which meant we had to angle the guide rail at about 15° in order to have the rocket go something resembling upwards. It also meant that the drone was grounded. Craft #1 was small and light, weighing in at 42.5g with an A8-3 motor weighing 16.2g providing an average of 8 Newtons of thrust (9.7 peak). That's 0-60 mph in 0.2 seconds (not counting air resistance).
Rocket #2 was a bit heavier (62.4g), with the same motor. Evidence suggests that we need something bigger to get a decent launch from it. I think that's an excuse to go out and buy some more explosives.
And finally, here are the videos from the launches!
07/04/2016
A Game of Drones
There is one thing that will, without doubt, induce fear in the heart of any undergraduate computer scientist: group project. The problem is that they come with all the responsibility of paid work, but none of the accountability. Maybe I'll revisit the game theory of Warwick group projects in a later post.
The topic we chose for ours was one I'd been wanting an excuse to explore for a while: quadcopters. After some brainstorming we decided that the best approach we could take given that this was an academic project was to devise some framework for reasoning about drone networks, and to devise a way of writing high level scripts that could task them. I think the particular use case we had as an example was monitoring forest fires.
The problem is though, that the FOSS software available for simulating sensor networks is *really bad* from a beginners perspective. The de facto network simulation application is NS3 (yes, as imaginatively named as you think), but the learning curve is really high. The hands on section of the sensor networks module at Warwick for *third years* spends weeks building up to the point of moving some nodes around. Suddenly it began to dawn on us that we had bitten off rather more than we anticipated.
Upholding a long tradition of software engineers everywhere, we took a fresh look at the problem and decided that it would be easier to create our own simulation software than to learn the intricacies and quirks of NS3. To be honest, it's done wonders for my understanding of the domain, as well as the specific problems we are trying to model. The best example of this probably lies in the communications side of things. If we had used NS3, I would have experimented with a few different message routing models before trying to piece together a conclusion based on what the corresponding Wikipedia articles told me was supposed to be going on. As it stands, I've actually taken the RFC for Ad hoc on demand distance vector routing and implemented it in C++.
We made a conscious effort with the project (named octoDrone) to keep things as modular as possible. To this end, the simulator, communications processing, programs that run on drones, and scripts that define simulations are all separate and configurable. This payed dividends when it came to deploying our software on to real drones instead of simulated ones, as we were able to swap out the code that simulated the operating environment for one that sent the same instructions to real hardware (I'll cover the deployment in a separate post as it's something I could talk a lot about). The other goal during development was to cut out a lot of the bloat that plagued NS3. Instead of it taking half an hour and a handful of tutorials to visualise a simulation, the application *should just do that for you*. Instead of having to access node components by passing strings with the same name (eugh), you should just be able to access them through code the way you normally would.
At the end of a year of work we're left with a lightweight simulation package that does exactly what one would want a drone simulator to do, and nothing more. Being able to run the same programs on real drones as you do in a simulation is a real selling point (and that it works at all on the drones we had to test on is a point of personal pride). It even got to the point where I seriously considered running my coursework assignment in octoDrone instead of NS3, which serves to show just how far we've come.
GitHub: https://github.com/mcnutty26/octoDrone
The topic we chose for ours was one I'd been wanting an excuse to explore for a while: quadcopters. After some brainstorming we decided that the best approach we could take given that this was an academic project was to devise some framework for reasoning about drone networks, and to devise a way of writing high level scripts that could task them. I think the particular use case we had as an example was monitoring forest fires.
The problem is though, that the FOSS software available for simulating sensor networks is *really bad* from a beginners perspective. The de facto network simulation application is NS3 (yes, as imaginatively named as you think), but the learning curve is really high. The hands on section of the sensor networks module at Warwick for *third years* spends weeks building up to the point of moving some nodes around. Suddenly it began to dawn on us that we had bitten off rather more than we anticipated.
Upholding a long tradition of software engineers everywhere, we took a fresh look at the problem and decided that it would be easier to create our own simulation software than to learn the intricacies and quirks of NS3. To be honest, it's done wonders for my understanding of the domain, as well as the specific problems we are trying to model. The best example of this probably lies in the communications side of things. If we had used NS3, I would have experimented with a few different message routing models before trying to piece together a conclusion based on what the corresponding Wikipedia articles told me was supposed to be going on. As it stands, I've actually taken the RFC for Ad hoc on demand distance vector routing and implemented it in C++.
 |
| Credit: David Richardson |
We made a conscious effort with the project (named octoDrone) to keep things as modular as possible. To this end, the simulator, communications processing, programs that run on drones, and scripts that define simulations are all separate and configurable. This payed dividends when it came to deploying our software on to real drones instead of simulated ones, as we were able to swap out the code that simulated the operating environment for one that sent the same instructions to real hardware (I'll cover the deployment in a separate post as it's something I could talk a lot about). The other goal during development was to cut out a lot of the bloat that plagued NS3. Instead of it taking half an hour and a handful of tutorials to visualise a simulation, the application *should just do that for you*. Instead of having to access node components by passing strings with the same name (eugh), you should just be able to access them through code the way you normally would.
GitHub: https://github.com/mcnutty26/octoDrone
03/02/2016
What's all the FOSS About?
This weekend I joined some friends from the computing society on a trip to the Free and Open-source Software Developers' European Meeting (FOSDEM), an opportunity to learn from and share opinions with ~5,000 other developers from the continent. Having such a broad topic means that FOSDEM is a great place to learn about all sorts of incidental things you wouldn't expect to. I learnt about window managers, DNSSEC, and ?. These weren't things that I went with the express intention of learning about, but it helps make me a more rounded engineer than what my course and personal projects allow.
It's nice to be around others who share the same niche interests as you do. I went up to the stall of one of the projects that I use (ownCloud), expecting to say hello and exchange pleasantries, and instead ending up discussing the project and it's intricacies with one of the developers. It takes a bit of courage, but this is the best opportunity you can get to learn from the best of the best. I finally got to see what all the fuss about this Stallman bloke was about, and learnt more than I thought would about software licenses (from the perspective of a developer and a community).
The other astounding thing about FOSDEM is the sheer amount of beer that gets consumed. The convention takes over the delirium cafe in the centre of Brussels on the Friday before the event starts (complete with bouncers that ask you about the JVM before they let you in), which is packed to the point where you can't get into the street it's in. After everyone's woken up with sore heads the next day, extra shops open up around the ULB campus to serve the mas of developers who are still hungry for booze. A few of the stalls bring free (as in beer) beer, and will happily swig away while talking to you.
This time we decided to write off Monday and get a later train back (the idea that you're going to do anything productive on the day you get back to the UK is a naive one), which let us visit a few sites in Brussels. We didn't do this last year, and it was a really nice way to spend the day. We saw the cathedral, complete with the fanciest pulpit you ever did see. On the way out we spotted the Banque Nationale De Belgique, which turned out to have a temporary exhibit open. There's something about money which makes it intriguing, and the ability to print banknotes with your face on aside, it was an insightful look in to the way the euro is managed, and the role the member states play (and what's left to the central bank. My favourite was the machine used to invalidate old coins, which corrugates them :P We also went around the European Parliament, which was filled with quite a lot of European propaganda, but served as a reminder of how incredible it is that the European Union exists and does all the things it does (especially when the press opinion of it is overwhelmingly negative).
It's nice to be around others who share the same niche interests as you do. I went up to the stall of one of the projects that I use (ownCloud), expecting to say hello and exchange pleasantries, and instead ending up discussing the project and it's intricacies with one of the developers. It takes a bit of courage, but this is the best opportunity you can get to learn from the best of the best. I finally got to see what all the fuss about this Stallman bloke was about, and learnt more than I thought would about software licenses (from the perspective of a developer and a community).
The other astounding thing about FOSDEM is the sheer amount of beer that gets consumed. The convention takes over the delirium cafe in the centre of Brussels on the Friday before the event starts (complete with bouncers that ask you about the JVM before they let you in), which is packed to the point where you can't get into the street it's in. After everyone's woken up with sore heads the next day, extra shops open up around the ULB campus to serve the mas of developers who are still hungry for booze. A few of the stalls bring free (as in beer) beer, and will happily swig away while talking to you.
This time we decided to write off Monday and get a later train back (the idea that you're going to do anything productive on the day you get back to the UK is a naive one), which let us visit a few sites in Brussels. We didn't do this last year, and it was a really nice way to spend the day. We saw the cathedral, complete with the fanciest pulpit you ever did see. On the way out we spotted the Banque Nationale De Belgique, which turned out to have a temporary exhibit open. There's something about money which makes it intriguing, and the ability to print banknotes with your face on aside, it was an insightful look in to the way the euro is managed, and the role the member states play (and what's left to the central bank. My favourite was the machine used to invalidate old coins, which corrugates them :P We also went around the European Parliament, which was filled with quite a lot of European propaganda, but served as a reminder of how incredible it is that the European Union exists and does all the things it does (especially when the press opinion of it is overwhelmingly negative).
21/01/2016
A Nodd in the Right Direction
It's been a long time coming, but we're almost at the end of the ill-fated UWCS migration! After the target machine we were planning to move to developed power supply problems (as well as a worrying amount of bad configuration decisions), we finally gave up and started again. In hindsight, it was a godsend that we had a machine to do what would eventually become a test run on. It served as a stark reminder that we had underestimated the complexity of what we set out to do, and that we didn't know what we were doing. This lead to lots of quirks that weren't quite right, and meant that the communications we send out to users was patchy, confusing, and sometimes downright wrong.
This second attempt allowed us to select more reliable hardware (as opposed to, I shit you not, some server we got cheap second hand and untested) and move away from software raid, which turned out to be more trouble than it was worth. We now have a RAID 1 configuration in hardware, with an additional two hot swap disks. We went with an OS with long term support, and postponed the load balancing plans I mentioned in a previous post. That said, we've set things up in a way that means we can transition to a load balanced setup in the future.
Configuring things for the second time was a lot smoother, and now I've learnt more than I probably ever need to about managing IRC, Apache, and MySQL. Our interactions with the user base were a lot more professional, and it feels like we've actually helped people to navigate the switch over, instead of just letting them know and hoping for the best. We're currently in the grace period before turning off the old server for good, which gives us some time to check that everything is working properly (and fix the things that aren't without being in panic mode). Hopefully we've built the infrastructure that will carry us through the next decade, as the last server has taken us through the previous ten.
This second attempt allowed us to select more reliable hardware (as opposed to, I shit you not, some server we got cheap second hand and untested) and move away from software raid, which turned out to be more trouble than it was worth. We now have a RAID 1 configuration in hardware, with an additional two hot swap disks. We went with an OS with long term support, and postponed the load balancing plans I mentioned in a previous post. That said, we've set things up in a way that means we can transition to a load balanced setup in the future.
Configuring things for the second time was a lot smoother, and now I've learnt more than I probably ever need to about managing IRC, Apache, and MySQL. Our interactions with the user base were a lot more professional, and it feels like we've actually helped people to navigate the switch over, instead of just letting them know and hoping for the best. We're currently in the grace period before turning off the old server for good, which gives us some time to check that everything is working properly (and fix the things that aren't without being in panic mode). Hopefully we've built the infrastructure that will carry us through the next decade, as the last server has taken us through the previous ten.
29/12/2015
Music to My Ears
The first step is admitting that you have a problem.
We have a music server at LAN parties, which acts as the gateway for all of the connected PCs and a place where people can queue music and videos. Anyone at LAN can submit media, and everyone at LAN has to suffer through our collective bad taste in music. Following on from the theme of the last year or so, the current music server software is dated and slowly falling apart, and therefore it must be time to make a new one. There are currently 11 implementations either developed or in development (see list).
This is a textbook case of a time where the usual approach of "I think I can do better, therefore I should" has clearly failed. There's a horrendous amount of effort being duplicated, each with a slightly different way of doing things, or a different philosophy. Of course, some people are writing new music servers as a way of learning a language, and that's fine. Others are writing one because everyone else is, which is more of a problem. In theory the best approach would be for everyone to contribute to a central project, as was done in the past, but in reality this is likely to lead to arguments and little progress (university deadlines have a habit of exacerbating with this).
Unfortunately I'm a guilty party here, because I wrote a music server *because* everyone else was trying (and failing) to come up with a finished project. Enter music-get, styled after pizza-get, and designed to be easy to maintain as opposed to what might be considered a 'well engineered application'. To allow for this the front and back ends are split up, and there are extra dependencies (like Apache) that could be eliminated if you were trying to make a compact app. But in reality, we're running this on a fairly modern desktop, not a Raspberry Pi. Maybe there are better languages for this than Java, but everyone can use Java. In general modifying music-get doesn't assume much technical knowledge, as when you need to fix something at 4 in the morning during a LAN party you may not quite be on top form :P
This is the first project that I've come up with proper documentation before (as in, how it works instead of just how to run it), which was interesting at first but quickly became tedious. Hopefully it, or something better, will get used at the next LAN - ultimately the goal here is that the problem gets solved, not who solves it! Still, it would be nice if it were mine...
GitHub: https://github.com/mcnutty26/music-get
We have a music server at LAN parties, which acts as the gateway for all of the connected PCs and a place where people can queue music and videos. Anyone at LAN can submit media, and everyone at LAN has to suffer through our collective bad taste in music. Following on from the theme of the last year or so, the current music server software is dated and slowly falling apart, and therefore it must be time to make a new one. There are currently 11 implementations either developed or in development (see list).
This is a textbook case of a time where the usual approach of "I think I can do better, therefore I should" has clearly failed. There's a horrendous amount of effort being duplicated, each with a slightly different way of doing things, or a different philosophy. Of course, some people are writing new music servers as a way of learning a language, and that's fine. Others are writing one because everyone else is, which is more of a problem. In theory the best approach would be for everyone to contribute to a central project, as was done in the past, but in reality this is likely to lead to arguments and little progress (university deadlines have a habit of exacerbating with this).
Unfortunately I'm a guilty party here, because I wrote a music server *because* everyone else was trying (and failing) to come up with a finished project. Enter music-get, styled after pizza-get, and designed to be easy to maintain as opposed to what might be considered a 'well engineered application'. To allow for this the front and back ends are split up, and there are extra dependencies (like Apache) that could be eliminated if you were trying to make a compact app. But in reality, we're running this on a fairly modern desktop, not a Raspberry Pi. Maybe there are better languages for this than Java, but everyone can use Java. In general modifying music-get doesn't assume much technical knowledge, as when you need to fix something at 4 in the morning during a LAN party you may not quite be on top form :P
This is the first project that I've come up with proper documentation before (as in, how it works instead of just how to run it), which was interesting at first but quickly became tedious. Hopefully it, or something better, will get used at the next LAN - ultimately the goal here is that the problem gets solved, not who solves it! Still, it would be nice if it were mine...
GitHub: https://github.com/mcnutty26/music-get
12/11/2015
Balancing Act
There comes a time with most IT systems where you have to call it a day and upgrade. Reasons often include increased load and equipment failure, and in the case of UWCS we have both.
Our main server, codd (after Edgar F. Codd) has been going for a long time now. A lot of things have changed since it was built, including what users expect their hosting solutions to provide for them. Coupled with the improvements in hardware and software this means that there isn't any excuse for providing a good service. No matter how 'executive series' the motherboard in codd is, it doesn't make up for the fact that it's less powerful than my laptop. Sure, it still works, but we can do better.
As luck would have it, we were gifted some poweredge servers last year that pack a bit more of a punch. Along with some of the others that we've bought we ought to have enough metal for a decent setup. But a racks worth of servers wouldn't be much without somewhere to put them! Some grovelling to the department of computer science prevented us having what would have amounted to a very pricey purchase. It didn't fit the servers though, so we had to take it apart and bolt it back together in a more accommodating configuration.
With the servers racked and imaged came the task of actually figuring out the details of this grand plan. I mean, it would of if we hadn't spent six months procrastinating. Once the shiny new toys had come out of the packaging things slowed right down. Thankfully we've started this year with some fire in our collective belly and actually come up with a plan we might actually be able to implement! The design features a number of application servers behind a load balancer, with each app server containing a copy of user files and databases. It might be better to have dedicated storage/db clusters if we had more traffic, but the focus here is on something that holds up to the next ten years whilst being doable in between lectures and assignments. And being intelligible to the next tech officer who has to inherit all of this :P
Ceph is a distributed file system, and how we've chosen to store the files that users store in their hosting accounts. We'll need some way of letting users interact with the system whilst keeping the app servers in sync, so all SSH sessions will terminate at nodd, which will have the Ceph drive mounted. Any changes made will be propagated to their actual location on disk which will be on all of the cluster nodes. Currently there are two, but in the future we will be able to spin up some more and just add them in to the haproxy configuration. SSL connections are terminated at nodd, which then uses regular http to retrieve files across the internal network. This way we can add a cookie to http sessions ensuring that users are served by the same backend server for the entire session (important for managing things like logins).
It's been a long road, but I think we might just make it!
Our main server, codd (after Edgar F. Codd) has been going for a long time now. A lot of things have changed since it was built, including what users expect their hosting solutions to provide for them. Coupled with the improvements in hardware and software this means that there isn't any excuse for providing a good service. No matter how 'executive series' the motherboard in codd is, it doesn't make up for the fact that it's less powerful than my laptop. Sure, it still works, but we can do better.
As luck would have it, we were gifted some poweredge servers last year that pack a bit more of a punch. Along with some of the others that we've bought we ought to have enough metal for a decent setup. But a racks worth of servers wouldn't be much without somewhere to put them! Some grovelling to the department of computer science prevented us having what would have amounted to a very pricey purchase. It didn't fit the servers though, so we had to take it apart and bolt it back together in a more accommodating configuration.
With the servers racked and imaged came the task of actually figuring out the details of this grand plan. I mean, it would of if we hadn't spent six months procrastinating. Once the shiny new toys had come out of the packaging things slowed right down. Thankfully we've started this year with some fire in our collective belly and actually come up with a plan we might actually be able to implement! The design features a number of application servers behind a load balancer, with each app server containing a copy of user files and databases. It might be better to have dedicated storage/db clusters if we had more traffic, but the focus here is on something that holds up to the next ten years whilst being doable in between lectures and assignments. And being intelligible to the next tech officer who has to inherit all of this :P
It's been a long road, but I think we might just make it!
Subscribe to:
Posts (Atom)