So as day one closed we were ready to get our heads down into hacking some code and try to produce something we could release.  We broke up the responsibilities for UX, creative and technical tasks to the relevant roles.  As I mentioned in day one we had chosen a technical set that was mostly familiar.

A problem did arise in the fact we had decided to go with Backbone.js and Marionette, not a problem with the framework itself but the fact we were not so familiar with its inner workings.  I have to say that it wasn’t the best choice to go down with for the event i.e. a single page application route using a technology we had little experience with at the time.  

It was challenging but we did make some great progress in the morning.  Authentication was up and running with Facebook along with the ability to post content.  Haro did some sterling work in getting MapBox integrated into the application to display hotel details in around the Las Vegas area.  The hotel data itself was to be added manually (I had collated the hotel details the night before in a Google Spreadsheet) but obviously this wasn’t the most ideal solution but for now it would suffice.

As lunchtime came about we decided to get the team together and go to the local pub for some well deserved fish and chips.  After a few pints and a bit of banter with team we got back to it and continued hammering out as much as we could.  Sari got her magic wand out and managed to come up with some branding in no time at all, working with Samera the UX was also really taking shape.

All in all were coming to the end of the afternoon and it was apparent as much as we tried we were not going to get a completed application out of the door this time.  This was mainly due to trying to create a one page application with new technologies as previously mentioned.  I would safely predict that if we had gone down a standard web application with the technologies we have used many many times before in projects we may have got it out of the door.  Having said that we now have good knowledge of Backbone.js and Marionette to allow us to judge when or when not to use it in future projects.

The event itself to me was a success and I have mostly gotten what I wanted to really jump start the application to get something delivered.  The biggest downside I had after the event was losing the vision of delivering a true Minimum Viable Product.  This is something I need to work on for future events and any ideas I want to deliver in the future, “it’s all about delivery” and at the moment the phrase “close but no cigar” comes to mind.  

It really rams home what / why people say single member teams rarely succeed due to not ever ending up shipping their products.  An example of integrating yelp! really steered me off track and I have ended up adding more features that I could of left out to deliver grazr earlier.

 What I need to do right now is literally get the last bits of functionality delivered and delivered fast, I am in what I would call a “lingering phase” and if left to linger too long grazr will rot away.  It needs to be out there for the world to see, it is the worst position to be in as I can’t even say “I tried and failed” as no users have even tried the product at the moment it is just that “I tried”.

I intend to follow this up next week with the launch of grazr, and hopefully some statistics on what happens with users I send it out too.

If you are interested in one page applications the guys over at airbnb are doing some very interesting things with Backbone.js to allow client and server side rendering of templates for single page applications (see blog post here).

The full technology stack we ended up using was as follows:

• Node.js
• Backbone.js
• Marionette
• MongoDB
• Heroku
• Jade Templates
• Grunt
• LESS
• Bootstrap

Watch this space (no really I mean it)…. 

At Red Badger there has been a significant transition to open source technologies which are better suited to rapid prototyping and highly scalable solutions. The largest area of growth for us as a company is in Node.js development, there are a number of active Node projects, some of which are now in production.

Node.js has gained enormous traction since its inception in 2009, yet it is still an immature technology (although maturing rapidly) therefore ‘best practices’ in the context of Node do not really exist yet. Initially, we did not have the streamlined Continuous Integration and deployment process we were used to from the .NET development world, so we began to look for a solution.

The Tools

Historically, we made constant use of JetBrains TeamCity as a CI server on our .NET projects. TeamCity is an excellent solution for these types of projects, which we would wholeheartedly recommend. However, it was hosted and maintained by us, running on a cloud instance of Windows Server 2008. It was both a heavyweight solution for our now much simpler requirements (no lengthly compile step!) and also not ideal for building and testing Node.js and other open source technologies which run much better in Linux based environments.

In searching for a new solution, we considered:

• Jenkins – a well established, powerful and complex Java based CI server
   
• Travis CI – Extremely popular in open source, particularly among the Ruby community. Travis CI is a lightweight hosted build server which typically only works on public GitHub repositories, although this is changing with its paid service, Travis Pro
   
• Concrete – an extremely minimal open source CI server we found on GitHub, written in CoffeeScript by @ryankee

[gist]https://gist.github.com/4606090[/gist]

 

[gist]https://gist.github.com/4633276[/gist]

[gist]https://gist.github.com/4606129[/gist]

Q: What do our 3 favorite open source projects (node, redis and nginx) have in common?  Apart from being uber-cool?

A: They are all single threaded.  

But aren’t they all really fast and highly scalable?  Yep.  So how does that work?

Nginx, redis and node are all event-based.  They have an event loop that will listen for an event saying that an asynchronous operation (IO) has completed and then execute the callback that was registered when the async operation started.  Rinse, then repeat.  It never waits for anything, which means that the single thread can go hell-for-leather just running code.  Which makes it really fast.

In days gone by, when we were Microsoft slaves, we used to wrestle with multithreading as a way of dividing up work.  In web apps every request started a new thread.  We’d also use the Task Parallel Library (TPL) which was not an easy abstraction.  And combine that with some event processing library like Reactive Extensions (Rx).  Now you’re asking for a lot of trouble.  The new await keyword in C# helps out alot, but either way you have to think about thread safety all the time.  And all kinds of locking strategies to deal with concurrent access to the same data.  And even with all that, it isn’t as fast.

The difference between the two worlds lies in the way that pieces of work are orchestrated.

Event-based applications divide work up using callbacks, an event loop and a queue.  The unit of work, or task, is a callback.  Simple.  Only one callback is ever executing at a time.  There are no locking issues.  You can write code like you’re the only kid on the block.  You decide when you’re done and then effectively yield control to someone else.  Everyone is really polite so it just works.

Thread-based applications essentially divide work up in hardware.  Because each piece of work has its own thread, and will block if it needs to (like when it’s waiting for IO), the CPU will suspend that thread and start running another that is waiting.  Every time that happens there is quite a hefty context  switch, including moving about 2MB of data around.  In effect the hardware decides when to yield control and you don’t get much of a say.

Who’d have thought that a single thread, dealing with everything, could be faster than multiple threads each dealing with just one thing?  Well, on a single core, that may be true.  On multiple cores it actually may also be true.  That’s because you’ve probably got nginx and node and redis all running on the same machine – simplistically, on a quad core, that’s one core each and still one left over

But isn’t writing synchronous code for a multithreaded environment a lot easier than writing asynchronous code for a single threaded environment?  Well, maybe, a little.  But some great patterns have emerged within the node community that really help.  

The simplest continuation-passing style (CPS) is the callback.  Which actually is not at all hard when you get used to it.  And it happens to be a great way to encapsulate and really easy to modularise.  The pattern for async functions is that the last argument is always the callback, and the pattern for callbacks is that errors are always the first argument (with results after that).  This standardisation makes composition really easy.

There are a ton of npm modules that can often help reduce complexity.  The best, in my opinion, is still Caolan’s async.  It’s still the most popular and follows the node conventions.  And there are also a few CPS compilers that allow you to code in a more synchronous style.  I wouldn’t have recommended these in the past, but there are a few, such as tamejs and Iced CoffeeScript, that use an “await, defer” pattern that is quite nice.  We’re using CoffeeScript more and more these days, and this “icing” is very tempting (seeing as we’re compiling anyway), but we haven’t strayed that way yet.

We’ve been writing big apps in node since October 2011 and have learnt a lot about how to separate concerns and modularise our code.  It’s a lot different to the object-oriented class-based separation we were used to, but after your head is reprogrammed to use a functional style it becomes second nature and actually much easier to structure.  Caolan’s post on programming style for node sums it up nicely.  If you hear anyone say that node is no good for big projects, tell them that all you have to do is follow a few simple rules and then it becomes perfect.  And fast.

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… 

Here at our (currently) sunny workshop in Clerkenwell, myself and the fellow badgers have being busy carefully crafting this, the new red-badger.com 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

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.

Nginx

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.

Node.js

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.

WordPress

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 http://responsive.is/red-badger.com 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 red-badger.com website.  Feel free to comment with any thoughts about the site or even the technology stack we decided upon.

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 bbc.co.uk.

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.