Posts Tagged ‘javascript’


Learning to program with the world’s best hypnotists.   

by Toby Merlet


Everybody was very focused during this 2 day seminar.  Veerryy Fooccussedd…   And I’m sorry to disappoint, but they were not teaching us to program JavaScript, Closure or Elixir! This was about a different sort of programming altogether.


Hypnosis pendulum


Most of you will have heard of Paul McKenna.   A household name in the UK, he started out as a stage hypnotist getting audience members to dance around like chickens.  But he soon realised he could make more money help people change their lives for the better.  You can hardly walk into a branch of Waterstones without  being assaulted by his myriad of books and audio recordings.  Apparently he can  “Make you sleep”, “Make you rich”, “Make you thin” but also “Make you smarter” and “Play great golf”.

All for a mere 12 pounds each.  Bargain.

His change from entertainer to self-help guru was facilitated by a man called Richard Bandler, the co-creator of a discipline called NLP (Neuro Linguistic Programming) and a hypnotist himself.  What is NLP?

“(n) a model of interpersonal communication chiefly concerned with the relationship between successful patterns of behavior and the subjective experiences (esp. patterns of thought) underlying them; a system of alternative therapy based on this which seeks to educate people in self-awareness and effective communication, and to change their patterns of mental and emotional behavior.”




The seminar I attended was called “Get the life you want“,  hosted by both Paul McKenna and Richard Bandler.  I was interested in attending to learn more about NLP, and hopefully feel more confident.

And yes, we did get hypnotised.

If you’ve never been hypnotised then it might sound a bit scary.  Mainly because stage hypnotists have given it a bad name.  But the induced trance feels more like a state of increased focus.  The best way I can describe it is when you read a book  and the world around you disappears because you’re so engrossed in what you’re reading.  Coders might call it “being in the zone”.  Anyway, I first learned techniques of self-hypnosis from Dr. Val Walters, who was at the time Professor of Hypnosis at University College London, so it wasn’t unfamiliar to me.

40 years ago, if you wanted to get rid of a phobia, it required 6 months of desensitising therapy, and even then, the results were uncertain.  McKenna claims that ‘if it takes you more than 60 minutes for 99% of patients’, you’re doing it wrong.

Traditional forms of therapy look into the past to try and find the root of your psychosis.  Because, apparently, having that knowledge will fix the problem.  Bandler on the other hand, told us with a degree of playfulness that “People start telling me how fucked up they are, but frankly, I don’t give a shit”.  Charming.  But he wasn’t being mean, he just believes that it isn’t very helpful knowing about the past, and cares more about how you think rather than why.  What is it you see in your mind’s eye when you remember a disturbing thought?  What goes through your head when you’re beating yourself up?  How does it make you feel physically?  With this knowledge he can, with the help of hypnosis, do something about it.


Hand with eye


He was a charismatic fellow.  His stories were entertaining and while he was talking to us he was apparently using his NLP techniques to connect with our subconscious and feed us positive subliminal messages.  I felt very focused listening to him, but I’m still to be convinced by NLP; that may be because I wasn’t sure what to look for. I knew when he was using hypnosis, but NLP was not apparent to me.

On the other hand, I was sold on the hypnosis aspect of the seminar.  We learned practical techniques to help control that little voice we all have in our heads.  The one that tells you you’re not good enough, that you can’t do something, or that you want to eat the rest of that giant cake all by yourself.   You know who you are.

When I left the seminar, I was a bit disappointed.  I was tired and didn’t feel much different to when I first walked in the room 2 days earlier.  But a week on, I can honestly say that I feel like a much happier more content human being.

That’s a big claim! So let me clarify. I’m sleeping better, I worry less, I’m able to concentrate better and feel more productive.  I’ve even written my first blog.   Training Budget well spent?

“If you like the idea of an annual training budget, trips to conferences like this and a big focus on learning, Red Badger could be the place for you. Check out of current vacancies here.”


React London Meetup September 2016

by Seb Flippence

Free beer and pizza, developers, and maybe React talks? You’ve come to the right place!

This month’s React London Meetup was held at Skillsmatter, CodeNode, which a great place for like minded developers to socialise, share their ideas and see the latest trends in the React community.

So without further ado, on to the talks!

Keith Woods – Building Maintainable Single Page Applications With React

Keith Woods

Keith Woods works for Adaptive, who are real-time application and infrastructure specialists.

His talk was around patterns that they’ve used to manage complicated state. He also demoed a simple Scrum Task Board using esp-js-react with epics, stories, and tasks.

They’ve used their framework esp-js at Adaptive to avoid creating fat controllers, views and models. esp-js revolves around a model-first development process, which can be used to deterministically update their models.

A React view can be used with the ESP event router, this acts as broker between the model and the view, so anything that wants to publish events can stream updates to the view. This means that the latest version of the model is dispatched to the view or observers in real time. It’s similar to unidirectional data flow that exists in React Flux architectures.

For their team, it also simplifies their codebase by providing these events where certain computations should happen such as working out sums and when/if components should update.

Events can be serialised into an event queue and replayed through the ESP event router to help manage state.

His talk also covered mutable (changing states) and immutable (non changing state). To change an object’s properties in an immutable event-based system, you first have to create a new object and assign it the previous object properties and any new properties you want to set.

Using immutable state makes it easier to track if a component should update, because you can check to see if an object instance is equal to another object instance. Whereas in an OO/mutable model you have to keep track of property value updates to make sure that it’s okay to set your React components shouldComponentUpdate flag.

ESP events can be wired up using the ES7 decorator syntax, which then observe events as they happen. These can be created in a granular fashion and then built up to handle complicated state changes.

There were examples of how you can use esp-js’s built-in React components such as <RouterProvider /> and <SmartComponent /> to configure your application, which creates the router and pass down the props the relevant components/subscribers. ESP also provides an @esp.viewBinding decorator to automatically resolve view bindings for models.

His team have built a real-time FX Reactive Trader Cloud app written in esp-js which is bundled as a client application using openfin and Electron. Traders can use it to buy and sell different currencies and get notifications on prices and transactions. It’s push-based and can be left open all week and will automatically update the app’s base code and prices:


The backend is event-based and works using linked microservices in the cloud.

Graham Mendick – The Navigation router

A photo of Graham Mendick presenting

The Navigation router is a new data-first URL router for React. In his presentation, Graham explained what’s wrong with the existing React Router:

“React Router was initially inspired by Ember’s fantastic router. Many thanks to the Ember team.”

He went on to question their reasoning, that if: “React is nothing like Ember, why have they used used this statement?” and that it’s only “fantastic for Ember and not for React”. When parameters change in the Ember’s router it’s passed down into the view, but it doesn’t replace the view.

React router “Displays a view”, “Changes a view”, and “Changes the data”, but there’s nothing new here that you can’t already do in React itself.

Graham’s Navigation router is the opposite and provides new functionality which React and React Router do not provide.

A new StateNavigator can be created and this holds URL parameters that can be used to map/route to a certain state. So when the URL changes it checks to see if the key state.${your-react-render-method}.navigated exists as a function and will then call it. This gives you control on how the route is rendered.

When building hyperlinks the URL is never hard coded, instead a <NavigationLink /> component is imported and given the stateKey you want to navigate to and navigationData that you want to provide to the route.

Default values can be used for your state properties, so that you don’t have to provide it in the URL or <NavigationLink />. State is maintained across the application so you won’t lose user input when navigating.

URLs are automatically generated for states, but can be configured into prettier URLs being any subpath the user requires. So that query strings can be route/subpath parameters.

Alexey Golev – Pros and Cons of Static Typing

A photo of Alexey Golev presenting

Alexey argued “Should we use typed language within a dynamic untyped language like JavaScript and do we actually need types?”

As a developer using JavaScript there are a number of typing stages we go through:

Stage 1 – Denial

Types don’t exist in JavaScript, or do they? Under the hood, variables are casted into types and providing types upfront can help us find problems before we even run our code because if we provide an incorrect type our IDEs and compilers will complain.

In JavaScript we can use TDD to assert if variables are a certain type (e.g. assert.isFunction(myVar);), but this seems like a lot of extra work. So we should either use a typed language upfront or use type hinting.

“A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.”

–Benjamin C. Pierce, Types and Programming Languages

Stage 2 – Anger


– ██████████, Good Programmer

People may disagree about using types in their programming language of choice, saying that it’s too verbose and less flexible and maybe that’s why they are using that language in the first place.

Stage 3 – Bargaining

Using an additional framework or runtime checks can provide some safety nets around typing issues such as:

In React we tend to use PropTypes to define the type contracts between our components.

Stage 4 – Depression

The depression stems from fatigue and “What am I going to use?”:

There’s also the problem of how long the framework will be around and if it will just disappear.

Looking into how many stars and forks a project has on GitHub can help you decide which one you should use. There are a lot of JavaScript based type system out there, so choosing the right one can be tricky. Looking to some of the larger companies to see who’s using what, can also be an influencing reason.

Alexey did also suggest not to use the any type as it’s pointless!

Stage 5 – Acceptance

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

– Martin Fowler

Using a statically typed system that outputs JavaScript has a lot of advantages and can help you write better error free code.

Are we what you’re looking for?* Red Badger is hiring! For details on our tech stack, positions and clients take a look at our Join Us page.

* And vice versa


London React Meetup – April 2016

by Leon Hewitt

An evening of testing workflows and dynamically built forms awaited visitors to Code Node last Wednesday when the London React Meetup was once again in town.

Tom Duncalf kicked things off by describing what he has found to be effective unit and integration testing strategies for React applications.

Tom explained his rationale for writing tests and in particular unit tests. In addition to verifying the application behaves as expected and providing a useful set of automated regression tests (allowing you to refactor with confidence), he pointed out how well written tests can act as documentation for the code and enable faster debugging with less dependency on end-to-end tests (be they automated or manual) to expose errors.

Taking this testing philosophy, Tom went on to discuss how this applies to testing applications built with React and listed the qualities he looks to test in his components (e.g. do they render correctly, can you interact with them as expected and how do the integrate with the rest of the application).

The talk was full of code examples of how Tom went about implementing his tests using his toolchain of choice: Mocha, Chai and Enzyme.

Next up was Anna Doubkova discussing her experiences with Redux Form and how useful it was in developing a CMS application she was involved in with her team here at Red Badger. One aim of the project was to deliver a CMS with less dependency on developer input to extend. Anna noted how great it would be for the customer to alter their CMS just by changing the data structure. i.e. have fields added by the CMS administrator automatically render on the page without the need to bring the development team in.

A combination of JSON SchemaRedux Form and React enabled the team to do just that. Anna took us through the journey of developing the solution and the reasons for the technical choices made.

Anna ended by listing the pros and cons of working with redux form, expressing overall how easy the team found it to use.

Rounding the evening off was Arnaud Rinquin who shared his journey of reducing the friction he was feeling around testing in the javascript ecosystem. It’s no secret that the toolchain takes a bit of setting up, leading to developers experiencing what has been politely termed Javascript Fatigue.

Inspired by Dan Abramov’s Redux tutorial,  Arnaud aimed to recreate the feel of Dan’s environment in his own workspace. That being: run the tests in the browser, have tests alongside the production code (in the same file), have the tests run automatically on a code change and have the tests execute in the shell  (to facilitate continuous integration).

He successfully achieved this through a combination of a babel plugin (to remove the test code and any dependencies from the code files) and a specially written chrome plugin (to control the test runs). This achievement has enabled Arnaud to enjoy what is for him “a proper TDD workflow”. He can now keep coding and stop worrying.

The success of these meetups (all the 300 tickets for this event were snapped up within an hour) demonstrates the popularity of React in the London software community and the quality of the talks highlights how open the React community is to exploring and embracing new techniques. Everyone’s already looking forward to what fresh insights May’s meetup will provide.

Hear about when new events are announced first by joining the meetup group here.



Building Desktop Apps With Electron, Webpack and Redux

by Roman Schejbal

In March 2016, as a part my annual training budget – a perk that every badger gets – I had the opportunity to go all the way to the Fluent Conf, which was in sunny San Francisco. You can read the best bits from the conference in Alex's blog.

One of the workshops I attended was about building a basic desktop application with Electron, that’d be compiled for every major OS and I’d like to share the knowledge and the takeaways I grasped during a 3 hour long session.

We’ll take a high level look at how Electron works, but we’ll also use ES2015/16, Git, Webpack, Babel and a bit of Redux, therefore it’s good to have a clue about what those are so we can focus on our topic and it’s not too overwhelming. We’ll see how we can implement live reloading and get that fast-paced development cycle that most of today’s developers are used to.

What we’ll be building

To highlight some of the things that a desktop application excels in from a normal web app, we’ll need to build something using the native features. Electron provides many APIs above the native functionality and I’ve decided to build a simple HackerNews app or a watcher, that’ll let me know when there is a popular post (>= XXX votes), because I don’t want to miss those and it’s quite reasonable size of a project for this purpose. Well, at least I thought so when I started writing this blog. ¯_(ツ)_/¯ You can download the app (for Mac) here.


If we go to the Electron homepage, we’ll find quick startup instructions at the bottom of that page; so startup your terminal and let’s get on with it!

Note: make sure you have the latest node and npm installed to avoid any potential errors

# Clone the Quick Start repository
$ git clone

# Go into the repository
$ cd electron-quick-start

# Install the dependencies and run
$ npm install && npm start

After running those commands you should have a Hello World app running on your desktop.

Main Process

What you see is genuinely a browser window, in electron we call them renderers and they are created by the main process. By main process we mean the main script defined inside package.json. You can think of it like a parent of all it’s children (renderers) that is responsible for creating instances of the BrowserWindow class. This is also the place where you’d work with file system operations for example.

Renderer Process

The browser window you see is one renderer process. Electron uses Chromium for displaying pages, but it’s topped with some Node.js APIs allowing interactions on a lower level.

Now that we know the entry point, let’s have a look into it. It’s pretty well commented out of the box so should give you a good idea what’s going on in there.


'use strict';

const electron = require('electron');
// Module to control application life.
const app =;
// Module to create native browser window.
const BrowserWindow = electron.BrowserWindow;

// Keep a global reference of the window object, if you don't, the window will
// be closed automatically when the JavaScript object is garbage collected.
let mainWindow;

function createWindow () {
  // Create the browser window.
  mainWindow = new BrowserWindow({width: 800, height: 600});

  // and load the index.html of the app.
  mainWindow.loadURL('file://' + __dirname + '/index.html');

  // Open the DevTools.

  // Emitted when the window is closed.
  mainWindow.on('closed', function() {
    // Dereference the window object, usually you would store windows
    // in an array if your app supports multi windows, this is the time
    // when you should delete the corresponding element.
    mainWindow = null;

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
app.on('ready', createWindow);

// Quit when all windows are closed.
app.on('window-all-closed', function () {
  // On OS X it is common for applications and their menu bar
  // to stay active until the user quits explicitly with Cmd + Q
  if (process.platform !== 'darwin') {

app.on('activate', function () {
  // On OS X it's common to re-create a window in the app when the
  // dock icon is clicked and there are no other windows open.
  if (mainWindow === null) {

On the application ready event we call the createWindow function that’ll instantiate a new BrowserWindow (a renderer process) and load url 'file://' + __dirname + '/index.html;' which is our main html file, from there on we are in our very known single-page application land. Also, we programmatically open the Developer Tools by calling mainWindow.webContents.openDevTools(); since Cmd+Alt+J does not do anything inside Electron.

Looking into the index.html we can see there is a usage of the global process variable and as you know this is not available in a normal browser window. It carries all the environment values that can come in handy as we’ll see in our app.


<!DOCTYPE html>
    <meta charset="UTF-8">
    <title>Hello World!</title>
    <h1>Hello World!</h1>
    We are using node <script>document.write(process.versions.node)</script>,
    Chromium <script>document.write(</script>,
    and Electron <script>document.write(process.versions.electron)</script>.

I mentioned that the renderer is topped with some Node.JS APIs, the process variable is one of them. The other one worth mentioning is that you can actually use require on the client and load modules as you do in Node environment, but we’ll go a slightly different direction today.

The setup

We’ll use Webpack with it’s hot module replacement (HMR for short) for live reloading. So we need to build a little server that’ll host and reload our code while we develop.

In order to do that, we need to install a few node modules:

npm i --save-dev express webpack webpack-dev-middleware webpack-hot-middleware webpack-target-electron-renderer

Then we create a basic webpack configuration:


var webpack = require('webpack');
var webpackTargetElectronRenderer = require('webpack-target-electron-renderer');

var config = {
  entry: [
  module: {
    loaders: [{
      test: /\.jsx?$/,
      loaders: ['babel-loader'],
      exclude: /node_modules/
    }, {
      test: /\.css$/,
      loader: 'style!css-loader?modules&importLoaders=1&localIdentName=[name]__[local]___[hash:base64:5]!postcss-loader'
    }, {
      test: /\.png|\.svg$/,
      loaders: ['file-loader']
  output: {
    path: __dirname + '/dist',
    publicPath: 'http://localhost:9000/dist/',
    filename: 'bundle.js'
  resolve: {
    extensions: ['', '.js', '.jsx'],
  plugins: [
    new webpack.HotModuleReplacementPlugin(),
}; = webpackTargetElectronRenderer(config);

module.exports = config;

Since the electron index.html page is running from the file system, we need to provide a correct path for the webpack-hot-middleware so it knows where to connect. Same goes with the output.publicPath for the webpack-dev-middleware so the reload of scripts works properly. The webpack-target-electron-renderer is needed to set all of electron built-in modules as externals plus some other bits here and there. You can find out what exactly it’s doing in the npm package itself.
Also, as you can see we’ll use babel and css-modules so we actually need to install a few more modules which you can do with this command:

npm i --save-dev babel-cli babel-loader babel-polyfill babel-preset-es2015 babel-preset-stage-0 babel-preset-react css-loader style-loader postcss-loader

Now that we have our config, let’s write up the server and connect it to Webpack.


import express from 'express';
import webpack from 'webpack';
import webpackDevMiddleware from 'webpack-dev-middleware';
import webpackHotMiddleware from 'webpack-hot-middleware';

import config from './webpack.config.development';

const compiler = webpack(config);
const app = express();

app.use(webpackDevMiddleware(compiler, {
  publicPath: config.output.publicPath,
  stats: {
    colors: true



Update the index.html to use the built javascript.


    <div id="root">
      We are using node <script>document.write(process.versions.node)</script>,
      Chromium <script>document.write(</script>,
      and Electron <script>document.write(process.versions.electron)</script>.
      (function() {
        const script = document.createElement('script');
        script.src = process.env.ENV === 'development' ? 'http://localhost:9000/dist/bundle.js' : './dist/bundle.js';

Then tweak the package.json for a babel configuration and a startup script:


  "main": "index.js",
  "scripts": {
    "start": "ENV=development electron .",
    "server": "babel-node server.js"
  "babel": {
    "presets": [

But now we have to run two scripts to startup the app.

npm start
npm run server

Let’s get rid of that by installing the concurrently module npm i --save-dev concurrently, update the package.json once more and we are back to one command:
npm run dev


  "scripts": {
    "start": "ENV=development electron .",
    "dev": "concurrently -k 'babel-node server.js' 'npm start'"

Engage dev

Until this point, we were setting up the development environment to have this convenient developer experience. From here we’ll actually start building our app, but I want to apologize for omitting (on purpose) quite a lot of app-specific stuff just because we want to primarily focus on the electron APIs and see the usage of it. In any case, you can find the full source code on my github.

Inside the webpack config we’ve set the entry point to ./src/index, so here is the content of it.


import 'babel-polyfill'; // generators
import React from 'react';
import { render as renderReact } from 'react-dom';
import debounce from 'debounce';
import configureStore from './store/configureStore';

const state = JSON.parse(localStorage.getItem('state'));
const store = configureStore(state || {});

let App = require('./components/app').default;
const render = (Component) => {
  renderReact(<Component {} />, document.getElementById('root'));

if ( {'./components/app', function() {
    let newApp = require('./components/app').default;

const saveState = debounce(() => {
  localStorage.setItem('state', JSON.stringify(store.getState()));
}, 1000);
store.subscribe(() => {
  if (process.env.ENV === 'development') {
    console.log('state', store.getState());
store.dispatch({ type: 'APP_INIT', store });

Since we are using Redux and having a global state of the app on one place, we can use this minimal HMR mechanism that’s inspired by Dan Abramov’s blog.
Basically we re-render the app every time when something that’s imported under the App or even the App component itself changes. If it’s something else, we then refresh the whole page as this is set by query parameter reload=true inside our webpack config. Additionally we could write a reducer replacement mechanism so the webpack doesn’t have to refresh the page when we update actions, reducers or sagas. On any change of the state we save it into the localStorage, therefore we don’t really care about losing the state after refresh.

Moving on


function fetchTopStoriesApi() {
  return fetch(``)
          .then(response => response.json())
          .then(stories => => ({ id: storyId, loaded: false, loading: false })));

I’m using redux-saga but feel free to use anything else like redux-thunk or not redux at all! The key thing to see here is the native fetch function for collecting HackerNews stories. I want to point out that in a normal web application I wouldn’t be able to do this (at least on the client side) because of CORS. But since we are in a native-like application, there’s no restriction on CORS in Electron.

Once we have the stories inside our state, we can print them out and attach some onClick handlers. In a normal web application we’d just create the anchor tag and give it a href, but if we do this inside an electron application and then click on the link, electron would load the page inside giving us no option to go back! What we want instead is to open the story in the user’s default web broswer. That’s where the electron’s shell module comes into play.


import electron from 'eletron';
handleClick(story) {
    return (e) => {;

Now let’s just skip all the other components, reducers and have a look at one particular action.


export function notifyAboutStory(story, onClick) {
  const notification = new Notification(`Hacker News ${story.score} 👍💥 votes`, {
    body: story.title
  notification.onclick = onClick;

This is where we trigger the native notification to pop up. It follows the Web\Notification API so if you, for example, want to make it silent, you’d just add that as an option inside the options parameter within the constructor.

Communication between processes

Sometimes, depending on what we’re building we might need to communicate from the renderer process to the main process. It could be anything from a native open-file dialog that’s available only on the main process, or simply quitting the application with app.quit() as we have here.

Processes may communicate by messaging each other via ipcRenderer or ipcMain (depending on what side is being implemented) which is basically an instance of EventEmitter and we use it like this:

Event emitting:

import electron, { ipcRenderer } from 'eletron';
<button className={styles.quitBtn} onClick={() => ipcRenderer.send('quit')}>Quit App</button>

Listening on event and taking an action:

var ipcMain = electron.ipcMain;
ipcMain.on('quit', () => {

Driving this home

From the screenshot above you can see we have the app inside the OSX menubar, we’ll use this menubar package for it’s ease of use and all we have to do is to update our main.js to implement it.


var menubar = require('menubar');
const mb = menubar({
  'width': 500,
  'height': 700,
  'preload-window': true,
  'resizable': false
mb.on('ready', function ready () {
  console.log('app is ready')
  // your app code here

Building the app

For building the app we have a special webpack production config, that just overrides some of the development configuration and saves the build into a dist folder.

Then we use electron-packager to get the actual executable build.

Our final scripts section inside package.json looks like this:


  "scripts": {
    "start": "ENV=development electron .",
    "dev": "concurrently -k 'babel-node server.js' 'npm start'",
    "build": "webpack --config webpack.config.production.js && electron-packager . HackerNews --platform=darwin --arch=all --overwrite"

And that’s it! If you have any questions, use the comments below or get in touch on twitter.


London React Meetup – March 2016

by Joe Paice

This month we were back at the London Facebook office for another brilliant London React Meetup. We had another full house with plenty of pizza, beer and React geekery.



For this meetup we had two presentations. Red Badger’s very own Stuart Harris gave a talk on Redux Sagas and Facebook’s Martin Konicek gave us a look under the hood of React Native.

Managing and testing side-effects in Redux with Redux Saga

Stuart Harris – Red Badger



Stu gave some great insight into how to go about incorporating Redux Saga into Redux applications. Redux Saga is a Redux middleware that handles asynchronous actions in your applications. Instead of dispatching Thunks which get handled by the redux-thunk middleware, you create Sagas to gather all your side effect logic in a central place.

Stu took us through what Sagas are, how to use them and how easy they are to test. No more crazy spies or mocks. No more manipulating time or rewiring dependencies. Just pass in actions and test the output effects.

If you are having trouble with asynchronous actions in your project perhaps Redux Saga can help.

Under the hood of React Native

Martin Konicek – Facebook


Martin works on the React Native team at Facebook. He gave a great tour of React Native with a focus on Android development.

Martin delved into the porting of Facebook’s Ads Manager app from iOS to Android. He demonstrated some of the ways they were able to share code across both platforms, boasting over 85% code reuse in the Ads Manager.

Martin elaborated on the architecture and extensibility of React Native and gives some insight into the React Native Open Source process. It is pretty amazing how Facebook handles syncing their internal React Native and the public React Native on GitHub. I look forward to more tools like the Facebook Github Bot to help developers manage their open source projects.

The recordings of the talks will be available shortly, we’ll post a link here soon.  Thanks to Stu and Martin for their great talks, Facebook for hosting and the members of the community that joined us! Join the meetup group to receive updates on future events!


O’Reilly Fluent 2016 – impressions and trends

by Alex Savin


Roman and Kadi and I are back from San Francisco and Fluent conference. A week-long escape into the rains and floods of California, with an extra flavour of JavaScript. This was my second Fluent conf, and it’s time to share some takeaways.

For now this is the last Fluent event in San Francisco. It was announced that next year will be in San Jose, and there is also one more Fluent this fall coming up in Amsterdam.

Worthy talks available to watch

All keynotes from day 1 and 2 are available online. To save your time, here’s my favourites:

  1. How NPM split a monolith and lived to tell the tale. Laurie Voss on making large breaking changes without anyone noticing.
  2. Quality, equality, and accessibility – Laura Palmaro on the current state of web accessibility (which has become cutely named ‘a11y’ because it takes too long to type).
  3. Complex responsive SVG animations by Sarah Drasner.

Douglas Crockford from PayPal also did an intro on The Seif project – PayPal’s own reinvention of the Internet. They are pretty early stage, and their vision is debatable to say the least. They do have good intentions.

General trends and feelings

Last year React / Node combo was something of a novelty, a curious thing to learn. Netflix was doing introductory level talks on React and why they chose it. This year React / Redux / Babel / Node is the default. Dan Abramov’s name was mentioned in every other talk. Interestingly, Facebook was pretty much absent from this conf – which is understandable since they are busy having their own React-dedicated events. Notable cool guys on the ground included Google, Netflix, New Relic, Uber, and Léonie Watson doing an epic talk on a11y.

Notable conference swag included Heroku socks

A lot of talks were about interesting ideas or wishful thinking, less of production-ready reality. I suppose this is what webdev is about – there is no platform really, more like a herd of clients and engines somewhat held together by loose rules and standards.

Meanwhile, Brendan Eich was pushing for service workers, WebAssembly and class decorators. He was surprisingly quiet on the sensitive topic of his new browser Brave, which blocks bunches of JavaScript by default.

Two days of talks

The keynotes were followed by five tracks of talks to choose from. Sometimes it was hard. These talks are not available online and will be later published and sold by O’Reilly. I’m going to handpick some quick takeaways from the sessions I attended.

Design process in a nutshell



Accessibility is still very important. There are lots of different disabilities, and addressing such users is more important than addressing old browsers. Different OS platforms contain different a11y APIs, but with regard to the Web, semantic HTML combined with basic ARIA markup gives a huge heads up for a11y tools to read through your page correctly.

Few personal takeaways:

  • Browser in addition to DOM tree creates separate a11y element tree based on your markup
  • aria-live=“polite” element creates live region on the page, when action on one element affect content of other element. Every time content of live region is affected, screen reader would announce that as soon as it changes. Generally screenreader is unable to jump around the page, and cannot be in two places at once.
  • role="complimentary” when content is incidental but related to the content on page (similar to aside HTML tag)
  • Use tabindex=“0” to allow keyboard focusing on otherwise unfocusable elements

Léonie Watson did a highly practical talk on semantic HTML and ARIA roles. Her screenreader for some reason failed to function when connected to the projector, and so she did the whole talk from memory, without being able to see any slides.

There was also an announcement of the upcoming Web A11y free course on Udacity.

Progressive webapps

Google did a presentation on their vision of web apps and software delivery to the end user. In a way from the user’s perspective there is no difference between web apps and native apps, as long as they behave in exactly the same way. There’s also a negative trend regarding users buying new apps from App Stores, and in general they use only three native apps 80% of the time. Google wants to address issues with web apps lagging behind native apps in terms of offline availability, home screen shortcuts, direct to full screen launching and push notifications. Some of that stuff is already solved. The biggest missing piece is probably offline access, which they claim can be resolved with service workers and an extra layer that intercepts all requests and behaves according to the network availability.

All these ideas have a common name and a site – Google’s Progressive Web Apps initiative.

NPM lifehacks

As an avid npm user I spend a good chunk of time every day typing npm into console. There was a talk with various hints and hidden features that might be pretty useful.

  • npm install when you are offline – npm contains a (huge) library of modules on your machine and can install the relevant module even when you’re offline from the local cache. To do so run npm install --cache-min 999999.
  • npm version [major, minor, patch] will bump version of your npm package and save it in package.json file. You can even auto-commit this with npm version major -m "bump to version %s”
  • npm prune – get rid of all packages in your local node_modules folder that are not explicitly specified in the package.json
  • npm outdated – quickly check for old and outdated packages in your app
  • – Node sandbox that lets you require npm packages in the browser
  • NSP is great for maintaining 3rd party security in your Node app (although it is known to be down from time to time).


There were two somewhat orthogonal talks on aspects of monitoring your production apps.

New Relic did a presentation on NR Browser, which is a handy way of getting data about how your users actually perceive the app. It gathers everything that a normal browser would, including JS errors, and time to load pages to the client based in various locations. Server side pages usually load 10-20x faster than client side. There are also a number of most strange JS related errors that can be experienced by users and their (derelict) browsers. You can also detect bad deployments by monitoring spikes of client errors.

Shape Security did a talk on dark traffic. According to them, 92% of the global web traffic belongs to non-humans, which is sort of a pity because you still get all the monitoring alerts, but none of your human users are actually affected. Here lies an interesting question of traffic origin detection. You are likely to only care about human users, but they are a minority nowadays. Most of the bots will also try and pretend to be real humans the best they can. Bots will try to authenticate with real usernames / passwords, which are quite openly available on sites like Reddit/r/pwned, or less openly traded for money on the dark net. Since most users are using the same password everywhere, bots will often succeed in signing in, then will crawl everything they can, and move on to the next site.

Falcor by Netflix

Falcor deserves a dedicated blog post. It is Netflix’s answer to GraphQL and Relay by Facebook – central store and dynamic data fetching combined with request optimisation. Its implementation however is distinctively different from both GraphQL and Relay.

@jhusain did an impressive job to a full house explaining Falcor while live coding an app and getting things to work. We are using GraphQL in our production apps, so my angle was obviously on how Falcor is compared to what we already have. Here are a few takeouts:

  • GraphQL is a query language that allows you to request any amount of resources. With Falcor you request either a single resource or a known range. There is no way in Falcor to ask something like “give me all you have”.
  • JSONGraph for data
  • There is no schema in Falcor – as opposed to GraphQL where you must specify types. This works for Netflix since their production app has something like 6 types of resources.
  • Falcor might be more lightwave and easy to start
  • Current implementations of Falcor are in Node and Java. There is internal implementation for iOS which is not released yet.

I shall come back to this topic and write a more comprehensive blog.relevant-swag-600
Other relevant swag

Workshops day

We also attended a full day of workshops. The first half of the day was about implementing desktop apps with Electron, then we did a session on writing your first language compiler, and finally real time drawing on HTML canvas. Electron was probably most notable out of the bunch – in about three hours we ended up implementing two functional desktop apps from scratch. Roman is going to write more on this topic.

Electron provides you with tools to make native OSX / Windows / Linux desktop apps while using the familiar stack of Node and React. But unlike conventional web apps, you also get full access to the filesystem, no CORS restrictions and the ability to integrate into the system menu. If you always wanted to get your app behind the system tray icon, with Electron you finally can.

Extra activities

Red Badger is hiring and we have an #officedog

The general format over the conf was 30 min talks followed by 15 min breaks. After two or three talks there would be 30 min break. In the middle of the day there was an hour lunch break. Everything started at 9am and finished around 6pm.

Breaks were filled with extra activities you could choose to attend. The main attraction and largest source of swag was the exhibition hall, filled with companies presenting their products and giving out freebies. During the last two days the organisers also moved coffee and snacks to the middle of the exhibition hall.

I should probably mention – we were fed pretty well, considering the scale of the operation.

In the main foyer they also tried to get introverted software devs to talk to each other by having topical meetups, speed networking and lightning talks.

exhibition-oreilly-600 vr-signed-book-600
Being primarily a book publisher, O’Reilly brought a bunch of authors signing and giving away free books. I got a couple too.


This trip was possible thanks to Red Badger’s training budget programme. Me, Roman and Kadi had an amazing time, despite the daily dosage of rain. This time I also did daily video log episodes covering our full journey outside of the conference. Yes, we had some fun.


Team Badgers

I enjoy Fluent mostly because of the variety of topics covered. Writing compilers, programming GPU, WebVR, fending off the evil bots, deploying clusters of containers, debugging performance – there’s something for everyone. So, thanks O’Reilly for making this a reality once again!

If you like the idea of an annual training budget, trips to conferences like this and a big focus on learning, Red Badger could be the place for you. Check out of current vacancies here.


London React Meetup February 2016

by Roman Schejbal

A week after our fancy functional meetup we had another, the popular monthly London React and I’m bringing you a short summary of how it went.


Once everyone made themselves comfortable by filling their bellies with pizza and beer from a wide selection, we all moved to the conference room and took our seats. Badger Jon grabbed the mic and after a quick intro, we had the first Reactor on stage.

Sharing React & Redux across applications

Christopher Cook – Software Engineer @ Sky

Sharing React & Redux across application

Chris talked about an interesting topic which is how to efficiently share code between different platforms like smart tv, console, how to work with styles in such a project and about practices for code reuse in general. He primarily focused on the process and the thinking behind the approach they used to tackle the problem so don’t expect any code snippets or technical details there.

I dare to mention that here in Red Badger, we actually face the same challenge on one of our projects and it is not exactly an easy task to solve. I can imagine how Redux is helping with this by embracing the idea of separating presentational and container components, however, it is not a silver bullet and you still have to think things through before you start smashing those semicolons and brackets in.

Watch the talk here:

Designing React Components

Monika Koziol – Visual Designer @ Red Badger

Designing React Components

Monika gave an insight on how we collaborate, design and build React components as cross-disciplinary teams in Red Badger. She also explained why as a designer she is so excited about component-based UIs and highlighted the similarity between React and Sketch app. Although this wasn’t a technical talk she kept us all entertained and even flavoured her speech by adding a cool real-time poll, getting everyone to vote on naming components, which was fun.

Watch the talk here:

After that, we had a quick break to grab more beer and kill the thirst. Then we moved onto our final talk.

Using Redux Everyday / Real World with Redux

Chris Pearce @ Lystable

Using Redux Everyday

We’ve already had a couple talks about Redux, but they were mostly a high-level overview and about how it differentiates from the Flux architecture. None of them, until now, dealt with the tricky parts the developer faces when building a more complex application; that’s exactly what Chris covered for us! He took us through their 7 months journey of building Lystable, an app for companies to manage their external workflows.

Chris also touched on Redux-reselect and selectors. When your app gets more complex you’ll want to normalise the data in your at the reducer level to minimise data redundancy across your application. Once you have that handling relations between models can get tricky and this is when, Chris explained, that redux-reselect or selectors should come into play.

Watch the talk here:


Thanks to all the speakers for such great and educational talks, Sky & Red Badger for the pizza and beers, Alex for recording and also thanks to Skills Matter for hosting! Don’t forget to follow us on twitter for future events!


London React Meetup – January 2016

by Jon Yardley


Christmas is over and New Years resolutions have been made (and/or already broken?) but regardless of the sub zero temperatures, 250 developers flocked to Facebook’s London HQ for the first London React Meetup of 2016. This month’s topics covered React Native, Redux, testing with React & declarative coding with React.

With pizza consumed (110 in total) and beers in hand, our very own CTO took to the stage to kick things off. 

Jani Eväkallio, Futurice

Actually Building Things In React Native


Jani took us through his personal experience at using React Native to build production apps for clients. In a nutshell, Jani informs us that React Native is in a good place and although there are still a few issues you might hit upon is ready for production. Sixty frames/second is apparently easy achieve however more complex transitions might need some tweaking.

He also tells us that it is pretty simple to implement an unsupported native API of 3rd party component even with little to no knowledge of Objective-C. This talk most certainly made me want to kick off my own React Native project! Check out the talk here:


Oliver Woodings, Qubit 

Are you suffering from Selenium-itis? 


Oliver’s talk covered the ways in which we currently test UIs with React and offered an alternative approach to implement end-to-end testing using Qubit’s open sourced react-driver.

React driver aims to eliminate flaky service timeouts by hooking into your React application using selectors and allows you to use whatever test framework you prefer. As a nice addition it will ‘automagically’ install selenium-standalone for you so you don’t have to go through the pain of trying to do it yourself.

Check out the talk here:


Jonas Ohlsson, State  

Using Redux – a case study


Redux is the next evolution of Flux and comes with dramatic productivity benefits. Jonas covered the Redux way of doing things, demonstrated how he’s using it on, a product he built recently and explained what he’s learned along the way.

Check out his talk here:


Michael Jackson

Lightning Talk – react-stdio


With Ryan unable to make the event Michael took to the stage to deliver an engaging talk on how to write (or re-write) components so that they are way easier to reason about. This uses a really simple app that generates simple and more complex sound waves.

Interestingly he creates components that didn’t render any visual UI but generated sound using the WebAudio API. As he pointed out, for internet users who are blind or partially sighted, audio is their main or only UI when using a browser. In addition, these audio components allowed him to quickly iterate on the application during his live demo.

Check it out here:

Thanks to all the speakers for an engaging and educational evening. Also thanks to Facebook for hosting and Alex Savin for the great snaps. In my opinion it was one of the best meetups so far!

The next meetup will be happening in February so keep you’re eye on twitter @londonreact for updates as I am sure you’re well aware they go super quick.


Arch framework – update

by Alex Savin


Arch framework official logo by Sari Griffiths, Clementine Brown and Blanca Tortajada

Arch is an isomorphic single page app framework built on top of React and Immutable.js. It was announced and open sourced at the  React London meetup in April by Viktor and Tiago. Many of us at Red Badger are really excited about Arch, its performance, flexibility and openness. Last week we had a first of its kind Arch hackathon at the HQ, and here are a few updates we’d like to share with you.

Official Twitter handle is reserved – it’s ArchFW. Follow it to get quick updates on development and future events (especially if you’re in London!). It is also one of the quick ways to contact team, ask questions and get feedback.

New dedicated organisation is now available on Github – Arch-js. It contains all Arch -related repositories, including Core of the framework, command line client and example apps from the original announcement talk.

We invite you to join the discussion under the core repository. Post issues you encounter, or comment ongoing topics. If you have an idea on missing example app that would enable you to try the framework, feel free to add it here.

Crash course into Arch and functional web programming is now fixed and available for brave new users. You’ll find even more chapters on Arch internals, concept of immutables, cursors and isomorphism in the docs folder. We also have reserved domain for the upcoming webpages.

And don’t forget the talk from London React meetup by Viktor and Tiago with introduction to Arch and apps with centralised state.

What’s next? Few things:

  • More sample apps, in ES6 and Livescript
  • Designing more powerful routing DSL
  • Default support for unit tests
  • Improving command line client

Arch is now properly open sourced with BSD 3 license. We hope you’ll like it.


Join me as a new voice in the tech community

by Winna Bridgewater


A glimpse at the weekend workshop I led. Photo by Alessia D’Urso, Girls In Tech UK Board Member.

London has a staggering number of events for coders. It’s awesome.

The only thing is, I’ve gone to a lot of events, and I can count on one hand the number of times a technical discussion—about a tool, an industry standard, or the craft of code—was led by a female. For the majority of the events I attend, I am one of only two or three females in attendance.

I decided that this year, if I want to see more women presenters, I need to step up. I need to talk at an event.

Getting Inspiration

As if the universe was listening, two events came up this spring that got me more excited and less nervous about going for it.

First, Ladies Who Code London ran a workshop on public speaking, and it was hosted here at Red Badger. Trisha Gee and Mazz Mosley were wonderful. Their message was simple: it gets easier each time you do it, and there are ways to work through nervousness. They also emphasized that the audience is rooting for you–everyone in the room wants to see you succeed. Pretty nice, right?

Then I had the chance to attend the Women Techmakers Summit, an evening celebrating International Women’s Day that was organized by Google Women Techmakers and Women Who Code London. There was a series of speakers and panelists, and every presenter had a powerful message. The speaker whose message stayed with me most was the keynote, Margaret Hollendoner

Margaret said she sometimes makes her career sound like it was all “right place at the right time” luck. But she told us it wasn’t that simple. Every opportunity was lucky in one sense, but the opportunity wouldn’t be there without her hard work. She also emphasized that deciding to say “yes”  required confidence and bravery.

Margaret’s presentation gave me another nudge: get past my fear and present at an event.

Saying Yes


Only two days after the Summit, I got an email from Lora Schellenberg about Spring Into Code, a weekend workshop on Web Development offered by
and Girls In Tech. Lora asked if I was available to teach–the original instructor had to back out, and they were looking for a replacement.

It sounded like my lucky chance, so I agreed.

Then I got all the details. I was going to be the only teacher for 12 hours of instruction over two days. I’d be teaching at Twitter headquarters to an audience of 100 people.

I felt pretty panicked, so I knew it was time to make some lists.

Why I should not do the workshop
  1. I’m not an expert in web development.
  2. I’ve only been doing this stuff professionally for a year and a half.
  3. I won’t be able to answer all their questions.
  4. 12 hours is a long time.
  5. 100 people is a lot of people.
Why I should do the workshop
  1. I’m not an expert in web development. I still spend most days learning new things. I know what it’s like to feel confused and lost. And I know how to recognize and celebrate small triumphs.
  2. I did set that personal goal.
  3. Those nice ladies did tell me the audience will root for me.
  4. That other nice lady did say you need to take advantage of luck that comes your way.
  5. If I’m going to teach 100 people for 12 hours, this is the ideal audience. Eager learners who, by choice, agree to a weekend in front of a computer taking in as much as possible.

I decided to go for it—butterflies, sweaty palms and all.

There are so many things I could focus on under the umbrella of Introduction to Web Development. I decided my main goals would be:

  • Make techy code stuff seem less scary.
  • Make people feel ok about asking questions.

Saturday morning arrived, and I had a rough start. I spent the first session working out how to use the mic and the two screens floating on either side of me. My notes weren’t loading like I hoped. The Internet was down. My demo wasn’t working even though it worked mere hours before. I was shaking.

After the first demo fell flat on its face, I knew I needed to stop. I took a few minutes to get everything running properly. I got water. I took some deep breaths. Those minutes felt like ages, but it was worth it. When I started up again, stuff finally started working.

The first day flew by. A few folks came by during breaks to say they were enjoying themselves. At the end of the day, lots of people came by to say thanks. Were my silly jokes working? Did my missteps when typing—forgetting a closing bracket, leaving off a semicolon, incorrectly specifying a source path—help people understand that breaking and fixing things is what this job is all about? During the second day, people from all over the room were asking questions. Tables were helping each other debug and understand what was going on. Breaks came and went with people staying at their seats to try things out. I couldn’t have hoped for more.


I have so many ideas about what I’d change if I could do it again. I missed some concepts. I glossed over others. But I did it, and I had an amazing time.

If you’re tempted to give a talk or run a workshop, please go for it. It’s scary but great, and you have a wonderful community rooting for you.

Red Badger is always looking for ways to connect to the tech community. Like that sound of that? Then come join us.