Monochrome is a web application development company based in Epsom, Surrey and a Heroku partner.

We are looking for two experienced and enthusiastic Ruby on Rails developers to join the team towards the end of July. Permanent or contract/freelance.

Based in Epsom, Surrey and working alongside the Technical Director and the in-house development and design team, you will have responsibility for building web applications for our clients as well as supporting the development of our own suite of web apps. You will be working on some leading brand websites and web apps.

This is a great opportunity for somebody who wants to take on a lead Ruby on Rails role and play a pivotal role in delivering best practice solutions using the latest technologies.

In addition to high technical standards, we also expect team members to have good social and communication skills and be used to working well with a team and clients in an agile, flexible environment.

You must have experience with:

• Modern RESTful approach to Ruby on Rails development
• Using distributed version control systems as part of the daily development workflow (we use Git, but experience on any will do)

Experience in the following is a bonus:

• Development on OS X or Linux.
• Working in an agile, flexible environment.
• We test using RSpec/Cucumber with Behaviour Driven Development, but any test driven development experience will be considered
• Systems administration, deploying Rails on a variety of Linux based environments with tools such as Capistrano

Candidates should be fluent in Ruby and have a grounding in one or more of the following: PHP, Python or Java

A Computer Science degree wouldn’t go amiss either.

Permanent Salary: up to £40k (depending on skills and experience)
Contract/Freelance Rate: up to £350 / day (depending on skills and experience)

Applicants must have the right to reside and work in the UK.

Please contact jobs [ at ] monochrome.co.uk to apply.

AGENCIES NEED NOT APPLY: Monochrome does not work with recruiters.

After 12 years in the industry experience has always told us to adapt and modify strategies in your business in order to survive and thrive. Monochrome are not adverse to taking on new challenges and looking at the direction our industry is going in order to give the best service to our customers. Nothing could demonstrate this with such clarity as in the explosion in web applications requirements. We have always worked historically in application development using what we believe is the best tools for the job. Our expertise in this field has enabled us to work with Adobe and over the last 3 years with Microsoft which has given us a fantastic insight into the direction these business feel what are deemed Rich Internet Applications have been heading.

No one can deny that the explosion in the mobile application market has dominated the media of late Google, Apple, Adobe and Microsoft have all moved to embrace this space.

It is important to stress however that web application are making a name for themselves as important tools for both consumer and business alike. Monochrome for one have seen a massive increase in it requests for the design development and delivery of these applications.

Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility. Common web applications include webmail, online retail sales, online auctions,wikis and many other functions.

Another reasons organisations invest heavily in Web applications is to empower their employees and build an extended enterprise. Increased mobility means organisations have to think about providing employees easy access to corporate applications, regardless of their location. Greater workforce mobility, growing adoption of mobile technology for business use; and recent improvements in centralised visibility, management, and control of mobile costs, have rendered mobility an inexpensive and important strategic asset for many organisations.

Many companies are investing in web applications including

Amazon | BBC | Capgemini | BPN | Cisco | CNET | Electronic Arts | IBM | JP Morgan Chase| NASA | Oakley | Oracle | Siemens | ThoughtWorks | Yahoo!

The needs to deploy these application quickly and efficiently has meant picking a development environment that is efficient and cost effective, Ruby on Rails meets this requirement and a main reason why Monochrome have considered this a significant area of expansion for it’s business. With our experience in UI design and our Agile approach to working on projects, Ruby on Rails has been a perfect marriage for our business.

It’s success has been proven in the work we have done with our client Premier Foods and Great Little Ideas a case study that demonstrates how Monochrome can help reduce costs through choosing tools that significantly reduce development times and allow your business to have confidence in the way budgets are being spent.

We have some interesting announcements to make over the next few weeks so keep checking on what we are up to. Please feel free to follow us on Twitter or if you have a requirement get in touch by phone or through our website.

Quite often in the office we will end up having a conversation about some particular company, that does something on a massive scale, and has a relevance to either technology or some sort of large scale logistics (which is something that most of us find pretty fascinating). Usually these are brought up while we’re brainstorming on a particular problem for a client, and inevitably end up with a comment such as ’I wonder how xxx does it?"

In our ideal world, these companies would let us come into the lair and effectively have a guided tour. It’s only so we can have a poke around based on a genuine interest and find out more about how these people work…

So, we decided to formalise this into a list, and let everyone know who we thought had interesting stuff to show:

The Google Datacenters

Google has a massive number of servers, and probably more than anyone else out there. So how do they look after it all? How do they keep these things in trim and functioning correctly? How do they do it on the scale they do?

Amazon shipping

Amazon ship a massive amount of goods. And what’s more, you can buy almost anything and have it shipped from Amazon in a matter of days. So how do they manage this? What systems are in place that mean they stocks coming in, and going out the right people at the right times?

Heroku

Heroku are our hosting company of choice for all of our Ruby on Rails development. We love them as we don’t have to worry about simple things like servers, networking or hardware leaving us to focus on spending all of our time on the product. At time of writing, Heroku are hosting 115,000 applications, so how is this done? What processes manage it and make sure everything is working as it should? How does it manage scale?

Fedex

Fedex move a massive amount of boxes around the world, sometimes in under a day, so how? How do they get millions of parcels, every day, from point A to point B, reliably and on time?

Tesco

Tesco’s essentially these days feeds Britain, which is a lot of food. So how do they make sure that all the stores are stocked on time, especially considering the short shelf life of some products.

Amazon Datacenters

Amazon do hosting on a massive scale. Everyone now seems to be using Amazon S3 for storage, so how does Amazon manage this. For every byte uploaded to S3, Amazon will need to have four or five to store it, and its backups. This is additional to all the disks that are failing on a near constant basis, as well as the growth that needs to be managed.

Ideally, we’ll now get an email from everyone listed above offering us all an all expenses paid trip to see them for the weekend. If not, we can only wonder.

Over the weekend, we had one of our flagship sites, greatlittleideas.com be subjected to a TV advertising campaign laid on by the site owner Premier Foods. This consisted of three days of advertising over a weekend across a range of different ads and channels ranging from 10 to 20 seconds in length.

Now, initially this doesn’t sound too scary, except that we were seeing projections that were predicting thousands of users visiting the website as a result of these ads. What’s more, they were all going to arrive at the same time which meant that we had to think about handling massive peaks in traffic.

The results were fascinating and the site stayed solid as a rock, but there were a lot of lessons that we learnt that are all described below. But first, here are some stats:

Normal traffic for the site is in the 20-40 requests per minute range throughout the day. The site is Rails 3, running against PostgreSQL and using Memcached for some fragment caching. More importantly this site is hosted on Heroku, the EC2 based rack hosting start-up that’s just been bought by SalesForce.com. Behind all of this we were monitoring the stack with New Relic’s RPM.

During the TV advertising we saw peaks in the 5600 requests per minute ballpark (an 18000% increase in traffic) but no downtime. This, for us, was massive load over normal, and one that required a little babysitting to ensure that users were always given fast and responsive pages. At no time did we want users to be waiting for a page to load. For us the site had to maintain it’s fast, snappy pace.

So, what did we learn through this weekend? Well, quite a lot of things:

Your URL is irrelevant

One surprising thing we noticed is the proportion of people came to the site from search engines. Given that the adverts in question were advertising the website, and emblazoned a massive URL across the screen using the most obvious URL format possible (greatlittleideas.com), two thirds of the traffic came to the site via search engines such as Google having searched for the term ‘Great Little Ideas’. What’s more, this is a 93% increase in the amount of traffic that usually comes via this source, which tells us that TV advertising is good at getting a brand into peoples’ heads, but not any particular details (like a URL).

People come, and come straight away

The most fascinating thing for us was the immediacy of TV advertising. From an advert going out, we would see a traffic peak within two or three minutes. This suggests that people, when they see something interesting on the TV, will immediately hit the web looking for the site, and this will continue. At peak times, we were seeing the site go from 50-60 requests per minute to over 4000 within 120 seconds of an ad, quite simply an astounding traffic increase that lots of traditional platforms would have trouble handling.

Another thing that we found surprising, was the long tail of traffic we would get after an ad was shown. For instance, we were expecting a sharp spike of traffic that dropped off when people went back to watching whatever it is they were watching. However, we found after any ad that you could easily expect an hour or two of elevated traffic which had to be accounted for.

It just goes to show that whatever your predictions of human behaviour are, they’re most likely wrong.

TV Advertising is not predictable

One thing we did have in our arsenal prior to the advertising was a timetable of what ads were going out when, and on what channels. This meant we were roughly able to predict when the peaks would be and to what extent. For instance, a 20 second ad at prime time on a Sunday was worth five or six ads placed during a soap on a Friday early afternoon. However, one thing we found was that the TV companies don’t always stick to the timetable. Some ads were going out an hour late, some weren’t showing at all, and some were showing at such random times that we don’t know who showed what, when. One thing we do know though is that prime time is simply massive in terms of gathering engaged users.

If you need to place one ad, that’s the time to do it.

TV Regions are not one and the same

In the UK, ITV has different output for the different regions of the UK. Normally this is only an advertising difference, but sometimes the programming will change too. At one point we had an ad due to go out across six or seven regions simultaneously. On time, the ad went out and we started receiving some additional traffic. However, I didn’t see the ad in my local region which was puzzling me somewhat. An hour later we saw the ad and traffic went up massively, double the previous peak.

After thinking about it and looking at the stats it turned out ITV London put the ad out an hour late, but also generated twice the traffic of the other regions put together.

So lesson learnt, TV Regions yield very different results.

Having ‘infinite’ capacity is awesome

As mentioned earlier, we host all our our larger Rails stuff on Heroku, the EC2 based rack hosting start-up that’s just been bought by SalesForce.com. One of the reasons for this is the way that the hosting works from a scaling point of view.

Using Heroku, we are able to take our available resources from the equivalent of one physical server, to over a hundred with a simple console command, and those new servers are up and provisioned within a couple of seconds.

This is a massively handy tool to have when dealing with the sort of peaks that TV brings, and not something that is practical using traditional hosting methods.

For instance, at peak we were running on 45 dynos (roughly equivalent to 12 physical servers). Had we wanted to host this using our own physical hardware, we would have been looking at purchasing around £20,000 worth of hardware, the associated rack and installation costs, plus the bandwidth required – all to serve a 10 minute peak.

With Heroku we were able to do this with very little outlay (sub $5) and no additional costs or lead time to worry about. Having seen Heroku under load, I estimate that if needed, we could scale to around 1000 requests a second on Heroku with no application changes required.

Performance tuning for the most part isn’t worth it

A lot of developers will spend ages wringing every bit of performance out of an application, trying to shave off 10ms here, 50ms there, getting the page as fast as possible.

We found that given the scalability of Heroku, this isn’t really worth it. It’s a lot simpler to increase capacity for the short term, than spend ages tweaking the code.

However, this only applies to peaky style traffic. If you’re sustaining high load, performance improvements will certainly help you reduce your hosting bill, but not really make any difference in the eyes of the user as they won’t be able to notice such small improvements.

New Relic RPM is a must-have tool for hosting Rails applications.

New Relic RPM is a tool that we use for monitoring the performance of our Rails applications. It tells us all sorts of statistics regarding throughput, response time, and breaks the requests down to the different layers and components of the application in question. Without RPM you’re effectively flying blind, not really knowing where the bottlenecks might be or how much traffic you’re pushing out.

However, in the rapid peaks scenario we were experiencing, we found a shortfall of the product which is the latency between receiving the traffic, and it showing in RPM (around a minute or so).

Normally this wasn’t an issue, but a couple of times we had a queue of users to deal with as we hadn’t provisioned sufficient horsepower to process the requests. Only once RPM reported the load could we react. To get round this we added the Heroku queue depth to our source so we could hit the website in real time, assessing the response time, but also seeing the state of the queue.

Saying this though, RPM is a must-have tool, whether you’re hosting large or small.

In Summary

So, all in all hosting a website through such substantial peaks is an interesting experience, but also one that’s perfectly achievable if you put a little thought into the basics: What tool are you going to build in? What method of hosting are you going to use? What metrics do you have to try and predict the numbers you’ll be seeing? How accurate are these?

However, this style of hosting is very different to that which is a website with sustained high traffic. For this sort of environment you’ll need to focus more on performance, cost, and reliability, but that’s probably another post for another time.

Around 6 to 7 years ago, User Experience (UX) was a term a lot of marketers weren’t aware of or familiar with and those that did often viewed UX as an afterthought.

We might be guilty of stating the obvious, but Apple have been the leader in changing the way we consider a users experience. UX is now at the forefront in terms of the way we plan and manage application projects, and this is a growing trend across the industry, especially within in the last 2-3 years.

Software vendors have taken their time to invest in this area when creating solutions. However, market leaders such as Salesforce.com have proven that the return on investment is there to justify additional user experience design and testing. Microsoft invested heavily in UX when creating Zune, their MP3 platform, and is considered by many reviewers to have a superior interface to its obvious competitor. Unfortunately, this is not nearly enough to draw attention away from the market leader, Apple. Who would have thought Microsoft would become a follower? They were so used to being in front that they forgot to look at what was behind them…..a topic for another time perhaps.

I believe the recent surge of attention to UX has been driven by the availability of good user research and UX specialists available in the UK. We are, after all, a world leader in design. Neither discipline was readily available a few years ago, but with significant growth within the telecoms and digital markets, designers have focused their attention on expanding their user experience knowledge which in turn means agencies can now recruit the right resource. This means that you, the customer, has an application that meets user expectation, creating both brand and customer loyalty.

Fairly often, we at Monochrome come across ‘search engine optimisers’. These people are there to provide a service to companies that sits somewhere between the technical, the marketing, and the design.

Essentially the brief is simple. Take a website (either at concept stages, or already live) and tweak it so that when a user is looking for a relevant term on one of the major search engines, the site in question will appear near the top of the organic search results.

There’s a number of tried and tested ways of doing this, plus a wide variety of old wives tales that some people believe make a difference. However, search engine optimisation is fairly simple and straightforward, and not something that a lot of people need spend a lot of time on. Once you’ve got the basics in place you’re pretty much good to go, as long as you keep your standards up and keep doing what the search engines like you to be doing.

However, one thing that is becoming more and more apparent is the quality of these services that other people provide and the approach that is taken. From the various optimisation companies that I have come across, the vast majority follow a standard path. This will initially consist of the running of some sort of tool that spits out graphs and tables of how your site might be performing on some varying measures (which might or might not be relevant), and they then chuck all this into a standard document that get’s sent to the client.

You’ll always get the standard fare – Meta tags, page rank, canonical URLs, H1 tags etc etc etc.  You’ll also find that most of the data is already available to you via tools such as Google’s Webmaster Tools.

Now, this initial work could cost thousands depending on the agency and site in mind (bigger client, bigger bucks), but ultimately the work required isn’t drastically different. SEO is SEO.

What comes next is the monthly cost that the vast majority charge – for instance, charging to tend to the garden of keywords that you might be targeting, or ensuring your markup is up to par. Other than that, it’s pretty much rinse and repeat.

So, why do companies blindly pay this money out? Essentially you’re paying the vast majority of SEO’s to cut and paste into a word document, and provide you with a few snazzy graphs.  You’re then paying well over the odds for a couple of hours of maintenance.  If developers charged the same amount, we’d all be laughed out of the room.

The biggest problem is the charging model.  Every SEO company I’ve ever met charge via the standard mechanism.  However, their benefit to the site varies, so why do we not have these companies charge by results?

You engage with an SEO in order to raise the profile of your site and achieve some other objective – increase traffic, increase leads, increase conversions, raise brand awareness.  You have ideas on how much you want to achieve your objective by – page views up by 25%, conversions up by 10%.  Therefore, why do we pay SEO’s regardless?  Surely we should only pay these people if they achieve what we wanted and to a satisfactory level? After all, you wouldn’t pay a interior decorator if he only painted half a room, would you.

So – search engine optimisers – do yourself a favour.  Find out WHY the client wants to talk to you,  WHAT they want to achieve and WHAT sort of budget they might have to try and do this.  Only once you do this will you truly be able to add a worthwhile service to your client that they will be happy to pay for again and again.

Taken from :neil_middleton

Every single day, we find ourselves as an agency, telling people what our day rate is. In most cases, for people, this is a race to the bottom, the challenge of finding the cheapest development shop out there to get a certain piece of work done. People often believe that if someone is charging £500/day, whilst someone else is charging £600/day then the cheaper option is the best one and will save them a shed load of money. Well, funnily enough, it’s not that simple. For instance, let’s imagine for a minute that you don’t care what technology your idea is built in, you just send out some tenders. Two come back – a Java shop with a day rate of £400, and a Rails shop with a day rate of £750. The Java shop is an offshore setup, with unlimited developers to throw at your job, promising a quick turnaround. The other, the Rails shop, is local, and has a really nice portfolio (but still costs nearly twice the price). You’d love to employ them but you just can’t afford that rate so you plump for the cheaper option.

Six months later, you’re broke. You’ve just spent twenty grand on some Java work but it’s not finished, and you’ve got no way of moving forwards as you’ve got no more money. However, looking on the bright side, you know that you’ve not sunk nearly forty grand into the same project with the other company.

Except you’re wrong.

What you failed to realise is that everything you’ve assumed in the pricing of your job is incorrect. You’ve assumed quality is a constant, i.e. that the number of bugs is consistent between different agencies, and that performance is identical. You’ve also made a even more fundamentally bad assumption, and that is that a developer only achieves a certain amount in a certain amount of time.

They don’t.

Take the above example. Rails is a much more productive tool to use for web development than Java, and a Rails developer could reasonably expect to outperform a Java developer by as much as 100%. Add into this that Rails developers tend to unit test much more so than others it all starts to add up.

So, you go back to the Rails shop.

“Oh yes, we could have turned that project around in 22 days, which would cost you £16,500″

You slowly, and quietly, start to cry.

The moral of the story is this – day rates, for development work, are irrelevant. You, as a customer, don’t want to buy time from a development house. You want a development house to produce you a ‘thing’, whatever that ‘thing’ might be – and you want to know how much it costs. It doesn’t matter how much a day of developer might cost you. What matters is how much can be achieved and what level of quality might be achieved.

So, next time you’re out there looking for a development house for your next project, ignore day rate – it’s irrelevant. (And remember, we use Rails)