Archive for June, 2012



by Jon Sharratt

Here at our (currently) sunny workshop in Clerkenwell, myself and the fellow badgers have being busy carefully crafting this, the new website and blog.

Internal projects here are run with an ethos of allowing software engineers to learn, trial and sometimes fail (but that’s ok!) with new technologies and methodologies.  To give you some insight, my background is heavily based on developing all things on the Microsoft technology stack.  It was a welcoming surprise that we were going to be getting ourselves knee deep into a complete opposite of what many of us were used to.  From hosting environments and development tools it was a journey of discovery that ended with a great product at the end of it (of course I am biased).  As with any product built here we like to share our experiences and give an insight on how we do it, so lets begin….

Amazon EC2

Previously the Red Badger website was hosted on Rack Space but we thought we would try out Amazon EC2.  The first thing we noticed is that the speed to setup instances from start to finish was incredibly easy and quick.  A massive plus is that EC2 has a layered approach to its infrastructure setup.  Elastic IPs gave us a great benefit and flexibility when we were releasing some of the bigger changes initially.  It allowed us to efficiently spin up a clone of the production instance then release to it and switch the Elastic IP association from staging to the new clone.  Straight away Samera could test the effects of the new release, giving the green light to release to production.


Ubuntu gave us a lean, fast operating system and being open source no license fees.  It has a great community and documentation for many of the tasks we required to setup.  I would say that Haro, Can and Stu had a much easier time setting up their local development environments being on Apple Macs.  It did take me a little while (running Windows 7)  to setup a Virtual Box with Ubuntu to get it up and running for development.  I used Samba to enable my Windows 7 based laptop to network share the files.  Additional to this, I setup port forwarding within Virtual Box to divert port 80 host traffic to the Ubuntu guest machine.  This meant I could work locally within my Windows 7 environment.  I would say though it took me a bit longer to get up and running because of the fact it was the first time I had ever used the Ubuntu operating system via command line.


Initially for the project we started using Apache but the team having done some research moved on to the decision to use the lightweight webserver Nginx which is pretty much built for speed.  The main difference is the fact that Apache’s model is process and thread based where-as Nginx is event based.  This means that rather than waiting around for a response to happen before continuing and blocking a thread, callbacks in an event driven architecture allow the thread to continue executing other jobs whilst still waiting for a response to respond to.  The configuration was simple and allowed us to very easily configure reverse proxying to Node.js along with caching of pages.


Apart from the blog section of the site the pages are rendered using Node.js.  The framework used was Express, it provides a quick and easy setup for the building blocks when building a website via Node.js web development.  The template engine is Jade which I found to be incredibly easy to use and takes a lot of the bolierplate code / html tags when writing templates for content managed websites.  The way in which we do this is to tell Nginx to reverse proxy requests and serve up the response from node.  This allows us to use WordPress as our content management system yet keeping the awesome capabilities of the blog features.


For the management of site content and general blogging (which is very much encouraged here at Red Badger) we chose the ever so popular WordPress.  We coupled the default install with a custom theme as well as installing a couple of extra magical plugins.  These plugins are Advanced Custom Fields, JSON API and Disqus to name a few.  Advanced Custom Fields is a great plugin that allows you to specify many new custom fields for certain pages turning your WordPress blog into an easy to use content management system.  These custom fields ranged from relationships, images, WYSIWG editors and more.  The JSON API plugin allowed Node.js to get relevant content as a JSON response and simply render out our Jade templates against the data.

Twitter Bootstrap

To give us superb results viewing across all devices we went for a responsive design and layout.  To do this we implemented the Twitter Bootstrap framework giving us a grid based layout / framework along with jump starting support across browsers.  You can see what I mean if you head to which provides a great site to roughly test what your responsive layout looks like on different mobile devices.  Another interesting aspect when building the site with Twitter Bootstrap was that we followed the route of using LESS for CSS for stylesheets on the site.  On Windows machines I would recommend Crunch to compile them all.  LESS for CSS provided some nice features for setting global colour variables amongst other elements to allow reuse and maintainability of our styles.

So all in all that about sums up the technologies and infrastructure which powers the new website.  Feel free to comment with any thoughts about the site or even the technology stack we decided upon.


BBC Connected Studio–HPSN Pilot here we come!

by Cain Ullah

So, you may have seen our recent blogs about the BBC Connected Studio for Homepage, Search and Navigation – Creative Studio and Build Studio.

So far the experience has been an incredible one. The BBC have run two fantastic events that have been very well organised and almost militant with their timing. In brief, the Creative Studio had 32 teams presenting which was then whittled down to 9 for the Build Studio.

It sounded like the BBC judges had an incredibly hard time in choosing the finalists to go into the funded 6-8 week rapid prototyping Pilot phase because there were some incredible ideas amongst the 9 participants.

We are really pleased however, that we have been chosen as one of the three teams to go through to the Pilot stage. The other two are Kent Lyons and Goss Interactive so congratulations to both of those as well.

Our original concept in the Creative Studio combined a number of ideas including a time based homepage combined with varying levels of manual and automatic personalisation and the semantic web. In the Build Studio we had 2 days to focus on one idea and the BBC wanted us to explore the timeline view. It was a bit of a risk but the team chose to rebuild the prototype for the homepage from scratch using Node.js (rather than using the existing PHP codebase that was provided)  in the 2 days allocated.  This was integrated to real BBC data and demoed at the end of the 2nd day.


So, in the Pilot we will more than likely be taking the timeline view further and making it production ready. We haven’t yet defined the requirements for the 6-8 week project and it going ahead is subject to some business case analysis and agreement being reached on costs, deliverables and timescale. If it does go ahead however, once we have built it, the pilot will be live to the public on the connected studio site so the BBC can gather some real feedback before making a decision on whether to implement it into

So far the Connected Studio has been a great experience. We have given the opportunity for a a number of our staff to be involved (the team for Build Studio was entirely different to Creative Studio) so it feels like it has been a real team effort. We’ can’t wait for the pilot to begin.


In the Brain of Uncle Bob at Skillsmatter

by Arnaud Lamotte

I went to an excellent talk last night at the Skillsmatter exchange on Object Oriented Programming by Uncle Bob (Robert C. Martin).

The talk was mostly about his S.O.L.I.D principles for OOP: Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion but also about the history of OOP and what makes it so powerful. It is this last part I am going to develop below because surprisingly, in a room filled with approximately 100 OOP developers, nobody was able to correctly answer how OOP was created and what is so good about it.

Object Oriented Programming was created by Ole-Johan Dahl and Kristen Nygaard in Oslo in 1966. They were simulating ships going around the fjords using ALGOL but were not particularly satisfied with it and started hacking it. All they did was move the data structure from the stack frame to the heap and were well surprised with what happened. ALGOL is a block structure language; it is possible to declare a function inside another function. Once moved to the heap, functions were still callable, the outer function still returned, local variables still existed. The outer function had become a constructor, the inner function had become an instance method and local variables had become instance variables. And they could call methods on these objects. Object Oriented Programming was born.

And now the tricky question: what is so good about Object Oriented Programming? The answers provided by the audience did not satisfy Uncle Bob Martin, especially not the myth of modelling the real world, probably invented by a developer who wanted his boss to buy him an expensive C++ compiler he reckons, or the myth of re-usability, which is not an advisable practice anyway. As per inheritance, mixing data structure and code and encapsulation, it was all possible in C, even easier in the case of encapsulation.

The true added value of OOP is polymorphism. Polymorphism was possible in C but very difficult to manage and generally avoided. OOP made polymorphism easy. And what polymorphism brings us? Dependency management. Until OOP source code dependency and flow control were always going in the same direction. Polymorphism gave the ability to take some dependencies and turn them around without changing the flow of control. What did that allow? Plugins. It allowed the creation of modules that could be called even if unknown; it allowed invoking methods on unknown objects. This is the beauty of OOP!

A great couple of hours at the Skillsmatter exchange, half-way between the tech talk and the one-man show. Brilliant.


Functions to consider for Mobile testing

by Samera Butt

Having a mobile version of an application has now become a must. With mobile devices ranging from different OS platforms and tabletdevices – as testers, we have a lot on our plate!!

However, there are key points that we must consider whilst drafting out test plans and scripts for any mobile device. In this blog I attempt to cover some of the key points along with functional testing we should consider for mobile testing…

User Interface

Unlike our desktops, mobile devices come with various interfaces, from small screens that can be re-orientated when the device is physically rotated, touchscreen only devices to those which allow a combination of touchscreen and hard keypads, soft keypad only and not forgetting the various navigation methods such as hard keys and trackballs.

Being familiar with the device you are/will be testing on is important, if you are not, ensure you have a play around with it before testing. Check for the following:

  • Check for overall colour scheme/themes of the device. For example, Windows phone allow you to change the accent colour and background colours.
  • Style and colour of icons
  • Progress indicators when pages are loaded
  • Menu’s – how they are invoked and typical items they contain
  • Overall responsiveness of the application on the device

Screen Orientation/resolution: Applications should be tested in portrait and landscape view. Rotating the device fast, and checking to see the application’s response and errors

Touchscreens: Things to consider when testing touch screens are:

  • Multi-touch such as : pinch to zoom and single touch.
  • Long touch and short touch. For example, on some phones, pressing and holding an item will bring up a context menu, or a secondary function of a button.

Button Size & Position: Buttons and icons should be large enough to be seen clearly and be clickable by a fingertip.

Workflow: Use of radio buttons and checkboxes to minimize the amount of typing required, as this can be time consuming.

External Factors

Factors such as interaction with other devices and interruptions from the devices own functions such as incoming phone calls should be considered.

Factors to consider are:

  • Loss of Network Connections
  • Memory Card usage
  • 3G Network, 4G network, 2G network
  • No SIM card in the device
  • In airplane mode
  • Test intermittent network scenarios that a user might encounter in the real world such as:
    • Walk out of Wi-Fi range so the connection automatically switches to 3G/2G (for example, in a large building like a hospital or airport, or outdoors)
    • Ride in a lift or on a train where the network connection may go up and down
    • No network connection available at all

Device Options such as Screen Timeout/Auto on/off: Is your application subject to screen dimming or automatically turning off even when it is actually busy? For example, you wouldn’t want your screen to dim or turn off while watching a slideshow of your photos.

Screen orientation: You may be able to enable/disable automatic orientation switches when the device is rotated. Does your application apply the setting set on the device?

Font: Does choosing a different font family, size, or style affect the appearance and usability of your application?

Connections: Using one of the connections on a device, such as Bluetooth or Microsoft Direct Push (only on Windows Phone devices), could have adverse effects on your application. How does enabling/disabling Bluetooth or other connection types affect your applications behaviour?

Emulator Use

Can be a great way to achieve testing coverage across multiple devices, but it is not safe to assume that just because your application works on an emulator, it will work on the actual device itself. When using Emulators, it is important to consider the following points:

  • Not all activities can be realistically emulated, like switching network connections, or taking a picture or video.
  • Some activities don’t work at all on emulators, like streaming video on a Blackberry emulator.
  • Due to lower device power and memory, the application could exhibit slower performance overall when run on an actual device (versus in an emulator on your powerful desktop computer).
  • If the emulator and actual device have different resolutions, your screens may not display as you expect.

Stress Testing

Mobile device applications have much less memory and power available than PC’s

Security Testing

This applies to applications which require sensitive data storage such as banking applications, and how the application behaves under various device permission schemes.

Mobile devices will no doubt continue to grow, and as testers we will need to keep up to date with the latest gadgets out there to keep on top of the latest changes in OS and functions belonging to a gadget. No doubt the device functions discussed in this blog will continue to grow.



Red Badger’s Collaborative, Agile Environment

by Arnaud Lamotte

I am Arnaud the new Agile Project Manager at Red Badger. I have worked for over 10 years in the Internet industry notably as Service Support Manager and Product Manager and I am delighted to have joined the ‘Badgers’ a couple of entertaining and interesting months ago.

Agility at Red Badger is not an add-on or a trend but an intrinsic part of the company’s philosophy and business model. The founders have set a very adaptive environment. There is no desk allocated, employees can choose their own laptop and mobile phone and can move around depending on the project or task they are working on. All our internal tools, from HR to project tracking software are cloud based allowing us to collaborate in-house and with customers both local and remote, with great clarity, adaptability and effectiveness. The integrated team members whether they are technologists, creative or business focused are encouraged to self-manage, help each other and learn from each other. Each one of us has a consequent budget for personal development that we also self-manage . The hierarchy is flat and the team empowered. My first contribution to this setting encouraging collaboration and creativity has been to make it an even more visual workspace. Tools like Agilezen or Youtrack are very effective for collaborating with offsite customers, tracking and producing reports but they cannot replace boards and burn-down charts to remind any in-house stakeholder at any time with a quick look what we have done, what we want to achieve and how we are progressing.

In this very favourable environment one of my tasks is to maintain and eventually reinforce Agile and Lean practices as well as adapting them to our customer’s needs, structures and projects. The very essence of Agile is flexibility and at Red Badger we are well aware that in terms of processes, methodologies and even engineering practices one size does not fit all. We believe in best practices within a context and choose our methodologies depending on project. For instance although we are all fervent Scrum practitioners, if an iterative approach is not necessary i.e. low complexity and well defined requirements, we like using Kanban. In any case our aims are to avoid unnecessary overheads and not constrict creativity with processes while providing our customers with control, transparency, and most importantly a setting for enhanced collaboration.

Collaboration between Business and IT, developers and customers, is fundamental to most software development projects. This is particularly true at Red Badger. Many of our customers come to Red Badger because of the exceptional know-how of our development team in leading/bleeding edge technologies and therefore many of our projects tend to be technology driven. Typically in this kind of project the boundaries of the problem to be solved are blurry and the customer wants to achieve market differentiation. Enhanced collaboration allows us to work in short iterations with rapid feedback. Our customers can change or improve their requirements as they discover their new software and get feedback from users. Rapid feedback leads to a better fit to the target market while short iterations leads to regular deliveries and market differentiation for a longer period of time. Red Badger’s developer’s excellence in rapid prototyping comes particularly handy in these projects and I will explain this further in other blogs.

In a competitive market and difficult economic times where software is expected to be delivered within a few months with phases reduced to a few weeks, it is very refreshing and motivating to work for a company that responds to those market constraints by encouraging innovation, creativity, continuous learning and comradeship.


Return of Swiss Typography – Metro

by Sari Griffiths

It’s been a month already (where has my month gone?) since  I attended a workshop for Windows Phone Design Clinic on Thursday 10 May at Soho, London, organised by Microsoft and Nokia.

Can’t believe it’s Microsoft

I was 10 mins late coming in and as I walked in, I was greeted by a presentation showing classic Swiss Typography. This the kind of stuff I learned about at art school and the kind of stuff I’ve got a quite a few books about at home. Examples include beautiful urban transport signs from around the world and the famous grid system.

Here are some posters by Josef Müller-Brockmann – typical Swiss Typography.

The audience was about half developers and half designers, so I’m not sure how the developer folks took to this presentation, but my honest first opinion was: this is a lovely design – can’t believe it’s Microsoft. (Sorry!)

I have seen their Metro design templates prior to the workshop, so I knew it was pretty ambitious. But hearing from Dave Crawford first-hand how it came about and what it was all about, it really hit home. This was really happening and it was very well thought through.

When iPhone changed the smart phone market, it was revolutionary. But its iOS design relied heavily on real life metaphors of buttoned machines. I suppose this was to  provide some clues to how a crazy device with no buttons works.

That’s a while ago. These days, users are happily swiping and pinching their devices away – they know how these button-less things work now. It is the perfect time to rethink interfaces for touch devices.

It was surprising that it came from Microsoft.

Let’s face it, they were not really known for good graphic design (Some old fun: Microsoft repackage iPod video). Their brand was more of ‘you can do anything as long as you know what you’re doing’ and it’s about performance, not the look’.  Whereas Apple was more about ‘user experience’ and ‘our way is the right way’.

Lately, I think there is a shift in this positioning. Apple is still criticised for not making iOS open enough etc, but as long as their user experience is concerned, it’s anything goes. They are not doing much about their slipping standards of user experience and slick graphics, that they were once famous for.

Android provides an alternative to iOS, but it is an alternative. The interaction models aren’t very different. It basically has a few more physical buttons than the iPhone. Having said that, it is a jolly good alternative with lots more freedom for developers.

And now with Metro, Microsoft is providing a new approach, rethinking the interaction model for touch screen devices.

Two points stand out for me.

1. Panorama interaction: the edge of screen isn’t the edge of screen.

The screen they call ‘panorama’ is a wide page with a few columns. You have to swipe to see it all, but it’s pretty intuitive to use. It really brings the horizontal direction into play, not just vertical.

2. Back means back.

Metro doesn’t encourage apps to have a ‘home’ button. Sometimes it’s unavoidable, but if you can get away with it, it’s better for it not to be there. Having this principle really challenges you to think about interaction and user experience, and not to default on the standard website model that you see a lot on iOS.

Respect your device

In one of Dave’s slides, he told us to respect a few rules. “Respect your device” was the most memorable one.

There were a few comments from the audience about some clients asking for the apps across mobile devices to be identical because they want consistency. Between iOS and Android, their similarity allows these apps to seem pretty identical, but not in Metro.

I thought the question for this situation will be “what ‘consistency’ means in this context?” It is unlikely that someone is holding two devices side by side, using the apps and saying “oh, they’re not the same”. It’s more likely the user feels they are the same. If your back button didn’t go back as you expected it to do, you feel it’s wrong, even if that’s what happens with other devices. Consistency can only come from how well the app operates on the particular device you’re using.

Having worked on an app for iOS and Android, for both to have the same feel, I know that they can’t be identical either. There are subtle differences due to the existence of the back and menu buttons, forcing architecture to be different. However their visual styles could be very similar, giving the illusion that they are identical.

Okay, I admit that recreating an iOS app for Metro requires a much harder rethink than doing the same for Android. Several speakers at the workshop recommended going back to the drawing board rather than trying to translate. And actually, your app could work much better in Metro than in iOS as a result of it by digging deep into the concept of the app and the brand.

So would I use it?

Yes is the simple answer.

I am a long-term iPhone user but I really wanted to try this out. It’s great having someone challenging the way we interact with devices. It’s a beautiful system to use and look at. I’ve asked for my company phone to be a Windows Phone 7.

I am also looking forward to doing some work on Metro. Although it’s really well thought through, it is not an easy task to design for one. You still need a good design to make it work. But it’s really exciting to see where it’s heading UX-wise. Now, what I’m not so sure about, is what it’s like for devs…?

For further reading about designing for Metro: