They really have got jeans selling down to an art form and have a mind boggling array of jeans, cuts, styles and colours. With all those options many customers would get overwhelmed and walk out.
The staff took their time to explain all the options and help me choose some jeans to try on.

The staff made buying jeans a pleasant and easy experience and it paid off. Firstly I bought some jeans and secondly, they made me feel comfortable, so much so that I tried on a few pairs of jeans and ended up buying two pairs.

Great Customer service really does pay off and turned a no sale into a double purchase.
Now I am probably going to go back to the Levi store whenever I need jeans (repeat custom, building a customer relationship with a brand) and I feel compelled to blog about the great experience (free marketing)

If you have a business, product or are an employee for a company remember customer service is important!

Here are some of the useful links in the presentation.

• CouchDB online book - The best resource I have found for CouchDB, written by core contributers.
• CouchRest on github
• Cool interactive CouchDB emulator - great for learning how to use map/reduce
• couch.io - CouchDB hosting

I have been using CouchDB for the last few months in a side project and at work (at the BBC). Couch is a document oriented database and is an interesting alternative to a traditional SQL database.
I hasten to add I am not in the NoSQL camp, SQL databases still have their uses and CouchDB is no solves all wonder solution.
I’ll be talking about the pros and cons of CouchDB, how I have used it and when you may want to use it.

I’ll shut it now, don’t want to spoil it.

My current bookshelf

A pic of my current bookshelf. It nicely sums up my learning trends over the past 6 months.

So you’ve written your user stories and acceptance tests as a team and converted them into cucumber features and scenarios. The steps are all implemented and code is written.
Now you need to show the rest of the team a visual report of the acceptance testing. Because some of the team are designers or project managers they want to see something pleasing on the eye. You are proud of your efforts, you don’t want to disappoint.

So you generate a html version of the cucumber features…

Out of the box the HTML that cucumber generates are not particularly good looking. Thankfully its dead simple to supply your own custom html formatter.
Simply create a class and save it in features/support. I have chosen to call mine nice_html.rb

Basically just subclass the Cucumber::Formatter::Html class. Then override the inline_css method to load in your own css file.

To run it from the command line.

cucumber -o features/report.html -f NiceHtml features/

Cucumber will then look for the NiceHtml formatter and create a report.html file in your features directory.
You can then show this nicely formatted file to the rest of your team and bask in your own glory.

I use job boards to get a snapshot of what skills I need in the current job market. But I would like to keep a record of the skills I have actually learnt and experience gained.
Easy!

Your CV is an accurate record of you experience and skills and is the perfect vehicle for keeping a record of your career development.
Put a copy of your CV in the source control management system of your choice, I have mine stored in git.
Every time I learn a new skill or improve an existing one I edit my CV and have an appropriate commit message.
You now have a log of your career development from the commit messages and a version controlled CV.
Review it every few months and make an effort to add something to it or plug a gap in your knowledge.

Instead of only dusting off your CV and updating it when you need a new job your CV will be up to date and current.

Bonus Tip: Gorilla marketing on github

If you are looking for a job write your CV in textile format and you can put it up on github, I would not advise not including all your personal details in that version.
Your CV will then be showcased in a place where peers and other geeks go.
Most jobs are found and filled through networking or industry peers so github is a good place to put your CV. I have also seen jobs being advertised on gist.

Development

Ever since I have been at the BBC (nearly 2 years) our team in Manchester has mainly used Ruby on Rails.
The majority of our work is to create internal applications for editorial staff and to do quick prototyping of new ideas and proof of concepts.

We use Rails because:

• Its quick to develop with, especially when doing prototypes.
• Its open source so there is a huge resource of plugins and Ruby Gems to use.
• Has built in testing
• MVC framework
• Simple, RESTful based design patterns built in.
• Lots of other nice features, have a look.

We are all pretty hip developers in Manchester so we like:

• POSH, standards based markup
• Accessibility built in as standard
• JQuery - what all the cool cats are using, although Prototype is not bad either
• Progressive Enhancement
• Unobtrusive Javascript

We are all on Macs so most of the team use Textmate. We develop sites locally on our own machines then deploy to linux based servers.

When testing user interfaces I like to get the app working in Firefox using all the nice developer addons (A special mention to Firebug, Its like a mobile phone, I can’t remember how I managed without it).
Unfortunately we still have to support IE6 so we have a PC with various virtual machines on to test all the IE browsers and assorted others.

Source Control Management (SCM)

Code, configuration files and anything else that needs keeping safe, like wireframes or designs, are stored in a source control management system.
Doing web or software development without SCM is irresponsible and very naughty!
Either git or Subversion is used depending on the type project.

My personal preference is for git. Its perfect for collaborative working hence why many large open source projects, including Rails, now use it for SCM.
Its really easy to branch and has fundamentally changed the way I work, for every new feature I create a new branch. That way if a bug request comes in I can still fix the bug on the main branch without the new code interfering.

Testing

The middle last year we decided to introduce formal testing methodologies into all the work we were doing. Previously we were testing in an ad hoc manner just using a browser and server logs.
How did we know for sure that the application worked properly and that when we refactored code it didn’t break something else?
We started doing Behavioural Driven Design (BDD), a derivative of TDD and using RSpec as the test framework. I won’t go into the details, you can read about it yourself.

Since using BDD the number of bugs has reduced significantly and there is the ’safety net’ of a test harness in place to catch bugs when we refactor.
A nice side effect is a full specification of how the application works written in code. This can be checked against how the application is meant to behave and can be used to generate reports to show to non-technical people on the project.

It was not all plain sailing, we did have some problems.
Initially there is a big learning curve, its a different way of looking at development and while we were learning BDD our speed and output were effected. It took a few months to really bed down, despite this I would still encourage everyone to give TDD or BDD a try. Stick with it for a few months, you will soon see the benefits.

Deployment

For a standard deployment to one of our servers (Vision) we use Capistano to check code out of version control and deploy behind Passenger. Passenger really has made deployment much easier, because its Rack based its simple to use with other frameworks like Merb and Sinatra.

We also have stuff hosted on Audio & Music servers also. Deploying here is a little more complex involving building and installing RPMs to an integration server. The service management team then deploy to the final production server for us.

Communication and Organisation

The team uses a hybrid form of Scrum to run and manage the projects. We work in iterations of between 1 and 2 weeks in length and usually have some sort of working code demo or deployment for the end of each cycle.

When working in a team the most useful part of scrum is the standup meetings in the morning. It helps to keep track of what everyone is working on and more importantly, used to share problems that block the project.

For Personal time management I use Things to organise my day-to-day tasks in a GTD stylee.
We used to use Basecamp for project collaboration but not any more, not sure why not. Probably down to office politics or red tape issues : )

Those are the tools of my trade, hope someone finds this interesting.

So for the first time in a while I am going to give myself some focus. I guess if you publish out your goals into the blogosphere then there is more accountability.

The resolutions

In no particular order.

• Run another half marathon.
• Learn to converse in Spanish.
• Give a talk on Tech related subject.
• Complete one of my side projects
• Improve my Javascript and learn JQuery
• Commit to a large open source project merb, rails, etc.
• Start my own open source project
• Move from Wordpress to a home grown blog system
  (I know its reinventing the wheel but it’s good experience and Wordpress is bugging me just enough to do it)
• Grow tiny code factory as a business
  (without conflicting with the interests of my current employers)
• Get a higher profile project at the BBC
• Post at least 3 times a month on this blog
• Start a photo blog and improve photography skills
• Go to Scotland on Rails again
• Start learning a JS framework like cappuccino, sprout core etc. That is the future after all
• Photoshop to a practical level
• Learn a bit of Erlang
• Get up into the Clouds at some point
• Implement a proper GTD or GTD like system to do the above

I am a big fan of both frameworks, I use Rails at work and merb at home in my side projects. If I had to choose I would pick merb, I like the simpler style of coding, the smaller “lego block” pieces of functionality and the agnostic approach to ORM’s, Javascript libraries and testing frameworks.
What I am trying to say is that this post is written by a ruby developer who favours merb but not so much that I have stopped using Rails.

I did and still do have reservations about the merge but here is why I think you should stop worrying and start loving Rails 3.

Duplication of effort

As far as I can gather one of the biggest reasons for this merger happening is that DHH wants a more modular Rails with a stable public API, which is basically what merb has now. As both camps have the same views and ideals why duplicate effort in two places. Work together to create a great framework that the whole community will enjoy and benefit from. Effort can be combined to achieve the same goal and the addition of more core developers makes the project stronger.

Rails is broken for some people

Merb was born out of frustrations with Rails, these frustrations were addressed and a very good framework was produced. Merb has proved the community required something else from Rails that they were not getting previously.
DHH has reacted to this. Some say he has too many opinions and has a big ego, I say he realises that Rails needs to change and its missing features are present in merb. He has taken steps to stop Rails from stagnating by taking a very bold and brave decision to merge with merb, this could be a disaster. I think DHH is genuinely interested in delivering a Rails that the community wants and not a Rails just for 37 signals, this bodes well for the future. Having a lead developer that makes big decisions means the framework will be able to stay agile and evolve when it needs to.

Merbists need not worry

I must admit my first thought when I heard the news was that I would lose all the things I love about merb when it gets merged into a larger framework like rails.
I had some stuff to say about this but I think Matt sums up merbists concerns and answers them with more authority than I could.

Rails developers need not worry

Rails developers have no need to worry. Rails will get performance gains, a nice public API and when developers need to stray from the golden path they will not get bitten in the arse. It will improve an already great framework and they will finally get engines that work properly.

Personality clashes

Will the personalities gel? Everyone knows about DHH’s opinions and Yehuda certainly had strong ideas on the direction of merb.
There is a danger that when the core developers get down to the nitty gritty that problems may arise. I suspect that the new core team members have a great deal of respect for each other, hence why this merger is actually going ahead.

In a recent post DHH has admitted that actually both camps had the same views.

I think what really brought this change around was the realisation that we largely share the same sensibilities about code. That we’re all fundamentally Rubyists with very similar views about the big picture. That the rift in many ways was a false one. Founded on lack of communication and a mistaken notion that because we care about working on different things, we must somehow be in opposition.

Strong personalities are needed to drive things forward, the problem comes when these personalities are unreasonable, stubborn or just don’t like each other. I think only time will tell whether there will be any clashes.
I hope not.

Mono culture bad for competition?

Some people argue that a lack of competition could lead to stagnation and a lack of innovation within the community. I agree, there is a danger that without another framework pushing back against Rails it could plateau.
I hope that by bringing in new developers from merb is what Rails needs to stimulate more innovation. Rails has always been very good at that but maybe it was too focused on the Rails community and took its eye off the Ruby community as a whole.

Rails 3 == stronger community

I think the conclusion I am trying to make is that this decision is all about community. Part of the community was unhappy with Rails and turned to merb. A community that seemed to be at odds has come together to build a better web framework, that shows a high level of maturity. So you should love Rails 3 because its a product of the Ruby community uniting and hopefully getting stronger.

Personally I am proud to be a part of such a community and will continue to use Rails and merb until the two merge.

ERROR:  Error installing merb:
  merb-core requires RubyGems version >= 1.3.0

I tried to do a gem system update to the newest version of RubyGems (1.3.1) which failed.

$ sudo gem update --system
Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.3.1
ERROR:  While executing gem ... (NameError)
    undefined local variable or method `remote_gemspecs' for #<Gem::Commands::UpdateCommand:0x1138b24>

When I ran it again everything seemed fine. Then tried to install Merb and got the same message about needing RubyGems version 1.3.0 or higher.

Turns out there is a problem upgrading from RubyGems 1.1 and 1.2 when rubygems-update is not previously installed.

If you try the alternative update commands then you should be able to gem install Merb 1.0 ok.

$ sudo gem install rubygems-update
$ sudo update_rubygems