23
Feb
2015

Understanding the Enigma machine with 30 lines of Ruby. Star of the 2014 film “The Imitation Game”

by Albert Still

Scene from The Imitation Game 2014 filmI recently watched the film “The Imitation Game” and it’s brilliant despite Keira Knightley’s failed attempt at a posh British accent. Everyone should watch it especially if you’re interested in technology. It’s about the life of a genius called Alan Turing, he is also known as the father of modern computer science. That means the very tech you’re using to read this blog works on the foundations of his discoveries. His major breakthrough took place at GCHQ during WW2, he made a machine that decrypted secret German messages they sent using the Enigma machine. Furthermore, historians believe his work shortened the war by two years and saved thousands of lives. To me stories don’t get much more interesting than this, how us Brits used maths and computer science to help the Allies win WW2 and save Europe from fascism. 

After watching the film I became very interested in the Enigma machine and I’m going to use Ruby to explain to you how it works. If you don’t know the Ruby programming language don’t worry, you’ll be surprised how much syntax you understand. 

Journey of a single letterFirstly it’s important to realise the Enigma machine is just one big circuit. Each time a key is pressed at least one rotor is rotated which changes the circuitry of the machine thus lighting a different letter faced light bulb. The rotors are the only moving parts within the circuit and each have 26 steps, one for each letter of the alphabet. When a key is pressed the right rotor rotates by a step, when this reaches a full revolution the middle rotor rotates by a step, and when the middle rotor does a full revolution the left rotor rotates a step. Here is a video to best explain the circuitry:

I found the best way to understand the machine was to visualise the path of an electron traveling through the circuit after a key is pressed. First of all we get to the plugboard, here we literally swap 10 of the 26 letters. For example D becomes E and therefore E becomes D. In Ruby we can model this as Plugboard = Hash[*('A'..'Z').to_a.shuffle.first(20)] and then Plugboard.merge!(Plugboard.invert) so we can make it reflective. As for the 6 letters that are untouched and simply map to themselves we can make the value default to the entered key with Plugboard.default_proc = proc { |hash, key| key }.

Next we get to the rotors, think of each of the rotors as a substitution cypher, each of its two sides has 26 metal contacts. And there is a mess of 26 wires inside that randomly pair the contacts. We can model a rotor as Hash[('A'..'Z').zip(('A'..'Z').to_a.shuffle)], for the return journey we can call invert on the hash before passing it a key.

The electron travels through all the rotors and then it gets to the reflector. The reflectors job is simply to turn the electron around and pass it back through the rotors. We can model it with Reflector = Hash[*('A'..'Z').to_a.shuffle] and Reflector.merge!(Reflector.invert).

It will now go back through the rotors, through the plugboard again and finally hit the letter faced lightbulb which would indicate to the operator what the letter had been encrypted or decrypted to, depending wether the operator is receiving or sending messages.

I have written a gist of an Enigma machine using the above code, please feel free to comment below if any of it needs explanation.

Why was it secure?

The Enigmas security comes from the large number of configurations the machine can be in. Every month German operators were issued a code book that told them what setting to put their plugboard and rotors in for each day of that month.

  • The Enigma machine came with 5 rotors to choose from and the machine used 3.  You have 5 to choose from, then 4, then 3. Order matters here therefore this yielded 5 x 4 x 3: 60 combinations.
  • Then each rotor has 26 starting positions. This yielded 26 x 26 x 2617,576  combinations.
  • The plugboard maths is more complicated, Andrew Hodges explains it well. The number of ways of choosing m pairs out of n objects is n! /((n-2m)! m! 2m). Therefore the enigma machine has (26! / ((26-2*10)! 10! 2^10): 150, 738, 274, 937, 250 combinations.

Shot of the Enigma machine in The Imitation Game 2014Multiply 60 x 17,576 x 150,738,274,937,250 and you have 158,962,555,217,826,360,000 combinations! And that is what GCHQ were faced with. They had to figure out which one of the combinations the Germans Enigma machines were using for that day so we could understand what the Germans were saying to each other. Furthermore the next day it would change making any promising work from the day before useless, a moving target!

This is where Turing’s master mind came in. Him and others built a bombe machine that speed up the process of working out what setting the Enigma machines were in for that day. First they tried guessing a small section of plaintext within the ciphertext, then the bombe was used to find the setting that would yield this plaintext through brut force. If I get the time I would love to study the bombe and try and write it in Ruby.

Did UX lose Germans the war?

The reflector was practical because it meant the Enigma machine operators used the same setting to send and receive messages. This was great but it also meant that a letter could never map to itself. This was a major weakness in the system, because it allowed the code breakers to eliminate possible solutions when the ciphertext and the putative piece of plaintext had the same letter in the same place. And it was this weakness Turing exploited with his bombe machine.

Why did they only use 10 pairs for the plugboard?

This puzzled me for a while, if you play around with the n! /((n-2m)! m! 2m) formula you will see 11 plug pairs yields the most combinations, with the number decreasing after 11. Here is the best explanation to why they used 10:

British cryptanalysts believed that the Germans chose 10 plugs because this resulted in the maximum number of plug-board permutations.  While the actual maximum occurs for 11 plugs, the discrepancy could well be a mistake in slide-rule computations on the part of the Germans.” — Deavours and Kruh (1985), “Machine Cryptography and Modern Cryptanalysis

So because they didn’t have computers back then doing maths with large numbers was difficult and had to be done by hand, and they simply believe it was a slide rule mistake.

21
Feb
2015

London React Meetup: February

by Imran Sulemanji

In previous months we’ve witnessed growing interest in both React and the London React meetup. As the number of attendees swelled to beyond the reasonable capacity of our office, Facebook stepped in and offered to graciously host the event at their London offices. The timing couldn’t have been better, as this week attendances exceeded 250.

It is clear that with React, Facebook have captured the interest of developers and these growing numbers highlight just how united the community is with its philosophy.

In addition, this January seen the 2015 React.js conference in San Fransisco, with notable announcements being React-Native, Relay and GraphQL amongst others. It is exciting to see Facebook responding to community feedback and evolving React to accommodate its concerns.

What did we learn this month?

An Introduction to Flux

Guy Nesher; a lead developer at Conversocial, introduced us to the Flux architecture in a talk rich with granular details and applied examples. He demonstrated how Flux is a powerful pattern that can be used to simplify data flow and that these benefits are not exclusive to React applications but can be used to great effect in other JS frameworks. Given the announcement of Relay at React.js conf, it will be interesting to see how the Flux pattern changes and how we approach the problem of managing data flow using these new technologies.

A Preview of React-Native

Robbie McCorkell is a user interface developer at Red Badger, and attended React.js conf last month. In doing so, he saw React-Native first hand and walked us through an early release of the IOS implementation with examples in XCode. For the uninitiated, Robbie demonstrated just how productive and enjoyable React-Native development can be in the seemingly torturous world of native app development.

Show and Tell

Two lightning talks on projects currently being worked on by meetup members.

Rui Ramos demoed his project, Great.dj. A simple yet slick playlist manager for parties and powered by React and web sockets. The killer feature was the ability to join a party’s playlist simply by visiting the site via the same network.

Steve Heron showed us react-app-layout; a framework for handling complex, user customisable layouts. By harnessing the power of flex box , Steve showed how we might offer power users, levels of customisation previously only seen in native/desktop applications.

13
Feb
2015

Learning to Code in Two Days

by Amy Crimmens

animal-17474_1280

When I arrived at Red Badger to start my lovely new job as Community Manager last August I can honestly say I had very little idea about how websites were produced. Considering I had six years experience of working in the tech industry under my belt this was pretty ridiculous.

 So, once I’d got into the swing of things a bit, I decided I should spend some of my generous training budget on a coding course; we are each given £2K a year to spend on training so the world was my oyster.

 I decided on the General Assembly “Programming for Non- Programmers” course. This is a weekend bootcamp designed to give total beginners a crash-course in web development basics including HTML, CSS,  Javascript and a little bit of Ruby.

We know the General Assembly guys pretty well at Red Badger; we are one of their hiring partners and several of my colleagues coach on their courses so it seemed like a good bet.

 We started off the weekend with the usual introductions “Hello I’m Amy from Red Badger and I’m here because….”. Pretty much everyone fell into one of two camps; either they had an idea for a start up and didn’t want to have to pay a developer or they worked with developers and wanted to understand what was going on a bit more- like me.

 Our teacher Antonio warned us that it was going to be a full on weekend and explained that  by the end of  the weekend we would each have produced a simple “business card” website using basic programming.

 This seemed like a lot to ask but as we got to grips with HTML and then CSS I could see my site coming together. It was when we added Javascript that I was really impressed with myself, menu items now changed colour when you hovered over them like a real website!

 I can’t say Ill ever use the (rather ugly) website I built- that wasn’t the point, but the knowledge I picked up over the weekend will help me tremendously in my job at Red Badger. I now understand several of the mysterious terms that fly around the office (div means something quite different in programming) and I feel confident I could make simple content changes to our CMS- less website which was previously a bit daunting.

 The weekend has also given me a real appreciation of the work that goes into creating even quite basic sites never mind the stunners my colleagues build like the new Fortnum and Mason site. I already knew they were a talented bunch now I think so even more.

 Just as an aside, if you are also a super talented developer who can magic up websites as fancy as these we’d love to hear from you.  Get in touch via jobs@red-badger.com and I’ll try not to bore you with tales of my new found coding skills.

 

28
Jan
2015

Why I moved my static blog to HTTPS

by Alex Savin

Fialka ciphering machine
Photo credit Brett Neilson

By the year 2015 general awareness of the differences between plain HTTP and protected HTTPS seems to become more or less general. When making online purchases, or sending private messages, or entering passwords online we are now getting this warm fuzzy feeling if there is green lock icon shining next to the page’s URL. And panic attacks if there isn’t one. Being HTTPS only became standard for online services dealing with customer sensitive data.

On the other hand there are pages like personal blogs, or, well, Wikipedia. Or BBC. Just good old unencrypted HTTP. You can actually access Wikipedia via https, but if you try the same trick with BBC page, it will just redirect you back to the land of plain HTTP. And why would you want encrypted connection anyway? It’s not like they are selling stuff and you’re submitting personal credit card number. You’re just wandering around the Web, reading stuff, minding your own business.

Recently I moved my personal blog pages to be HTTPS only. Here are few reasons why.

  1. With plain HTTP there is no certain way of telling if you are actually reading my blog. You type URL in the browser (or click a link), and browser politely requests content for this address. During the journey of this request, at any point it can be read, interpreted, and responded with any content. And the browser will display whatever is returned.

  2. A classic example would be man-in-the-middle attack. Open unencrypted traffic allows anyone on your (free) wifi network to intercept it, track your requests, as well as potentially alter content of the page. With example of BBC pages, you could inject some news articles, or in general alter the content in any possible way.

  3. If you think that only evil hackers would do such atrocities, think again. There are reports of in-flight and hotel wifi networks injecting banners into webpages. Goes without saying that this would not be possible with HTTPS pages.

  4. Google started using HTTPS support on the page as a positive ranking signal last year. Meaning, HTTPS pages will be ranked higher than plain HTTP only pages.

  5. HTTPS traffic is much harder to block and filter out with corporate firewalls. You would have to force install additional certificate onto machines in that network (which is a common practice in certain places).

  6. In general, living in post-Snowden era, when TheVerge reveals new details on digital surveillance almost weekly, strong reliable encryption of everything seems like a very good idea.

  7. One interesting topic is state controlled firewalls, like Great Firewall of China. Wikipedia article on this matter contains following curious trivia:

The Tor anonymity network was and is subject to blocking by China’s Great Firewall. The Tor website is blocked when accessed over HTTP but it is reachable over HTTPS so it is possible for users to download the Tor Browser Bundle.

The very same Google recently announced that not all SSL certificates will be treated equal, and SHA-1 certificates are going to be retired and indicated as unsafe already in Chrome 41. In a way, it is a danger in itself to blindly trust any SSL certificate. There are quite a few online tools to test various security aspects of your SSL – the best and most helpful being SSL Test. It will test pretty much everything, and provide you with a grade and bunch of hints how to improve it, and why it is capped (if it is).

One notable thing about SSL Test is that once you decide to buy a certificate, you can run this test against pages of the issuer, to make sure that it is indeed legit, and there are no issues like broken certificate chain.

This post is inspired by HTTPS everywhere talk on Google IO 2014, and this ATP podcast episode.

23
Jan
2015

2015: Native App Development is Dead in the Enterprise

by Cain Ullah

With Gartner results showing that in 2014 mobile and tablet sales equated to approximately 2.4 billion unit sales compared to 318 million PCs and with an ever increasing proliferation of mobile devices, for many enterprise level organisations developing an effective mobile strategy continues to be one of their biggest challenges.

So what questions are organisations currently asking themselves when devising a strategy for a successful mobile presence?

Native vs Responsive

There has been a long standing argument between the value of building native applications specific for a device such as an iPhone or Android vs. the mobile web i.e. responsive web sites that work across all devices.

The nirvana is that developers wouldn’t have to worry about devices at all and that there would be a solution to write an application once, for it to cover all use cases and work on all devices be it in the guise of a native app or a website. Unfortunately this doesn’t yet exist and Facebook’s attempt at doing this via HTML5 was followed by a rapid backtrack that was well publicised.

There are obvious pros and cons to both (you can read David’s article here for some great insight into why responsive web design is a great strategy). Native applications give you more flexibility when accessing a smartphone’s features (such as the accelerometer) and there is the obvious advantage of offline browsing. However, native applications are only built for a specific device resulting in you having to build multiple applications; development costs and ongoing maintenance escalate as a result. Responsive websites on the other hand can be built once and work on most devices (if tested properly) providing a far greater reach for less development cost. But offline browsing is not easy and user experience can often be hindered by the limitations of HTML.

At the moment there are use cases for both that solve separate concerns. If you have a complex set of requirements you may not be able to avoid the need to have to build both a website and a native application. It is common place for enterprise companies to have many desktop applications each with 3-4 mobile applications to support them.

Enterprise strategies differ from company to company. A fine example is The Times newspaper. They have focussed more on the optimum interactive experience of their native applications for both Apple and Android tablets, with separate editorial teams dedicated to each device. The website on the other hand is not responsive. They’ve not even bothered to redirect to an m.site, instead just displaying the desktop site on a mobile with a link to download the app from the app store.

In contrast to The Times, the Guardian has opted for a great adaptive/responsive website detailed in David’s aforementioned article from October 2013.

So is there a happy medium?

Cross Platform Tools

To tackle this problem, there are tools in the market that facilitate cross-platform mobile development such as Phonegap and Titanium. These allow you to build apps using Javascript and Web Technologies, and deploy them to  multiple marketplaces in the guise of native apps, across multiple platforms. The advantages on the surface are obvious – you get access to native features that are not available to web browsers but you also only have to write and maintain one code base. If only it was that simple.

There is a great blog highlighting the comparison and the weakness of both Phonegap and Titanium by Kevin Whinnery here.

Other cross-platforms also exist. Another blog by Kevin Whinnery’s former colleague, Matt Schmulen provides details on the options and how they fit into the current mobile ecosystem where there is an ever increasing demand in the Enterprise.

These frameworks include:

  • PhoneGap/Cordova (HTML/JavaScript)

  • Titanium/Appcelerator (JavaScript)

  • Mono/Xamarin (C#)

  • Rhodes (Ruby)

  • Kony (Lua)

Our experience of these cross-platform mobile development tools is that you simply cannot replicate the native app experience. We have experimented with these tools before, an example being the build of the mobile applications for our BMW project using Phonegap. We found that the iPhone version of the app was great. However, getting an optimum experience on Android took a huge amount of effort in optimisation and testing to get it close (but still not close enough) to a native experience.

So what does the future hold?

Native App Development Is Dead in the Enterprise

Mobile

This is a bold statement that will take some time to become completely true. However, 2015 is going to be the dawn of a new era of technology that will replace existing cross-platform tools such as Phonegap and Titanium with a much better offering that will finally succeed where Phonegap and Titanium have largely failed. This will be the beginning of the end of enterprises building responsive sites with multiple native applications to compliment them.

Responsive websites, with the help of new technology will form the basis of the code for native applications without hindering user experience. The applications will be fast and responsive, and there will be a single code base with very little device specific code.

What does this mean? Software companies like Red Badger that currently focus on the enterprise web (i.e. responsive web sites and not native applications) will also be able to deliver great native applications without a great deal of additional effort or the need to hire native app developers. Native application agencies are going to have to adapt and re-skill their employees in order to keep up, or face the consequences of withering into eventual obscurity. The winners will be the enterprise companies. They will have options available to them to  build great experiences across web and native applications on multiple devices with close to a single code base. This means fewer applications, less maintenance, lower development costs and happier customers.

This will ultimately kill the question: “should I build native or responsive?”. Why choose when you can have it all?!

P.S. Where’s my proof you may ask? Watch this space.

UPDATE 2015/02/08: On 28th January, Facebook announced React Native at React Conf. React Native is a game changer and already answers the predictions made in this blog. You can view all of the videos from the conference here.

23
Jan
2015

January London React Meetup

by Roisi Proven

1_red_badger-38-x3

January 21st saw the first React meetup of the year, and we packed as many people as we could squeeze in to the Red Badger office for another round of talks from teams around London who are using React within their organisations. This month we had Jof Arnold, VP of Product from timecounts.org, Gary Champers, a Software Engineer at Football Radar, and Christian Moller Takle from Billeto.

Jof Arnold – from Backbone to React

Jof has been a long term attendee of our React meetups, and we were excited to have him step forward and share his experiences with us.

After a painful experience with using purely Backbone, Jof and the team at timecounts.org discovered React. There were elements of backbone (isomorphism and Backbone models) that he and his team felt they needed to keep, so they worked to merge Backbone with React to get the best of both worlds. Although it’s not necessarily the “correct” way of using React, it is a way to use React with Backbone without rebuilding everything from scratch. 

Gary Chambers – Go Reactive Building UI with Rx and React

Gary came over from Football Radar to join our roster of external speakers for this month.

Football Radar have a very data heavy system, and publishing hundreds of events a second then trying to publish them all to the DOM didn’t work out. After investigating alternatives to their current solution, they too came across React, this time using it in conjunction with Rx. Rx is a library for async dataflow programming, or in other words, a methodology for “data first” thinking, which Football Radar needed. He then went on to discuss how you can translate Rx into Flux, to really get the most out of React.

Christian Moller Takle – Whirlwind Tour of Functional Reactive Programming Using Elm-lang as a Base

Last but not least we had another of our React meetup regulars. Christian built upon the other talks, and took the stand to give an engaging, and very technical, talk.

Elm is a functional programming language that is “not scary, just different.” Christian spoke about Elm language and put a functional programming spin on the core tenets of React. Using Elm, Christian showed how, as in React, you can improve your UI development by modelling your UI as data, and discussed the common concept of the virtual DOM.

 

Here at Red Badger, we love hearing about new ways of using React in conjunction with existing technologies, so this set of talks really gave us a lot of food for though. I think several of our developers are particularly interested in delving further into Elm.

As ever, this Meetup was massively popular, and our humble Red Badger office now fills to bursting point at every meetup. As a result, we have been speaking with Facebook, who have kindly agreed to let us use their offices near Euston for the next React meetup. So expect bigger, better things, and lots more beer and pizza!

Sad you missed it? You can watch the full meetup over on YouTube

8
Jan
2015

Consumers in the driver seat

by Olga Loyev

Empty carI love math. So when it comes to analytics and stats, my brain smiles and my eyes spark, which is one of the things that attracted me to work at Red Badger. We are agile by nature and methodical in practice. We take analytical approach to problem solving and it is an integral part of the solutions we provide to our customers.

I’m a project manager for the Red Badger team at BSkyB where we recently delivered their new Help Site along with the supporting custom CMS to improve user’s ability to find the right content available and enhance their overall experience on the Sky Help site. As part of the the new solution we also added custom events tracking (things like clicks on links, buttons, page views, etc) that feed stats into New Relic Insights so we can closely monitor user behaviour to understand consumer’s requirements. The data we get back serves many purposes: from helping to prioritise work to highlighting outages to understanding customer demand and responding accordingly.

One example that stands out in my mind is what we saw recently on just another normal rainy day in London:

  • 80% of all unique visitors going to a specific article were clicking on “still need help” indicating they haven’t found the information they were looking for

  • 10% of all unique clicks on “still need help” across ALL articles were coming from that specific article. In comparison, the next article where most of “still need help” clicks were coming from accounted for only 5%

  • Daily top 10 most common search terms from the next action after clicking on “still need help” were referring to a specific issue the users were looking for help with

Notifying the stakeholders, we quickly found out that the information regarding the issue needed to be approved by the legal department before it could be published on the help site. Understandable, as it’s important to make sure product information is correct and consistent across different channels.

Fortunately, as soon as demand for this information spiked, we were able to immediately respond to the changing customer requirement and adopt the content to meet those. We shared the stats above with the legal department as soon as the spike occurred. The data highlighted the urgency of the request which was approved to be published within 15 minutes. The editors were then able to instantaneously publish the latest draft of the article which they already had prepared (thanks brand new CMS!) with the info customer was seeking. The published copy appeared on the live site 60 seconds after.

Within 12 hours, the percentage of all unique visitors to that article who still needed help after viewing the content dropped 50% from 80% to 40% with numbers levelling out to expected average by end of next day. Shazam! The power of numbers used for good!

Stats and analytics are powerful tools and should be at the forefront of decision making; driving the delivery of features (and in this case, content) based on real time user requirements. Put your consumer in the driver seat to best meet their online needs and bon voyage!

 

5
Jan
2015

My favourite talks from RubyConf 2014

by Albert Still

RubyConf - San Diego Convention Center

I’ve recently returned from San Diego, California where I attended RubyConf and I’d like to share my experience. Overall the conference was awesome and I learnt a lot. One of the big values of visiting the conference was experiencing the community behind the language. Chatting with other Rubyists, core contributors and even meeting Matz the creator. It made me appreciate what it’s all about and made the long plane journey from London worth it.

Videos of all the talks have recently become available on Confreaks and here are some of the talks I found especially interesting:

Isomorphic App Development with Ruby and Volt

This was a very interesting talk by Ryan Stout and his web framework Volt that runs Ruby on both the server and the client. It uses the Opal Ruby to JavaScript compiler which is apparently very good. Building this framework I’m sure is no easy challenge. But executed well it could make Ruby web development in the future a lot more productive with less context switching. A full stack web developer could get by only thinking about one language! It also means having the same code for validations and routing on both the server and client. It’s still early days for Volt but definitely one to watch out for. Check out the speed he makes a to-do app! And if you’d like to play with Volt quickly clone it’s todos3 app and get it’s server up and running.

Testing isn’t enough: fighting bugs with hacks

Interesting talk by Paul Gross about an additional strategy to fighting bugs. He references bugs such as the Mars Climate Orbiter which crashed due to ground based software that returned an output in the wrong units. And the Knight Capital $440 million trading loss due to some redundant code that interacted with the system. Writing tests and having testers is great but bugs are inevitable. He references Rails and talks about strategies, hacks and monkey patches to reduce bugs. For example Paul works at Braintree and as a security measure they don’t want developers writing code that will look up customers unscoped, they must always look up the the customer through a merchants has many relationship with customers.  So they added a “scoped find hook” which will throw a runtime error if a dev writes code that looks up a customer unscoped. 

Epic intro music: BLE beacons in Ruby

Christopher Sexton explains how we can play with Bluetooth Low Energy beacons and Ruby. Imagine a Raspberry Pi running a Sinatra app connected to a speaker and an BLE beacon next to the entrance of your office. The BLE beacon simply emits a UUID. And when a mobile with his iOS app built in RubyMotion receives this UUID it posts to the Sinatra app running on the Raspberry Pi . Which in turn can play that member of staffs theme tune. When I get the time I’m keen to buy a beacon and get my Raspberry Pi up a running. I had the idea to get the Sinatra app to allow us to post funny quotes we heard our colleagues say. And then when someone walks in the door it could announce one of their quotes!

Stress Testing as a Culture

João Moura talked about integrating stress tests as part of the build process for a 2014 World Cup app. He recommended cloud based load testing loader.io, it provides an API that a continuous integration server could use. This is especially interesting with regards to e-commerce platforms where slow page loads can lead to a surprising decline in revenue.

Best,

Albert

When somebody has learnt how to program a computer … you’re joining a group of people who can do incredible things. They can make the computer do anything they can imagine.

Sir Tim Berners-Lee, inventor of the web

5
Jan
2015

London React Meetup: Christmas Special

by Robbie McCorkell

React Logo

Last time I told everyone that we wouldn’t have a meetup in December, because we assumed you all would be partying too hard to care. However Christopher Chedeau, front-end engineer at Facebook and co-developer of React, decided to come for an impromptu visit. And with Christopher himself in town how could we not put a meetup on? So technically I wasn’t lying to you all!

We knew this would be a popular night, and we haven’t had the time to find a bigger venue just yet, so to avoid the crush of last time we decided to limit numbers for this event. For those of you that couldn’t get a ticket don’t worry, this was just a one off and we’re hoping to find a bigger place next time.

To kick off proceedings our own Stuart Harris talked us through his latest work on a client project. Since his last talk on building isomorphic applications using a custom react view engine for node, Stu and the team have been hard at work expanding on these ideas for a new project for the same client. This time Stu’s talk has the catchy title ‘Building Isomorphic Single Page Applications With Cursors Over Immutable Data’.

In this talk Stu describes a few new ideas that has been packed into his latest project. The first of these is an isomorphic router that allows the server and the client to respond to the same routes, making isomorphic single page applications much easier to build. He also describes how using immutable data structures can help enhance React’s performance, and how this also allows for the use of cursors to unify your application’s data across components. Finally he shows how this all fits together in a sample application along with some comments on testing in a component hierarchy. The source code for Stu’s demo should be available in the new year, and Red Badger is also working on a React template/framework using some of these ideas called Reflex which should be available to contribute to soon.

Next up was Christopher Chedeau to talk about how react was born, how it’s doing now, and what the future is for React. Here he spans quite a range of topics from React’s origins in writing markup in PHP for security reasons, to Facebook’s widespread use of React components today, to the controversial topic of writing CSS styles in within react components.

It was fascinating to hear about React’s humble beginnings, and to hear Christopher’s thoughts on the future of React. It would be unfair of me to try and do the talk justice on here, so you’ll just have to watch it for yourself in the video below! Christopher was also kind enough to stick around for a lengthy Q&A session afterwards which I know everyone appreciated (his talk starts around 55:35 in the video).

Our next meetup will be held around mid January, and we are hard at work finding a bigger venue to fit everybody in. We’ll let you know a date and venue as soon as we can but until then, a Merry Christmas and happy New Year to you all!

24
Dec
2014

UX Tip of the week: Making UX part of the Process

by Sinem Erdemli

Design has gone a long way. Roles have expanded from being a last minute add ons to product strategy influencers. 

Design is no longer seen as the last step of a process that makes a product look pretty to defining product scope. UX design as a profession has been creeping in businesses, as ‘user needs’ start being taken into consideration at board meetings. Now, managers are actually curious about their target users. They want to understand what makes them tick and what is a turnoff. This is all great, but too early to call it a day and go home…

Mom are we there yet?

No. We’re still not there yet. We seem unable to shake off the industrial mind set no matter how agile we are. Our industrialised minds are still programmed to deliver efficiently, we want fast returns to our investments and love performance charts that point upwards. We most certainly don’t like cards that go back, against the flow. 

The question is: How can UX and design be integrated in the development process?

At Red Badger, we work in agile. That means we talk to each other all the time (occasionally about work stuff), we change things, we question the decisions we made, check in with users and do it again until it is right. The designers, developers, testers they all sit together and work together. 

However, that process of close collaboration is difficult to capture on the Kanban board. The project board is there for a reason, it should be a mirror to team activities, it should communicate the process and the goal we work towards. But does it really?

Out of sight, out of mind? 

The issue with keeping UX as an isolated step in the process is that once the stories pass through and get closer to Done, the goals change. After a certain point, the goal becomes efficiency and you find yourself focusing on just delivering features, making sure they pass cross platform tests. 

We’ve talked about how crucial it is to keep your personas close and introduced Bob. If you haven’t seen that post do it-here and now.

We suggested sticking a picture of your version of Bob next to your computer, on the wall, by the project board. Somewhere you pass, and will see-daily. 

ALWAYS keep in mind that there will be people using your product (unless of course your target group is animals, insects, aliens..) It is important to have check-ins with users. Just like daily stand-ups you have with the team or weekly progress meetings with your client, make sure you check-in with the end users, and take a step back to make sure the greater goals and the purpose of your project are still there. 

kanban

  • Discovery: This is a good point to discover why you should get started in the first place. Find out about the strategic goals as well as the technical feasibility. Test the concept, go and get a feel for what the intrinsic needs and behaviours are. What people might like doing, what do they enjoy, who do they follow and most importantly why they do so. Use this space and time to go wild. Explore and question everything.
  • UX: You know the drill here. Use all the wisdom you have to do your magic. 
  • Design: Make sure the design reflects the brand direction, the look and feel is consistent with your intended messaging
  • Dev: Check that the high-tech features make sense to people who will be using the product
  • Test: Try to find out the different use scenarios, validate the assumptions you’ve made
  • Done: Watch usage, do some proper testing, measure and watch behaviour. Use all the data you’ve collected to write up new use cases, start thinking about improvements 

Disclaimer: We’re still testing this out. It’s already changed within a week. The user testing section doesn’t have to be a physical test with users, . 

It’s merely a suggestion rather than a solution- as always. Do try it at your own risk- we suggest collaboration over supervision. 

Until next time..

Ta!