Unboxed latest

Rails performance tuning is often a matter of SQL tuning but we recently stumbled upon code involving a named scope that caused more SQL to run than expected.

We were looking at an SQL trace in New Relic RPM for one of our apps when Nige and myself noticed what appeared to be duplicate SQL. The query was a monster (a monster in this case being a beast of over 20ft in height and over 2 seconds in length) so having it run twice was pretty ruinous even with fragment caching in use. To identify the cause, we used the query reviewer plugin which is fantastic and enables you to see the SQL being run for an individual page request in the browser window. As well as identifying inefficient SQL, it also shows at what point in the code SQL is fired.

The apparent duplicate SQL was running from a partial where there was a products variable set to a named scope. The partial contained:

At first glance it looks innocuous as products.first is meant as an alternative to products[0]. If products was an array the two statements would be equivalent but in this example, first is a named scope. It is chained together with the the named scope defined by products and has the affect of adding LIMIT 1 to the executed SQL since products is yet to be populated. When products[1..2] runs, the same SQL is executed without the LIMIT 1.

To ensure that the SQL runs once, we used products[0] instead of products.first. By calling products[0], the named scope is populated and subsequent calls including a call to first does not result in any SQL.

Lying awake in bed last night I was thinking why IT organisations find it difficult to implement Agile techniques. My initial thoughts were that the business owners are always pushing back on it and not seeing the benefits. Why are IT organisations always trying to lead the business to implement good practices? The more I rationalised the more I started to think that I was actually wrong and that in many instances the business is in advance of IT with its approach. I thought back to projects I had worked on and business departments that I had managed.

Consider this for a moment. Would businesses implement a new business process using a big bang approach or would they do this in a more Agile manner? I have worked in an operational role in two companies; in both cases we moved existing business processes to an external party. This was when we wanted a cheaper option for processing. Rather than move the existing process in a wholesale fashion we reviewed the process to identify what would make sense to move in the first instance, to prove that the changes would work. We implemented the part of the process that we were sure about and then monitored it. After an agreed, timeboxed period of time (of a month), we reviewed what had worked, what needed to change and what we should do next. We then implemented our changes and additions to the process. We did not have a product backlog but we certainly knew where we wanted to get to and updated our approach as we went along. Also, we held meetings to review how the process was working and what was beneficial. We did not call these meetings ‘Retrospectives’ but we certainly used the meetings to revise the approach we were taking. We also learned from the amount of time that the first implementation had taken and revised our estimates for the next implementation. All of this was done in a very informal manner, without detailed documentation defined up-front. We were being Agile because that makes most sense, although we didn’t have a name for it.

There is another everyday occurrence of another technique that is associated with Agile. If you walk along any High Street in the morning take a look into the windows of the estate agents that you pass you will see scrums of estate agents discussing the progress they made yesterday and the plans for the day ahead. I am sure that similar activities take place in other sales teams, but this example is very visible to us all. They may not call these meetings scrums and they may not have a scrum master but the discussion shows the fundamental attributes of an Agile technique.

What can we learn from this? IT organisations are very good at formalising techniques and detailing how they should take place. We, as IT organisations, should recognise this. We should also recognise that the business works in a far more informal manner to us, however they do have a good understanding of how to make things work – and this is by using what we call Agile. Therefore IT organisations should change their approaches and rather than trying to sell Agile to the business as something new and different to how they currently operate, we should identify the areas that where they are already using something akin to Agile and bring it to their attention. They will then see the real benefits of adopting a similar approach to the development of their IT solutions.

At Unboxed we are continuously checking the latest tools which enhance Rails application development.

Being a front-end specialist I am always keen on different approaches which make front-end development easier and more enjoyable. In recent years, the science of CSS and the need for semantic XHTML has become much more complex but the CSS specifications don't provide enough for large projects.

The problem

CSS is the language for everyone, and therefore does not provide some of the key features of programming languages used in large teams/on complex projects which help quick and bug free development, such as constants and expressions. CSS is great, but after a small time working on large projects, you quickly learn its limitations. CSS files can easily become bloated and hard to maintain unless extreme care is taken.

The solution

One of the best things about being a Ruby/Rails developer is that you are part of a community which never rests. Every day someone comes up with better tools to enhance web development. "Extending" CSS through a pre-compiler really is not a new concept. If you've worked with CSS and pre-compilers before you've probably come across SASS ('Syntactically Awesome Stylesheets') which is meant to serve the purposes mentioned above.

SASS really is a great tool, but its syntax differs so much from the original CSS that it is unfamiliar and results in a high learning curve for new developers.

There is a new kid on the block. Less, created by Alexis Sellier, is a new attempt at a CSS pre-compiler. Less allows you to do the same as SASS and more importantly its syntax resembles CSS, which you are already familiar with, making it exceptionally easy to pick up.

Less is exactly what CSS would be if it was a programming language. It extends CSS with constants, mixins, operations and nested rules adding a big boost to your CSS development. It provides constants to define widely used values which you can re-use. Making global changes across your style definitions becomes a matter of changing one line of code. It's saving us from a lot of headaches!

@brand_color: #4D926F;

#header {
  color: @brand_color;
}

h2 {
  color: @brand_color;
}

You can also apply the same philosophy to whole classes using mixins to embed all properties to another ones. That is quite handy if you are applying behavioural definitions to multiple elements.

.rounded_corners {
  -moz-border-radius: 8px;
  -webkit-border-radius: 8px;
  border-radius: 8px;
}

#header {
  .rounded_corners;
}

#footer {
  .rounded_corners;
}

Adding expressions into the mixture makes Less even more fun. Expressions come in handy if certain elements in your stylesheet are proportional to others allowing you to deal with complex relationships between properties. You can add, subtract, divide and multiply different values:

@the-border: 1px;
@base-color: #111;

#header {
  color: @base-color * 3;
  border-left: @the-border;
  border-right: @the-border * 2;
}

#footer { 
  color: (@base-color + #111) * 1.5; 
}

Less is also really great at code maintainability. Rather than constructing long selector names to specify inheritance, in Less you can simply nest selectors inside other ones. This makes inheritance clear and style sheets shorter and well-constructed.

#header {
  color: red;
  a {
    font-weight: bold;
    text-decoration: none;
  }
}

Less is under heavy development and there is also a Rails plugin for it which automatically parses your applications .less files through Less and outputs CSS files.

Head over to github and start experimenting with it. At Unboxed we've already started making some changes to Less to reduce its dependencies and made it more robust when included in an application. You can check out our changes to Less on our github account.

As you can probably see now it is really a great tool and makes CSS development a piece of cake in Ruby/Rails applications. One small caveat, though; Less won't deal with your IE6 problems. You still have to sort them out yourself.

I have to confess I have played team sports all my life, especially football with a somewhat unlikely claim to fame of having played the game in Papua New Guinea and watched by the country’s Prime Minister! I have some experience of playing at different levels of the game and in hindsight can conclude that the sum of the individual skills of the players is not as important as team morale, a team plan and an ability to adapt to different situations quickly and effectively. Not a striking revelation I hear you say, but how does it apply to software development and delivery?

Let’s start with the obvious. Both football (feel free to insert any competitive team sport you like at this point) and software delivery share certain characteristics; both have goals (one literally), the result is paramount-requiring a team to deliver, and that team has to be well managed and adaptable to succeed. Both have constraints and these are both formal - the rules of the “game”- which in sport is easy to see (e.g. only the goalkeeper can handle the ball within a confined area), and in software delivery this might be start and end dates, total costs, minimal acceptable functionality etc, but generally are formally laid out and are considered as read and common to all participants. The fun starts when you look at the informal rules and see how successful football managers use them to differentiate themselves and deliver a quality result.

This is where the WAGS come in (Wives and Girlfriends). A new manager (Fabio Capello) has taken over the England national team and has not, by and large, changed the players but has achieved an unbeaten run in competitive matches, which is leading to the team goal (to win the World Cup in July 2010). What he has done is to introduce a series of systems the team play to, created confidence (through belief in the system and the results achieved), and brought in clear leadership and discipline. E.g. WAGs’ are not allowed in the team hotel before the match and must always be in the background. To bring it back to the software delivery analogy - they do not contribute to the immediate result and therefore can be put to one side!

Having cleared up the WAG mystery I want to move onto Dutch “total” football. In the 1970’s the Dutch were credited with revolutionising the game and what they did, in effect, was to change their approach to the informal rules. Cruyff (world footballer of the year) attributed this to the willingness of all to question and improve (in agile we use retrospectives to achieve the same result). Fundamentally they chose team strength over individual ability and each player took responsibility to make the team effective. They did this because they wanted to lift the informal constraints every team played by - which was each player had a specific role which he performed in a very particular area of the field. The Dutch decided that, as everyone has sufficient skills (confidence in one another) they could freely interchange roles and positions – hence the term “total’ football. The agile approach also embraces this liberation by having as few roles as possible and playing a system, which allows the team to adapt incredibly quickly to changing circumstances.

At Unboxed we have taken the same approach as Capello and the Dutch. Everyone at Unboxed is keen to understand our clients' needs and constraints, and we're driven to deliver the right results. We are confident in our Agile system, and we have a proven track record to show it works. We recognize the importance of good team management, and our players are a bright, multi-skilled folk with a strong delivery mentality, and the confidence to succeed.

We’ve been lucky enough to be one of the sponsors of the Young Rewired State event that took place across the 22nd and 23rd August in London. It’s an innovative event that encourages governments and young people to get together and explore the way they approach software development and make information available to citizens through public facing websites in new ways.

There are three reasons why we decided to get involved in sponsoring this Rewired State event, an organisation that James Darling, a Rails developer that works with us, gives his spare time to.

Firstly, Unboxed Consulting has a long-held belief that there are some not-so-good, out-of-date and, frankly, idiotic IT practices that remain in use today. In our past lives several of us have worked for large organisations and found ourselves needing to argue and cajole for the basics of good IT practice to be put in place. No names mentioned but why does a large financial institution need to be convinced that their 30 testers plugging away at manually executed test scripts month after month is a waste of money? How can a software company working for a multinational customer not have revision control or unit tests? Why does one of the world's leading application frameworks costing millions not come with a comprehensive unit test suite, or deployment scripts? Why did a global company get to the end of a long development programme only to find that no-one had budgeted for the production environment, let alone ordered, installed, configured and tested it?

I could go on for hours, quoting examples of programmes of development work costing millions of pounds "finishing" without being tested against non-functional requirements. Needless to say, all these organisations have reams of documentation, PIDs, PIGs, plans, RAGs, PMOs and other TLAs. To address this, we have conceived the idea of an IT Boot Camp. Somewhere where fresh graduates can go and be immersed in good practice, wholesome, modern, hands on experience of doing things properly. We want them to emerge understanding Scrum, XP, ITIL having defined, built, tested, and put live an application that works and can be maintained, several iterations of it, in 8 weeks. Keep an eye out for more on this in the future. James Darling's concept of getting 15-18 year olds starting to learn about these modern techniques gives us hope for the future of large organisations.

Which brings us onto our second reason why we love the Rewired State concept, government projects generally fall into the category of "large". How does one deliver a large project? Go to a large System Integrator, if you can find one who isn't too busy defending their last project in court. Call me a cynic, but I have been to the High Court asking for a 9 figure sum back, "please, because you only delivered paperwork, not working software". We are on the Supply2.gov.uk distribution list and see tenders going out that we know we will do a better job of delivering than a large integrator. We know we will do it better, cheaper and faster but we have stopped applying for this work because it is too onerous a process to go through. We only have 20 people in the company and we can't afford for them to be filling in tender documents week after week when we know we won't qualify. Here's an example: 65% weighting of the selection was on ability. Turn to that section and there are two blocks to detail work done for the department and nothing else. So you can only work for that department if you have worked for them before? Surely that hasn't always been the case? What about our ability to deliver successfully to FTSE 100 companies? What about the fact that we had delivered two very similar projects already? What about the the government's pledge to support small business? That message has not yet filtered down to the procurement departments. Our hope is that one day the OGC will put an Agile methodology alongside Prince 2. For now Rewired State is doing a fantastic job of demonstrating the power of working software as a deliverable.

Finally and unashamedly, we love the idea of Young Rewired State because we are in the fortunate position of being a growing business in these recessionary times and are on the look-out for more dynamic developers. We would prefer to get them before they have been tainted by the practices mentioned above. We don't use agencies because we like to hand pick our employees – they are our only asset. The best people tend to find us, or we find them through our network of contacts. Still, the "just left school and looking for an internship" is a difficult pool to tap into. James Darling and Tom ten Thij were both at the event and had some really interesting conversations with those taking part and were excited by the way young developers talked about modern software development practices. They were energized, open-minded and want to try new agile approaches. Lots of industries, such as media, broadcasting and some banks really get Agile and feel the same way, hopefully the rest will realise what they are missing as these young developers enter their businesses.

I don’t know about you, but I struggle to understand the nuances of the varying flavours of Agile that fly around and, at times, the purist adherence to one particular dogma, be that Scrum, Agile, XP, Lean, etc. To me it is all about taking the bits that work for you and applying them – but the real question is – to what purpose?

Although technology has moved on, the age old problem still exists – how do clients get what they want, when they want it, and for the price that makes economic sense? Sadly we know waterfall doesn’t work and I have the scars to prove it! I was responsible for the delivery of a 50-man year project that came in “on time, within budget and to the right quality”– trouble was it took 3 years to implement, requirements were vague (though signed off), and the business model had changed (what a surprise!). How can you be proud of building something that you know isn’t what people want, but more importantly how can any organisation fail to get any real return on what is a substantial investment?

The simplistic answer is go Agile and although that doesn’t guarantee success it at least makes it far more likely. Agile gives you a framework to build small parts at a time, and for very regular reviews to happen (every 2 weeks is optimum I suggest) so that everyone knows they are on the right track. Guess what? - In the real world people change their minds, refine their thinking, change priorities… Agile embraces all these facets but to achieve success you must have strong management and powerful business involvement.

If you are interested in knowing more give me a shout. In the coming weeks I’ll be adding more on the subject, as I’m passionate about business getting benefit from IT investment.

Unboxed Consulting is a forward-thinking, innovative bunch of people with fresh modern ideas and unwavering professionalism on everything from building great websites and IT applications to making world-class cups of coffee! Needless to say, a company like this needs a website to match!

So how do you solve a problem like the Unboxed Consulting website?

There is a formula for creating the perfect contemporary brand. The secret lies in the feel of the communication and tone of the message. The key is to strike the perfect balance between personality and professionalism, fun and actually knowing what you’re talking about and seeing it through. The ideal contemporary brand needs to embrace the modern ethos of having a friendly, warm and approachable image mixed with classic old-fashioned professionalism, unwavering quality and expertise. It sounds so simple… but why do so many people get it so wrong? Remember, we’re not talking pretty aesthetics; we’re talking trust, confidence, success or failure.

The key ingredients for this saucy dish include: Apex, a tasteful sans serif typeface with enough personality to separate it from the contemporary design default Helvetica. Pantone 254M or ‘Purple’, and our new cartoon men, a visual signifier of childlike innocence and fun to offset any crisp typography or straight talking content that might scare people away!

White space is very important too. Clean, considered design allows the user’s eye to digest so much more of the communication on the page, and remember- EVERYTHING communicates, whether you like it or not, so be aware and engineer that message as best you can! Soft edges and rounded corners add a feminine elegance to juxtapose with the masculine IT stereotype, also adding a vibe of accessibility and ease of use.

To finish off, illustrations of the team - the friendly human face of Unboxed Consulting, carefully positioned within the frame to give the site the illusion of spatial depth and size.

And there you have it, a short synopsis on the thinking behind Unboxed Consulting’s fancy new look. If you’d like to know more get in touch and we’d be happy to help.