Posts Tagged ‘Red Badger’


WE HIRED A GERMAN CASTLE! ( AKA the best summer party ever)

by Amy Crimmens

Last month all the Badgers plus a whole heap of our friends and partners headed off to Leipzig to spend the weekend IN A CASTLE.

Red Badger is quite well known for throwing pretty fantastic parties (last year we took everyone to a private island) but I think last weekend was our best yet. We have resorted to writing a collaborative blog as after looking through the fantastic photos we have realised many of us have a missing hour here and there; so here are some of our favourite bits….

London > Leipzig, Joe Dollar-Smirnov

It was that time of year. The Badgers were ready. The annual summer party was upon us and in preparation we had packed our bags, booked our tickets and made arrangements to convene in one of the various trains heading to Standsted airport on that Thursday afternoon.

Badgers, distributed around Central London put down their tools, let down their hair and embarked on a journey to the mystical place that had been slowly revealed from a series of teasers earlier in the year.

The holiday had started.

Champagne toasts on the train, cheering and laughing and last minute panics, checking to see if everything was packed.

By the time we got to the airport the Badgers were united with their beloved plus ones for double the fun. Meeting and greeting new faces and old. Distributed teams, across bars in departures. Long queues. Very long queues. Then the next long queue to check in to our flight.

Looking up and down the line every other person was a Badger. The plane took off, more drink, some sleep then land.

A slightly lethargic but excited group gathered in arrivals led our fabulous crowd control expert. One by one she called off the names from her list. Organisation like this does not come easy. Herding cats.

“Half of you in that coach, half of you in that coach”

And off we went.

1 hour later the hi-tech luxury coaches pulled up to a mysterious location in a quiet village.

150 tired but excited, ready to go again, yet some hungover people all disembarked. It was 11pm at night.

BOOOOOM and a fireball of red hot flames shoots into the sky. Some duck and cover, some cheer. Everyone is amazed. Again, BOOOOOOOOM. Another fireball. A dragon is spitting excited fireballs into the air and then above the din the sound of the founding Badgers and the rest of the welcome party can be heard shouting, laughing and enticing these coach loads into the Castle.

This is where the real fun begins.

The Gothic Masked Ball, Valentina Soricaro

Finally the long awaited evening comes….I had been preparing my outfit for months and I was so curious to see how everyone else looked like. And I was not disappointed!



Despite being the only known “goth” in the company, everybody had made a massive effort and when I walked  down the castle stairs to meet at the Champagne Reception accompanied by a String Quartett, my eyes were overwhelmed with lots of black, darkness, mystery, fascinating masks and beautiful smart dresses.

group blog

The evening continued  with a great dinner and when we entered  the hall, everything was  decorated in the classiest way and there were beautiful flowers and candles all around, thanks to the work of our 3 amazing colleagues Amy, Saadia and Becca. I am sure I wasn’t the only one feeling like I got the time machine back to the 12th century.  The food was fantastic and we soon were drowning in rivers of delicious wine from the castle vineyards. After the dinner the merry Badgers met on the dancefloor to set free their inner ballerinas at the rythm of Trikosaki music (a band hired just for the occasion) and not long after down in the basement for some Techno courtesy of our founder Cain and other amazing Djs!


Remembering it now, I get a weird feeling of nostalgia and euphoria at the same time. Being in that decadent beautiful place, all dressed up, all having fun, all sharing our life outside of work, all being happy,  truly made it a special and unforgettable evening (despite some blurs given by the wine…). Most of the Badgers made it through the end of the night and I retired in my room at the early hours of the morning, with smudged make up and the happiest smile on my face!

The day After…., Harri Adams

I would love to tell you about our visit to the vineyard on Saturday, but sadly I was still dancing with a bottle of prosecco clutched in my hand when many badgers were getting up for breakfast. Safe to say, when I eventually went to bed, I was out for a good few hours. When I eventually emerged (around 5pm) I was feeling fresh and ready to do it all again!

By this point, there were some interesting tan lines (award for best suntan undoubtedly goes to Jon Yardley’s sock-marked ankles), some jolly wine faces, and all sorts of stories about the weird things that had be found in the castle the night before. Sombreros, bottom halves of mannequins, giant bathtubs, creepy portraits, strange metal sculptures, furry-walled rooms… And that’s just for starters.

We sat by the pool in the evening sunshine, drinking more prosecco and smothering each other in glitter, growing more ravenous by the second. As soon as the BBQ was ready, we scampered up to the ballroom and enjoyed a feast of german sausages, burgers, halloumi and a variety of salads, all washed down with many more alcoholic beverages. I’m sure you’re starting to see a pattern here…

IMG_2354 (1)

An hour or so later, and we heard there was a surprise waiting for us all by the pool. Electric with excitement, we gathered outside, just as the first of the fireworks lit up the night sky. What a spectacle! A truly special and memorable moment for us all – sparklers in hand, or in Federico’s case, a flare in hand.


Afterwards, feeling on a high, we all headed back to explore more of the castle. I found myself an hour or so later in the Liebe room, a room with fur walls hung with many naked pictures. I chose not to think too carefully about what those walls had seen. Towards the end of the night, about 20 of us ended up sat around the huge dining table chatting and listening to music. The venue couldn’t have been better suited to us and it was fantastic to share this experience with so many like-minded, fun people – it’s sometimes easy to forget they’re our colleagues.

Huge hats off to Saadia, Amy, Val, Becca & Nathalie for all their hard work – without which either the party would never have happened, or we’d all still be there.

The Castle, Becca Evans

I think it is fair to say the castle itself was EPIC. I remember when we first went over in June to do a recce – there had been a rave for about 300 people the weekend before, the place was a tip, people were literally still crawling out of it – but even in its state of complete chaos we were still blown away.

It took 3 hours for Armin to give the complete tour of it (albeit we were stopping every 20 minutes to refill our wine glasses) and at the end of it all i thought was the Badger’s are going to bloody LOVE this!

As soon as everyone arrived on the Thursday evening (much to Dave’s dismay…) they spread like wildfire – for such a huge place we really managed to make our mark. From the main dining room, to the balcony, to the weird Liebe room (I still haven’t worked out what that room is actually used for although i think i have a good idea…) there were Badger’s everywhere – it was the perfect setting.


I think the best thing about the castle was how versatile it was. On the evening of the Masquerade Ball everything was done to perfection – the chandelier staircase leading down to the champagne reception looked like it was built for royalty and the main dining hall that we ate in was equally as grand…. Fast forward 6 hours and you would find half the badgers had made their way down to the underground caves where the after party had begun. Things were a lot less fancy down there – it was dark and there was a smell that I would like to forget – but no one seemed bothered – they just wanted to carry on the party..

It really did cater for everything we wanted  – An evening to begin with decorum and to end in debauchery…


I think the main reason for the weekend being such a success was because of Armin (the owner of the castle). For those of you that met him, you will agree he is a unique character – his answer to pretty much anything to both men and women is “just take your clothes off”. Throughout our trip he was on hand to make sure everything was going to plan and that we had everything we needed, e.g. 20 extra bottles of Cava at 9am by the pool – it was there without fail.


(Armin with his brilliant yellow trousers)

The castle really was a magical place but it was the people that made it special. Now that we have been back a couple of weeks and just about recovered – who is ready for round two? I am.

Back to me again ( Amy)…

It may sound like it was one big party, and it was, but we also spent a day thinking about what we want to achieve over the next 12 months and came up with some great ideas. Spending time away together is also a great opportunity to build memories as a team and remind ourselves what fantastic people we work with. I think we’ll be talking about this trip for a long time to come!

There are heaps more great photos from our trip here. If you’d like to join our brilliant team check out or vacancies here and get in touch!


Celebrate National Badger Week

by Roisi Proven

It’s National Badger Week! I thought I’d take this time to talk a little bit about our namesake, and the qualities that we share (and some that we don’t).


  • Badgers have been present on the British Isles for up to 400,000 years. Red Badger has been present on the British Isles for 6 years.
  • Badgers live to about 24 years in captivity, and around 14 years in the wild. We have proof that Red Badgers live well into their 50s, and we hope much longer than that.
  • There are eight different species of badger. There are two species at Red Badger. Human, and Daschund (which is German for “badger dog”).
  • The welsh name for badger is “moch daear”. Which translates to “earth pig”. People at Red Badger have been called many things, but never earth pigs.
  • Badgers are very clean and will not poo in their sett. They have special chambers designated as latrines. Red Badger has two toilets which are fiercely fought over. Milo has not been given the badger rule book on pooping.
  • Badgers can eat several hundred earthworms every night. I asked in the Red Badger Slack channel if anyone has ever eaten an earthworm, but I received no response. However someone did respond with the snake emoji which I am taking as an admission of guilt.


  • Badgers have unusually thick skin. Here at Red Badger, we’re a far more sensitive lot.
  • European Badgers are famously social and vocal creatures. Red Badger parties are the stuff of legend, and we do a mean karaoke.

by flickr user


Badgers are protected in the UK. It is an offence to wilfully kill, injure or take a badger (or attempt to do so), or to cruelly ill-treat a badger. We always make sure everyone at Red Badger is treated kindly, and we have space in our sett for more.


Give it 5 days – Facebook Relay and GraphQL

by Albert Still

Relay schema screenshot

Me and Alex Savin have been rebuilding Red Badger’s blog with Relay and GraphQL. Relay is a front end Javascript framework that works with React to consume a backend GraphQL server. Relay deals with querying a GraphQL server and passing the data to your React components as props. And making mutations on the server while giving you optimistic update and error handling capabilities. But it will soon also be handing in-memory/client state and isomorphic universal app features. Then it will become a competitor with Flux, Redux and Red Badgers Arch. Furthermore a React / React Native / Relay / GraphQL set up could become all you need to deliver the ultimate single page web, iOS and Android app.

A blog by Basecamp co-founder Jason Fried called “Give it 5 minutes” was referenced in the React docs when it came out because React challenges conventional wisdom such as having HTML in your JS. Unfortunely with GraphQL and Relay it’s more like give it 5 days. There is a lot to learn and some of the example code is long in comparison to the short neat examples we saw with React. But power through and you will see the light of Relay and GraphQL. However do bare in mind the libraries are young and there will be some time consuming and confusing error messages along the way.

The libraries

Before Relay came out we only had one library to play with which was graphql/graphql-js. I wrote a blog on this library where I made a GraphQL sever for querying data on any movie in The Open Movie Database. Now since Relay came out on August the 11th we have 3 more libraries to play with!

  1. graphql/graphql-relay-js – A small library to help us construct a graphql-js schema supporting Relay. There are 3 core assumptions Relay make about your GraphQL schema. You can think of these as additional specs to the pure GraphQL specification.
  2. graphql/express-graphql – Express middleware that makes it easier to create an endpoint that will receive a GraphQL queries. It accepts queries via a HTTP POST or GET and returns a JSON response.
  3. facebook/relay – the Relay library itself which runs in the clients browser with React

And fortunately relayjs/relay-starter-kit which ties React and all four of the above libraries together to help us get going quickly. Also if you want to play with example Relay apps check out the 3 official Facebook ones in the example folder in the Relay repo. And the very recently released utility library graphql/graphiql is absolutely sick, it’s a React component that lets us render an in-browser GraphQL IDE to test out our GraphQL server.

The magic

Native app speeds with caching – no need to refetch the same node attributes again over the network!

When you visit our /blog index page our SPA application using Relay & React Router (great blog post about doing this here), Relay makes a GraphQL network request asking for 15 posts and a small subset of the post fields(aka attributes) we need to render the multiple PostPreview components. These fields are specified in the PostPreview’s Relay container. For example it asks for the title and the published at date but not the posts body. Now what’s cool is when you click on the post and view the actual post page, Relay makes another request this time asking for more Post attributes such as the body. But this time it does not ask for the attributes Relay already has in it’s store, even though the Post Relay container specifies them. This is because a Post in our GraphQL schema implements the node interface and has a globally unique id which Relay asks for and uses as a key in it’s cache. Overall this is nice feature we get for free that makes our app more performant and gives us native navigation speeds! 

Continuous scrolling made easy

One of Relays features is it declarative like React. Watch here how I declare the post’s index page displays 15 posts initially, then fetch 5 more when the user gets to the bottom of the page. Furthermore I use React’s setState(function|object nextState[, function callback]) and Relay’s setVariables([partialVariables: Object, [onReadyStateChange: Function]]) callbacks to display a loading message to the user! Very easy to do!

It lets your front end developers move faster

A GraphQL/Relay set up separates your back and front end team and allows your front end developers to move fast and provide awesome UX. When a view needs an extra attribute you simply add it to your components fragment and your done. No need to make changes to traditional ad-hoc backend server endpoints.  

We are hope to open source our Relay blog soon so people can reuse it! Cheers.


Nerdy Babelfish – The Importance of Communication in Tech

by Roisi Proven


Here on the Red Badger blog, we certainly don’t pull any punches where technical discussion is concerned. In a lot of posts, we assume a high level of knowledge when it comes to our readers, and avoid going overboard with explanation in order to get to the core of our discussion without being boring.

I for one think that this is a great thing. We want to attract the most intelligent, highly skilled people to interact with us, and we can’t do that if we over-simplify things. I feel hugely proud to be a part of a company that has the courage to push forward with new tech, no matter how complex it may seem at first glance.

However, for the less technical people in the team (I include myself in that) it can present a bit of a dilemma. For testers and project managers especially, who bridge the gap between technical and operational, knowing how to explain things is crucial. When you work with a team of such highly skilled developers, you have to be able to not only keep up with them, but make a very complicated thing highly digestible from a business perspective. 

From Code to Conversation

To me, good communication skills are vital if you want to work in tech of any kind. Just because one person understands everything there is to know about a system, doesn’t mean the person fixing the bug you write does. Similarly, your client will likely have a very different, non-technical focus to the project. As a result, you need to be able to distill a sometimes mind-bogglingly complicated technical problem into a form that even the least technical Product Owner can understand.

Let’s take something that, for anyone in web development, will be very familiar. Deploying code from a local environment into a live environment. This will obviously vary depending on how your business functions, but the core steps are the same. You write your code, spinning up a local environment to check your work. You write some automated tests to cover your work, and then submit a Pull Request on your repository for review by another coder. This code will then be tested further and deployed on to your live environment, usually running the tests through a Continuous Integration tool such as Circle or Travis. Simple right?

Or maybe not. Here is a top level breakdown of concepts and terms in the paragraph above that may leave non-technical people scratching their heads:

  • Deployment

  • Local environment

  • Automated tests

  • Pull request

  • Repository

  • Continuous Integration tool

That list is just the tip of the iceberg, as I’m sure if we were to go into more detail about the the build process we would lose people even further. So when I’m explaining how long a build will take to a customer, there is absolutely no point in me explaining it like this. 

From Conversation to Code

This process can most definitely work the other way around as well. If a client adds a bug of their own to the database, or requests a new feature, it can be easy to dismiss it because it seems frivolous or insignificant. This is because, as technical people, our priorities are different. We want to have something that runs smoothly and looks beautiful, and woe betide anyone who asks for something that we feel may compromise that.

A notable example of this for me, is some of the tracking and 3rd parties that I’ve seen requested for integration into various projects. If you look at them in a purely technical way, they are by and large quite undesirable. They may risk slowing down your site, or perhaps cause conflicts with already implemented features that will take more work to fix.

This won’t matter to your client. What matters, invariably, is the continuing success of the business. If the implementation of a 3rd party could hugely improves customer engagement on their site, arguing with them about milliseconds is unproductive and may become needlessly combative.

So What Can You Do?

On both sides, the point at which communication breaks down is the point at which people stop asking “Why?” From the tech side, why am I making this change? Why is doing it this way better than doing it in a way that may seem faster? There’s no need to get technical with those answers.

Going the other way, we should be asking why we are implementing, while still staying empathetic to the overall needs of the client. Yes, to a developer certain 3rd party integrations may seem painful, but if they have sat down prior to starting the work and learned a bit more about the situation surrounding the task, the work will feel more meaningful, and you may even be able to suggest a better alternative.

Through all of this, you should always try to put yourself in the other person’s shoes. I will never sit down and have a conversation with someone without first spending some time thinking about how they might take the news I’m going to give. Often it’s not about the words you say, it’s about the delivery. So I can boil a build deployment right down to “the feature you want will take us 3 hours to take through our internal process” and as long as I’m delivering that with meaningful information such as timescales, the complicated stuff isn’t going to feel so important.

Once you put tech jargon or business jargon aside, it really is just two people having a conversation about something that they both really care about. As long as you remember that the person sitting across the table from you wants the same thing, the rest is easy.


Want to work somewhere where you don’t need to be afraid to stand up and give your opinion? We’re hiring! Join Us


Staggeringly Smooth – the Fortnum & Mason E-com Release

by Roisi Proven


It would be difficult for me to overstate the importance of launching a brand new version of an international e-commerce website. This was no mere reskin, we have been rebuilding the Fortnum & Mason website from the ground up. We started with the decision to use Spree Commerce for the storefront, and have been continuing all the way through to building them a bespoke CMS using our very own Colonel.

Because the Fortnum brand values customers above all, they felt it was of the utmost importance that the customers help drive the direction of the site. As a result, we decided it was important not to rush a release. We have spoken already about our approach to deployment, allowing us to deliver rapidly and regularly, but in order to get to that stage, we needed to be confident that the core of what we were delivering was sound. 

The First Step

The first thing that we had to do before we could make a plan, was to figure out where our weaknesses were. If we knew the elements that were most likely to fail, we could work pre-emptively to fix these areas before going live to the world. What has always been apparent to us is that with so many 3rd parties to rely on, no amount of automated or manual testing was going to truly expose our pain points.

So, as soon as the site was fully transactional, we made the decision to do a highly controlled soft launch prior to Christmas peak. A selection of Fortnum’s trusted customers were contacted, and given a password to our still very much unfinished site. By communicating to these customers, and making them a part of our development, we hoped to not just get a more robust test of our site. We also aimed to gain feedback from these key users which would inform the ongoing development.

The Slow Burn

And so the feedback came. However, it came slowly. Too slowly for our liking. So, further down the line towards the middle of January, we had a meeting with the team over at Fortnum. We came up with a plan to run both the old site and the new site in parallel, directing traffic in ever-increasing quantities to our site. So was born.

The need to login to get access to the site was removed, and people started using our site. For the first time, we weren’t just inviting people to use the site, we were allowing them to get there on their own, initially via a marketing email, and later by directing a percentage of traffic from the old site to the new. In doing this, we were making sure that when the time came to release to 100% of the public we wouldn’t see the dip in sales and conversion that so often accompanies site re-launches.

Running two sites at the same time came with it’s own problems. There were moments when we wondered if we should have held off on introducing users to the new site, despite the fact that we knew releasing to customers early with the intention of learning from them was hugely important. However, how well it worked was undeniable. Major issues were uncovered, but instead of affecting hundreds of customers, it would affect one or two. If a couple of people encounter an issue, you can contact them personally and make sure they still feel of value. If hundreds, or even dozens of people are affected, it becomes a great deal harder. Also, if there were any issues that we needed more time to fix, it was very easy to direct all users back to the old site.

“Release” Day

The 17th of February rolled around. This was the day we had all been waiting for. For the previous fortnight, around 40% of Fortnum and Mason users were being directed to using the Qubit system to redirect them. We had encountered issues, some minor and some not so minor. We had managed to maintain our development momentum along with fixing these issues. Using Kanban, we had a clear view of work in progress and bugs that needed fixing urgently, all the while maintaining a focus on throughput – getting features shipped into live.

At 8am we made the call to change the DNS records. The old site drifted away, and became We pulled up our analytics and collectively held out breath.

It just worked.

A part of everyone was waiting for the other shoe to drop, for complaints to start flooding in or for orders to start failing. A bigger part of us knew that our gentle filter of customers over the previous weeks and months had prepared us well for this. Of course there were still small issues, a customer struggling to pay here, a missing product there, but overall there were no alarming issues.

Ongoing Positivity

The new Fortnum & Mason, complete with Feedback banner


As the website bedded in over the next couple of weeks, we continued to see minimal issues and an increasingly positive impact. We have already seen an overall growth of 89% year on year, with the conversion increase coming in at an impressive 20% up. We have also seen an 18% reduction in customer service calls, with a particular drop in calls related to issues with payment.

As we finish up our first couple of months being fully live, the mood across Red Badger, and across the business at Fortnum, has been hugely positive. We are immensely proud of what we have achieved, and we don’t feel that we could have had such a successful release if we hadn’t ramped up slowly in the way that we did.

We are looking for a great Agile Project Manager to join Red Badger- if we sound like the kind of place you’d like to work drop us an email – we’d love to hear from you!


Death by meeting (strippers need not apply)

by Harriet Adams

Over the years, I’ve worked with a number of FTSE 100 companies. To this day, I still have no idea how anyone gets anything done, considering most of their 9 – 5 is either in meetings, preparing for a meeting, or talking about the actions from those meetings in another meeting.



Utterly bewildered, I’d go along, often spending hours going over the same topics for the output to be:

  • We need another meeting to discuss further because we’ve run out of time
  • We can’t make a decision yet because [insert name] isn’t here
  • We don’t have enough information to make a decision

URGH. If there’s something that frustrates me it’s inefficiency. What’s the point of inviting all these people unless we reach a decision or a series of next steps? And why on earth am I here?!

It’s almost like the more people involved, the better and more important the meeting is perceived to be.


Funeral strippers

A couple of weeks ago, I read an article about the Chinese authorities clamping down on “funeral strippers“. Supposedly, the more mourners you have to your funeral, the more well-off your family appears. Therefore, in order to achieve higher levels of attendance and seem more wealthy, some families have resorted to hiring strippers to attract the crowds. 

On paper, it may seem a bit of a stretch as a comparison, but all too often we are big-headed and assume that what we need to discuss is particularly important. The entire team (and often innocent bystanders) are invited to pointless, boring discussions with no tangible output. Everyone joins, drawn in by the promise of something exciting, feels awkward throughout, and ultimately leaves feeling dead inside.


Upfront contracts

I learnt a technique on a training course a while ago about Upfront Contracts – something I try to enforce before every conversation and every meeting. A UFC should consist of the following.

  1. Purpose. What’s the point of the meeting / conversation?
  2. Agenda. What are we going to be talking about? Are we all in agreement that this is the right agenda?
  3. Timing. How much time do we have in total to reach a decision?
  4. Output. What do we all need out of the meeting, and at what point do we decide that it is over?

What this doesn’t consider, however, is the quality or number of people in attendance. This goes back to the Lean Start-up concept. Who are the influencers that will enable you to progress? What’s the minimum amount of input you need to reach a way forward?

This is a very important point, as inviting the wrong people may lead to the same problem, despite having a clear set of objectives.


Another one bites the dust

In fact, sometimes meetings aren’t necessary at all. Again, referring back to Lean Start-up, sometimes it’s necessary to pivot to be more efficient. A good example of this at Red Badger was during a recent project. Retrospective discussions were being held at 4.30pm every Tuesday afternoon but it became clear that the team were mature enough to raise issues in a reactive manner, and add them straight to the Kanban board.

By removing the meeting entirely and only running it when there were three items for discussion on the board, the team were able to be more productive but continue to make important changes to the process when it was necessary.


Making peace 

I’m not saying that ALL meetings are unnecessary. Quite the opposite.

But next time you have an important decision to make or need to arrange a meeting, think about the following.

  1. Is this meeting absolutely, definitely necessary?
  2. What is the purpose of the meeting and what do you need the end result to be?
  3. Who are the main influencers in reaching this point?
  4. What do we need to talk about to get to this result?

If you ask yourself these questions and make the answers clear to everyone who joins, you’ll make decisions faster and avoid disrupting the team.

In Layman’s terms, you’ll be slicker and quicker (with no stripper).


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, 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 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!



Silicon Milkroundabout – From both sides of the fence

by Roisi Proven


On Saturday May 10th, I nervously walked through the doors of the Old Truman Brewery for the first time. I’d heard good things about Silicon Milkroundabout, but had always been too nervous to give it a go myself. However, job dissatisfaction paired with the desire for a change drove me to finally sign up, and I was assigned a spot on the Saturday “Product” day.

I have to say as a first timer, the experience was a little overwhelming! The hall was already starting to fill up when I got there at 12pm, and there was a maze of stalls and stands to wade through. The SMR staff were very helpful, and the map of the hall I got on entrance made navigating the maze slightly less daunting.

I’d done my research before I got there on the day, and I had a little notebook of companies that I knew I needed to make time to speak to. There were 5 I felt I HAD to speak to, and a few that I was drawn to on the day, based on their stand or the company presence overall. At the top of my shortlist was Red Badger.

In May, RB had a small stand near the door, not in the middle of things but easy to find. I had to do a bit of awkward hovering to get some time with one of the founders, but when I did we had a short but interesting conversation. I took my card, filled in the form, and kicked off a process which led to me getting the job that I am very happy I have today.

Fast Forward to November, and my Saturday at Silicon Milkroundabout looks a whole lot different. This time, I’m not a candidate, I’m the person that people are selling themselves to. A different sort of weird! The Red Badger stall looks different this time around too. Where before we had a small table, this time around we had an award-winning shed.


That awkward hovering I said I did? There was a lot of that going on. Having remembered how daunting it was to approach a complete stranger and ask for a job, I did my best to hoover up the hoverers. I had a few really interesting, productive conversations during the day, but just as many were people who just wanted to compliment us on our stand or our selfie video. It was great to get some positive feedback for all of the team’s hard work on the run up to the weekend.

The biggest difference was, given the fact I was standing still, I was able to fully appreciate the sheer amount of people that came through the doors, and the variety of roles that they represent. The team at SMR have done a great job of keeping the calibre of candidates high, and it does seem like there is a candidate for almost everything the companies are looking for.

Here at Red Badger we’ll be combing through the CVs and contacts that we made over the weekend, and will hopefully be making contact with a several potential new Badgers soon. For anyone that met us this time around, thanks for taking the time out to hang in our shed. For anyone that missed us, we’ll see you at SMR 9 next year!


Improving Performance with New Relic APM and Insights

by Roisi Proven

In any kind of tech development, knowledge is power. When working on an ecommerce site, knowledge is essential.

The more information you have about your application, both during development and when it goes live, the more value you will be able to provide your client and in turn to the client’s customers. When in a development environment, it’s easy to provide yourself with a breadcrumb trail back to an issue, but when your code moves into a staging environment, the information you provide can end up being a lot less useful. At one point, this was as useful as it got for us:

With no way to know what this “something” was, and after a few awkward problems where we very quickly reached a dead end, we made the decision to introduce New Relic APM into our workflow.

New Relic APM helps you monitor your application or website all the way down to the code level. We have been using this in conjunction with New Relic Insights, their Analytics platform.

With New Relic we have been able to track VPN downtime, monitor response times and get stack traces even when working in a Production environment. So the above vague message, becomes this:

This monitoring enables you to increase confidence in your product in a way that isn’t possible with simple manual or even automated testing.

In addition to the APM, we’ve also been working with New Relic insights. It behaves similarly to Google Analytics. However, its close ties to APM’s tracking and monitoring, means that the data is only limited by the hooks you create and the queries you can write in NRQL (New Relic’s flavoured SQL language). It feels far meatier than GA, and you can also more easily track back end issues like time outs, translating it into graphical form with ease (if you’re into that sort of thing).

Being a new product, it is not without its pitfalls. In particular, NRQL can feel quite limited in its reach. A good example of this is the much publicised addition of maths to NRQL. That a query language didn’t include maths in the first place felt a bit like an oversight. However, this has been remedied, and they have also introduced funnels and cohorts which should add a lot to the amount you can do using Insights.

As a company Red Badger has always valued fast, continuous development. While traditional BDD test processes have increasingly slowed us down, by improving our instrumentation integration we hope to be able to improve our speed and quality overall.