Red Badger meets Queensmead School for BIMA Digital Day

by Jack Vickers

Over one hundred agencies and 100 schools from around the UK took park in BIMA Digital Day, a special day that helps to educate students giving them an insight into the tech world to impart their knowledge. A few Badgers attended Queensmead School in South Ruislip to participate on 17 November.

What is Digital Day? Digital Day was created in 2012 as a pragmatic response to the digital talent shortage by coordinating BIMA members to help raise awareness of digital careers amongst young people.

How does BIMA benefit students around the UK?

Digital Day links industry professionals like Red Badger with schools and colleges like Queensmead School across the UK to raise awareness of the fantastic opportunities for young people in digital which started because of a digital talent shortage. BIMA Digital Day provides students with a broad knowledge of the tech industry and some practical challenges which could be beneficial to some students futures, as some may choose this as their career path because they enjoyed the challenge they got involved with, and found the presentation from the agency really interesting and exciting. BIMA Digital day is a proven success story now in its 4th year with over 5000 students having taken part.

To begin the day, Hanna Cevik, our Senior Marketing Badger took to the stage and introduced the other Badgers to the students, and explained what us Badgers do and get up to on a daily basis, who we work with, and an overview of our agency Red Badger. Hanna then went onto to explain Badger Academy where we take in university students for work experience who we call ‘badger cubs’ of which the students found amusing. After the Badgers were introduced to the students, Hanna went on to explain the role of BIMA and Digital Day and what the day aims to achieve.


Our other badgers, Sari, Monika and Sarah were brave enough to take over and went on to explain in more detail what it is Red Badger do presenting slides to the students.


After, there was a BIMA Digital Day live stream which had a very cool camera enabling someone with a smart phone / mac to rotate their device 360 degrees enabling the user to see all angles of where the live stream was taking place. The students found this cutting edge technology fun, so did we. 

After the slides the Badgers gave a brief overview of their career path, all interesting and exciting but eventually landed them in Red Badger to our delight. 

Below are our digitally savvy sponsors who set the briefs for this year’s 3 challenges as well as be providing money-can’t-buy prizes for the winners.

Challenge 1: Standard Life - Britons are currently the worst in Europe at setting money aside as savings, meaning we have little to fall back on or to finance our dreams. This situation is even truer when it comes to young people. A recent survey assessed only a third of younger adults (aged 21-24) as financially literate. Standard Life have tasked Digital Day students to think of a fun, easy and most importantly digital way to help younger adults to save money.

Challenge 2: Vodafone - Vodafone have given students the challenge of creating a new and exciting feature for the ‘My Vodafone’ app. Participating students will need to go beyond the current ‘My Vodafone’ app features and think about what their phone can do and what it knows about them, and how they can use these features to create something that will drive downloads of the ‘My Vodafone’ app and engage users.

Challenge 3: Sony Music - Sony Music have challenged Digital Day teams to plan a digital marketing campaign to help their favourite Sony artist with a new album release. Students need to think about emerging channels they can utilise, how to create a buzz before the release date, engage fans on the day and how to drive downloads and purchases after the release.

After the 3 different challenges were explained by the Badger team the students decided amongst their group members which challenge they wished to do. In total, there were 5 teams, of which 2 did the Vodafone challenge, another 2 did the Sony Music album release challenge, and 1 other did the Standard Life savings challenge.

While the groups were discussing ideas amongst themselves for their chosen challenge, the badgers walked around talking to the students about their ideas and gave them some useful tips and advice without giving them a whole new idea. 

bima 30

In the afternoon, the students were bringing their ideas to life, designing their apps and putting their idea onto paper, all very exciting. We then had a dragons den type event where the groups had to present their ideas to the other groups. Only 1 idea from each challenge could be submitted so a vote was taken to select the best ideas. We then asked the groups if they were interested in getting into the tech industry, and the majority said yes :-) so we must have done a good job.

The day ended on a fantastic note and the badgers had great fun, Hanna in particular, and all definitely deserved a pat on the back with some well deserved wine.

We’d like all the students that took part in the event for being brilliantly behaved and thanks to Mr. Green for just being a great host.


Here’s a short video of the great day we had at Queensmead School :-)

BIMA Digital Day from Amy Crimmens on Vimeo.


Click here to watch Rory’s Talk in 360 degrees (Live stream on BIMA Digital Day)


Corporate Culture – a big pill to swallow

by Sinem Erdemli


There are a lot of things that feed into the quality of your work life. As social creatures, the culture of our surroundings is one of the most important one. 

Happy employees lead to happy companies, inspired employees make inspiring things. Yet I keep hearing sentences like “Ugh, work is work. I don’t really like it, but why should I?” and that’s always felt terribly wrong. Given we spend more that half of our awake hours at work, the culture at our workplace ends up having a great impact on our wellbeing. It affects our quality of work, our motivation, performance and mental state. Which got me thinking about the big question: How might companies create a place where people like to come back, in fact enjoy spending more than half their lives at? What do employees want from work so that it’s more than just work but also play. 

Organisational culture cannot be built in a boardroom, isolated from the rest of the company and be served across the organisation. That trick simply won’t hold up. 

Influencing social interactions are difficult, once they get going you, as an organisation, have very little control over the knock on effects. There are ways to nudge the direction though, John Coleman’s article on Harvard Business Review talks about the 6 building blocks that affect corporate culture which is a good place to start thinking about factor affecting change. 

1- Vision

The simplest foundational element of a culture is it’s vision. It gives purpose to the organisation and the work being done. Knowing what the purpose is also encourages a certain way of decision making. An organisations vision statement will not only help orient employees but also communicate expectations to clients and stakeholders. 

2- Values

While the vision statement sets purpose, values provide guidelines on how to get there. Values of a company are practical instructions that set behaviours and encourage certain mindsets. 

Look at what employees feel strongly about, is it consistent throughout the organisation? Does everyone share a set of values which allow them to work harmoniously towards the purpose or do you need to check in with every decision that’s been made and make sure they come from the right place? 

3- Practices

“We are what we repeatedly do.” — Aristotle

Doing over saying. Evidence of your culture can be seen in ways you do things, the processes you follow, incentives you provide and things you punish. It doesn’t really matter if you repeat your purpose, your values, put them on posters and hang them tall, if you don’t practice what you preach the words will only remain on the wall, they won’t become embedded in your culture and be part of your employees daily life. 

4- People

The people in a company are the ones who make the culture and carry it on. It’s your second family, you see them more than your mom, dad or even your partner. Just like a family, employees that share or have the willingness to embrace the same core values as your company will stick together and support each other no matter what. They will enjoy being together, look forward to spending time with and learn from each other. That’s why cultural fit is a top requirement in recruitment, selecting who you bring in the family is a way to keep feeding your corporate culture but also ensuring that your employees are surrounded by like minded people who share their values.

5- Narrative

“Any organisation has a unique history- a unique story.”-John Coleman

All organisations have a history, narratives are powerful tools that tell the organisations story. They feed the culture, and deliver stories about key events that shaped the organisation into what it is now and the values it stands for. 

Cultures feed on narratives, they provide not only a shared view of “what is” but also of “why is”.

Narratives can be formal, planned and organised or informal, they travel across the organisation and carry culture in narrative form. 

6- Place

Ping pong tables anyone? Or colourful slides welcoming you at the lobby? Office furniture has been the most obvious signifier for corporate culture for quite a while now. 

Our surroundings are invisible cues that trigger certain emotions and mental states. Our monkey brains scan the environment constantly and tell us whether we can relax or should be alert and ready for combat. 

The layout and architecture can be used to facilitate new ways of working, Steve Jobs when redesigning the Pixar office, made sure the facilities like cafeteria and toilets were in a central location to encourage social interaction and spark ideas across team members

.Office space is the most tangible signals of an organisations culture. Each item along with its location repeatedly tells a story, just like a broken record it repeats a message over and over again. From the motivational posters on the wall, to the office chairs and the carpet. It can make or break the mood of an organisation and determine whether it’s as a place people desired to be in. 

So have another look into your office, what does the lamp tell you?

Keeping it all together

So what do you do with these? 

Just like in everything else, there needs to be consistency. To be able to shape and sustain a solid corporate culture, organisations should make sure the foundations are in the right place and that they work harmoniously. Any discrepancy between the building blocks will lead to mixed messages to employees and have knock on effects to overall business performance. Not to mention, you’ll end up with a big group of unsatisfied, underperforming employees that are constantly at the lookout for the emergency exit to get out the war zone as soon as possible. 

Revisiting the foundation and taking a hard look on your what’s been embedded into the employees day would explain what the culture has become. Easier said than done, organisation can still influence how culture can be shaped, by carefully rethinking the building blocks the workplace can turn into an inspiring place where people want to be and perform their best.


London React Meetup – November 2015

by Kadi Kraman


The November React meetup was this month hosted by Bloomberg who have been using server-side JavaScript literally before it was cool, running it in production since 2006 (3 years before Node.js was even born!). With the a 100 million line codebase, they are heavily invested in JavaScript.

Watch the meetup on YouTube

Michele Bertoli (YPlan) – Inline Styles


Michele Bertoli kicked off the talks with a controversial topic of inline styles. “Trust me”, he said, “I’ve got the CSS is JS skill on LinedIn”. He went over a few tools and pointers to get you started if you fancy venturing into these dangerous waters, most notably:

Radium – a set of inline styles on top of React elements, which fixes a lot of issues that come from using inline styles… but on the downside does not support server-side rendering

CSS modules – import CSS modules into your component using Webpack or Browserify

Watch this talk on YouTube

John Maxwell & Peter Horne (Music Glue) – News from the Vanguard – adopting React, Relay and GraphQL


John Maxwell and Peter Horne from Music Glue gave an exciting talk on how they use GraphQL and React to do schema-driven development. They are essentially using GraphQL to render React component layouts.

Watch this talk on YouTube

Mateusz Zatorski – React Router 


Last but not least, we had a brilliant talk by Mateusz Zatorski showing us new features of the now stable version 1.0 of the React Router. He admitted that there are quite a few breaking changes in this version so he (bravely!) took us through a live demo of upgrading an existing application from 0.13.x to 1.0.

Watch this talk on YouTube

We’re having a break over Christmas so the next React meetup will be in January. Watch our Twitter for updates or join us in our public Slack for more React chatter! See you next year!


Tips for keeping User Experience lean

by Joe Dollar-Smirnov


There are a huge number of buzzwords, acronyms and trendy methods around in our great industry, the title of this article is a case in point. At Red Badger we have started to collate some of them into a glossary and we have already exceeded 20 different processes or methods for what amounts to ‘getting shit done’. 


Sometimes these methods and techniques are credited with being modern and new but normally they are simply a rehash of previous ideas and methods based on years of historic research and study. Scholars come up with theories and methods, they become adopted and then adapted – and repeat.


Let’s take UX design as an example. Although User Experience as an explicit discipline has only been around for 25 years or so, it’s roots go back much further. 1957 was when the Human Factors and Ergonomics Society was formed. It is a group committed to “the discovery and exchange of knowledge concerning the characteristics of human beings that are applicable to the design of systems and devices of all kinds”. Sound familiar?


Frequently we come across organisations who have Agile development teams with talented pools of designers who have not had a chance or the space to get to grips with the implications of working Lean. More often than not they have read all the books and are concerned with how to implement what they have read. The focus should not be on doing everything by the book if it isn’t necessary, but in delivering value. The reduction of waste in the process. That is how we work – by offering maximum value and great quality. It’s also how we create multi-award winning websites that delight our clients, their customers and generate significant return on investment.


So how do we integrate user experience design into a fast paced, lean, multi-disciplined team?


1/ Build a shared understanding

Jeff Gothelf says that Shared Understanding is the currency of Lean UX. Do what you need to do to get a shared understanding. Collaborate, pin up your thinking, sketches, notes, discuss around the project board every morning, during the day, whenever you can. Involve the team in as much of the following points as possible.


2/ Keep ideation rough and fast

Do not to spend ages working on ideas that might not work. Keep it loose so that people can understand the idea is not final and can be open to interpretation. Keeping it rough and fast means you do not get too attached to your ideas and if required you can discard them easily.


3/ Check your assumptions – research and test

Designs should be based on your knowledge of the problem. Research, check your assumptions and test your ideas on real people. Use quantitative and qualitative methods. Some feedback is better than no feedback but make sure you use your data to inform, not dictate your decisions.


4/ Be humble and ask questions

If something is unclear then ask. Speak to the client, or other team members. Don’t fall into the trap of automatically thinking that your way as the designer is the best way.


5/ Make it a team sport

Everyone is a designer, well at least everyone likes to have an influence on design, harness this. Allow people to have their say, input into the problem. Run sketching sessions with the whole team if possible. Include the client in this. It helps to build shared understanding and allows you to quickly understand the business and technical constraints on a problem if everyone is present.




If you are doing all these things there are no promises about the output, but you should find that you can start to work with more freedom and produce more ideas at a greater quality, furthermore, the ideas will have already got team buy in. Time selling in design ideas and presenting the client will be reduced and the overall productivity of the team will increase.



Patterns for scaling CSS

by Dominik Piatek



How we write CSS has changed a lot in the recent years. Many developers do not write vanilla CSS at all anymore, BEM seems to be the industry standard for structuring the codebase and the advent of SPA’s has magnified it’s shortcomings. But in some ways things have not changed, we are still often going down the rabbit hole of specificity wars and rampant complexity, and finding some new problems on the way too (e.g. nesting). Until CSS, as a language, can accommodate for these requirements, we need to constantly re-evaluate the patterns we use to make sure we minimise those problems and can tackle smartly new ones. This blog post looks at some of my findings when exploring writing good, modern CSS, treating BEM as a base, preprocessors as enhancement and picking up things from various frameworks on the way.

Using BEM

BEM is well adopted, but also quite often misunderstood. People tend to take BEM solely as a naming convention while the main goal of it is a component architecture. Hopefully, it’s not a surprise that these are not the same. As a naming scheme, BEM is mostly an eyesore, because at first sight, you sacrifice the power of CSS and it’s expressive (all too expressive) selectors for a fiddly name-spacing mechanism.

As a base for component architecture, BEM is quite decent. While designing a system we need to aim for orthogonality for our components and BEM helps us to do that by giving a scheme for encapsulation (alas, poor man’s encapsulation, but still). But consider the below:

.block-one .block-two

This is as a BEM anti-pattern; one component is modifying the other one. If this pattern is rampant in your stylesheet, then no one declaration is definite and without trawling through the styles (or opening your dev tools) you will not know if your rule has been applied. Add to that media-queries and you’ve lost your battle before it has even begun – BEM is giving you no benefit.

BEM is a convention and so it’s really important that your team understands the why (“Why do we use certain selectors and not others?”), what (“What is a block, element and modifier?”) and where (“Where do I put my stuff?”). There should be no ambiguity in the answers to these questions. As with any convention, consider the help of preprocessors and/or linters here, as well writing documentation for your project (although that is only useful if people read it).

One problem with BEM is the scope of block and element, especially if there is no correlation to components in the rest of your codebase (e.g. your javascript is just a bunch of jQuery scripts) or it has a different idea about them (e.g. you are using React without considering it’s relation to CSS). Tying in all of your code into a component architecture helps with defining these boundaries. You can as well get rid of element completely, of which I wrote in one of my previous blog posts.

DRY, smartly

In CSS, DRY (“Don’t Repeat Yourself”), quite often does not mean what it should. It should mean: “Don’t repeat yourself. Find the right abstraction for your duplicated code.” In CSS land, it often means: “Don’t repeat yourself. You just wrote something twice”.

To do DRY effectively, you need to know well the context. For CSS, the context is the design. The more your abstractions exist on the design already (e.g. a variable holding a given font style) the easier it is to translate ongoing changes to the design. Ideally, when talking with designers and the rest of your team about the designs “outside” of the code, you are using those same abstractions. This helps communication, gives your designers more ownership over the end product and helps you in keeping the codebase DRY. When going from design (ideas) to tangible products it’s crucial to think about how changes are going to happen because changes will always happen. Having a common language when speaking about the designs (not only of components but also of lower-level things like font-sizes and colours) is extremely beneficial, not only in terms of DRY.

That said, DRY should be also employed on a much more granular level, within selectors. Having the padding of a button to be relative to the font-size of the text it contains helps to accommodate not only for design changes but also different users (people using zoom, different viewports, different default font size etc.). This applies in many cases and CSS has a lot of mechanisms helping you achieving this (like the modern abundance of relative units).

Don’t go on a class diet

In the early days of BEM, people complained heavily about the amount of classes needed to be added to HTML. This is certainly true; but it also makes it explicit what a given tag is, which is certainly more valuable. The important bit here is the ratio of signal to noise. “Pure” BEM tends to be quite noisy (e.g. you repeat your block name in blocks, elements and modifiers – .block-name, .block-name__long-element-name, .block-name__long-element-name—christmas theme.) so there are many techniques to reduce it, like string concatenation (the & operator in SCSS), leading dashes for modifiers (.-christmas-theme), make BEM wholly encapsulated in mixins (@include block(ad-module)) and other inventive ideas. I’ve not found any hard and fast rules here – I think how inventive you want to get depends mostly on what your team wants to achieve.

It’s important to realise that classes are your best bet when writing robust selectors. It’s easy to assume that you will have one h1 and h2 style, but really that’s rarely the case. Classes convey a lot of meaning while keeping a degree of flexibility. You can be explicit about what a selector is or is not, and you can combine many of them frictionlessly in HTML. Combining classes is, of course, a very common source of bugs, but with the help of affixes we can bring them under control. E.g.:

<div class=“block block—mod”>

The above is just a simple modifier pattern from BEM. It’s incredibly useful, as long as the class is defined as:

.block.block—mod {}

This way we know that .block—mod will never work by itself. This increases specificity, but in a true component architecture, specificity needs to be as flat as possible anyway. You need few, predictable patterns for your selectors (which usually means classes + the odd special selector, like ~ or :before). Your components should always override base styles and their order should never matter.

You can combine multiple modifier classes and when a conflict arises from cascade (i.e. in your encapsulated component), you can just create another modifier class which has the functionality you want while keeping the other modifiers intact (for the most part, cascade should never matter). Watch the size of your modifiers – if they are complex, perhaps your abstraction has outgrown itself and you need a new one. Modifiers should be simple and used for theming, adding context to components (e.g. .block—in-sidebar) and states (e.g. .block—is-open).

Another great class pattern is style classes:

.h-block {

.h-text-align-center {
  text-align: center;

Some might shudder in disbelief, but this is actually a great technique to add some very common rules in places where components do not make sense, or you are just experimenting. Helpers are quite similar to modifiers, with the difference that helpers are independent and will always have lower specificity – so we should not use them on components. Two important rules to making helpers are:

  1. Keep them simple – so you can infer exactly what they are doing just from looking at the name. Ideally they have no more than two properties.
  2. Give them a clear affix – so it’s unambiguous what they are (.h—block, .style-block, .display-block-util etc.).

Helpers are a very common pattern, but their role in a framework can differ widely (in the past, some advocated building a whole system around them, as if they were inline styles).

A note on code reuse: it’s best tackled using preprocessors. Extending in vanilla CSS in error-prone: you will start to have to depend on specificity and cascade heavily, which is the opposite of what you want. You want to minimise the problems arising from using these because they tend to grow problems exponentially in big CSS codebases. Again, class selectors, used properly, help with this greatly.

Keep it simple

Did you ever use calc? It lets calculate values in the browser, like this:

.module {
  width: calc(100% - 68px);

It’s support in modern browsers is great so you definitely should. Things like calc are immensely valuable because they let you remove all of that indirect cruft that you used to have to do to solve your problem – it adds not only functionality, it adds expressiveness. The lack of it, plus browser quirks, is what made CSS such a frustrating language in places (e.g. layout). You had to accumulate a large body of knowledge to get anything done in a reasonable amount of time.

These days, you can make things simpler and we should abuse that. If position: absolute does the exactly same job for you as display: inline-block, you should think about not the end-effect but as well about the accuracy of what you are trying to express. The best example of this is float. float has a very specific meaning in laying out things, but is used extensively in grids.

CSS is often hard to read for beginners; being a declarative language describing presentation, when there is a strong disconnect with what we see and what we write, we need to remember internally what effect a property (or a given set of properties) will have (or fiddle with it in the dev-tools). This is a waste of time. We should strive (whenever possible) to make things simple and intuitive, not only to beginners, but also to our future selves (this is a well known design concept, but it’s usage in the wild varies).

Don’t be fooled in thinking that these patterns are only for big projects – less complexity, better readability and good modularity helps everywhere. The CSS we need to write became more complex in recent years because of the rise of responsive design and SPA’s, both of which it was never initially designed for. But we are at a point where browser support of key CSS is consistent, and the language itself is evolving at a good pace. You don’t need a wizard’s hat anymore to do it and who knows, we might even finally get over vertically centring things.

At Red Badger we are committed do doing things right. If you’d like to join the team check out our jobs page here 


TestExpo 2015: Fragments of a dream

by Monika Ferencz

Too often in my career I have found that testing is exactly like water, gravity or Google: you don’t realise how important it is to your life, until you suddenly lose it for some reason. But to the people behind the yearly TestExpo conference, testing does seem to be everything – they dream of a world in which time and money doesn’t matter, testing is done for the sake of perfecting quality, and it’s more an art than a barely acknowledged necessity. Which is quite far from reality, so the conference was subtitled “We have a testing dream”, hence the title of this post (no, I’m not nearly that poetic on my own).

Honestly, I don’t have a testing dream. I have a nightmare though, one that I lived through, crafted by Morpheus’s darkest testing environments and emotionally scarring choices of software. What got me through those times was the idea that testing is precious, amazing and artful, and can be a continuously interesting experience. So I was really hoping to get in touch with my testing dream at TestExpo, and did my best to write up the ideas and tidbits that stuck in my mind after the talks.



So what did I walk away with at the end of a day spent surrounded by the dreamers of the UK’s testing professionals? 


The dawn of DevOps testers. I’ve seen people break down in a fit of rage when someone refers to themselves as a “DevOps developer” or anything like that. Yeah, DevOps is a culture, not a set of tools or titles, but it leads to a certain way of working and organising tasks, which does affect the way we do our testing. At huge companies like IBM, according to Glyn Rhodes, there is an emerging new role which differs from both the Traditional Tester (manual) and Technical Tester (automated) roles, and involves tasks that incorporate a new way of thinking about practices and policies in a DevOps enabled environment. In any case, that’s a new label on Linkedin we should look out for.

Agile is still a hip new thing. You’d think DevOps is the new Agile, that is, a fancy buzzword that sells tickets and ushers in the interest of every manager leading a development team. But it turns out, Agile is still something that some bigger companies struggle with! As natural and effective as it feels to startuppers and the younger generation of software craftsmen, corporate environments take ages to change, even if that change is for the better. So while you might want to forget (or rather never look up) what Waterfall means, you should still not take Agile for granted. Consider it a gift that keeps on giving.

It’s not just you, mobile testing sucks. No one who ever looks around the tube on a crowded Tuesday morning is surprised if I say, there’s a myriad of different devices actively on the market, with differing hardware capabilities, screen sizes and diversely crappy OSes. If you take into account all variables, like the device itself, the browser in use, the OS version and everything else, you can easily end up with almost 19.000 different setups showing up in your metrics in just a year! Which is horrifying. But comfortingly, Christian Breitwieser, the specialist talking about his experiences with the Sisyphean task of mobile testing, shed some useful insight and made us all feel a bit better about sometimes being lost in the midst of rounded screens, JS disabled browsers and misbehaving Samsung phones.

Roundtable discussions. They are apparently very useful! Also, they’re not for me. It’s a personal thing, on some days I just don’t feel like talking to people… And it was one of those days.

Us testers are not special. Nah, of course you are! But when it comes to the trends and challenges of our path, we are not that far from developers. Though our daily tasks differ, newly introduced methodologies and swiftly evolving technologies not only affect the way software is developed, but also how it’s tested. The closer you work with automated tests, the more apparent it becomes – learning to use new tools, getting familiar with the trendy languages, wrapping your head around the changing requirements is a challenge you share with your more development-inclined peers. In fact, it’s getting increasingly hard to even separate these two roles, mostly because of my next point, which is:

Automated testing is on the rise. You think it’s self-evident, right? Not really. There’s still a general attitude towards testing that it should strictly be a manual, purely user-mimicking chore, and that anyone diverging from clicking through a UI is mostly just a developer in disguise. But automation is gaining momentum and recognition in the consumer facing world. Partly because of the sheer volume of work that mobile testing entails, but mostly because it really is a practical and powerful addition to the irreplaceable manual testing. We now have more tools and means to carry out automation than ever, and even the slowest moving corporations are starting to see the value in automation teams, which makes me really happy, for a number of reasons. But that might become a blogpost of its own in the future.


And that’s all the fragments I can remember of the dream shared at TestExpo 2015. Here’s to another great year of testing!

Do you have a testing dream, or a living nightmare you’d like to escape? We are hiring! Come join us in making the world a better place testing and breaking software!


Relay runners and dance revolutions

by Olga Loyev

This week I’m in Antwerp, Belgium for a 2 day Lean Change Agent workshop with Jason Little. Day 1 just ended and I’m exhausted!! But in that great my-brain-is-buzzing-with-new-ideas-and-information kind of way. Since my brain is way too excited to let me fall asleep, I thought I’d share just a few interesting bits from the workshop today that got me thinking:

But I’m a people’s person!!



Jason started off the morning by comparing organisations to relay running. In a relay race, participants run around passing sticks to each other. Okay, it’s more complex than that but you get the gist. Sometimes while passing the baton to the next runner, they might drop it. Things happen. Runners will then train harder, learn passing techniques, get leaner etc; and they’ll get better, faster and drop less batons with time.

As organisations grow, some things get dropped. And oftentime instead of focusing on how to get leaner, organisations will instead add a “baton passer” to be in charge and accountable that the baton gets from one set of hands to the other. If we put one person in charge and accountable for something, then it’ll for sure get done, right? But what you end up with as company continues to grow is less runners moving you forward and just more “baton passers”.

Lean organisations on the other hand, don’t want unnecessary specialisation. They want T shape people with depth of knowledge in some area (like programming) as well as an interest and understanding of a broad range of other disciplines (like user experience). The result: lean organisations are faster and stronger because they hire and nurture the relay runners and not the “baton passer”.

Waterfall is right!

How many of the following statements would you agree with?

“Kanban brings about evolutionary change”

“Agile is the right way to deliver software”

“Waterfall is best way to deliver software!”

Say whaaaat?!?! Jason almost lost most of the crowd at the workshop when he made that last statement. For me it was a very loud and definite “NO”.

What will it take for me to convince you that Waterfall methodology is the right way to go?

Some of you might be screaming “absolutely nothing!” in your head. And I was the same. I had an immediately and very strong reaction to that question where I’ve already made up my mind and no matter what was going to be said after, it was never going to convince me that Waterfall is the way to go.

And now imagine that that’s exactly how some other people feel when you tell them “Agile is the right way to deliver software”. Some people have such a strong and immediate negative reaction to that statement that no matter what you say after, you will never be able to convince them by starting off making a statement like that. And that doesn’t make them crazy! Did you experience first hand the failure of a Waterfall project? Well what if they have experienced the same with an Agile project?  

What if instead you ask them how they would do a project. I bet you most of them would say (more or less) something along the lines of “Well, I want to understand what needs to be done, design it, build something that works and ship it”. Yes! That’s pretty much how we’d do it as well, but we’d do it more frequently and in smaller batches. Ultimately, in the context of software delivery we all want the same thing: to deliver the right thing in the right time at the right cost.

As a change agent, start with what people believe, value and do; establish a common goal; and focus on the positives. Don’t start off with by pushing your beliefs or approach on to them as “the best”. I personally think the term “Agile” has been bastardised almost beyond recognition by individuals and organisation using the “Agile stick” to force change or beliefs onto others. And it was fantastic hearing Jason Little say to take “Agile” and “Waterfall” out of the conversation completely! Focus on what’s good and agree on ways to eliminate waste and continuously improve. Drive positive change together.  

Let’s get focused

How many of you have seen this video before? If you haven’t, get ready to laugh (and learn). Even though I’ve seen the video below previously, it was the first time I watched it with this commentary. Although hilarious, it’s also very insightful into how movements and change happen.


“All mankind is divided into three classes: those that are immovable, those that are moveable, and those who move.” –Benjamin Franklin

In simple terms:

The movers are the leaders. The movables are the people that can be converted to the believers or to the non-believers of something. And the immovables are the ones that just won’t budge. They are strongly opposed and resisting to whatever the movement the movers are trying to start.  

Change agents often focus their attention on converting the immovables to understand and join the “movement”. Most of the time that results in spending insane amount of energy and time in vain trying to convince someone that has no intention of trying to understand or consider your suggestion.




What if instead we focus more on the majority of people, the movables? The people that are willing to listen and to try. The people who are not absolutely and unconditionally opposed to the change you’re trying to bring around. Nurture the first few followers. Facilitate them with the skills they need to bring about the change. Help them become the movers who will then help to do the same with the movable group. And then maybe, just maybe, the majority will convince the immovables to try something new and give change a chance. And then, well, then you may have just started a dance revolution!

Red Badger offers an annual £2,000 training budget to experience things like this. Sound good? Then come join us.


London React Meetup – October 2015

by Jon Yardley

GraphQL talk at React meetup

With pizza eaten and beers in hand the Facebook auditorium was once again rammed for this months React.js meetup. We were incredibly excited and honoured to welcome Nick Schrock, Facebook Engineer & GraphQL co-creator, to give an extended talk on his creation – GraphQL. GraphQL is server side query language which is designed for client side applications to interact with trees of data and takes a markedly fresh approach to client-server communications.


Nick started by giving us some background about how GraphQL came to be. It was essentially Facebook’s solution to the problem of having potentially hundreds of different app versions all needing different data. Traditional RESTful APIs aren’t really ideal for a great mobile experience due to the ping-pong nature of how data is requested when drilling down into an app. Facebook have been using GraphQL to power several of its applications including the iOS & Android Feed applications as well as Messenger and Ads Manager for some time. GraphQL is able to support multiple versions of all these applications without having to support multiple versions of their API. The beauty is that the client application decides what it needs and the server responds with the data in one single response. If a new version of an application requires data that isn’t yet supported by GraphQL schema then it can be added without fear of polluting older versions as they won’t be asking for it. Sticking with an additive attitude means that backwards compatibility is much easier to handle.

How can I use this now? 

GraphQL talk at React meetup

A large portion of Nick’s talk was devoted to how a developer might be able to start using GraphQL or at least selling it into an existing project. Obviously for GraphQL to be most efficient it makes the most sense that it would entirely replace any API that currently exists but this is not always possible and is more than likely too big an ask. The best way would to introduce GraphQL into a project would be to build a thin layer over existing APIs, most likely a subset to start off with, and rather than speaking directly to a database GraphQL is used to glue your API endpoints together. He coined this approach ‘REST Polyfill Structure’. This approach means you can have the marked improvement of a single request and also you can demonstrate how GraphQL can be used in your application. To really show of you can use GraphiQL to demonstrate the power of introspection.

To get a more detailed look into how you might start using GraphQL on your project take a look at swapi-graphql - a GraphQL wrapper around the Star Wars API.



Although there were no official announcements about future features there was mention of subscriptions which will mean an end to polling; a very welcome addition to the GraphQL feature set.

Next meetup

The next React.js will be on Tuesday 17th November this time at Bloomberg. Check out the Meetup page for more info about the event and how to get your free ticket.

Want to be using GraphQL in production now?

Red Badger has already started using implementations of GraphQL in production as well as loads of cutting edge tech including React.js. If you fancy working for a company which thrives on innovative new tech get in touch.



The Importance of Stealing – Adventures at WebExpo

by Robbie McCorkell

Lucerna Cinema, Prague

Last month I was fortunate enough to be invited to speak about React at the WebExpo conference in Prague, the largest tech conference in central Europe. It was a real honour attend, especially as I had never visited the Czech Republic before and the guys at WebExpo were incredibly welcoming. I was asked to attend because WebExpo hadn’t had a talk on React before, which on the surface made the task seem quite easy. But when I got into writing the talk, this turned out not to be the case.

Pitching it right

How do you pitch a talk on an upcoming framework like React for a conference that hasn’t had a talk on it before? WebExpo didn’t want an introductory talk, and were more interested in something in-depth, but I also had it under good authority from my Czech colleagues that PHP is very popular there and people might not be intimately familiar with the details of React. I needed to try and summarise what I liked so much about React to a group of people that may have only heard of it, while others may be experts.

After some contemplation I finally hit on a solution. I was a beginner to React not so long ago, so why not talk about some of the most interesting discoveries that my team and our London React community have found and learnt along the way. Through explaining some of these concepts and ideas, I could try and demonstrate how React helps to change the way you think about software development.

Disclaimer: It looks like the company that linked the slides and video were supplied an old version of my slides and desperately tried to piece it together. As a result some of the slides look a bit funky, or don’t fit with what I’m saying. I’ve been assured this will be fixed soon.

But where did this lead us? What should the message of this talk be?

While looking at the list of topics that I could talk about I realised something interesting. All of the best ideas or we had adopted in our projects so far were not original, but stolen. At least, stolen from the world of functional programming. At Red Badger we had known for a while that the functional programming community has some very interesting concepts, and had been researching them to improve our work. So this should not have come as much of a surprise. React itself is so good because of its heavy influence from functional languages, but I found it interesting just how many of the best additional ideas were lifted from this space. Not only that, but these other concepts complement React so well as a result of its functional nature.

Complementary Ideas

Concepts like immutable data, central state storage, or isomorphic rendering are directly stolen from, or are only possible because of functional programming. The functional nature of React and it’s composition as a series of pure functions with a one way data flow allow us to adopt these ideas in the world of javascript.

It is for this reason that we started a new meetup at Red Badger to try and emulate the success of the London React meetup, called Functional Programming for the Web. Because at Red Badger we know that we’re not experts in Functional Programming (yet), and we also know how useful the concepts that lie within this community can be. So we want to learn more.

We also have another project that involves our best ideas around React and functional programming. It’s a lightweight framework around React that we call Arch and open sourced earlier this year. Arch wraps up the concepts mentioned above into an easy to set-up and use application framework. It makes playing with functional paradigms on the web easy and fun.

Going full circle

With Arch and our new functional programming meetup, we are going to try and create a feedback loop for ourselves. We will learn more functional ideas and concepts with our meetup, build them into our own projects, and the ones that stick we will build into Arch to help the community discover them too.

This is the message that I tried to convey to WebExpo last month. By digging deeper into the functional programming community and stealing the best ideas that they have to offer you can greatly improve your React applications. Not only that, but if you bring these ideas back to your respective communities and disciplines, especially to React and javascript, you can benefit the community as a whole.

So get out there and start learning. And if you saw my talk at WebExpo, thanks so much for listening. I hope you enjoyed it because I had a blast!

You can hear more about my experiences in Prague on our very silly and often NSFW podcast Red Badger Don’t Care. Seriously… this episode contains explicit content about my adventures walking through Wenceslas Square drunk at 3am.


Elm – what is it good for?

by Kadi Kraman

Introduction to Elm

Elm is a small but expressive language for building purely functional user interfaces for the browser. Elm code compiles down to JavaScript/HTML so our dream of writing JavaScript without actually writing any JavaScript may finally be here! All values in Elm are immutable and it is a statically typed modular language, syntactically quite similar to Haskell.

But what’s so good about Elm and why should you bother learning yet another programming language? Well. Firstly, we need something other than JavaScript for the frontend devs to play with. Secondly (and on a more serious note): Signals. Signals are the key feature of Elm and the reason it is very much of interest to the bleeding edge community. In order to really understand the power of Signals and how to use them would take an entire afternoon, but in simple terms, a Signal is “a value that changes over time” which you can sample and react to in discrete or continuous intervals. A Signal can be of any type (String, Int, Tuple, Record) and can denote anything, for example, the mouse position on the screen, the width and height of the browser window, the collection of currently pressed down keys etc. The reason this is such a groundbreaking language feature is that gets rid of the need for callbacks when modelling change over time. All Elm programs end up with a very clear MVC pattern and the use of Signals prevents async issues like the Model getting out of sync with the View.

Hello, World!

But let’s go back to basics. First things first! Everybody loves a good Hello World.

Neat! But this brings us quickly to the biggest problem Elm has so far as a frontend language… file size. The size of the compiled version of the above code is 288KB (for comparison, the latest version of jQuery is 252KB). The reason the compiled file is so big is that even though all I’m doing is printing out “Hello, world!”, in order to compile that Elm code into JavaScript, the entire Elm core library (and any dependencies I’ve installed, e.g. the html module) need to be included. This means that the file size is going to grow more logarithmically rather than linearly as your app gets bigger, but the reality is that you start out with a huge source file for not a lot of content.

This is a shame because otherwise there is an amazingly risk-adverse way to try out an Elm component in your existing application: after compiling your code, you can simply embed it to any div in an existing application with just 2 lines of JavaScript!

In order to do this, simply compile your Elm code into JavaScript with

>> elm make Hello.elm –output=app.js

And embed this file in your index.html like so: 

Elm embed in div

The only thing to watch out for is that Hello.elm must have a module declaration at the top of the file. In this case, it would have to be module Hello where. This is needed because we’re using the module name to initialize the app. The Elm component can then send/receive values from the rest of your application using Elm’s Ports system.

Alternatively you can launch the Elm app fullscreen like so:

Elm fullscreen

Documentation and Partially Applied Functions

One of the things that threw me when I first started looking at Elm documentation was the way method signatures are written. For example, take a look at the method signature for the repeat function in the String module:

>> repeat: Int -> String -> String

We can kind of infer what the function does: it takes in an Int and a String and returns the String repeated Int times. However, there is no distinction between the separators of input and output values: an arrow is used for both. It is implicit that the last value in the method signature is the type of the return value. There is actually a really good reason for this and it is to do with partially applied functions. Here’s the String.repeat function in the Elm REPL:

Elm String.repeat

And this is the same function but with an intermediate step where we create a partially applied function:

Elm String.repeat partially applied

Notice that at each step, we get a printout of the current method signature and it goes from

>> Int -> String -> String
>> String -> String
>> String

Partially applied functions are supported in plenty of languages, but there is something really nice about having the method signatures actually written in a way that encourages actually understanding and using them.


This is the core feature of Elm. This is what makes the language so neatly reactive.

The above code listens to the Window.dimensions Signal which broadcasts a tuple of the window width and height in pixels. The area function is applied to this these values and the result displayed in the browser. You can try this in the online editor. Resize the window and see the value dynamically update. Yay.

Side note: method signatures in Elm are actually optional! The above code would still work if I removed them, however once you include them, the Elm compiler will check that they match what the function does and not compile if there are any discrepancies.


Mailboxes are basically “signals that have an address you can send messages to”. You can use them for reacting to UI events.

Here, I have defined a Mailbox for a String, and an Input field with essentially an onChange event handler. Whenever the text content of the input field changes, I call an anonymous function which passes the changed text into the Mailbox address. This same value is printed out to the page in the paragraph below.

Again, feel free to copy/paste this code into the online editor to try it out yourself. Or read more about Mailboxes here.

So… the future?

“Should I write my next eCommerce site in Elm?” … I think we’re not quite there yet. But I it has huge potential. In fact, integrating Elm into an existing React/Flux application has been done before with huge success! The article also includes a tutorial on how to port a store from the Flux TodoMVC example to Elm.

Writing Elm is fun. It’s a bit of a challenge as the online community is very small still (Googling for a “common” Elm problem will usually not get you to a solution). On the plus side, Elm compiler preemptively picks up on any runtime errors so you’ll never see undefined is not a function ever again. I’d say that alone makes it worth giving it a go.

There’re a few resources to get started with. Read the documentation. Learn by example. Do an online course. Try out the online editor.

And if you like it, come to our special Elm edition of Functional Programming for the Web with Evan Czaplicki who will perhaps convince us why we should write our next eCommerce site in Elm.