ThinkRefresh Articles

BDD and The Big Rewrite

Mon, 29 Jun 2009 22:20:04 +0000

Rewriting your whole application is no easy task (as demonstrated by the lack of news about Textmate 2 until recently), but after some research and a little experimentation, I’ve realised it’s made easier if you’ve written user stories – an integration testing method used in BDD.

Why bother rewrite?

Steven Baker spoke at Scotland on Rails about this very topic, and his points were very clear:

It’s a blank slate, a fresh start, an empty canvas – nothing bad has happened, you don’t need to learn what some other developer’s code means, or worse: your own from years ago!
It’s a green field – no edge cases, integration bugs or many problems you may have run into in the past.
No technical debt – there is no lack of tests or documentation in the new project.
You can avoid making the same mistakes.
You get to use sexy, bleeding-edge, new technologies.

My excuses fall into #3 and #4 – when the application I am rewriting was first developed I hadn’t learned about TDD and the whole architecture is totally wrong. One file even has 1000 lines of code in it, it gives me nightmares…

So why not rewrite?

Some people argue that rewriting a system from scratch is usually by no means the best idea due to the risks involved. Steven continues in his talk to mention the following problems:

It costs money, lots of money.
It might fail again (i.e. no/low acceptance).
Lack of bug fixes.
Could make same mistakes.
You could run into the same problems.
You probably won’t know how to use these new technologies.

Thankfully I can justify pretty much all of the above points because it is (or rather, should be) a small application, and I am confident will improve sales, besides, there are more bugs caused by just upgrading Rails than I can foresee in the development of a new application.

How user stories can help.

“Very Important User Stories”
Source: SweatPantsNinja @ Flickr

User stories explicitly define the goals of the system, so provided they pass, the system contains all the functions that it is required to provide. So if you take these as a basis for your new application: once they all pass, you’re back to where you left of with the previous iteration.

Of course your new UI might differ, but usually you can just copy over the view files and CSS from your old application, if you are tempted by something like HAML or SASS, I’d make the switch as part of refactoring once the application is back up to it’s previous state.

So what should change? Well since the stories were first introduced, your client’s requirements (whether they are a business, or the general public) may have changed – so you should look for stories that can be cut or altered, however, make sure the stakeholders are involved in this process otherwise you might finish up with people not accepting the update (read: Vista).

You may also have new features that you’re gagging to dig your teeth into, but you should avoid temptation to add these into the initial build – the reasons for this being:

You will probably dive in head first into those features without thinking about the differences in the new base code.
You should be able to provide your client with a preview of the update, especially if there have been feature cut-backs, and they should be perfectly happy using it – as they (hopefully) were with the previous system.
Over-complicating releases with hundreds of new features all in one go will send users running for the hills and also releasing over time will make your client feel like they are getting more for their money – as they can see the time involved in each release.

That said, you should keep the new updates in the back of your head so you don’t end up throwing away too much code when you get round to implementing them, just doing get caught up with “I’ll code this in because it might be useful in future”.

If you’re not already using BDD through user stories, you should seriously consider implementing them sooner rather than later – because they’ll not only help any rewrites, but will also reduce the need for a rewrite in the first place!

To get started, I suggest you check out Cucumber, Ryan Bates (of Railscasts) has produced a video introduction.

As a closing warning, note that you should always still consider modifying current applications over the ‘big rewrite’, user stories simply aid in redevelopment if that’s what you must resort to. If you are simply looking to refactor and improve your code – a rewrite is most likely not for you – if you don’t have tests in place to aid in refactoring, I suggest you view the Ruby Code Review video from Scotland on Rails, where Joe O’Brien and Jim Weirich discuss retrofitting tests.

This article’s photo: I’m afraid I lost the URL, if you are/know the author, fire me a tweet.

Maintenance Pages: VirtualHost Configuration

Fri, 08 May 2009 14:59:32 +0000

Are you running a Rails app in production and making regular updates to the codebase? If so, you probably already appreciate the need for an easily deployed maintenance page for handling all requests during significant code updates, particularly those running migrations and altering the DB schema. Luckily, existing tutorials on this topic (Custom Maintenance Pages, Rails maintenance page with images and styles) make Capistrano-powered maintenance pages look pretty straight-forward.

Unfortunately, this wasn’t my experience with the Ubuntu + Apache2 + Passenger stack on the Notipal production slice on SliceHost; I followed the Mike Clark tutorial, but the rewrite conditions just didn’t appear to do anything whatsoever.

After a bit of trial & error, it was all figured out; these are the additional steps that I had to take to get our stack & Apache configuration to work with VirtualHosts and Rewrite Conditions:

1. Install mod_rewrite

Apache 2 comes bundled with mod_rewrite, but it isn’t always enabled by default, so run the command below to enable it:

sudo a2enmod rewrite

2. Include RewriteCond conditions WITHIN your VirtualHost blocks

In my experience, you have to put these commands within the VirtualHost blocks nested in the Apache conf files to get rewrites to spring in to action once your maintenance page has been deployed by Capistrano (including them globally in the apache2.conf just didn’t seem to work):

3. Restart Apache

The code below will restart Apache 2 in a graceful manner, so you won’t cut off any visitors currently loading a page from your website:

apache2ctl -k graceful

4. Check It Works

Hit cap deploy:web:disable to put your site in to maintenance. Hit cap deploy:web:enable to take your site out of maintenance.

And that should be it. Your .com should now be showing a completely unstyled Capistrano maintenance page when ever you use the capistrano web:disable command.

In a follow-up post we’ll be styling your maintenance page and making it far more user/visitor/customer friendly.

Staying on-track with side projects

Sun, 08 Mar 2009 17:04:29 +0000

Recently I have been so busy with my main projects, Notipal became left untouched. This wasn’t because I wasn’t excited about the project, but just that I couldn’t commit any particular dates to the 3 or so days it needs to become launch-ready.

When speaking to Neil about the issue of not knowing when I will find these 3 days, he came up with idea of spending an hour, or even half an hour, every evening and pre-assigning all the leftover to-dos to their own date – rather than trying to tackle them all in 3 sessions.

In the past I have always tried to avoid working on different things for a small amount of time each because of the cost (in time) associated with figuring out where you were and what needs to be done next, but as Notipal is not a complicated application, I thought I’d give it a try…

I cannot stress enough how much of a difference assigning these days has made, I’ve found that most of the to-dos are taking 20-30mins to complete, and the feeling of getting something done has often spurred me on to complete a second item, so in terms of the schedule I’ve quickly become ahead.

Giving yourself small goals that are easily achievable (even if they seem trivial) can really aid overall development and you’ll soon find yourself anticipating those 30 minutes of your day where you can get a kick out of something as simple as ticking a box. Everyone can find 30 minutes – I’ll leave you with a well-known phrase:

The busiest people have the most time.

Agile is not an excuse for an absence of design processes

Thu, 26 Feb 2009 18:27:06 +0000

With the economic climate in such an awful state, project management skills are becoming increasingly important as businesses strive to minimise wasted money.

You have probably heard the phrase:

Work smarter, not harder

This idea is ever so important, however the trouble faced by Rails developers is that Rails has helped us work faster not smarter. Agile has become the latest cool development model, however many of us are simply avoiding the design phase because of it’s potential to slow us down – using agile as our excuse.

Design doesn’t slow you down

…bad organisation of a design process does, or rather a lack of a design process altogether, either of which lead to inaccurate or useless plans.

As a human being, we naturally construct solutions all the time, so what we do as developers is simply an extension of this on a greater level. The problem brews when we don’t formalise our process. In our brain we can formulate solutions on the fly, which is fine for problems such as ‘what should I have for dinner this evening?’, but when there are multiple dependancies on the solution, things tend to go a bit haywire – how many times have you been to the supermarket and forgotten to purchase an ingredient you needed for your dinner?

How do we cope with our dependancies? Well in the case of shopping, we tend to make a list – our documentation if you will. Not documenting your design can waste an incredible amount of time if you are constantly referring back to the application or even the code behind it.

So, we need a process to manage the choices we are making, and their evolution as solutions.

Developing a process

If you’re going to be doing something day-in-day-out, you need it to be as streamlined and natural as possible, hence why I won’t be telling you exactly what tools to use, or how you should be documenting. To make things natural, it’s best to base them on something common to yourself, everybody has to eat and most people go shopping, so I’ll take that as an example.

It’s pretty easy to see how this relates to developing web applications, however taking on an iterative approach it’s important to note that this process should be cyclic – your ‘select solutions’ phase should actually contain a set of cycles itself, reviewing each solution one by one.

How to document

As I mentioned earlier, I can’t tell you what tools to document this process will work best for you, but if you want to get your foot in the door, then you can’t go wrong with a ToDo list, provided it has categorisation and descriptions for each task, LessProjects is a good example of this.

Each problem can start it’s life as a task, in the ‘Gather Requirements’ phase (part 2 in the diagram above), and progress through the following 5 sections as you continue to work on the application.

Documenting all the proposed solutions is by no means necessary, but you should at the very least give a short explanation for why each one was chosen / denied, so looking back at things you can see why you avoided one thing or another. Some problems might not actually have a suitable solution, so it’s worth having a ‘denied’ status for when you reject functionality – but remember to always explain why you denied it.

You could also skip documenting the pre-conditions and actions, as you’ll probably be calculating them in realtime, and are unlikely to be referenced in the future – we want to keep this process as lean as possible so you actually follow it!

Conclusion

There is no excuse for not following a process in your work, even a bad process will help you in the long run – perfection cannot be achieved without failure. Your process should be very streamlined – don’t pack it full of unnecessary planning because you’ll just end up avoiding following it. It’s also worth reviewing your process over time too, maybe after each big project, your habits, team and environment will change, and so should your design process.

This article’s photo: “Snakes” by _boris @ Flickr.

A Simple Spam Solution

Sun, 01 Feb 2009 11:02:02 +0000

After updating the ThinkRefresh blog, for a while there was no spam which was nice, but the bots quickly returned and were back at it. My old anti-spam solution didn’t work particularly well, I was using Jonathan Snook’s method of building up a score from various criteria, however this still required me to check my email notifications for people who’d been wrongly marked as spam.

An ideal spam solution places no visible limitations on a visitor, but also doesn’t involve any work by the site’s owner, hence why I am against using CAPTCHA. From this I think I may have come up with a pretty good solution – the blog certainly hasn’t had any spam since I installed it.

What’s the plan?

A typical bot will do either of two things:

Load your form once, process the fields and then use the command line to send POST requests adding comments on a daily basis.
On a daily basis, load random posts in a browser on your site, fill the comment fields and hit submit.

One might think you can prevent the first method of spamming by checking referrer variables, but those can be spoofed, so we need some way of checking they are human without the humans knowing they are being checked.

This is where it hit me – if an automated bot is submitting spam, it probably won’t be hanging around to do so… so lets add a timer. If you mark any comments within a few seconds of loading a blog page as spam, visitors don’t have time to type a comment in that time, and spam bots won’t be waiting.

I have quite long blog posts, so I opted for 15 seconds, it’s unlikely anyone with anything useful to say will have typed it in 15 seconds and most people won’t even notice!

What’s the code?

My blog engine is coded in Ruby On Rails (of course), but it should be pretty simple to convert this to PHP or other languages. First we need to setup a session on any page that has a comment form, all this needs to carry is a timestamp:

Then on our ‘add comment’ page (in my case comments controller → create action), we need to check this session value is present and whether it’s after the limit (in this case 15 seconds):

That’s all you need functionality-wise, but you should really let your user know about the limit, so I went a little further and added some JavaScript (using Prototype) to disable the submit button on my forms:

Hope this is useful to you, and there is a live demo on this site! You may need to reload to see it in action below. If you use this solution on your site, please let me know how it works out for you.

This article’s photo: “Spam Wall” by FreezeLight @ Flickr

Web Development & Education

Thu, 29 Jan 2009 13:21:57 +0000

I have a few peers who are intending to go into web design / development, but are planning on going to university first, and others who are looking at the same career path, but already at university. Based on the experience of myself and my coursemates, I’d like to share an insight into what university can provide young web designers, and what you need to be doing to prepare yourself for the exciting world of work.

Where am I heading?

This is the most important question you should be asking yourself. Most students leaving 6th form make the mistake of asking themselves, ‘do I want to go to university?’, and ‘what should I study?’, probably because, in many schools & colleges, going to university is regarded as ‘the done thing’.

There aren’t too many enterprise-sized businesses involved in public-facing web design & development, which is a shame, because in my view that’s where all the excitement lies. However, if a big corporation is where you want to be, the choice is simple; university is probably for you because they are unlikely to hire you without a degree.

Smaller businesses are often much more flexible in who they’ll accept, looking for an excellence in actual skills rather than qualifications. At the age of 18, it’s unlikely you’ll have the skills necessary to command a good salary in web design, so you have 3 options, firstly, try to get a job and build up your skills (and salary) over time, get an internship where you will get training with work promised at the end, or go to university and gain your skills there.

The final option is, of course, setting up your own business, again this still doesn’t mean you should forget the idea of going to university. You have a lot of spare time when studying an I.T course, so you can use that to work on developing your business without having the risk of not being able to pay your rent/mortgage/bills if your business goes under. I have pretty seamlessly worked part-time for Agincourt over the 3 years I have been at university, so there is no reason why you couldn’t be running a business of your own in that time.

For those who are mind-boggled by all the choices thrown at them for post-6th form education/employment and cannot decide at all; university is a safe bet. You can always decide what you want to do for a job during your time there, and there is little worry about getting on the right course, you can usually swap pretty easily. Neil was studying a business degree, but got interested in the web, and managed to mould his degree around his interest.

So what is university like?

“Today’s Lecture”
Source: Andrew Scott @ Flickr

I have always maintained that I.T. should not be taught above a very basic level – those who are going to be successful will learn the required expertise off their own back. You can’t float through university, grab your degree certificate, and walk into a well paid, exciting job because you will be up against those who’ve used their free time wisely to develop a portfolio of design and development work and network with the head honchos of the industry.

Universities try to teach skills that will still be useful in 20 years time, which is why many courses have very generic units. The trouble is, the web won’t be the same in 2 years, let alone 20! My course, ‘Internet Computing’, is by name pretty specific to web technologies, and yet we’ve never studied CSS, Javascript or any scripting language – we only created a small HTML-only website in first year… using framesets (I feel dirty just mentioning them). To counter-balance this, radically new ideas are taught as well (hence my post on the Semantic Web), however, these ideas are not yet applicable to real life. So, you come out with knowledge that’s too basic and too bleeding-edge to be of much use… unless you supplement it yourself.

A degree will only prove that you are capable of learning if provided with teaching. To take the next step, learning has to be off your own back, you must always have a desire to learn more.

You may have heard the phrase:

Learn a new [programming / scripting / markup] language every year

Your 3 years at university is the best time to really take that on-board. If you really want to succeed in web design, University is great for those who want to learn, but not so great for those who want to be taught – it’s up to you how much you get out of it.

How can I make the most of my time?

I cannot stress the importance of learning, it doesn’t have to be from books, most people learn web technologies best through practical use, so here are a few ideas and tips:

Design as many websites as possible – if you can’t find clients give them away for free.
Develop/run your own blog
Create some screencasts / write some tutorials
Develop some open-source applications / plugins (GitHub will host the repositories for free)
Network with industry leaders (get on Twitter right away!)
Do some pair programming with a follow web developer
Give some talks on what you’ve learnt from the above ideas
The above ideas will hopefully help you learn some the following:
- Markup & design: HTML, CSS, XML
- Scripting: Python, PHP, Ruby, JavaScript
- Frameworks: Django, CakePHP, Ruby On Rails, Prototype, jQuery
- Paradigms: OOP, DRY, TDD, TATFT, Microformats
- Marketing: Social Networking, SEO

Also, please please please: decide on what you’re going to implement and only follow tutorials for the bits you can’t figure out – don’t just follow tutorials blindly, hoping to learn something – you’ll just end up cut & pasting and not really understanding.

A chap I know on Twitter, James Padolsey, is already using many of these tips (before my recommendation), so I really recommend you check out his blog where he often posts his open-source jQuery Plugins.

I’ve used my time to learn Ruby On Rails, Git, *nix server administration, considerably built on my CSS, Javascript and general design skills, designed numerous websites and develop a few web applications, and I’ve loved every minute of it. Do you have any suggestions to upcoming students?

This article’s photo: “Lecture Pattern” by Foreby @ Flickr

Concepts, Benefits and Problems of the Semantic Web

Mon, 26 Jan 2009 17:57:33 +0000

Prologue

Multiple people have requested that I post my latest essay on ‘The adoption of the Semantic Web’ publicly, however I don’t feel it accurately represents my views. Funnily enough, when you express a negative opinion of something, you don’t stand yourself in good stead for getting a top grade when the marker has dedicated much of his/her life researching the topic.

So rather than a simple cut-and-paste, I have opted to write an article from scratch about the Semantic Web to provide an insight into the ideas and technologies for those who know little or nothing about it, and my views on where it’s heading.

What is the Semantic Web?

The Web, as we know it, is Syntactic, or rather it contains information in a language which computers can display to users. However, the computers don’t understand the information; if you have a page about cars, only humans can understand what it’s about – and while that’s not so much a problem as such, it isn’t ideal.

The Semantic Web adds meaning to information, so you can essentially tell a computer that a car may be left or right hand drive, it might have air conditioning and whatever else the computer might need to know.

Why is it important?

So you’re probably wondering, ‘why does a computer need to understand information?’, and the simple answer is: automation. To illustrate below is a case study from an article by Tim Berners-Lee himself (edited for readability):

At the doctor’s office, Lucy’s Semantic Web agent promptly retrieved information about her mother’s prescribed treatment from the doctor’s agent, looked up several lists of providers, and checked for the ones in-plan for her mother’s insurance within a 20-mile radius of her home and with a rating of excellent or very good on trusted rating services. It then began trying to find a match between available appointment times and the busy schedules of her and her brother Pete.

Whilst this is technically possible using the current Syntactic Web, it requires a developer to code an application to run such a service. On the SW, however, no coding would be required. Pretty sweet, eh?

“Good Morning!”
Source: Lolandese Volante @ Flickr

Another great feature would be the ability to infer information by combining information as such:

I have a vitamin C deficiency (I don’t, but roll with it for a minute)
Citrus fruits are good sources of vitamin C
Oranges are citrus fruits

Which would allow a computer to calculate I need to eat oranges. This is only a very simple example, experts have suggested the spread of disease, cures for ailments, and a variety of life-changing information could be inferred.

How is this all possible?

The W3C has produced a couple of markup languages, based on XML, that allow for semantic description of objects.

These work much like Object Oriented Programming. You have:

a class that describes an object (e.g a car)
properties or attributes of a class (e.g how many doors the car has)
instances of a class (e.g a Vauxhall Corsa)
relationships between instances (e.g the Corsa is owned by Ryan)

The classes (or ontologies) are defined using OWL, and the instances and their relationships use RDF.

Sounds great! Why haven’t I heard about this before?

“Semantic Web Roadmap 2008”
Source: Ina Galway @ Flickr

There are quite a few problems with the SW which must be ironed out before it even has a leg to stand on in comparison to the uptake of the current Web. For typical users to adopt it they must be able to see real results; it’s all very well explaining what they’ll be able to do in the future, but what can they do now? Answer: not a lot.

Ontologies

First of all, there is little point in creating ontologies if everyone uses their own, there needs to be a central reserve for them, so when people ask themselves “how would I define my page of cars?”, they know where to look up the car ontology. However, this does pose the problem of who will decide what is a ‘correct’ ontology? Different people perceive objects in different ways, even between experts there are multiple ways of looking at things – look at how long specifications for HTML and other languages take to get W3C approval – you can’t expect people to wait years to find out how to define their cars in RDF! And even then, people still don’t fully agree!

Even if we assume the relevant parties come to a swift agreement on the definition of an object, there is limited scope for what can be included. OWL is split into 3 sub-languages; Full, DL (Description Logic), and Lite. In the full version you have unlimited expressive power, but the computational resources required are too vast to be feasible, hence why the latter two compromises were created. On the Syntactic Web we have been compromising all along – search engines have been scraping information from HTML that web services can manually link together. So, one could adopt the view, ‘If we’re still going to be in roughly the same position, why change anything?’.

Inference

Before I gave you an accurate example of inference but there are problems, take a look at this one from Clay Shirky:

Count Dracula is a Vampire
Count Dracula lives in Transylvania
Transylvania is a region of Romania
Vampires are not real

You can draw only one non-clashing conclusion from such a set of assertions – Romania isn’t real. That’s wrong, of course.

“Burglar”
Source: Wellstone @ Flickr

For the SW to take off in a public environment, the data produced needs to be publicly available – but many companies will be reluctant to share their information because others could use it with their own data to infer information, which could lead to competitors having an advantage.

Many of the public are already paranoid enough about what can be discovered about them on the web – I have heard stories of burglars tracking people’s movements on Facebook so they can accurately predict when their house is going to be empty.

Also, in a private environment, it’s not as if this ‘artificial intelligence’ method of discovering data isn’t already being employed; governmental security agencies don’t sit there browsing the web to monitor terrorist activity, they have computers sat around doing the work for them.

Conclusion

For developers to push the SW into business environments, it really needs to be a solid technology with obvious benefits (e.g. improving a company’s bottom line). Otherwise, we will forever be stuck in the catch-22 of nobody creating data because there is no data to use it with, and nobody developing applications because there is no data to base them on.

At the moment, there are no clear benefits which cannot be broken down by major pitfalls. If RDF and OWL had been around at the inception of the web, we would probably be using the SW now. But at this late stage, trying to introduce them into such a massive environment would be somewhat counter-revolutionary (counter-evolutionary?).

To get most businesses on-board there has to be short term returns; only the biggest of companies can afford to invest in semantics and wait to yield the benefits. SW can only achieve in the long term.

Of course, these are only my thoughts, what do you think? Do you think the Semantic Web is going anywhere soon?

Fixing Paperclip's Alpha PNG to JPG Conversion

Mon, 12 Jan 2009 19:30:43 +0000

Paperclip has to be one of my favorite plugins for Rails, providing simple storage and validation for uploads, and thumbnailing of images.

Whilst it isn’t technically broken, for small image sizes many people want to convert 24-bit (semi-transparent capable) PNGs to JPG and sadly this creates images containing artifacts where the transparency is assumed to be black not white. Luckily the fix is very simple, but it took me a while to figure out, so as always I thought I’d share it with you guys & gals.

The important option is the :convert_options which takes a hash of ImageMagick flags for each of your thumbnails. In the code below, I am converting the large and max sizes to JPG, so for those I need the ImageMagick options -background white -flatten which specifies the transparency should be white. Note: the -flatten flag is very important – this is the sole reason I ended up spending hours searching for a solution.

Personal Projects: Keep 'Em Simple

Thu, 08 Jan 2009 13:13:14 +0000

The last ThinkRefresh article covered simple specifications for client work. In this post, we’re concentrating on simple ideas for personal projects and startups.

Everyone has at least a couple of ideas which they’d like to pursue; the problem is, which one should you work on? You only have so much time in the day, and even if you’re the best developer out there, you’re always going to be limited by what you can achieve around current commitments, be it to friends, family, existing employment, or client work. As we’ve previously discussed, working all hours of the day can negatively impact your productivity.

Based on my limited experience with founding & developing start-ups, and nurturing them from the crazy ideas stage through to production, I’m now hedging my bets on web apps that are geared towards solving simple, tangible problems. You know the ones I’m talking about; they’re the sort of ideas you don’t need a rehearsed speech for because “The Problem” just rolls off your tongue, subsequently justifying the follow-up explanation of the potential solution whilst making it sound simple (potentially to the exclamation of, “why hasn’t somebody done this already?”) and undeniably attainable. If you have a web app idea that fits the bill, drop everything, and start coding. That’s the idea you want to pursue.

Example

I really wanted to use someone else’s project as an example of a simple idea (please post one in the comments if you have one of your own), but Notipal, an application that Ryan and I started hacking on just before Christmas, just works so well:

“Fail Whale”
Source: Twitter

My dad was trying to access his online banking. I was sat next to him. The bank’s website was unavailable. He kept clicking refresh in a vain attempt to access his bank account. This process quickly became tedious, and as soon as it did, I slapped my forehead and decided that there needed to be a web application that offered an email collection service for error pages. As a ‘webmaster’ you copy/paste a line of code in to your website templates, and if your site goes down, an email form (as provided by the line of code) can collect the email addresses of the people that hit your website’s error page during the outage. And when your website is back up again, the service emails all the people who left their email address for notification.

That’s the Notipal problem & solution in a nutshell.

Saying ‘No’

Aside from the fact that simple ideas sound great to other people, there’s a second, albeit no less important benefit for building an application which solves a problem – it’s much easier to say ‘no’ to anything but the core feature set required to solve the problem you’ve diagnosed. This point is particularly topical for ThinkRefresh readers; along with naming things and cache invalidation, feature creep is a programmers worst enemy. More info about feature creep is available on Six Revisions and Wikipedia. Simple ideas empower you to say ‘no’ to feature creep, unlike ideas which target a ‘gap in the market’ – if the feature doesn’t help you to solve the original problem, it doesn’t make it in to the spec.

The later breed of idea, which target a ‘gap in the market’, are usually conjured up whilst observing existing players in the market place, deciding that their market share can be eroded by a product with a slightly different ‘fit’, and only then trying to work out the required feature set. If you’re considering pursuing one of these ‘opportunities’, think very carefully about doing so, unless, once again, you have specific use cases of exactly how the product works/functions differently, or how it solves a problem in a different way. By now, though, this post should have convinced you that you just want to start with a small problem and to create a simple solution – something which you’re much more likely to launch within the time you have available for personal projects.

Finally, as an aside, does anyone have a new year’s resolution related to personal projects, or are you planning to launch a personal project in ‘09? We’d would love to have the scoop, especially if it’s a Rails app, so please let us know in the comments.

This article’s photo: “Chair” by Christopher Woo @ Flickr

Simple Specifications

Mon, 05 Jan 2009 23:12:12 +0000

Writing a specification for a website or web application can be difficult, what do you include? How much transparency should there be? What about pricing?

Here are some tips to start you on your way in a simple who, what, why, when & where format based on what I’ve learnt over the past few years.

What

I’m afraid I can’t really start with who, because without the context of what you are making for you’re client, it would be pretty confusing. So how should you go about describing what you are making?

You should start off with a quick paragraph or two on your objective i.e specify in layman’s terms what you are producing for your client. If you are making a website it may be pretty obvious what one is, but what kind of features are possible (even if you aren’t including them), however if you are making a web application, it’s probably best to explain what the difference is to website and desktop applications. Either way, what are the obvious benefits to the client?

I can get a website for £50 on the net.

We hear this a lot, but you can pre-empt this by explaining why you’re solution is more expensive, and suggesting in good-faith that you can look at more affordable, less extravagant solutions if they are looking for a cheaper presence.

Flexibility

Some projects don’t have strict deliverables, so what process will you go through to manage the scope of the project and how it’s designed? If you’re relying on prewritten systems, they might be fixed in implementation so it’s worth mentioning what you can and cannot do with them.

External Code

Are you going to be using open source systems like Wordpress or external services such as an API, and how are you going to plan for updates / changes in the specification? What happens if such service / codebase becomes unavailable or no longer supported? While these questions might be of no interest to the client, they are important to cover your back in event of any issues.

Who

“Office workers in downtown Singapore”
Source: Larry Carr @ Flickr

This is section is very important for not just your client but yourself also, first start with explaining whether it’s a public website, private intranet, or public/private web application and how that relates to the type of visitors to the website. The questions you should be asking yourself when looking at visitors are:

How computer literate are they?
How patient will they be, i.e are they broadband guzzling script-kiddies who must have everything immediately or they’ll go elsewhere, or employees who don’t mind waiting 10 seconds for a large page of data to load?
What functionality will they be using?
What data should or shouldn’t they have access too (whichever is more appropriate)

Context

How these users access the website/webapp can radically change how you display it. With mobile browsing becoming more and more popular it may be worth developing a streamlined mobile-specific interface, but context doesn’t just what devices they’ll be using, but the situations of access, for example when printing orders, a user might just want a quick list to scan through, but when dispatching them, the warehouse staff might only need to see a single order in much greater detail.

When

“Minimal Stripes”
Source: Alienate @ Flickr

If you are not particularly great at predicting when projects are going to be complete, discuss this with the client, and ask when their deadlines are – it might turn out that they don’t really need certain functionality until later down the line, so you can set a short deadline for the core functions and work from there. If you are following an agile development model, it’s also hard to determine exact dates, but you can always set deadlines with get-out clauses providing you give at least a set amount of notice.

It’s a good idea to set deadlines for your client too, an idea I came across through Paul Boag [I can’t find the exact article, sorry]. It may only be that you need sample content from a client to initially fill their website, but it keeps the relationship bi-directional, rather than the client just polling you for updates all the time.

Clients like to see their projects in action, you might be including them in your acceptance testing of each iteration, but if you aren’t planning on meeting with them to discuss the project details further, it’s worth considering booking progress meetings where you can demonstrate features to the client. This also helps with you’re project management as it helps define internal goals to be reached before these meetings. The meetings need not be set in stone, but nobody likes to repeatedly delay them so it’s always in the back of your mind.

Why

It’s always good to finish on a positive, so before providing a list of your costs which is likely to give the client a heart attack, tell them why they want this project to happen, why should they be excited, and also most importantly why use you? You may have some specialisms that will guarantee success, or a close relationship with the client which you feel you can use to both yours and your client’s advantage.

“Driving Dilemma (edited)”
Source: Sister72 @ Flickr

Finish Up

Pricing

Pricing is a difficult one because it not only depends on the type of client, but also the financial situation and various aspects of the project, for these reasons I won’t suggest how to price your work (that’s maybe one for another post), but here are a few tips that work for us at Agincourt Technologies Ltd:

Take a 50% deposit up-front, if you’re clients question this then you haven’t done you’re job properly in creating trust in the relationship.
- You might like to suggest a finance company to act as an intermediary providing you with the money, and the client with monthly bills rather than lump sums.
Unless you are charging by the hour, don’t indicate your hours. If you’ve quoted £10,000 for X many hours and it only takes you half the allotted time, then that makes up for the next time when you under-quote. You’re client is paying for a product, not the service of you coding it, so they should be prepared to pay the full amount.
Mention your pricing with regards changes to the specification after sign-off, it’s sometimes worth including a few hours for this when creating your total.
Alert clients of monthly costs as early as possible, hitting them with unexpected bills will harm your relationship.

Sign Off

The final hurdle is sign-off, I’ve big tip for this one, print off a couple of copies of your specification and sit down with the client to read through it all, explaining anything that crops up and do it on their turf. Don’t force clients to trudge all the way to your office, take the initiative to visit their office so they feel 100% comfortable when they sign your specification – as an added bonus on your part: you can walk away with a cheque!

Starling & Workling Capistrano Tasks

Sun, 04 Jan 2009 14:02:47 +0000

Just a quick slice of code for you, if you’ve followed the Starling and Workling screencast on Railscasts and you want to run them in production, then you’ll probably want to manage them through Capistrano.

I spent a large portion of yesterday getting the commands to work correctly, so here is my Capistrano tasks:

Developer Diet

Fri, 02 Jan 2009 12:23:35 +0000

We can all fall into the trap of hacking away until dawn, but it’s just not healthy to be doing repeatedly, especially if you’re like me and tend to drink more Red Bull than the yearly recommendation in one night.

My developer diet isn’t simply looking at the food and drink we consume but how we use our time, and how improving this can lead to not only a better lifestyle, but increased productivity also.

Have a decent breakfast

“Healthy Breakfast”
Source: Seitti @ Flickr

Starting the morning on an empty stomach is not just a bad idea for your health, but will also distract you and drain you of energy as the day progresses. Women especially need to have a really good breakfast as studies have shown they are more likely to snack throughout the day – so remember not eating breakfast is not a slimming diet!

If you can’t stomach cereal or toast in the morning, try fruit salad or even just bananas in yogurt, it might seem rudimentary, but it’s a start. Fruit juice is also a good way to wake you up in the morning without resorting to caffeine.

Don’t start too early

You’re brain isn’t active in the first hour or two of the morning, so why force yourself to work when you can use the time to ease yourself into work. A lot of web work / interest in services is acquired by networking be it using a blog, Twitter or any social network, so as Elliot Jay Stocks suggests: write of that first hour, read you’re emails, write a blog post and catch up on Twitter.

Planning

You can decide the fate of a project even before you have even put finger to key. Agile programming is often used as an excuse not to plan at all, when actually it’s really about being fluid and adapting the plan as you go along.

You don’t have to spend hours drawing class diagrams or ERDs, find something that works for you and stick to it. When working on Notipal, myself and Neil simply used queue-cards to storyboard our idea and it worked really well. Even if the plan changes, you aren’t stressing about where it’s going and the core functionality.

Work side-by-side with a co-worker

Recently I was joined by Neil up in Manchester to begin work on Notipal, all we had was a rough idea and a blank Rails project. Many companies may be adverse to the idea of pair programming as it may seem like cutting your resources in half, but you work much more productively because neither of you spend time on IM(Instant Messaging), reading your RSS feed midday, or in any other form of procrastination. You’ll find that working with another person actually makes you feel much more happy, as, believe it or not, you can actually have a laugh whilst programming!

Breaks

“Have a break, have a…”
Source: Pommykiwi @ Flickr

Everyone’s heard the idea of having a 15 minute break away from the computer every hour, and most of us laugh at the concept, we’re too busy for that… right? Wrong! The 15 minutes doesn’t need to be spent stood by the coffee machine, or staring out the window, just not concentrating on your monitor.

Try using the break to update your to-do list on paper or a whiteboard. The time concentrating on what you’re supposed to be doing rather than what you’re actually doing can freshen you up and help you optimise your time, so you’re not sat around wondering what needs to be done next.

Don’t give up on problems

All too often we come to a tricky / boring section of work and we either avoid it altogether or give up when we hit the first problem and work on something else. Try discussing it with a colleague or friend, regardless of whether they are technically minded or not, just by explaining the problem you might realise a much more simple solution.

If all else fails have a break, and then sit down to do some research, avoid rushing into it, but don’t deviate to something else as the knowledge of this problem will disrupt the rest of your work.

Lunch

Everyone engine needs fuel to keep running, not getting the right vitamins and minerals in your diet can lower your immune system and actually cause problems from deficiencies and developers are known to be some of the worst eaters.

A sandwich (preferably homemade), a bag of crisps, some fruit, and a cereal bar is a perfectly wholesome lunch, you push healthy eating as far as you want, but it’s pointless diving in at the deep end as it will just make you hungry and depressed.

If you’re not a big fruit eater, try rewarding yourself with a small amount of something you really like. I enjoy chocolate, like most people, so chucking in a small bar of Green & Blacks dark chocolate can really boost my motivation for other foods. On a side note, dark chocolate is significantly better for you than milk chocolate, there is much less fat and more antioxidants and yet it still releases serotonin, the feel good chemical produced in your brain.

Wind down

Don’t expect to be able to sleep moments after you hit shutdown, you’re mind needs time to relax otherwise you’ll be up all night thinking about what functionality can be added to your application – and while that might seem like a good thing, you aren’t in the right frame of mind to be making decisions on functionality in the early hours of the morning, it’s an easy way to create scope-creep.

My recommendation is to expect to sleep an hour after you finish working, in that hour you should be doing anything that doesn’t require too much concentration, TV is perfect – soaps may be mind-numbing to watch – but that’s the idea! If you have quite an active mind, or drinking copious quantities of energy drinks, you’ll have to extend the hour to two or more.

Routine is another aid for telling your body when it’s time to sleep, if you watch an hour of TV, then have a wash and brush your teeth before bed for a week, you’ll find you will sleep more promptly.

Don’t start too late

So we’re back round to the morning, make sure you’ve not had such a late night, and get up fresh and early, you only need around 8 hours sleep, any over that and you’ll feel lethargic, and most of all you’ll lose that great feeling when you do lie-in on a weekend.

Rails 101: Routing

Sun, 28 Dec 2008 19:55:42 +0000

Routes define what URLs are used to access different parts of your application.

When you run the scaffold generator described in the previous article routes are setup for you automatically but they only setup the default settings, sometimes you need something a little more complex.

In this article, I will show you how routes work and how to set them up yourself. You can download a video version of this article, however the article is more up-to-date.

How Routes Work

You might have heard the phrase ‘RESTful routes’, REST stands for Representational State Transfer and basically makes use of different methods of request to process different actions, this way applications can interact with one another very easily over the standard HTTP protocol.

So how does REST affect you? Well if you are familiar with HTML you will know that forms have a method attribute which is set to GET or POST, however there are actually a few more methods available to HTTP but not included in HTML, these include the PUT and DELETE methods, REST uses these to figure out whether you are trying to create, read, update or delete an item.

POST /users => Create GET /users/1 => Read (show) PUT /users/1 => Update DELETE /users/1 => Delete (destroy)

The standard Rails setup needs a few more actions than these, for starters there is the index action which lists all the items in the collection, this can be accessed by GETing the collection URL, in this example at/users. Other methods by default suffix the collection URL or object URL with their name, however this behavior can be overridden – but we’ll look into that later.

GET /users => Index GET /users/new => New GET /users/1/edit => Edit

Putting The Magic To Work

The routes file is located within the config directory, by default it contains just two routes, both of which aren’t restful and simply act as catch all for non-nested URLs, personally I like to remove these as they let you get away with not setting up your routes properly.

To make our RESTful users section, all you need to enter is map.resources :users, pretty simple right? Rails uses this one command to produce a set of around 14 routes!

You can now test this with a rake command: rake routes.

If you look carefully, you’ll notice that each route has a name associated with it, such as new_user, this becomes useful in our views and controllers where we need to reference the URLs dynamically. In views you suffix the name with ‘_path’, for example new_user_path and in controllers you should use ‘_url’, for example new_user_url, this is because we only want the path in the view (/something), but in controllers you want the full address for use in the API (http://…).

You can setup named routes manually by typing the name of your route after map. When setting up routes manually this way you have to specify a string which is parsed for parameters, the parameters are words prefixed with a colon, like symbols in Ruby.

For an example, here’s a route to disable a user, the route will be called disable_user, and the route will include the user’s ID, and it will call the disable method of the users controller.

map.disable_user 'users/:user_id/disable', :controller => 'users', :action => 'disable'

As you can see, ‘user_id’ prefixed with a colon, this means it’s a parameter and can be reference using params[:user_id]. You can also constrict the parameter using a regular expression, so if we only wanted to accept numbers:

map.disable_user 'users/:user_id/disable', :controller => 'users', :action => 'disable', :user_id => /\d/

Remember I mentioned those additional HTTP methods before? Well we can constrain by them too, by adding the conditions hash to the end containing only one key value pair, I’ll choose “PUT” which describes updating a current record.

map.disable_user 'users/:user_id/disable', :controller => 'users', :action => 'disable', :user_id => /\d/, :conditions => { :method => :put }

If you are going down the RESTful route (no pun intended), you generally won’t be writing your own routes like this very often, most of the time you can add them to the map.resources, so if we return back to our users entry, we can add our disable method to the member hash, which means it acts on one object, not the whole collection. If we wanted a disabled action to list all disabled users we can add it to the collection hash.

map.resources :user, :member => { :disable => :put }

Nested Routes

Another bonus for using map.resources is you can easily nest resources, so for example if a user has a profile, I would nice to be able to have routes like /users/1/profile, and to do this we can just change the current map.resources into a block and drop another map.resource within it, but you don’t use map this time, you use the word between the goal posts, in this case ‘users’.

map.resources :user, :member => { :disable => :put } do |users| users.resource :profile end

We can even refactor this further using the :has_one option:

map.resources :user, :member => { :disable => :put }, :has_one => :profile

There is also a similar option for has_many.

You can now access the profile using more route helpers such as: edit_user_profile_path(user_id)

Special Notes

There are a few special things to note about routes, and those are the root route (again, no pun intended), path prefixing, namespacing, route globbing and shallow routing.

Root URLs

When a user goes to the root URL of your site you often want users to be greeted with a homepage, or dashboard, so to do that simply create a named route called root without a URL string attached to it. In this example, I’ll make it point to the index of the users controller.

map.root :controller => 'users', :action => 'index'

Path Prefixes

Path prefixing allows you to prefix resource URLs with a string such as ‘account’, to make /account/users, this means that you can group various URLs under one section.

map.resources :user, :member => { :disable => :put }, :path_prefix => 'account'

Namespacing

If you have a bunch of controllers that have duplicate names but differing functionality, for example having a front-end ‘notes’ controller which only lists and displays notes, and a back-end one which is protected and has a different layout, then namespacing keeps things tidy.

You will need to group your routes within a namespace block as below:

namespace(:admin) do |admin| admin.resources :user # ... end

And your controller will have to be namespaced too:

Admin::NotesController < ApplicationController

Route Globbing

For route globbing, or in other words catch all routes with an unlimited nesting depth (i.e /random/url/here), you can prefix the parameter with an splat (asterisk) instead of a colon and in your controller and view the parameter will return an array of the parts.

map.page '*path', :controller => 'users', :action => 'page'

Shallow Routing

Recently introduced into Rails is the :shallow option, this allows you to access nested routes as if they were belonging to the root. For example the routes:

map.resources :notes, :shallow => true do |note| note.resources :comments end

Would allow you to use the routes comments_path and comment_path(1) rather than having to use the nested paths note_comments_path(note_id) or note_comment_path(note_id, 1).

Summary

To create RESTful routes, you can use map.resources or resource, depending on whether you want a collection, or singular resource respectively. You can use the :member or :collection options to map additional routes within the resource, :has_many or :has_one to specify sub-routes and :path_prefix to add string prefixes to your paths.

For the homepage you should use map.root which negates the URL option, as it defaults to an empty string.

And for other named routes you simply type map. followed by the name and the URL as a string, for example map.user 'users/:id' then follow it with a hash of options for :controller, :action and any constraints.

Rails 101: Generators

Sun, 28 Dec 2008 17:25:21 +0000

So you’re just about to crack on and dive into that code, but wait, you don’t even need to do that! Rails comes with generators for basic functionality so you can get going as quickly as possible.

Because Rails follows the strict file structure we covered in the previous article, you can have a large amount of files automatically generated for you, because it knows where to put them.

You also can download a video version of this article, however the article is more in-depth.

How?

Now, as I’ve mentioned before, these files aren’t like what is common in Java development where each IDE has it’s own set which can’t be used in another, just plain and simple Ruby classes, modules, and view files.

You can create your own controllers and models etc, but the beauty of generators is you get up and running quickly. The first, and most important thing to note is you can get help on generators at any time by typing script/generate --help

All the generators are called by typing script/generate followed by the generator type and any options.

Scaffolding

To setup your first applications, the easiest thing to do is use the scaffold generator, this not only sets up your model and controller, but a set of view files, a migration, a routes entry and some tests too.

To begin with lets create an application to store some notes. Each note will have a title and some content as attributes, so the command to generate this is:

script/generate scaffold note title:string body:text

Upon running this command you can see it generates a whole bunch of files, but at this moment we don’t need to worry about them, we’ll just migrate the database and boot up our server.

rake db:migrate script/server

We don’t have anything setup for our root page at the moment, so when you navigate to http://localhost:3000/ you will get the default Rails page. But if you go to the notes path at http://localhost:3000/notes you will see that a basic notes section with all the CRUD functionality is available.

Others

You don’t always need to create all these files, sometimes you might just want a model or a controller, in which case you can simply use the script/generate command again, but you can pass model, controller or migration instead depending on what you want.

One thing to remember with generating controllers is that you don’t actually specify the model name like in scaffold or model generations, you actually specify the controller name, which is plural, so script/generate scaffold note becomes script/generate controller notes

Edit > Undo

Finally if you decide you did something you didn’t want to, you can remove any changes by running the same generator but with script/destroy instead of script/generate

YAML Configuration Files

Sun, 28 Dec 2008 17:08:44 +0000

Sometimes it’s nice to have an easy place you can update options without having them hard coded into files buried in your application.

I find it somewhat bizarre that this is not included in the Rails framework, however it’s probably to do with keeping the directory tree clean. Anyway, it’s not difficult to implement yourself.

Creating the file

First we’ll need to create our file. I find the most suitable place for it to be located is _RAILS_ROOT/config/config.yml_, but you can save it wherever. The file will be converted to a hash, with strings as keys so you can nest your configuration as such:

uploads: timeout: 600 max_size_mb: 100

Loading the file

Rather than loading the file in for each request, we only need load it once when the application is booted up, so past the following code into an initializer or the bottom of your config/environment.rb file:

Now you can reference your configuration settings using the constant SETTINGS, e.g:

SETTINGS['uploads']['max_size_mb']

Rails 101: File Structure

Sun, 28 Dec 2008 16:38:26 +0000

When starting a project Rails automatically creates a large tree structure of folders and files, so what are they all for?

You can download a video version of this article.

Creating a Project

To create a project in Rails you need to be in your command line interface. Find an appropriate place to store your applications, for example, if you’re on a Mac, the sites folder is probably your best bet.

cd sites

You can then generate the project by simply using the rails command followed by the name of your project, for example:

rails store

Once all these files have been created. You will want open them in your editor, I recommend TextMate if you’re a Mac user, but anything that has a tree structure for files and ruby syntax highlighting will do.

cd store mate .

Now all these folders might be a little daunting to begin with but I’ll explain them one by one.

app

At the top we have our app folder, coincidently this is the folder which most of the logic behind your application will be put.

Model View Controller

As mentioned in the previous article, Rails uses a MVC format to keep your code organised by separating your code into a logical structure. Imagine a user navigates to a page on your website. Their request is first sent to the relevent controller, which picks out an action, like viewing the index, or updating an item.

The controller then loads the objects, or models it needs and maybe performs some updates on them. Models are, by default, linked to the database via ActiveRecord which means you don’t really need to write any database code (such as SQL) until you’re getting into advanced applications, so that is one less worry.

When the controller is finished detailing with the model it will pass on any information to the view, which will create the HTML, XML, RSS or whatever file format you want, before passing it back to the browser.

You might notice there is also a helpers folder within the app directory, helpers are basically small functions you can write to save you time and tidy your code up in the views.

config

The config directory contains all the files that are used during booting your application. One of the most important files is your database.yml file, which stores your database access details.

The environments folder which stores the different settings your application can run in, the defaults are development, production and test, however some people make a fourth for staging to test performance.

Initializers are used to run pieces of code during boot up of the application, such as setting up an exception notifier like Hoptoad.

Introduced in Rails 2.2.2 was internationalisation or I18n, the locales folder contains the yml configuration files for all your supported languages.

And finally the routes.rb file which basically decides what your URLs look like and maps them to the right controllers. You don’t need to worry about the others.

db

Your db directory will store any file-based databases, such as those using SQLite and the migration files which are basically Ruby-based commands which alter the database as you develop your application, ready for deployment.

doc

You can use the doc directory to store any documentation you might have for your application, or use the rake rdoc command to generate code documentation automatically.

lib

You will use the lib directory to store custom classes for repeat functionality you’ve sliced out of models and controllers.

log

One of the most important features of Rails is the log, the files store all the information you need to know while developing such as what queries are running, the performance of each page etc.

public

Your public directory is mapped to the root URL, so that means that rather than using paths prefixed with /public you can just address the file within the public directory as such: example.com/images/my-image.jpg (as apposed to example.com/public/images/my-image.jpg).

script

In the terminal you will run commands like script/server to boot up the server, these are all stored in the script directory, so you can leave that one alone for the time being.

test

You may have come across the acroynms TDD and BDD, which translate to test driven development and behaviour driven development. What these basically mean is that rather than waiting until the end of your project to test it, you test as you go along, so you will instantly pick up on any issues that might occur when you update your code. Because TDD & BDD are big in the Rails community, the test directory is an important part of the framework.

tmp

Cache files, sessions and process identifiers are stored in here – nothing to be bothered about really.

vendor

This stores any plugins you have installed, the edge version of Rails if you’re using it and any gems you have bundled into your application.

Read the next in the series: Generators »

Rails 101: Introduction

Sun, 28 Dec 2008 15:19:56 +0000

So you want to learn Ruby on Rails? Whether you are comfortable with programming or new to writing your own applications and websites – this guide is for you. This is the first article of many where we will cover everything you need to know to get to grips with programming and building your own web applications with Rails.

We won’t be starting with building a fully blown social network application to rival Facebook or anything of that sort, so don’t worry about being thrown in at the deep end – we’re taking this one slowly.

You can download a video version of this article, however the article covers the topic in a greater depth.

Agenda

Getting started is always the hardest part, so we thought we’d outline a little description of what this article, and subsequent articles, will cover before you commit your time to them.

In this first article we will look at what Rails is, why it came to be, and some concepts you should know about.

Future articles will focus on individual aspects of Rails to develop a deep and broad understanding of how everything works and how it can be moulded to your advantage.

Background

Web applications

So why would you want to write an application? Well as just mentioned: most websites are run from web apps of some description. Many believe “web 2.0” to be the new fad, however it really translates to user-generated content, which we’ve had for years, what do you think the first bulletin boards contained?

SaaS is becoming a popular means of businesses starting up with minimal costs, rather than needing expensive email & workgroup servers, they can use Google Apps, instead of expensive Sage licences, we are beginning to see LessAccounting accounts, the list goes on. If you can develop something that solves a problem for yourself, others are likely to have the same problem, and you should rightfully be able to monetize upon that.

Ruby on Rails

Rails was originally produced as a tool to fulfill the needs of 37Signals in their development of BaseCamp, however after Rails became public it has quickly become one of the best tools for web development.

A main point to grasp is that Rails is not a programming language, but a framework for quick and easy development of web applications, built on top of Ruby (which is a language), hence the name Ruby On Rails. You shouldn’t worry if you don’t know Ruby, or don’t know how to program Ruby I’ve written up an article on The Very Basics of Ruby I suggest you read before continuing.

What sets Rails apart from other frameworks is it’s agile mindset, opinions and paradigms – rather than trying to suit everyone it has focus. Rails employs the idea of convention over configuration whereby it uses defaults for most of the development, usually these defaults will be exactly what you want, but you will still be able to override them if you need something else.

Installation

Ruby

I won’t cover installing Ruby, as I’ve briefly described them in my guide to the basics of Ruby.

Rails

To run Rails you must first have Ruby installed and RubyGems, then it is as simple as: gem install rails

Once you have Ruby and Rails installed, you can start your journey to making millions in the next world-changing web application.

Suggested applications

For Mac users you are lucky as you can use TextMate, quite possibly the best text editor ever invented, however all you need to code Ruby is a text editor (even notepad would do) and a command line interface (terminal, console or command prompt).

Ideas & concepts in Rails

Generators

Rather than creating loads of files manually, Rails builds in generators which create sets of files based on options that you provide. This can mean that you can create a basic application with no code whatsoever!

Model View Controller

Rails is a fully-fledged MVC framework, so your HTML (views) is separate from the data objects (models) and the code which makes changes to such objects (controllers), this keeps everything neat and tidy so you don’t have to dig around to find what you’re looking for.

Currently, the general consensus is that you should have so-called skinny controllers having most of the logic in the models, because the skeleton for controllers is produced in the generators, so keeping them as standard as possible leads to much easier maintenance.

RESTful API

By default, Rails is setup to use the REST protocol as an API to allow other applications to integrate with your own.

Simple routing

Following on from the RESTful API which relies upon URLs and HTTP request methods, it would be a pain to setup these routes manually using .htaccess files and the like, so Rails takes away all this pain by allowing you to specify routes in a Ruby file, but they’ll be covered in a dedicated future article.

Object-Relational Mapping

ORM is a programming technique that links your classes to tables in a database, so you have to write little or no SQL. Rails defaults to SQLite for quick development, but also has adapters for databases such as MySQL.

Where to go for help

The Rails community is going strong and there are hundreds of places you can find help, checkout the official RubyOnRails community page, RailsForum, or you can even leave a comment below!

Read the next in the series: File Structure »

I'm 404'ed

Sat, 27 Dec 2008 12:24:53 +0000

You may have noticed ThinkRefresh has gone through a few changes. Most apparent of all, the layout has changed and my backlog of articles and screencasts has disappeared from the list (you can find them at the bottom of this article though), I have also updated my blog system which I coded in Rails.

Why the change?

Recently I am becoming more involved with a variety of web application projects (some with my good friend Neil), and so I need a suitable system for frequent posting of updates and tips based on my discoveries.

While the blog didn’t need a new layout – I enjoy working on new layouts, and I feel this one is much more professional and generally easier on the eyes.

Will the screencasts and articles return?

Update: most already have, you can find the whole Rails 101 series in the index.

Where can I download the screencasts now?

Below is a list of all the files, right click to save them:

Avoiding Presentation Problems

Fri, 26 Dec 2008 21:58:33 +0000

Recently I have been giving many presentations at university, and also watched others, some dire, some brilliant. You could immediately see who had put the effort in, for whom presentations were second nature, and who were simply let down by their slides.

I am no guru of presentations, but I do like to make notes on others presentations to improve my own work. Because presentations are becoming increasingly common in the workplace and events like BarCamp are cropping up more and more I thought it would be a good idea to pass these notes on.

Keep it simple, but not too simple.

Everyone knows reading from slides will never earn you any brownie points, looking at the top of someone’s head as they peer down at their laptop isn’t appealing, nor is the monotonous mumbling that usually follows, so please don’t reach for copy-and-paste in your essays or blog posts when you are producing slides – if you can’t be bothered to summarise, your audience can’t be bothered to read your slides.

Another recent trend is to make ‘designer’ slides, whereby you focus on your slide being an image, vaguely based on the topic, and limit yourself to just a few words, no bullet points, no diagrams. This technique works very well when you are a confident speaker as the slides can often have a much greater impact on the audience. You should only this technique when your audience are very clued up on what you are talking about though, because bullet points serve as summaries that can help your audience understand your speech, and without them you are relying on your accent, the microphone and what you say being completely clear and understandable.

So in summary, unless you are a well spoken, influential speaker presenting to an audience of gurus on your topic, please stick to concise bullet points. If you need a figure to work to, here is what I work to: a maximum of 5 bullet points per slide, no more than 2 lines per bullet (try to keep sub-5 words though) and no fonts below 18pt (preferably 20+).

Be honest.

My last presentation was about my final year project, a Rails-based e-commerce platform (soon to be publicly released), and you may know I am quite the evangelist of Rails, the ideas, concepts and services which surround it, this rubbed off on the enthusiasm of my talk because I thoroughly believed in my topic. It is amazing how much of a difference a smile, or indeed any facial expression, will influence the mood of your audience.

Involve your audience.

Presentations do not have to merely be one way conversations, you can ask questions too, it’s a great technique to grasp people’s attention. Questions to the audience don’t have to be your typical ‘how many of you…?’ or ‘who knows X, Y or Z?’, they can be rhetorical:

How long do you spend every day trying to debug your web apps, when you could be using X?

While you get no feedback other than the expressions and nodding of the odd person, it makes everyone think about their answer nonetheless.

Practice, but not too much.

Believe it or not, but Steve Jobs probably doesn’t spend weeks preparing his speeches in-front of the mirror, over practicing will lead to a less exciting presentation as you loose the enthusiasm, and besides Steve often has super secret news in his speeches so he can’t risk accidently leaking it.

On the other end of the scale, it’s not the best idea to avoid practicing altogether. Personally I like to run through it from start to finish (timing myself if there is a constraint) on my own, it feels bizarre to begin with, like producing screencasts, because you are talking to yourself, but you get used to it quickly. Once you can present to yourself well, try presenting to a small group of friends, even just one person will do, but try to get people as alike to your target audience as possible, because giving a presentation on Web Ontologies to your Grandma probably won’t get you any useful feedback. There is definitely no right or wrong way to practice, but this should give you a starting point to finding your preferential method.

If you have access to the room where you’ll be giving the final presentation, try to visit it and get a feeling for how loud you’ll have to speak, how many people to expect and the computer setup (or power and networking if you are using your own laptop).

Never, ever, rely upon technology.

In the last presentation I gave all 3 of the presenters, including myself, hadn’t scoped out the room beforehand, luckily I had my Macbook with me, and there was power available so I was fine, the other two ran into problems though. The first logged onto Linux and booted up her presentation in OpenOffice which was a different program / version to what she had used, so her slides did not display correctly, the second couldn’t even log on and required PowerPoint so she couldn’t use the others Linux account, in the end I provided her with my laptop, but it definitely had a negative effect on the audience.

There would have been a simple solution to both of these issues, which is to always export a PDF copy of your presentation and keep it on a USB stick so you don’t have to worry about getting an internet connection. You will loose the animations by using a PDF, but you should always keep transitions to a bare minimum anyway – you are much more likely to impress the audience with a lack of animation, than with an abundance of superfluous effects.

This advice doubles up for live demos, whether you are showing off your new web application or a physical product, keep an emergency PDF of screenshots or photos for backup, Steve Jobs keeps a whole separate Mac for if/when things go wrong during his keynotes, but that might be going a bit far in some cases.

Executive Summary

Keep it simple, but not too simple. Don’t overload your slides, but provide enough information to summarise your topics.
Be honest. It’s obvious when speakers don’t fully believe in something, or are unsure about an idea.
Involve your audience. Rhetorical questions really get those listening thinking.
Practice, but not too much. We don’t want a monotonous voice, but we don’t want ums and errs either.
Never, ever, rely upon technology. Always have PDFs as a backup, and if needs be even print them out.