Posts Tagged ‘Red Badger’

18
Nov
2014

Silicon Milkroundabout – From both sides of the fence

by Roisi Proven

seedpacket

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

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

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

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

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

badgershed

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

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

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

27
Oct
2014

Improving Performance with New Relic APM and Insights

by Roisi Proven

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

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

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

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

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

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

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

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

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

20
Oct
2014

London React October Meetup

by Chris Shepherd

Last week saw the fourth London React User Group and yet again the turnout was fantastic for such a young user group.

There were three talks this time and the first, “Learning to Think With Ember and React”, was by Jamie White who runs the Ember London User Group. Red Badger's own Stuart Harris had previously done a talk on React at the Ember User Group that had been well received, so it was time for them to come and talk to us. Jamie talked about how it was possible to combine Ember with React and it was interesting to see how flexible React is and how it's so easy to fit into a variety of existing workflows.

Next up was Rob Knight with his talk, “Diff-ing Algorithms and React”. Rob covered something that I think a lot of us now take for granted with React: how it updates the DOM through the use of a virtual DOM and efficient algorithms.

Lastly, Markus Kobler's talk, “React and the Importance of Isomorphic SPAs”, showed how to use React to avoid poor SEO and slow loading times. These are usually considered the pitfalls of building Single Page Applications.

If you missed the talk then you can watch it on YouTube below. To be informed about the next meet up then sign up here.

Hopefully we'll see you there next time!

21
Aug
2014

Computer Science students should work for a start up while at uni

by Albert Still

Don’t completely rely on your grades to get you a job after uni. A CS degree will prove you’re intelligent and understand the theory, but that will only take you so far during an interview. We have to talk about apps we’ve built with potential employers, just like you would want a carpenter to show you pictures of his previous work before you hired him.

While studying CS at university I worked 2 days a week for Red Badger, even in my final year when I had a dissertation. Some of my class mates questioned if it was a good idea suggesting the time it takes up could damage my grades. But it did the opposite, I got better grades because I learnt so much on the job. And when you see solutions to real life problems it makes for a better understanding to the theory behind it. And it’s that theory you will get tested on at university. 

What I’ve been exposed to that I wasn’t in lectures

  • Using open source libraries and frameworks. Theres rarely a need to reinvent the wheel, millions of man hours have been put into open source projects which you can harness to make yourself a more productive developer.
  • GitHub is our bible for third party libraries. Git branches and pull request are the flow of production.
  • Ruby - the most concise, productive and syntactically readable language I’ve ever used. Unlike Java which the majority of CS degrees teach, Ruby was designed to make the programmers work enjoyable and productive. Inventor Yukihiro Matsumoto in a Google tech talk sais “I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language”. Ruby is loved by start ups and consultants because they need to role out software quickly.
  • Ruby on Rails - built in Ruby it’s the most starred web application framework on GitHub. It’s awesome and the community behind it’s massive. If you want to have a play with it I recommend it’s “Getting started” guide (Don’t worry if you’ve never used Ruby before just dive in, it’s so readable you’ll be surprised how much Ruby you’ll understand!).
  • Good habits – such as the DRYYAGNI  and KISS principles. The earlier you learn them the better!
  • Heroku - makes deploying a web app as easy as running one terminal command. Deploy your code to the Heroku servers via Git and it will return you a URL to view your web app. Also its free!
  • Responsive web applications are the future. Make one code base that looks great on mobile, tablets and desktops. Twitter Bootstrap is the leading front end framework, it’s also the most starred repo on GitHub.
  • JavaScript – The worlds JS mad and you should learn it even if you hate it because it’s the only language the web browser knows! You’ll see the majority of the most popular repositories on GitHub are JS. Even our desktop software is using web tech, such as the up and coming text editor Atom. If you want to learn JS I recommend this free online book.
  • Facebook React – Once hard JS problems become effortless. It’s open source but developed and used by Facebook, therefore some seriously good engineers have developed this awesome piece of kit.
  • Polyglot – Don’t just invest in one language, be open to learning about them all.
  • Testing – This was not covered in the core modules at my university however Red Badger are big on it. Simply put we write software to test the software we make. For example we recently made an interactive registration form in React for a client. To test this we made Capybara integration tests, they load the form in a real browser and imitate a user clicking and typing into it. It rapidly fills in the form with valid and invalid data and makes sure the correct notifications are shown to the user. This is very satisfying to watch because you realise the time your saving compared to manually testing it.

Reasons for applying to a start up

  • They are small and have flat hierarchies which means you will rub shoulders with some talented and experienced individuals. For example a visionary business leader or an awesome developer. Learn from them!
  • More responsibility.
  • They’re more likely to be using modern front line tech. Some corporates are stuck using legacy software!
  • If they become successful you will jump forward a few years in the career ladder compared to working for a corporate.
  • Share options – own a slice of your company!
  • There are lots of them and they’re hiring!

Where to find start ups

A good list of hiring startups for London is maintained by the increasingly successful start up job fair Silicon Milk Roundabout. Also Red Badger are currently launching Badger Academy, they’re paying students to learn web tech! This is extremely awesome when you consider UK universities charge £9,000 a year. If your interested in applying email jobs@red-badger.com

Best,

Albert

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

C.A.R. Hoare, 1980 ACM Turing Award Lecture

8
Aug
2013

Faster, longer and more responsive

by Stephen Fulljames

blog-head  

You know how it is – you set out to make “a few content changes” and end up with a whole new web site. We wanted to make a bit of an adjustment to the version 2 Red Badger site, launched in mid-2012, to give a better feel for who we are and what we can offer. In the end, it made more sense to go the whole way and create version 3. So here we are.

The fundamentals

In the previous version of the site we used WordPress to manage most content, but rather than use it to render every page we instead pulled content through its JSON API to feed a more flexible front-end built on Node and Express. This was fine in theory, but in practice performance wasn’t really as good as we’d hoped – even with some aggressive caching built in – and any kind of content beyond blog posts turned into a tangle of custom fields and plugins. WordPress specialists would probably have an answer for all the problems we faced, but we felt it was time to strike out and try something different.

This also coincided with an interest in evaluating Docpad, a semi-static site generator built on Node. If you’re familiar with Jekyll on Ruby or Hammer for Mac its kinda like that, but as well as building purely static sites it can also run with an Express server to allow some dynamic behaviour where needed. We hacked on it for a couple of days, I rebuilt my personal site with it, and then liking what we saw we decided to proceed.

The principle of Docpad and other site generators is pretty simple. You have a folder of documents written in any supported format (we’re using Jade and Markdown), reflecting the desired URL structure of the site, a folder of templates, and a folder of static assets. The generator runs through the documents, compiling where needed, applying the templates, and saves them into an output directory along with a copy of the assets. Logic in the templates is responsible for constructing navigations and outputting collections of data – just as a dynamically rendered site would – but it only does it once. The theory being, your site only changes when you act to change the content, so why do you need to serve something other than flat files between those changes?

Docpad is light in its core form, but there’s a good plugin ecosystem to extend it. We’re using plugins to compile SASS, Markdown, Jade and Coffeescript, fetch RSS from Flickr using Feedr and serve pages with clean URLs rather than .html extensions (this is where the Express part comes in handy). We’ve also created a few of our own. The main one is to allow us to curate “featured” items in the meta data of any page – so if you look on the homepage, for example, all the content items below the masthead are manually set and can be changed and reordered simply by altering a list of relative URLs. We’re also using custom plugins to pull in Tweets and posts from the old WordPress blog, and Docpad’s event system makes it easy to hook this data into the appropriate render step in the site’s generation.

For the time being we’re still using WP for our blog, recent posts are imported by the Docpad site on server start using a custom plugin in order to be able to feature them on the home and other pages, and list them on our team profiles. In the longer term we’re planning to move to blog itself on to Docpad as well, but that will need careful consideration to make sure all the functionality currently given by WordPress plugins can be maintained (or improved!).

We’re responsive

The previous iteration of the site was built using the Bootstrap CSS framework. My own views on that notwithstanding, some of the design changes we were planning meant it made sense to look again at our approach to the CSS.

As the site design created by Sari does not inherit from Bootstrap’s design opinions, only a small subset of it – mainly the grid – had been relevant, and structurally with full-width background patterns on each section of a page it was easier to start over.

That’s not to say we’ve rejected it completely. In the new grid system we’re still using some of Bootstrap’s thinking, along with patterns adopted from Harry Roberts’ Inuit.css and Chris Coyier’s thoughts on minimal grids. So we haven’t really done anything earth-shakingly innovative, but we have found it to be a solid, responsive grid that – most importantly – we completely understand and can use again.

site-grid

1 – ‘section’ element. Inherent 100% width. Top/bottom padding set, optional background texture applied by class, otherwise unstyled. The paper tear effect is added with the :after psuedo element.
2 – ‘div.container’. Width set to site default (920px) with left/right margin auto for centering. Any full width headings are placed directly inside this element.
3 – ‘div.row’. Unstyled except for negative left margin of default gutter width (40px) to compensate for grid element margin, :before and :after psuedo-elements set table display and clear as with Bootstrap.
4 – ‘div.grid’. Floated left, all .grid elements have a left margin of default gutter width (40px). Default width 100% with over-ride classes for column width, in the case above we use ‘one-third’. Background texture classes can also be applied here.

We’ve switched from our regular LESS to SASS for this version of the site, again as a way to explore what it can do. With Docpad its as easy as swapping plugins and all the compilation is handled for you during site generations. Needless to say the site is responsive, with the grid gradually collapsing down to a single column view and elements such as the services carousels and case study quotes shifting layout subtly to suit smaller viewports. And to make sure corporate decision makers get a good experience we’ve also tested and fixed back to IE8.

The other final touch is that we chose to use a custom icon font for the various calls to action and other decorations around the site. We used Icomoon to generate it from our own vector artwork, and this has saved an enormous amount of time because you can colour the icons with CSS rather than cutting and spriting images for all the variants you might need. The adoption of icon fonts has had a few challenges, chief among them accessibility (screen readers tended to attempt to announce them) but with the technique of encoding icons as symbols, in the Private Use Area of the Unicode range, this problem is now largely overcome.

icon-font

There were still a few things we found in the process of creating our icon font. It’s not advisable to do anything more complicated than just use them as icons, for example, as it’s very hard to align them perfectly to regular fonts without browser hacks. Each browser has a slightly different way to calculate and render line height. Also, depending on how much consideration you give to it, they’re not supported by Internet Explorer on Windows Phone 7 (although the symbols it uses instead are quite cute).

What’s next

Of course a consultancy’s own web site is never really finished, as we’re always looking to show our capabilities and keep up with the latest thinking in a world of fast-moving technological change. And the cobbler’s boots syndrome also applies; its hard to find time to look after your own when you’re always busy helping clients deliver their own transformative projects.

But we feel like we’ve achieved a stable, maintainable new site and its time to put it out there. It feels much faster than the old one, and we’ve delivered the flexibility in content layout we set out to achieve. We wanted to make sure we were demonstrating our own best practices, and while a good deal of that is under the hood we’d be happy to talk through it in more detail if you’d like to get in touch.

There are tweaks to come, naturally, based on things we’ve already spotted and feedback we’ll no doubt get. One big task will be to make the site more editable for those of a non-technical nature. Its actually not too difficult, as most content pages are written in Markdown, but a nicer UI exposing that rather than the intricacies of Git pushes and deployments feels like a good next step. No doubt we’ll be blogging again to talk about that when the time comes.

15
Feb
2013

Automating myself – part 1

by Stephen Fulljames

photo-1

Having gone through the onerous task of selecting what type of laptop I wanted at Red Badger (13″ MacBook Pro with 16gb RAM and 512gb SSD) and waiting impatiently for it to be delivered, it was time to get it ready to use.

My previous personal Mac, a late 2010 11″ Air, has done sterling service – even just about managing when asked to run a couple of virtual machines concurrently alongside a Node.js environment. But it was starting to creak a bit and the poor thing’s SSD was chock full of all the random crap that had been installed to support various projects. So as well as the stuff I regularly use there were also leftover bits and pieces of Java, Python and who knows what else.

At Red Badger we’ve largely adopted Vagrant and Chef as a great way of provisioning development environments without imposing on the personal space of your own laptop. Clone a repo from Github, run ‘vagrant up’ on the project directory, the Vagrant script installs and configures a VM for you, ‘vagrant ssh’ and there you are with a fresh, clean dev environment that can be reconfigured, reloaded and chucked away as often as you like. Joe is going to be writing more about this process soon.

So I decided, I would challenge myself to install the bare minimum of tooling to get up and running, with all the stuff specific to our current project residing in a virtual machine. This should also, in theory, make a nice solid base for general front-end development to current practices. And hopefully leave 400gb -odd of disc space to fill up with bad music and animated cat gifs.

The clock was ticking…

  1. Google Chrome – goes without saying really (3 mins)
  2. Node.js – nice and easy these days with a pre-packaged installer available for Mac, Windows and Linux (5 mins)
  3. Useful Node global modules – First trip into the terminal to ‘sudo npm install -g …’ for coffee-script, grunt, express, less, nodemon and jamjs. This is by no means an exhaustive list but gives me all the Node-based essentials to build and run projects. (5 mins)
  4. Xcode Command Line Tools – Rather than the enormous heft of all of Xcode, the command line tools are a relatively slimline 122mb and give you the bits you need (as a web rather than OS developer) to compile the source code of stuff like wget. An Apple developer account is needed for this so I can’t give a direct link, unfortunately. (15 mins)
  5. Git – Last time I did this I’m sure there was a fair amount of messing around but there is now an installer package for OS X (5 mins)
  6. Virtual Box – This is where we start getting in to the real time saving stuff. Virtual Box is a free VM platform which can be scripted, essential for the next part (10 mins)
  7. Vagrant – This is the key part, as explained in the introduction. Once Vagrant is up and running, a pre-configured dev environment can be there in just a few minutes (3 mins)
  8. Github ssh key config – Back to the command line. To be able to clone our project from its Github repo I had to remember how to do this, and the documentation on the Github site doesn’t have the best signposting. (5 mins)
  9. Clone repo and post-install tasks – Get the code down, then run ‘npm install’ and ‘jam install’ in the project directory to fetch server and client dependencies. Run ‘grunt && grunt watch’ to build CoffeeScript, Less and Jade source into application code and then watch for file changes. (2 mins)
  10. Vagrant up – With the repo cloned and ready, the ‘vagrant up’ command downloads the specified VM image and then boots it and installs the relevant software. In this case, Node and MongoDB. At a touch over 300mb to download (albeit a one-off if you use the same image on subsequent projects) this is the longest part of the whole process (20 mins).
  11. Vagrant ssh – Log into the new virtual machine, change to the /vagrant directory which mounts all your locally held app code, run ‘node app/app.js’. Hit Vagrant’s IP address in Chrome (see step 1) and you’re there (1 min).

So there we go. By my reckoning 74 mins from logging in to the laptop to being able to get back to productivity. And because the VM environment is identical to where I was on my old Mac I could literally carry on from my last Git commit. I did those steps above sequentially to time them, but at the same time was installing the Dropbox client for project assets and Sublime Text for something to code in.

Obviously on a new project you would have the added overhead of configuring and testing your Vagrant scripts, but this only has to be done once and then when your team scales everyone can get to parity in a few minutes rather than the hours it might once have taken.

Vagrant really is one of those tools you wish you’d known about (or that had existed) a long time ago and really feels like a step change for quick, painless and agile development. This is also the first project I’ve really used Grunt on, and its role in automation and making your coding life easier has already been widely celebrated. Hence the title of this post, because this feels like the first step in a general refresh of the way I do things and hopefully I’ll be writing more about this journey soon.

25
Jan
2013

Back in the sett

by Stephen Fulljames

Hello, I’m Stephen. I’m a front-end web developer, focusing these days mainly on Javascript and Node but with a wide range of experience in most of the technologies that make stuff look good in a web browser.

I’ve been working with Red Badger as a freelance collaborator on and off for almost two years, in fact since it was just Stu, David and Cain at the Ravensbourne incubator programme, but we’ve finally decided to make it official and I’m going to be joining the team here permanently.

Switching back to a full time role after a stint freelancing has been a tough decision, but the strength of the team and the technologies in use here make it an exciting place to be. With a background in interface development I’ve had exposure at the integration stage to the various languages – PHP, C#, Java, and so on – that make the pages I build actually work, without really gaining a deep understanding of them. However now I can write server-side code in Javascript as well, with Node, it feels like I can really build on my existing skills to do new and interesting things.

With other developers in the team adopting Node from the other direction, from their excellent C# and infrastructure experience, it feels like we can bring the client and server parts of web development closer together – whether in shared code, better build processes or improved performance. On the recent BBC Connected Studios pilot project, Joe, David and I were all able to contribute not only ideas but also implementation across the whole application. There are still some problems to solve and the best ways of working will settle down over time, but as a company we want to contribute to the community and share what we learn so there’ll be more blogging on these subjects in the near future.

Now if you’ll excuse me, I need to go and get used to being an employee again… 

12
Sep
2012

How to build and launch a rocket in one night

by Sari Griffiths

We recently launched a competition ‘Windows Azure Media Challenge’ with Fluxx. The prize is to win an event called RapidStart. In the 11th hour* before the competition was introduced, I was asked to make a flyer to support it. 

It ended up with a stop motion animated Lego rocket. And this is a blog about it. If you’re interested in the competition, take a look at Fluxx’s Paul Dawson’s blog.

Rocket

*It was 11th hour because I had forgotten that I had Paralympic tickets on the day I planned to work on this. My fault. 

What’s RapidStart?

It’s a few extremely intense days of creative workshop and rapid prototyping. We all gather, come up with loads of ideas, and produce something tangible by the end of the event. We provided UX/Design and Dev support for some of these events organised by Fluxx. 

It’s a bit of a whirlwind experience even for those of us who have taken party in a number of these events. New set of people, new set of problem solving and new set of challenges all the time. But it’s always a very creative and productive few days, and it’s fun. 

Rocket & launch pad

My task was to illustrate the nature of these events. Quick prototyping in the way everyone understands. I was trying to explain this to my husband (a graphic designer and not-very-techie), and I was talking about sketches, origamis and Lego.

Wouldn’t it be great to build something bigger with these bits? Something that starts things off. Something that launches stuff. Did you say launch? What about a rocket launch pad?

As it was a flyer accompanying the presentation, I had a vague idea of creating an animation as well as having a few static visual ready for the flyer. A Lego rocket launch pad was perfect for it. I could take photos to make a stop motion animation!

Luckily both Paul (Fluxx) and David (Red Badger) who were creating the presentation loved the idea and got a go ahead immediately.

A stop motion fun

I started the whole thing after my little boy (2.5 years old who was way too eager to help) went to bed. 

As I only had a night (and was quite keen on the idea of sleep), I did quite a bit of planning before I started. I wrote down a list of shots for single pages to be used in the presentation. I downloaded a video of Saturn V rocket launch and created a mock up version so that I knew exactly how many frames were required and the compositions of each frame. I worked out the order of these shots to be most efficient.

I hung a sheet of paper over the kitchen table to create a back drop. I set up a tripod with my not-so-brilliant SLR and a bunch of masking tape to keep everything steady. The lighting was not brilliant, but there was nothing much I could do. And luckily, it looked quite stylish when I took a test shot. I was ready to go.

First, I took a series of shots for the launch. Looking at the edited Saturn V video, I added some smoke using white and yellow pieces. Then took a series of shots for building the rocket and the launch pad – backwards. I was removing one piece per shot. 

Then took a few more shots for other uses to finish the photoshoot. Like a bunch of Lego pieces to represent little bits of ideas at the beginning of the event.

Rapid idea2

And lots of different ideas.

Rapid idea1

All images for animations were put together in Flash for the presentation. Not sure if it was the best solution, but it did a job. Phew!

And here is the final animation that I stitched together later in iMovie. (In the presentation, it was separated to building bit and launch bit.)

Rapid Start Rocket Build & Launch from Sari Griffiths on Vimeo.

It was good fun making this. And yes, I did get some sleep too!

9
Jul
2012

No red nor badger? – Red Badger branding process

by Sari Griffiths

You may have noticed that we’ve recently rebranded.
Here is a brief account of how we did it.

Why rebrand?

The previous Red Badger brand was created when the company was set up by Stu, Dave and Cain. It served us very well, but as we grew, we felt that it no longer represented us and our ambitions as accurately as it did. Also we all had our own ideas of what Red Badger was all about, but there was no simple way to describe them. Working on a new brand would help us see and express ourselves more clearly in a single(ish) voice.

Brand essence workshop

The first workshop we had was about defining a brand essence. It’s basically a few words that describe and sum up the brand. Coming up with the brand essence helps you to focus on what the business is all about.

For example:

  • BMW Ultimate Driving Machine
  • Coke Open Happiness
  • Disney Magical
  • Starbucks Rewarding Everyday Moments
  • Sony Digital Dream Kids

Okay, these are big brands. And we are not trying to be one. But there is a definite benefit in coming up with something like this.

To find one for us, we did a few things.

1. Personality questions – “What would Red Badger be if it’s…”

We sent a questionnaire around the office and to some of our clients to find out how we see ourselves, and how we’re seen. All questions started with “What would Red Badger be…” and asked things like “…if it’s a car?”, “…if it’s a person?” and “…if it’s an everyday object?”. It was fun and a very useful exercise to find out what everyone thinks of us.

2. Looking at Red and Badger

We started the branding exercise by saying “we might not have a badger in our logo, and we might not use red”, so it was important to look at the meaning of both words to see how relevant they could be to our brand. After all it’s our name.

3. Who are our competitors?

We printed out all potential competitors’ website – or the ones we thought were competitors – to see the space they occupy in the industry visually. By the time we got to this stage, we had a good idea who we were and realised most of them were actually not in our space.

At the end of good discussion, we settled with a set of keywords rather than having a snappy brand essence, and we got a tagline we all liked. (Thanks Stu!)

“Experience. Design. Technology. Crafted.”

Look & feel workshop

Having agreed a tagline and a set of keywords, we had another workshop looking at how these can visually manifest themselves.

As ‘craft’ was one of the central themes that connected many of our ideas, we kept coming back to the idea of a ‘workshop’ as a physical space – where we craft and experiment.

We looked at different visual styles for the new identity and fonts as well. As we were on the same page with our branding, this stage went pretty smoothly. Sketches and photographs are in. Furniture makers’ marks are in.

Now all the important thinking had been done. Let the fun of making begin…

The badger

We looked at the identity as we started looking at a new website. Initially we were looking at a more typographical approach – as is common in Furniture makers’ marks – but in the end we settled on our new Penguin-esq badger. We thought it was appropriate to have a character in the end, considering our clients sometimes refer to us as ‘badgers’.

The strong visual style allowed us to have more than one logo format.

We also like the idea of having a stamp made to show ‘badger approved’ quality.

The red

We concluded that if we were going to use any colour, it had to be red. It’d be a bit confusing otherwise, wouldn’t it? So the red is in. We picked a bit brighter red than in the previous logo.

What now?

We are in the middle of applying the new brand everywhere, including the website. In the true workshop spirit, we’ll keep working on it. And have some fun!

9
Jan
2012

2011- A Redrospective

by Cain Ullah

As we now roll full steam ahead into 2012 I thought I’d take the time to do a blog on Red Badger’s year in 2011.

The Beginnings

Red Badger was formed in May 2010 with Stuart Harris, David Wynne and I investing some of our savings into building a company based on specific ideals with a specific long term strategy in mind (this has evolved over the last 18 months). We wanted to be in full control of Red Badger’s destiny and as such decided not to seek investment of any kind. We also made an executive decision that we wanted to dedicate ourselves full-time to Red Badger so decided that we wouldn’t contract ourselves out to clients as individuals to fund the building of the company. This of course had it’s implications. We all quit our jobs and for the next year we would be working in each others homes, building up the company with no income whatsoever.

Into 2011

As we entered 2011, the company was nearly 7 months old and we were still just 3 guys working from each others homes. 2010 had largely been about creating a presence. We formed some key partnerships, pitched to potential clients and generally got ourselves out there. In October, we also started to design our twitter app, Birdsong for Windows Phone 7. By January 2011 we had two main channels of work – we had been working on a couple of large pitches (amongst others) for 2 very big clients and developing Birdsong. By 25th January v1.0 of Birdsong was available in Microsoft’s Marketplace.

Birdsong

At this time, Windows Phone 7 was in it’s infancy having only been released in November 2010 – having been involved in developing on the platform in its beta stages, we had every confidence in a bright WP7 future. However, we knew that Birdsong wasn’t going to contribute to building the foundations of Red Badger in monetary terms and in fact didn’t plan for Birdsong to be making large contributions to Red Badger revenue in the long term as only a small percentage of apps actually make companies a lot of money. Birdsong for us was all about building a Red Badger presence.

The first half of 2011 was an incredibly enjoyable time for Stuart and David being able to focus on developing Birdsong, shipping features in response to customer demand – part of this involved creating a good customer service platform through Zendesk. We also started to do the promotional work around it, engaging with Microsoft at an early stage. The Microsoft activity is on-going but you can read the Microsoft Case Study on-line.

We knew that Stu and Dave’s time on Birdsong was going to be short lived once client projects came through so we had to ensure it was architected really well (This is a given anyway) to allow for someone else to come in, learn the code-base and take over where Stu and Dave left off. By May and over 1,000 BDD specs later, Birdsong was doing pretty well – it was on v1.4, was the leading premium social app on the WP7 platform and had gained some notoriety among the WP7 consumer base and internally at Microsoft. It was achieving what we had set out for it.

We have ambitious plans for Birdsong, were aware that it still had a long way to go and was by no means perfect but were preparing ourselves to have to leave it for a while.

The Madness Begins

In parallel to developing Birdsong we had been working hard on a couple of pitches (amongst others) for 2 really big clients for quite some time (At time of writing neither project is live so we can’t talk about them yet which gives you an indication of their size). In April, we finally won both projects with both of them due to start just a few weeks apart in May and June.

All of a sudden, we needed to build two project teams of ample size and find an office to run them out of. We started plugging into our network of people we have worked with before. We knew they were very high quality but availability was an issue. Everything we do is Agile and built on a UCD approach so we needed integrated teams consisting of a PM, UX Consultants, Designers, Developers, UI Developers and Testers.

With a lot of hard work we somehow managed to assemble two teams with the right people to work on our projects – 90% of which we had worked with before (Which eases the worry of whether you’re getting quality or not).

At the same time, another startup – Fluxx was formed in April. They are a digital strategy company setup up by a number of our friends and former colleagues at Conchango. They had just found a lovely new office in St. Paul’s that would cater for their growth expectations over the next 2 years but at the time they had ample space spare. We were in discussions to partner with Fluxx as a development partner so it made sense for both companies that we would sublet a floor in their building for 6 months.

So, with project wins in place, a new office and a staff rota of the highest quality we secured a bank loan to get us off the ground with rent, buying furniture and equipment. We moved into our new office in May, raring to go.

The Projects

Both projects were very different but both incredibly challenging and innovative. One is an interactive 3D HTML5 website for a large automobile company with no dependency on Flash for modern browsers. The other is a large Government project that I can’t say anything more about. Both are mutli-platform with Web, Mobile and Cloud elements.

The first thing to do was to get the processes and systems in place through which we would run our projects – we now had clients in Germany so a cloud based infrastructure fitted perfectly (See: How The Cloud Underpins Red Badger’s Business) to allow for a remote but collaborative working environment. We also had to educate our clients in the way we approach and deliver projects.

In May, we kicked off our first project, meeting in Hamburg for 2 weeks for project planning and requirements development (Sprint 0). Once that project was underway we started the kick-off for the 2nd project.

It was a very interesting time, integrating two new teams from scratch, getting used to the new office and spending a lot of time flying between Munich, Cologne, Hamburg and London. Over the next few months we iteratively improved the processes of the projects and solidified our working relationships with both the clients and the Red Badger team internally.

Both of the projects have gone incredibly well and are both still on-going 7 months later.

The Intern Programme

With all of the above going on, it is easy to understand how difficult it had now become for us to focus any time on Birdsong development. This presented us with an issue as we have long term ambitions for Birdsong but it is very difficult to dedicate a resource to it that can be earning us up to £1,000 per day when Birdsong has only made us about £3,000 in a whole year. We decided to align Birdsong development with our plans for developing talented youth by using Birdsong as a training platform for our interns.

So, in June (Earlier than initially planned) we launched our intern programme. We advertised for a few months through our blog and a number of University job board sites. In all, we had 65 applicants for 1 position (admittedly some of these were students that seemed to be applying for everything regardless of position and relevancy of their skillset) so there was quite a lot of work to narrow these down to a final 8. We then set the final 8 a coding challenge, reviewed the code that they sent us and ended up interviewing 3. We finally offered Joe (an incredibly talented and self motivated student at Kings College) a part-time position due to start in November. (Joe’s Blog).

We have given Joe the responsibility of owning Birdsong development and support. We are investing in his long term future at Red Badger (we are investing our hopes on him joining us after graduation) so take a senior developer off of projects to pair programme with him when he is with us. This is costing us over £1,000 a week in developing both Joe and Birdsong but we think both are worth it. If we didn’t have Joe we simply couldn’t justify doing this just for Birdsong development.

Joe has now been with us for a month, has two weeks off to sit exams in the first two weeks of 2012 but is making fantastic progress. There is an incredible amount of code to familiarise himself with but he has almost completed the Trends functionality (a good feature to ease him into the dev) and will soon be able to start moving on to more pressing bits of functionality such as updating the Push Service (which we know is in need of some desperate attention). So hopefully, Birdsong users won’t have to wait too long for an update. Watch this space…

Growth, a new office and new project wins

As well as running our two main projects (delivering quality is our primary focus), the second half of 2011 has been about solidifying partnerships, trying to secure new business, and growth (which is dependent on an improving cash flow).

At the beginning of December we moved into a new office as we were growing out of the Fluxx space (at the same time Fluxx were getting big enough to grow into the space we vacated). With so much going on it is taking us some time to get the office in ship-shape but the interior designers have been in, we’ve got water supply/drainage fitted and now need to get the kitchen fitted and let the interior designer do his work. Hopefully it will be done within the next 6 weeks and working in a messy office will be no more.

An important part of our growth is to hire permanent staff so we have started converting some of our contractors to permanents and bringing in other new permanents into the team. Rachel has also joined as Client Services Director (blog) who is responsible for business development and marketing so this should give us the extra focus on new business that we need. We need more people across a varied skillset but finding the right quality (which is absolutely paramount to us) is difficult so that is one of the challenges we face. A nice problem to have.

As well as growing and moving into the new office we have also won new projects, most significantly with a major media corporation doing some innovative rapid prototyping using Node.js (See Steve’s Blog here). We are well shaped for 2012, with 3 large parallel projects and some smaller ones to fit in also. There’s lots of hard but fun work ahead of us.

Moving on to 2012

2011 was a year of transition. 2012 will very much be focussed on securing the future of Red Badger. We have had a great 2011 but it would be naive of us to think we are out of the woods entirely. We are still very young so our focus must be to grow steadily and sensibly and to win new innovative projects with both new clients and existing ones. The first 6 months of 2012 will be very interesting. In the 2nd half of 2012, if all goes to plan, we have some interesting product development plans to kick-off.

We of course will continue to develop Birdsong, hope to take Joe on for a year long full-time placement in June and may potentially bring in new interns/grads in the summer to bolster the Birdsong development team.

We also will be doing a re-branding exercise and overhauling our desperately out of date website. We just haven’t had the time to do it up to now so hoping to get something moving on that this month.

Exciting but challenging times.

Ravensbourne

I realise in this (now rather long) blog that I haven’t mentioned Ravensbourne College. Ravensbourne is an innovative, creative University on the Greenwich Peninsula in South East London. They offer great support services to their post-grads and an incubation programme (with the help of a European Development Fund grant) for startups in London. This acts as a stimulus for new entrepreneurship in London. In Jan 2011 we were accepted into the incubation programme which provided us with free facilities and meeting rooms as well as an opportunity to work with other incubatees that were based there. This very much provided us with a platform from which we could launch ourselves. Our first meetings with our clients were held there and our first projects were won there. So, our gratitude goes out to all at Ravensbourne, especially Chris Thompson (Who heads up the Ravensbourne Programme) and Carrie Wootten (Head of Enterprise and Innovation).

Finally

Happy New Year to you all. I hope 2012 is as good for you as I’m hoping it is for us. I have a good feeling about it.