The League of Extraordinary Developers

Keep your requests thin

Fri, 06 Jan 2012 05:14:25 GMT

Keep your requests thin

When creating websites or web apps we give due care and attention to making sure pages load fast enough. We minimise our CSS, JS and compress images as much as reasonable to make sure page load times are kept to a minimum. How often though do we think about the impact of what's going on during a server response? Sometimes it can be a simple contact form submission which sends an email, sometimes it can be way more complex making large DB updates, image processing and calls to external APIs. These tasks need to be done, but do they need to be done there and then, or can they be off-loaded?

Image Processing Example

If we look at the simple example of a user uploading an profile image for some new fancy social site. The image probably needs to be processed into different sizes for later use. The thing to consider is if it's actually important that the processing happens right at that very second, during the postback process, or if it can be done via a background task. Does the user really need to wait while the postback completes processing the image into 4 or more different sizes? In reality they don't and so a task like this should be done in the background. Sure the postback needs to handle the file upload and the user has to expect to wait for that, but nothing more than this.

Bulk emails Example

In Incentive Maker, when a user creates a new game for their team the code sends out individual emails to each game player, to inform them of the new game. Depending on the size of the team playing the game this can be a large number of emails. It's important that this part of the game creation process doesn't slow anything up, so the email sending is done as a background task. This speeds up the process dramatically as the postback isn't waiting for a successfully sent message for each email. If an email fails to be sent the background task will attempt to send the email again.

External APIs

As more and more of the things we build are reliant on external API's we really do need to give more thought to off-loading the work done by a request to a background job. Sure there will be times where this can't be done as it's an important part of the process, but something like posting a message on a users Facebook page, or sending out a Tweet etc then it can be done separately.

A benefit of off-loading is that the user doesn't receive an "something went" wrong error message. So for example if Twitter is having a few issues, there is often no benefit to stopping the user on our site in their tracks and saying, "hey, Twitter is broken, please try again later". Move the Twitter api work into the background and let the user move on, oblivious to what's going on with the Twitter API. The background job can attempt to hit the Twitter API later if necessary.

Background job does not mean delaying things

Just because a task gets moved to the background, it doesn't necessarily get done later, it can be done asynchronously once registered. It just means those longer tasks are not holding up our users as they use our website or web app.

What should be done as a Background job

That's completely up to the developer. Sure, some stuff just has to be done as part of the request, but there is always parts that can be done separately. So basically, if the next part of the app is reliant on the tasks within the current request, then leave it there, if not, consider moving it into a Background job, and let the user have a better experience.

Storing a Product Catalog for eCommerce with a Document Database

Mon, 21 Nov 2011 03:00:40 GMT

Storing a Product Catalog for eCommerce with a Document Database

We have recently started developing our own eCommerce system that we hope to role out over a number of up coming projects. In the past we have always used things like Spree and Magento, but we have always had niggling issues with other systems, such as very complex DB structures.

Our overriding goal is to create a flexible system, that we can extend as we need for different projects. This blog post aims to cover our initial thoughts on how we are handling the modelling of the product data.

The first hurdle has been in deciding how to store the potentially very different types of product data. Clearly there are some common fields like name, sku, price but once you get further down modelling the details of different items, the data structure can look very different.

Modelling options with a RDBMS

In a RDBMS setup we really have the following modelling options for Products.

Entity Attribute Value (EAV)
Single Table Inheritence
Class Table Inheritance
Generic Columns
Serializing data into a blob

EAV

EAV is the technique used by solutions such as Magento. It offers a huge amount of flexibility, however if you've every looked at the DB structure of a EAV solution you'll know it soon gets very complex. On top of the complex schema, any queries to get data to the front end are also very complex, not to mention the issue of lack of database integrity.

Single Table Inheritance

Single Table Inheritance is pretty much a no-no in anyone's book. Once you start to have any more than a couple of types of products you end up with a pretty wide table full of NULL fields. Once again database integrity goes out of the window.

Class Table Inheritance

Table Inheritance is where you have your common data in a 'Product' table and then any variations are stored in separate tables such as 'FilmDVD' and 'MusicCD' tables. It would work pretty well for this, except for certain things like search queries. Sure querying on commons product fields is easy, and searching for results on a specific product type field is easy (e.g. search for all books by an author), however searching across different product types on a specific field is more hassle.

Generic Fields

Using generic fields is really not a neat solution at all. It means throwing data type enforcement out of the window, which is not something we're keen on. You can't apply indexes either, which will become an issue later.

Serializing data into a blog

The final option is to serialize all the non-common fields into a blob field. This option is pretty much pointless. It's basically trying to force the RDBMS into being a Document Database, except you get none of the benefits of using a Document Database. For example searching the data directly in the database and indexing just are not possible.

Modelling with a Document Database

Having already worked with MongoDB in the past for Incentive Maker, we knew it could give us the flexibility required for modelling product data. For example, in Incentive Maker all the generated games are all stored as different types of Game objects, which makes it easy for us to write code to search for specific details about the games, even though they don't all share the same data structure. We'll explain this a bit more below. The same principles of differing games can be applied to differing products. As stated earlier we know we have some common fields, but after that products can have all sorts of varying fields. MongoDB handles this flexible schema well though.

Before fully deciding on the MongoDB path, we did a little bit of a search and found this excellent presentation on using MongoDB for ecommerce. We'd definitely recommend you add this to your current reading list.

N.B. To help us model our data in Ruby on Rails we are using MongoMapper.

To model the common Product fields we have a class


class LedCommerce::Product
  include MongoMapper::Document

  key :sku, String, required: true, unique: true
  key :title, String, required: true

  key :description, String, required: true

  key :pricing, LedCommerce::Price, required: true

end

Each product type that we need inherits from the base Product object e.g. for film DVDs we'd have


class FilmDVD &lt; LedCommerce::Product

  key :directors, Array, required: true
  key :writers, Array, required: true
  key :actors, Array, required: true
  key :studio, String, required: true

  ...
end

and for music CDs we'd have


class MusicCD &lt; LedCommerce::Product
  key :band, String, required: true
  key :label, String, required: true

  ...

end

Although we have two different documents here, they are both stored as Product documents in our database


{
  [
    {
      _type: "FilmDVD",
      sku: "Film101",
      title: "Our Film DVD",
      description: "This is our stored film DVD",
      pricing: "1.99",
      directors: ["A Person", "A Nother"],
      writers: ["A Person", "A Nother"],
      actors: ["A Person", "A Nother"],
      studio: "TheLED",
      rating: 5
    },
    {
      _type: "MusicCD",
      sku: "Music101",
      title: "Our Music CD",
      description: "This is our stored music CD",
      pricing: "0.99",
      band: "The band",
      label: "The band's label"
    }
  ]
}

So basically whenever we have to work with a new product type, we just need the object to inherit from our Product object. This modelling really starts to show it's strength when we start to query the database. Note the complete lack of crazy joins etc when doing these queries that you'd get when modelling data with a RDBMS.

These examples are once again using MongoMapper.

Find all products


LedCommerce::Product.all

Find all music CD's


MusicCD.all

Find a single product by sku

This query applies to any of the base Product object properties. There are a couple of ways we can look for a product with a specific sku. Firstly we can search for a specific product type, like a MusicCD.


MusicCD.find_by_sku('Music101')

Or we can search more generically


LedCommerce::Product.find_by_sku('Music101')

In either case we will get the same object back.

Search a product for a specific key/value

We can also do queries like search for products from specific labels. Again notice how we can search on any field even from the base Product document.


LedCommerce::Product.find(:all, label: "The band's label")

Conclusion

As you can see from the above, Document Databases, such as MongoDB, are especially good at handling these kind of flexible database schema's very well.

As we get further down the line of building our new ecommerce software, we'll blog more on how we've used MongoDB. We've still got a lot of decisions to make, such as how to handle transactions effectively.

At the moment our code isn't open source. We may well change that as we get more of the project done, once we are happy with the core elements of our code.

Success for Incentive Maker - Hull Digital Post

Fri, 08 Jul 2011 02:17:07 GMT

Success for Incentive Maker - Hull Digital Post

We were very kindly invited by Jon Moss to do a guest post for the Hull Digital website to talk about Incentive Maker. We jumped at the opportunity and decided to talk about our experience of using "The cloud" to build a cost effective, scalable product.

If you are interested in reading about the development story of Incentive Maker so far, please view the post - http://hulldigital.co.uk/success-for-incentive-maker

SASS, Compass and some clarity

Thu, 16 Jun 2011 03:52:36 GMT

SASS, Compass and some clarity

Having recently read HOW TO: Get Started With the COMPASS CSS Framework, I realised there is still a lot of confusion about SASS and Compass and why developers should be using them. The Mashable article is very brief and the comments below it highlight show some of the confusion surrounding the tools.

My issue with the article is that it really talks about SASS and not Compass, it doesn't even show one example of the CSS3 features and it doesn't explain the separation between the two and the benefits of using them.

Hopefully in this post I want to try and clear up what SASS is, what Compass is, and why, as a developer, you should let them into your life. This post won't go into detail about each tool, but will hopefully just give you enough of a push to investigate further. The post will also try and deal with some of the common misconceptions I've heard and read from other developers.

What is SASS

SASS is simply an extension to existing CSS features. Some of the main features include:

Variables
Mixins
Nesting
Selector Inheritance

Some of features are so useful that they are being proposed to the CSS Working Group - CSSOM, Vars, Mixins, Nesting, and Modules.

Other useful features include:

Control Directives (if, for, each, while)
Colour operators
Colour functions (incredibly useful for tweaking your colour palette)

Some developers originally ignored SASS because it used a different syntax to CSS, but a while ago this all changed with the release of the SCSS format. SCSS uses the exact same formatting as standard CSS, so if you can write CSS, you can write SCSS.

SASS isn't the only tool that extends the capability of CSS, however once you add in the power of Compass it should be clear why developers should be choosing SASS above the other tools.

What is Compass

Compass is an open source CSS authoring framework that makes a developer's life much easier.

If you want a simpler way to maintain your grid layouts, an easier way to remember all the variations in CSS3 syntax, and a way to reuse lots of standard CSS patterns quickly, then Compass is for you.

Compass is built on top of SASS, so you get all the benefits of SASS as well.

At it's most simplistic level, Compass provides a huge amount of mixins that developers can use of to reduce the maintenance of their CSS.

Some of the main features of Compass include:

Cross browser CSS3 mixins (stop trying to remember all those CSS3 browser variations)
Common typography patterns
Common styling patterns
Built in spriting capabilities
Blueprint module

Compass also has a number of plugins that can be added to the core features to give you even more to simplify your CSS. Some of the plugins are listed here, however doing a quick search on github will reveal quite a few more.

Misconceptions

"But I don't want to use Rails"

This is a pretty common argument for not using SASS or Compass. Yes, SASS and Compass rely on Ruby, but you don't have to be using Ruby on Rails to use them. They are completely stand-alone tools and I've even used them when developing simple static pages. The only thing you do need is Ruby, as they are Ruby gems. The download page of the SASS site explains how to do that.

"But I don't want to install Ruby on my server"

Don't then. Yes, you do need Ruby on your development machine, but that's as far as you need to go. SASS compiles down to bog standard CSS so all you actually need to put onto your server is the generated CSS files.

"I don't like SASS, I prefer LESS"

In the Mashable article, one of the comments compares LESS and Compass. They are two completely different things. Sure compare LESS and SASS, but LESS and Compass are not comparable.

"But I can write proper CSS from scratch, I don't need something to do that for me"

As web developers we can all do that, but the point is that SASS and Compass offer us a way of writing more manageable code. I can guarantee you that when using these tools, you will be writing less code, changes will be quicker and easier, and therefore cheaper.

Additional reading

This blog post deliberately doesn't show many code examples, as there is just too much to cover. If you want to see some more specific examples, here are some useful references.

Finishing up

So in short, SASS and Compass are here to make CSS creation and maintenance simpler and quicker, leaving you with time to do other things to make your sites even better.

This post doesn't even scratch the surface of the capabilities of SASS and Compass, but hopefully it explains what they are and gives you a hint as to why you be using them as part of your development stack.

The big question is do you want to be maintaining code that looks like this?


.box-shadow-example div {
  width: 40px;
  height: 40px;
  background: #eeeeee;
  margin: 20px;
  float: left;
}
 
#box-shadow-default {
  -moz-box-shadow: 0px 0px 5px #333333;
  -webkit-box-shadow: 0px 0px 5px #333333;
  -o-box-shadow: 0px 0px 5px #333333;
  box-shadow: 0px 0px 5px #333333;
}
 
#box-shadow-custom {
  -moz-box-shadow: red 2px 2px 10px;
  -webkit-box-shadow: red 2px 2px 10px;
  -o-box-shadow: red 2px 2px 10px;
  box-shadow: red 2px 2px 10px;
}
 
#box-shadow-custom-multiple {
  -moz-box-shadow: rgba(0, 0, 255, 0.4) 0 0 25px, rgba(0, 128, 0, 0.2) 0 0 3px 1px inset;
  -webkit-box-shadow: rgba(0, 0, 255, 0.4) 0 0 25px, rgba(0, 128, 0, 0.2) 0 0 3px 1px inset;
  -o-box-shadow: rgba(0, 0, 255, 0.4) 0 0 25px, rgba(0, 128, 0, 0.2) 0 0 3px 1px inset;
  box-shadow: rgba(0, 0, 255, 0.4) 0 0 25px, rgba(0, 128, 0, 0.2) 0 0 3px 1px inset;
}

Or like this?


@import "compass/css3";
 
.box-shadow-example div {
  width: 40px;
  height: 40px;
  background: #eeeeee;
  margin: 20px;
  float: left; }
 
// Default single box shadow
#box-shadow-default {
  @include single-box-shadow; }
 
// Box shadow with custom settings
#box-shadow-custom {
  @include box-shadow(red 2px 2px 10px); }
 
#box-shadow-custom-multiple {
  @include box-shadow(rgba(blue, 0.4) 0 0 25px, rgba(green, 0.2) 0 0 3px 1px inset); }

The League of Extraordinary Developers : Year One

Fri, 01 Apr 2011 05:28:10 GMT

The League of Extraordinary Developers : Year One

A year ago today, The League of Extraordinary Developers officially opened it's doors. I thought I'd take this opportunity to write a personal blog post to talk about how things have gone in year one, and to thank a few people for helping year one to be a success.

I guess that last statement gives the game away a bit, but yes, I do count year one as a success. Don't get me wrong, it's not been perfect, there's still a very long way to go, but in general I'm happy with how things are going.

The Beginning: The Whys and Hows

Previous to setting up The League, I had worked for several marketing agencies around the country. Some big and some small. I've always enjoyed the marketing side of things, and taking the time to understand "the bigger picture" (urgh) when it comes to the work I've been involved in. I don't think sitting in the corner of an IT department tapping away on my keyboard has ever been for me. I think if I did that, I would definitely suffer from that "Sunday night feeling" that people seem to talk about. By the way if you do suffer from that "Sunday night feeling" you're in the wrong job. You spend a high percentage of your life working, you may as well do something you enjoy.

So I guess you're wondering why I set The League up if I've always enjoyed my past jobs so much, and that's a fair point. Well the reason is simple - control, and no I'm not a control freak, I just wanted to take control of my life and my career more. I have a young family, and I wanted work to fit around my family, not the other way around. On top of this, the area of the UK that I live in doesn't exactly thrive with opportunities for Senior Web Developers, so I decided to create my own opportunity.

There was one other major driving force for me. It's something that has bugged me for a long time. As a developer I've spent hours upon hours writing code for other people and producing websites / applications for them. What have I got at the end of each project? A nice thank you and a monthly wage. Now that's not a bad thing, but as developers we really are missing out. We are the ones with the tools in our hands and heads to create things for ourselves and yet so often we choose not too. We don't take the opportunity that is right there in front of us. Sure this isn't for everyone, but for me personally it was really starting to bug me. Don't get me wrong, there are aspects to the service industry that I like, however I hate being solely reliant on client work. Being solely reliant on traditional client work is not a good thing. Clients come and go, we need other streams of income.

I've heard plenty of people always say "There's a book inside everyone", well I'm a firm believer that there is a product idea inside every developer. Even if your idea isn't that great do it anyway, and force yourself to learn something new to create the idea with. Stop relying on the safety nets all the time.

That's my little rant about developers and their use of their skills overs. I promise to not mention it again, well, not in this blog post anyway.

So that's the "whys" over with, here come the "hows".

No I don't have a secret formula, there are books you can buy for that. Each day I'm learning new things about running a business, building a client base etc etc. I'm just going to mention how I got things going. The answer is simple really, slowly. There was no rush. The important thing was to do things right, and rushing things would make that a lot harder.

Year one objectives

I remember attending the first ever Hull Digital Live in 2009, and whilst the event as a whole was really good, there were a couple of talks that really stood out for me. One was about working Noded, by Jaan Orvet, and the other talk was entitled "Time to Start Up" by Mike Butcher. In his talk Mike said something that has stuck with me. "Consult, consult, product". By the end of HDLive09 I knew I wanted to run a Noded web development business, and as part of that business I wanted to build products.

To build products The League needed capital, this meant that the objectives for year one were simple. To build a solid client base that could provide regular work. Fortunately having worked with a few marketing agencies in my time, and built up a good list of contacts I was able to put the idea of The League to my contacts. Most liked the idea and The League has been able to win a varied range of projects. Unfortunately there are many we are not allowed to talk about, due to NDA's!

Some highs

Working with Nodes has been a fantastic experience. I've had the opportunity to work with some really talented developers and it's been great building up a reliable network of developers that I can rely on to get work done, and done well.

What I'm most proud of, is that for several clients The League has become the first port of call for when they need extra resource. We've even had several referrals, which is always nice.

At the beginning of this year, we received a very nice email from a client, with this glowing report in.

The League has certainly provided a very valuable and reliable service over the last year so I am certain we'll be working with you guys whenever we have the chance. I've outsourced to lots of places with mixed success but the level of professional consistency you guys have provided is a credit to your team.

Some lows

The worst part of running your own business is all the admin side of things. Each bit of admin eats into time that could be spent being productive. This is the one area of the business that I would love to improve upon, as I feel too much time is wasted. However, I doubt there is a lot that can be done about it, so it's just something we'll have to put up with.

Some thank yous

I'd like to take this opporunity to thank two groups of people.

Firstly, the clients that have used The League in our first year, without you we'd not have been able to pay the bills.

Secondly, the Nodes that have worked for The League and helped to grow the reputation of the business. So here is a big thanks to Adam, Andrew, Ashley, Darren and Hamilton and I look forwards to working with you guys even more in the second year of The League.

Plans for year two

The big push for this year, is to get several products developed and launched.

Slightly ahead of schedule The League launched its first product at the beginning of this year, called Incentive Maker. Incentive Maker is a online game based employee incentive application that we hope to get into sales teams and call centres. Of course it can be used by any company wanting to incentivise their work force. For this product we have partnered up with Wildfire Advertising.

The plan is for The League to increase it's product portfolio in year two, and we are already working in partnership with Experience Internet to build a recruitment system, that we hope will change peoples' opinions on how recruitment within the IT sector should be done. We hope to release more details about this product in the near future.

Final word

Year one has been really rewarding and setting up The League is the best thing I've done so far in my career. If you are thinking about setting up your own business this year, then I wish you all the best, and I hope it's as good for you as it has been for me.

A Client, a Sales Team, Incentives and the development of a Commercial Application

Tue, 01 Feb 2011 03:53:58 GMT

A Client, a Sales Team, Incentives and the development of a Commercial Application

It's been a while since our last blog post, so we figured it was time to let the world know what we've been up to and why.

Where it all began

About six months ago, Wildfire Advertising, spoke to us about one of their clients who wanted an online quiz game to help as part of a sales incentive. The initial idea was to create a quiz that the individual sales people could enter based on the number of products they had sold. The more they sold, the more time they got in the quiz.

Towards the end of our initial discussions with the Wildfire team, we realised that this quiz could not only used with this one particular client, but with several other Wildfire clients. In the past, Wildfire have run quite a few sales incentives for their clients, but the majority of these have always been one-off print based solutions.

With this in mind we started to think about how we could create a more flexible quiz system that could be easily re-skinned and changed appropriately for each individual client.

By the time we had our next meeting with the Wildfire team, we have a fairly good idea of how we were going to go about creating a solution. In this second meeting, we talked to Wildfire about their previous experience with sales incentives. The more we talked, the more both parties realised we could take this project a larger step forwards and we could build a incentive games system for use by pretty much anyone looking to make their incentive schemes more fun and interesting.

The Wildfire team mentioned figures to us like:

up to 48% increase in employee performance (Source: HR Management Magazine).
96% of employees think that 'incentive games are fun'.
only 45% of the employees who participate in an "ordinary" incentive programmes are happy with those.
tangible rewards (like cash, gift vouchers, holidays and additional days off work) increased performance by 26%, compared with just a 13% increase in performance for incentives that solely used non tangible rewards, like a points based system (The Incentive Research Foundation).

With data like this we knew that if we could create an online incentive application that there had to be a market for it.

After a short amount of investigation by ourselves and Wildfire, we realised there was a general lack of good, online based employee incentive applications out there. We had hit on a real world problem that needed a solution.

Early steps and investigations

Having agreed we were going to build an online employee incentive application for use by anyone needing to incentivise their sales teams, call centre staff, or any other groups of employees, we started to look at the technology side of the project. Two key words came to mind, flexible (to client requirements) and scalable (we didn't have a clue regarding the numbers of users of this system).

For the initial part of the development of the project, we concentrated hard on creating a solid core system. Our main aim was to create something that did a lot of the basics, like user management and permissions, team management, and basic game functionality, such as leaderboards and reward handling. Last, but certainly not least, the other area of development was the creation of a plugin architecture for all the different types of games that we were planning to build on an ongoing basis.

The majority of the functionality was developed and tested very quickly, but the game plugin system underwent a few rewrites to get it to a stage we were happy with. We now have a system where we can plugin games very quickly. We have initially concentrated on grid based games, with the plan to move into other types in the near future. Each of the grid based games is customisable with different numbers of squares and rewards. The games also have individually designed emails to give each game a unique feel.

The scalability of the project was actually fairly easy to handle. We decided upon using Heroku for the hosting of the application and MongoHQ for hosting the database. Heroku is a really good hosting solution for applications like this. It comes with a number of really useful tools, such as New Relic for profiling, Hoptoad for error collection, but most importantly it provides us with the ability to add more power at the flick of a switch. As the application grows and the number of users grows, using a mixture of profiling and adding more power, we will be able to keep the application stable.

Naming the product

Wildfire and ourselves didn't decide on a name for the product until about half way into the development stage. In the end the Wildfire team came up with Incentive Maker with a number of advertising concepts for it. We all instantly felt that Incentive Maker would be a strong brand name.

Next steps

We officially announced Incentive Maker a few weeks ago, with the idea of getting a few clients to do private Beta testing of the Incentive Maker. The initial feedback has been great. The majority of the feedback has been in regards to additional functionality. We've also had some great feedback in terms of how to improve the usability of specific areas such as game creation, and points awarding.

We've taken on board all the client feedback and spent time improving Incentive Maker. We feel the product is even stronger for this period of private Beta testing.

We are hoping to officially launch Incentive Maker in the next few weeks. We are in the process of putting together a website to replace the existing holding page, with far more information about Incentive Maker.

jQuery Mobile SASS Alpha 2 released

Fri, 12 Nov 2010 03:53:15 GMT

jQuery Mobile SASS Alpha 2 released

jQuery Mobile Alpha 2 has just been released and thanks to Eric Fields our SASS version of the CSS has been updated also. Eric has also taken our first initial release and improved upon it considerably, so huge thanks to him.

Each area of the SASS has now been separated out into separate partials. This makes it easier to style the individual components. For example if you want to style the dialog, you only have to work/think within the scope of the _dialog.scss.

If you want to contribute to the project please feel free to fork away and submit pull requests.

http://github.com/pollingj/jQuery-Mobile-SASS

jQuery Mobile CSS to SASS conversion - Trying to make theme creation simpler

Tue, 19 Oct 2010 07:45:10 GMT

jQuery Mobile CSS to SASS conversion - Trying to make theme creation simpler

Following the release of the jQuery Mobile framework we decided to have a serious look at it for all our future mobile web projects. The main area that grabbed our attention with this particular mobile framework was the graceful degradation of the code to those less capable devices.

Having looked at the theme side of things, we decided to start converting the CSS to SASS to make our life easier to theme future mobile sites and applications. So far we have not done a huge amount of work on the conversion. The main work so far has been around simplifying and separating out the theme swatches CSS rules. We have also implemented, where possible, a number of Compass CSS3 functions.

The next steps are to try convert more of the non-theme related CSS rules to make more use of SASS and Compass.

As the framework is only in Alpha release stage, we have decided to not completely rewrite the CSS to make use of nesting and other useful SASS functionality. When the jQuery developers firm up the CSS implementation, we'll then look how we can make full use of SASS and Compass.

Please feel free to fork away and submit pull requests. We want to make this project simplify the process of creating themes for everyone using the jQuery Mobile framework.

http://github.com/pollingj/jQuery-Mobile-SASS

What makes a good web development company

Fri, 17 Sep 2010 03:46:29 GMT

What makes a good web development company

The world of web development is still very much misunderstood. We've even heard people call it a "dark art". So when you need help turning your ideas and designs into a high quality website or web application, how do you know who you can trust to get this done?

The purpose of this post is to provide some key points on what makes a good web development company, and will help you understand the kind of questions you should be asking development companies.

This is going to be a very opinionated post and we make no apologies for it. If you disagree with anything we are certainly open to discussing it further.

Now to get on with the post. Below are the key areas we are going to be looking at, and what you should be looking for in a web development company.

Able to do both front-end and back-end development
Don't specialise in one back-end technology
Should follow best practices
Understanding of marketing strategies surrounding the projects
Invests time in research and development
Has a rigorous testing process, including automated tests
Flexible to change
Use source control

Able to do both front-end and back-end development

We don't subscribe to idea of developers that do front-end development and developers that do back-end development. That's the equivalent of having a plumber who only fits pipes and leaves the fitting of the baths, showers, sinks and toilets to someone else.

We agree there is a separation between web developers and web designers, there's a completely different thought process going on there, but the separation between front-end and back-end is just wrong. To be a good web developer you need to understand the full development cycle and to be able to get involved in the project from start to finish. There is also much to be learnt from the working with the varying technologies, but we'll come on to that.

Don't specialise in one back-end technology

There are a number of good back-end technologies that are appropriate for web development including Ruby on Rails, ASP.Net and PHP (and others). They all have their strengths and weaknesses and not one is perfect. A good web development company should be flexible in which technologies they use, so that they use the most appropriate one for their clients' needs.

The key reason we have spent time learning a number of technologies is to able to pick and choose the bits we like. Over the years the developers involved in The League have been able to take the good parts of each technology and formulate a number of best practices and use them across all platforms.

Should follow best practices

The key to being a good web developer is not the technologies that you use, but the best practices that you follow. As technologies come and go in our very fast moving industry those best practices will remain, or at least evolve. As a developer if you have a good grounding then you can move with the times and technologies fairly easily.

So what are these best practices that we are talking about. Below are some of the key ones we follow.

Writing semantic HTML
Follow web standards for all front end coding
Automated testing of both front-end and back-end code
Use of a MVC framework

Understanding of marketing strategies surrounding the projects

We've heard this complaint many times that web developers don't think about the marketing strategy of a project. This is generally because developers don't care. Well they should. How can they advise clients and think about helping clients produce the right solution, if they aren't thinking about the "bigger picture" (sorry, we know it's a horrid phrase, we'll go wash our mouths out now). If a developer blindly does the work, they are not offering the client a service, they are just being a meat puppet.

The most important question a developer can ask is "Why?". Take time to understand the client's requirements fully, and advise them, after all the client doesn't understand the ins and outs of web development, you do. Make the development cycle a two way conversation.

Invests time in research and development

As everyone knows the web industry is a very fast moving industry. Things come and go in the blink of an eye. A good web development company gives it's developers allocated time each week to look at new trends and technologies. Admittedly some of these trends and technologies are dead ends, but you won't know unless you look into them.

If you want to know if a web development company knows there stuff, simply ask them what their developers have been looking into recently. You don't have to understand everything you are told, note them down though and look them up on the internet to understand if the company are looking at new trends or not.

R&D is probably the most important time each week for a developer. If developers don't evolve, the solutions they build will become stagnate and dated very quickly. As a client do you want an out of date solution before you even start?

Has a rigorous testing process, including automated tests

Too often we have seen the client is the tester for a project. If this is happening, then, to put it bluntly, the development company don't understand your project well enough, they are just "banging out" code.

A good web development company should be writing automated tests (integration tests, unit-tests etc) for all their code, both front-end and back-end. On a simple level, tests help developers to concentrate on the code they are writing at that given time, they also help developers to write more concise code. More concise code means the code base is easier to understand and cheaper to maintain.

The major benefit of a test suite to a client is that when changes are made to the code in the project there can be a lot more confidence in the fact that the change, or new code, hasn't broken anything else.

We are not saying automated testing is the silver bullet of web development, and tests are only effective if they are written well, but they certainly should be part of any web developers toolset.

Automated tests aren't the only important aspect of testing. The web development company should also have a level of human testing as well, and this is certainly something clients should be involved in. User stories are key to this process. As part of the development process, clients should work with the web development company to put together User stories, so that all parties involved understand how users will interact with the site or application and the results of those interactions.

Flexible to change

We've all heard developers complaining how their clients' change the requirements of a project midway thought a project. Developers need to stop complaining about this, it happens to us all and it's never going to change. A good web development company should have processes in place to cope with change. If you are a client, ask how change requests will be handled.

Web developers should work to short release cycles, preferably 1 - 2 weeks. The worst thing that can happen to a project is that the developers get the brief, start the work and then 2 months later they announce it's finished, only for the client to say "This isn't what I asked for!". By working to short release cycles, clients can be involved at all stages. At the end of each release the client should review the project so far and submit any change requests.

Use source control

Our final recommendation is a pretty obvious and simple one, to most people, but we still speak to developers who don't use any form of source control. This seems more prevalent with freelancers as they don't see the need as they are the only ones working on the code. If that's how they see it, then they are missing the point.

There are lots of reasons why all code should be source controlled. We're are only going to mention a couple of key points here. Firstly it's a great way of keeping a log of changes made to code. (As long as developers put a comment into the commit). Secondly and most importantly is allows developers to change code without the fear of losing already work already done. This is especially useful when trying out other possible coding solutions to a problem.

...and finally

This isn't meant as a comprehensive list of everything that makes a good web development company, but really meant to act as a pointer to some key aspects that people should be looking for. There are many other factors, such as the ability to communicate in plain English.

If you have any thoughts or questions, please contact us or even ask us on twitter.

Are the days of full service marketing agencies coming to an end?

Tue, 07 Sep 2010 09:25:51 GMT

Are the days of full service marketing agencies coming to an end?

Since we setup The League we have spoken to a great deal of specialised agencies, such as User Experience Agencies, Web Design Agencies, with no serious back-end developers, Web Development Agencies, PR Agencies etc, etc. What does this mean for those agencies (you know the ones) that offer everything under the sun - "Web Design, Graphic Design, Multimedia, PR, SEO, Social Media, Marketing etc" ?

When we setup The League we always planned to only handle web development and we specifically advertise ourselves as a Web Development Agency. We have no facility for design and we never will. Our skills are purely in development and we do not want to dilute ourselves to cover more and more bases. This does not mean we don't understand how design or marketing works and we always take the time to understand the concepts behind the projects we embark on, we just stick to what we know.

A number of our team have worked in full service marketing agencies in the past and have seen the problems first hand for these types of agencies. In this day and age of hugely diverse forms of marketing it seems no longer possible to offer everything to clients under one roof. There is not only the issue of keeping knowledge up to date, there are also the cost implications of running teams of highly talented individuals.

For us the point at which this strategy of offering everything falls down, is when the sales and account handling teams talking to the clients simply do not understand all aspects of marketing. They maybe exceptionally good at understanding how to use Social Media to strengthen a brand, but their knowledge of marketing a brand with different forms of print may well be minimal, and thus the client cannot be getting the best marketing strategy out of the agency.

What about those clients who simply need a new web strategy? There is simply no need for them to go to a full service agency, and it's just not cost effective as full service agencies often demand more money for their time as they will have larger overheads.

Don't brands need these one stop agencies though?

The problem with all these smaller specialised agencies is that brands will always need someone with the full marketing strategy across all the different forms of media. A solution to this maybe that companies start to follow the broadcasting model, where a producer is hired to create the marketing strategy and it is their responsibility to pull together teams of specialists to produce the various forms of marketing required.

We believe that using more specialised teams and individuals will provide brands with better solution, but we would say that wouldn't we!

We'd really love to hear your thoughts on this. Please let us know if you think we are way off the mark, or if we have struck a chord with you on our facebook page.