React Native – The Killer Feature that Nobody Talks About

by Robbie McCorkell

React Native logo
At the end of January I was lucky enough to go to React conf at Facebook HQ in Menlo Park. This was my first tech conference, and it was a great and inspiring experience for me. The talks were excellent and I recommend everybody check out the videos, but the talks that really stole the show were the ones on React Native.
React Native allows developers to build real native applications using javascript and react, but not web wrapper applications as we too commonly see. React simply takes charge of the view controllers and programatically generates native views using javascript. This means you can have all the speed and power of a native application, with the ease of development that comes with React. 

Playing with React Native

This is a really exciting development for the native app world, and gives a new perspective on what native app development could be. I’d previously tried to learn iOS development a couple of times, first with Objective-C, and later with the introduction of Swift. Whilst I think Swift is a massive improvement in iOS development, I still ended up getting bored and life got in the way of learning this new system. So initially, the idea of using my current skill set in React web development to build truly native apps was extremely enticing (and still is).
I generally believe that as a developer you should pull your finger out and learn the language that suits the job, but in this instance React Native seemed to offer more than just an easy way into iOS development. It offered a simple and fast way to build interfaces and to manage application logic, and the live reloading of an application in the simulator without recompiling blew my mind.

Luckily for me, conference attendees were given access to a private repo with React Native source code inside, so I began playing as soon as I got back to my hotel room. Within 5 minutes I was modifying one the provided examples with ease without any extra iOS development knowledge, and I was hooked.

An addendum

Since then I’ve been leveraging my early access to talk publicly about React Native to some great reception. It’s been fascinating discussing this with people in the community because I hear very little scepticism and a lot of excitement from web developers and native developers alike (at least those that come to a React meetup).

However the more I talked about it the more I realised the message I was conveying in my presentations was not quite right. One of the major themes I focused on was the fact javascript developers like myself can now easily get into the native world, and that companies only need to hire for one skill set to build and maintain their entire suite of applications. 

This is still a hugely important advantage, but it isn’t the major benefit and doesn’t highlight what React Native offers over competing frameworks. It also doesn’t perfectly align with my view that looking for a tool or framework just to reduce the need for learning another language is lazy thinking. There’s more to React Native than this.

React Native’s advantage

React Native’s biggest feature is React.

This may seem a bit obvious (the clue is in the title) but let me explain. When I first looked at React I thought it was insane like most people. It takes such a different approach to web development that it gives many people an immediate repulsive reaction. But of course the more I used it the more I realised I could never go back to building web applications (or any front-end app for that matter) any other way. The patterns react provides are an extremely powerful way of building applications.

If you haven’t used React much it might help to know that React lets you declaratively define what your view should look like given some input data. A react component is passed some properties that it requires to render a view, and as a programmer you simply define the structure of the view and where that data should sit. In doing this you’ve already done half of the work in building your application, because if a component or any of its parents changes their data (in the form of state), React will simply re-render the affected components given the new data.

No specific data binding. No event management. No micro managing the view. Just change the data and watch React recalculate what your view should look like. React will then use its diffing algorithm to calculate the minimum possible DOM manipulations it can do to achieve the desired result.

The second half of your application structure is of course user interaction. Patterns and tools like Facebook’s Flux and Relay help with this, but essentially these are just ways in which you can modify the data in your application in a neat and scalable manner. The application still simply recalculates the structure of the view once the data has changed.

React really shines when you start to scale an application, because the complexity of your application doesn't have to increase too much. This is of course quite hard to demonstrate in a blog post, but I can give you an example of a simple little app written in angular and react that I adapted from Pete Hunt, one of React's creators.


See the Pen RNBVZz by Robbie (@robbiemccorkell) on CodePen.


See the Pen VYBbyN by Robbie (@robbiemccorkell) on CodePen.

You can see in the code above that the React implementation is pretty short, even with the markup defined in javascript. This is mostly because of the lack of linking functions connecting the code to the markup. React will just figure this out by itself. With all of this re-rendering of the markup every time something changes, you would think React would be quite slow, but it's not. For a demonstration of how React performs in comparison to other frameworks check out Ryan Florence's presentation from React conf.

This is an extremely simple and powerful way to build front-end applications. It combines the best of both worlds in a simple and easy interface for the programmer, and a performant experience for the user. It’s for this reason more than any other that React Native is an exciting new tool in native app development. It changes the way a programmer thinks in building the front-end of their app.

A sample React Native app

Tappy Button screenshotIn the talk I mentioned above I demonstrated some of my ground breaking research in video game technology with a game I created that I call Tappy Button. The objective of this game is to tap the button in the middle to increase your score.

The sample code below defines the full application seen in the screenshot including view structure, styling and application logic. What you should notice here is that the code is extremely unremarkable. It’s the same kind of React we know and love simply applied to a native app context, and that is what’s so remarkable about it. The only differences to traditional React web development are the element names1 and the inline styling2.

Building the same application in Xcode using Swift requires a similarly small amount of code, but it does require the developer to perform a process of clicking and dragging to create elements, constraints and method stubs in the code which quickly becomes tedious. As the application becomes more complex, the developer must manage collections of view controllers that manually update the view when required. But in React the view is declared once and all the developer must do is make sure the data inside each component changes when necessary. 

Other frameworks have crossed the JS-native divide in a similar way to React. NativeScript neatly gives developers direct access to native APIs in javascript3, and the creators of Titanium have been very vocal about the fact that they have provided similar javascript bridging and CSS styling for native apps for years. But all of the articles I’ve read that compare these frameworks are missing the biggest differentiator between React Native and the others, and that is React itself.

When discussing React Native, the ability to write native apps in javascript only really deserves a cursory mention in the discussion. What's really important here is that we can build native applications using the power of React.

React as the view engine

The important things in the future of React won't be more features, add-ons or utility libraries. Yes some improvements, optimisations and structural changes will be built in down the road, but I don't think Facebook want to overcomplicate something that works so brilliantly and simply already. 

We already have React being applied to different areas with React Native, and at React conf Netflix announced they were taking a similar approach, even applying React to embedded devices like TVs using their own custom built rendering engine. We've also heard that Flipboard have swapped out the DOM in favour of canvas elements in their latest web app to impressive results.

In the future we are going to see React applied to many different areas of front-end development by simply swapping the DOM and browser out for another view structure and rendering engine, whether that be mobile and desktop native elements, canvas, embedded devices, or who knows what. This will allow developers to use the power of React and its development patterns in any environment.  

Writing native applications for our phones is just the beginning, and it’s a direction I can stand behind. The biggest benefit of react native isn’t javascript. It’s React.


  1. The two base elements we can work with are 'View' and 'Text' and which act as block and inline elements respectively. Coming from the world of the DOM, we can simply translate 'div' to 'View' and 'span' to 'Text' and we’re basically good to go. Any other elements like 'TouchableHighlight' are utility components provided to us by React Native’s component library.

  2. Facebook have provided their own CSS based styling interpretation including their own clever implementation of Flexbox. We now write our styles as javascript objects and apply them inline to our view elements. Currently styles don’t seem to cascade, which is both an advantage and disadvantage depending on your use case. But the interesting thing about applying styles in this way is you have the full power of javascript at your fingertips. With a bit of forethought you could conceivably come up with clever systems to share global styles, and apply them to elements automatically in your application.

  3. I think NativeScript could be an interesting way to build react native bridges to native APIs, and we'll be experimenting with this in the future. However I’m still sceptical as to whether the overhead is worth it, and maybe if we want to build native bridges we should just learn the bloody language!

Red Badger are hiring. Come join us


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.

Red Badger are hiring. Come join us


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.


Learning to Code in Two Days

by Amy Crimmens


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.



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.


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


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.


January London React Meetup

by Roisi Proven


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


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!



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.



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


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!