Alex Young's weblog

Rails tutorial part 1

Alex Young — Fri, 27 Jun 2008 00:04:06 BST

My Rails tutorial (part 1 of 4) has been published in Linux Format 108. It shows you how to build a Rails-powered photo gallery, by using basic techniques and popular plugins.

Grab it from your favourite newsagent and let me know what you think!

We need to talk

Alex Young — Tue, 10 Jun 2008 19:23:46 BST

I’ve been writing technical articles on this blog for 3 years, and never mentioned much about my personal or professional life. Here’s what’s been going down:

I recently got married, and had an incredible wedding on a rare sunny English day in Derbyshire
We honeymooned in Sardinia, and pictures speak louder than words in this case
I took my wife to dinner for her birthday last night, in a restaurant with an incredible view of the River Thames on a balmy London evening. Never felt so good being in London before!
I’ve been writing again, for a magazine based in the UK (more details soon)
I’ve got about a million Rails articles in my head for this blog
My company, Helicoid, just commissioned some incredible illustrations from an artist who was a college friend of mine: check out Craig’s illustrations here
Helicoid’s also got a few secret projects that will be released over the next few months. I’m programming them as usual but getting some design help from a friend, Tom Loudon
Over the course of a year or two, I’ve trained myself in Mac programming and built this: http://flickr.com/photos/helicoid/2535435503/

Oh, and by the way, If you’re a Ruby or Mac developer and want to work with me on any of the Helicoid web applications, please get in touch.

5 great mac tools for programmers

Alex Young — Wed, 28 May 2008 11:35:17 BST

Diff visualisation: Changes

Changes is a fast and friendly diff tool. You can quickly list files that have changed in a project, and view differences between files. It also works with Subversion and Git (and several other version control systems), so it will fit right into your typical workflow. Oh, and it also has a TextMate bundle.

Changes gets perhaps the highest accolade for a mac application: I like Changes so much it actually has a permanent place in my Dock.

Performance analysis: Instruments

Instruments comes with Leopard, so you might already have it on your machine. It’s a performance monitoring tool, which means you can attach it to a process and analyse various aspects of its performance. This is incredibly useful if you’re looking for memory leaks or working on OpenGL performance in native Mac applications.

You can even watch the performance of any processes that support DTrace, which means Ruby programmers can use this tool to inspect everything from CPU profiles to network usage. The screenshot above is of a Ruby on Rails application.

Whilst we’re on the subject of Leopard bundled applications, check out Dashcode as well. It’s indispensable if you want to quickly prototype a widget or iPhone web interface.

Version control: GitNub and svnX

I usually use Subversion through either TextMate’s excellent bundle or the command line, but in sticky situationsI need to visualise things through a GUI. That’s when I reach for svnX, which is a solid enough Cocoa SVN tool.

GitNub is a pretty new tool for working with Git, and is written with RubyCocoa. It seems like they’re working hard on it, so this could become the default tool for Mac Git users. That is, unless there’s something lurking in the shadows waiting to jump out…

Database visualisation: CocoaMySQL-SBG

It’s getting long in the tooth and doesn’t get updated enough, but even so CocoaMySQL-SBG is still my favourite Cocoa database tool. I really wish something would come along with the pedigree of Panic’s software, but there’s been a gap in the market for so long that I somehow doubt it. While there are a few good Java or cross-platform multi-database clients out there, I want to see something with the elegance of Coda that will let me manipulate SQLite, MySQL and Postgres.

Text editing: TextMate, Coda, Vim

I’ve already written a lot about TextMate over the years, needless to say it’s one of the greatest Mac development tools. If you’re more into design or want an alternative, have a look at Coda from Panic. And don’t forget Vim!

Rapid Rails Part 3: Desktop mastery

Alex Young — Mon, 21 Apr 2008 22:32:56 BST

Welcome to Rapid Rails Part 3: Desktop mastery, the third article in my series focussing on making Rails (and yourself) faster.

A good programmer recognises when to reuse and therefore reduce code. A great programmer applies this tendency to their own workflow. Whether you use an IDE or text editor, working with Rails can be made more pleasant and efficient by observing commonly performed tasks and simplifying them.

The examples given below have a heavy bias toward TextMate, Vim and Mac OS. If you work in Windows or Linux, at the very least consider the following 10 ideas.

Ensure you can invoke Rails scripts without leaving your editor
Run tests without leaving your editor
Keep documentation nearby and searchable
Make sure your database schema and data are only key presses away
Integrate source code management with your editor
Make switching between projects as easy as possible
Use snippets, completion and generators when possible
Master your text editor – collect books, articles, blog posts
Learn how to extend your text editor
Code navigation

1. Ensure you can invoke Rails scripts without leaving your editor

Repeatedly visiting the terminal to run Rails scripts quickly gets tiresome. The TextMate Rails bundle allows you to call generator scripts and migrations by pressing shift-ctrl-|. Meanwhile rails.vim provides somewhat abstracted access to these scripts.

2. Run tests without leaving your editor

Running tests in TextMate is as simple as pressing cmd-r when you’re viewing a test file. To show a menu of types of tests to run, press ctrl-\. With rails.vim, you can use :Rake with the appropriate tests.

3. Keep documentation nearby and searchable

TextMate provides documentation for word using RDoc by pressing ctrl-h, which should cut down your trips to http://api.rubyonrails.org. Similarly, rails.vim has the :Rdoc command.

4. Make sure your database schema and data are only key presses away

Hover over a model name in TextMate, then press cmd-ctrl-shift-s—this will show the schema for the model. rails.vim provides integration with the dbext plugin. This is from the rails.vim documentation:

Then, you can use features like table name completion and commands like: :Create database brablog_development

5. Integrate source code management with your editor

In TextMate, press shift-ctrl-a to bring up the subversion bundle’s menu. The commit window is especially user-friendly. Vim has vcscommand.vim

6. Make switching between projects as easy as possible

Stacks were added in Mac OS Leopard, and I find these a great way of grouping my TextMate projects for quick, spring-loaded access. It’s worth getting to know your editor’s project management capabilities. Even though it’s tempting to use scratch projects (with TextMate this is usually done with mate . in the terminal), carefully maintaining your own projects allows you to group files (differently to the file system) and maintain state. Vim supports these features through project.vim.

Of course, there are many ways of quickly accessing projects. Here’s a few ideas:

Use Quicksilver with TextMate
Create memorable shell aliases
Pin them to your Windows start menu, or add a folder
Use a Windows-compatible Start Menu replacement to find project files

7. Use snippets, completion and generators when possible

TextMate has loads of snippets. You can access them by typing a phrase then pressing tab. For example, deft[tab] creates the outline for a unit test case. To search TextMate snippets (or any of the keyboard shortcuts I’ve detailed here), press ctrl-cmd-t to bring up the select bundle item menu. This can also be found by clicking on the Bundles menu.

Also, don’t forget to make the most of Rails generators. Run script/generate to see what’s available.

8. Master your text editor – collect books, articles, blog posts

O’Reilly’s Vim books helped me get to grips with Vim, I used to carry The vi Editor Pocket Reference around in my early days at university and my first job. Searching through Vim’s plugins can yield some useful finds, and there’s even a Vim tips wiki.

TextMate’s manual and Wiki are both great resources.

Another resource I can fully endorse is Peep Code. The TextMate for Rails 2 screencast is detailed and thorough, and comes complete with an indispensable cheatsheet PDF.

9. Learn how to extend your text editor

Vim’s macros can take a bit of getting used to, but this article should set you straight: More Vim: Save Time With Macros. TextMate is a bit easier, but the power of TextMate’s extensibility lies in the Bundle Editor (found in: Bundles, Bundle Editor, Show Bundle Editor.)

Many of TextMate’s bundles are shell scripts or even ruby scripts, and there’s a TextMate ruby library for integrating with the GUI. You can also create your own snippets, which can be useful for quickly writing our your company’s boilerplate file headers. The TextMate manual entry on bundles is pretty in-depth.

10. Code navigation

Some of these features require RubyAMP.

cmd-t lets you quickly search and switch files
shift-cmd-f is Find in Project
shift-cmd-m skips to a method definition
cmd-ctrl-alt-f greps through the project, and is usually faster than Find in Project
cmd-alt-down arrow switches from an action to a view or model to unit test
shift-cmd-alt-down arrow brings up the Go To menu
cmd-shift-t displays the symbol navigator

rails.vim has loads of equivalents, which uses :A (alternate) and :R (related) for easy jumping between files.

Bonus Stage: Workflow-dependent desktops

If you’ve got Mac OS Leopard or Linux you’ve probably tried out workspaces. Why not set up a work-friendly space, with terminals, editors, and everything else all set up so you can access them easily?

Here are a few more ideas:

Use Mac OS’s Automator. Leopard introduced macro-like functionality, so creating workflows is even easier
Make the most of Quicklook in Mac OS
Use smart folders and folder actions (ideas: search for project files, or even search for files that have been tagged in some way)
Try using some widgets: Dashboard

Super-Secret Bonus Stage: Stop working

Play more videogames. You can use the excuse that you’re researching their interfaces for ideas, it’s the perfect crime!

Rapid Rails Part 2: Rapid in the literal sense

Alex Young — Tue, 1 Apr 2008 00:01:29 BST

This is part 2 of the Rapid Rails series. Part 1 featured tips on how to work more efficiently with Rails by making the most of the bundled and related command line tools. This part discusses how to make your Rails application perform faster, with particular focus on server optimisation. Why? Because systems administration requires a very different skill set to programming, and I’ve been often been expected to manage sysadmin tasks on my Rails contracts—and I bet you have too!

I’ve included real-world examples from Linux, Lighttpd, Exim and MySQL because these are what I currently use on most of my servers. If you’re just starting out trying to boost your server performance there are some general principles for you, too.

Rails application performance

People new to Rails are often concerned about its performance in production. In my experience, unless you’re lucky enough to be dealing with a ridiculously popular site, you shouldn’t have major performance issues. However, at the very least you should do the following to every application you deploy:

Ensure database tables are indexed effectively
Employ caching
Identify expensive database queries and look for alternative approaches
Check sessions are managed appropriately for your application. Using ActiveRecord sessions may improve performance

I’ve previously discussed these basic application-based optimisations in Getting started with rails optimisation.

Server software optimisation

If your application performs well under tests, and benchmarks show it performs well, you might be left wondering if there’s any other ways to squeeze more performance out of your server. In all of the commercial Rails projects I’ve been involved in, optimising server software got killer performance gains.

Most server software (especially databases and web servers) are very conservative about memory usage by default. It’s likely you have a lot spare since memory is more affordable than it used to be, so consider increasing caching where possible
If you’re operating a service that sends out large volumes of emails, your MTA probably isn’t configured to perform well under these conditions (especially by default)
Servers are often left configured in a state that “works”, rather than well-tested and verifiably solid

In general:

Track down some good books about your mail, web and database servers
Use system tools like top and iostat to identify any hardware bottlenecks
Turn on logging to record poor performance (MySQL can do this)
Slowly reconfigure software, observing its performance using monitoring tools—don’t paste in “optimised” configurations found second-hand on forums!
Put configuration files in version control, and add comments where possible

Most server software has similar techniques to improve performance. Things to look out for when you’re scanning books and manuals are:

Caching: If you’ve got a few gigabytes spare it’s likely that you can increase cache and buffer sizes for practically anything
Cache optimisation: It’s important to get high cache hits, so check your software can display this information (MySQL will show you with show status like 'qcache%';)
Parallelism: Server software might be still running as single-threaded dinosaurs when they could increase parallelism to run through tasks faster (especially effective with the Exim MTA)
Additional software support: Sometimes even the most mundane tasks can be made faster with additional software. For example, FAM can be used to give lighttpd an extra boost by reducing stat system calls

Monitoring

It’s no good tweaking configuration files if you can’t prove you’ve improved performance, and this is partly why I said configuration changes should be applied slowly over time. The easiest way to get started monitoring your server is Cacti. It’s open source and will tell you a lot about what your server is doing. Since it’ll show you RRD graphs generated over time, it’s easy to see if your configuration changes had any impact.

You’ll also have a lot of monitoring options bundled with your software. MySQL and Exim provide various binaries and logging features for monitoring performance.

Practical server optimisation techniques

Memory, CPU and disk performance tuning

The first tool to familiarise yourself with is top. By pressing F you can select sort fields to analyse the processes running on your system. This is a quick way to view the overall activity of a system.

To get an overall picture of system resources, vmstat summarises memory, paging and CPU activity. To generate results over time, run:

vmstat 10 8

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0    640 146956 3072880 863520    0    0    15    35    1     0  4  1 94  1

This will generate 8 results, with statistics taken every 10 seconds. The vmstat man page explains each column. If you think lack of memory is an issue pay attention to the si and so columns – these represent page in and out, indicating where memory contents are being written to and read from the disk.

To keep track of disk performance, use iostat to produce reports. The format is similar to vmstat, and the manual page details the columns. Run iostat -x and check if any disk has a high %util result. To see which process is responsible for saturating the disk, run ps w and look for anything with a D in the stat column. It’s likely that this process is blocking IO.

Practical scenario: When initially running top to analyse a server, I noticed the Rails ruby processes were using far too much RAM on the system, simply because lighttpd had been set up to run too many processes through FastCGI. Reducing the number of FastCGI processes improved performance because (according to vmstat) the swap was being hit less.

If you’re using Linux, hdparm (for IDE devices) and blockdev are useful tools if disk performance is an issue. You can also benchmark any devices you found performing poorly in iostat:

hdparm -tT /dev/sda

Performance can often be increased by configuring drives with hdparm, older Linux distros often ignored DMA settings which visibly reduces performance. Here’s a detailed write-up on hdparm.

MySQL

Optimising MySQL is in-depth, and full of quirks. Settings vary between storage engines and MySQL versions too. Things to look out for are:

Logging: Turn on log-slow-queries so MySQL can help find slow queries
Query cache performance: Execute show status like 'qcache%'; in MySQL’s console to get an overview of how the cache is behaving, setting query_cache_size in my.cnf to larger values
innodb_buffer_pool_size can be increased depending on your situation

The MySQL performance blog regularly discusses how to optimise MySQL in detail.

Lighttpd

Lighttpd’s wiki includes details on how to optimise for FastCGI, with monitoring too. Beyond this, adding server.stat-cache-engine = "simple" (or fam) can improve overall performance.

Exim

Exim is structured as a set of binaries and processes that handle each part of the mail delivery process. This means that rather than dealing with one monolithic daemon process you’re dealing with a distributed set of tools. When sending out thousands of emails, don’t just loop through your subscriber list and fire off thousands of mails with ActionMailer. Exim will queue a certain number of mails per connection rather than immediately sending them with SMTP. Also, threading will improve performance here by sending out batches in several threads.

General Exim performance tips are:

smtp_accept_queue_per_connection = integer can be increased to match your desired per-connection mail batch
remote_max_parallel = integer forks the delivery process a number of times up to the maximum
split_spool_directory splits message queues into subdirectories which can improve filesystem performance
connection_max_messages increases the number of messages sent to the same host in a single connection
Ensure exim_tidydb is being run regularly with cron

To get a good idea of how these changes affect performance over time, generate reports with eximstats:

eximstats -txt /var/log/exim/main.log

Here’s an example of running exim_tidydb in /etc/crontab:

0 6 * * * /usr/sbin/exim_tidydb /var/spool/exim wait-remote_smtp > /dev/null 2>&1
0 6 * * * /usr/sbin/exim_tidydb /var/spool/exim retry > /dev/null 2>&1

Final tips

In general, change configuration settings one by one, monitoring as you go. This can unfortunately require downtime for your site, but if you keep track of what you’re doing it shouldn’t be too visible to your site’s visitors. Try to identify any hardware bottlenecks before blaming software for your problems: if you know something is using up too much RAM, either buying more RAM or scaling back caching or other settings is better than wasting hours trying to optimise your application’s code.

Server optimisation summary checklist of guaranteed win

Don’t make multi configuration changes at once, observe the impact of each change
Use monitoring tools to collect real evidence on performance changes
Use the tools that come with your server’s software to gauge the overall state of hardware resource allocation, try to identify bottlenecks and potential causes
Don’t accept defaults: Study books on your server software and operating system to properly understand configuration changes
Be proactive: Check with clients if you can book downtime for server maintenance, don’t get caught out trying to improve performance on a live system
Consider using version control to track configuration file changes and share them between servers

Rapid Rails Part 1: Command-line mastery

Alex Young — Thu, 27 Mar 2008 22:04:23 GMT

Rapid Rails is a series of articles containing succinct tips to increase your productivity when working with Ruby on Rails. This is the first part, and shows you how to make the most of the command-line tools that come with Rails.

Quickly generate migrations

The Rails generator script (found inside an application’s directory at script/generate) allows you to quickly create templates for anything you need within Rails. As well as models and controllers, you can also use it to write entire migrations:

script/generate migration AddIPAddressToUsers ip_address:string

The field definition is specified as field_name:type, and you can type in as many as you need for each migration. To read Rails’ help on this feature, type:

script/generate migration

This cuts down the hassle of changing database schemas around, and should be the nail in the coffin for lazy database schema manipulation with GUI tools.

Get more generators

People have written generators to create templates for sophisticated applications, providing a great way of rapidly prototyping an application: Rails wiki generator list.

What was I doing last week?

The Rakefile that comes with Rails contains a handy way of searching for comments with phrases including TODO and FIXME:

rake notes
rake notes:fixme
rake notes:optimize
rake notes:todo

An additional benefit of this is it can increase your understanding of recent code changes, especially when combined with version control logs.

More Rake house-keeping tools

To list all of the rake tasks, type rake --tasks. A few tasks I often use are:

rake tmp:cache:clear
rake log:clear
rake routes
rake db:sessions:create # Creates a migration for ActiveRecord sessions

Get help (and how to cheat)

Getting ruby library help in the command-line is usually ri’s job:

ri FileUtils#cp

The all-round maverick genius Mauricio Fernandez decided ri was too slow, and built FastRI. Not only is it faster than RI, but it can also work in a distributed fashion with Rinda. It’s easy to install and use:

sudo gem install fastri
fastri-server &
fri FileUtils#cp

If this isn’t enough help, why not use cheat sheets from the command-line?

sudo gem install cheat
cheat rails_console

These Ruby-focussed cheat sheets are intuitive, with plenty of tips for those things you can’t be blamed for forgetting.

Testing and command-line flags

If you’re running a unit test and there’s a problem with one test, just run a single test with -n:

ruby test/unit/user_test.rb -n test_authenticate

There’s more flags too, just run a test with -h:

ruby test/unit/user_test.rb -h

Debugging

If you’re really stuck, you can breakpoint and trace to your heart’s content by installing ruby-debug:

sudo gem install ruby-debug

ruby-debug is a more pleasant with autoeval set, so create a text file called .rdebugrc in your home directory and add:

set autolist
set autoeval
set autoreload

Now, run rdebug with a ruby script:

rdebug script/server

Add a breakpoint (obviously set this to something meaningful within your application) and continue execution:

b app/controllers/application.rb:10

The script should now halt at your breakpoint. To read more, check out rdebug’s home and a handy rdebug cheat sheet (or type cheat rdebug).

Reduce password entries during development

If your application uses a version control system on a remote server over SSH, consider creating SSH keys to cut down password entries. To do this securely, use ssh-agent. Read more here: SSH with Keys HOWTO

Speed up your development server: Mongrel and Thin

Mongrel and Thin are great alternatives to the built in Rails web server, and are both faster. To install use sudo gem install mongrel or sudo gem install thin (they’re both fast, thin appears to be slightly faster.) Then run one of the following commands from your application’s directory:

mongrel_rails start

Or:

thin start

Rails now automatically runs mongrel with script/server.

Rails plugin testing guide

Alex Young — Mon, 4 Feb 2008 23:55:00 GMT

This article is an introduction to testing Rails plugins. It’s a relatively lengthy post, so if you’re reading this in an RSS reader flag it and come back when you’re not too busy. It follows the “taxonomy” style of my previous plugin article, A taxonomy of Rails plugins, where examples are used from open source software.

Knowledge of both unit and functional testing is assumed. The following topics are covered:

Testing plugins outside Rails applications
Creating models and fixtures to test with ActiveRecord plugins
Managing a test database schema
Testing ActionPack plugins
Automating with Rake

Testing plugins outside Rails applications

Testing plugins that are tied to a Rails application is straightforward, and it’s tempting to leave things this way. If you need to distribute your plugin to developers working outside your project, or wish to open source it, you may have to do a little bit of work to create a miniature Rails environment to test in. The upside of this extra effort is that it also forces you to think about the plugin in generic terms, often resulting in better design and cleaner encapsulation.

Test directory layout

Most plugins use a test directory layout that is similar to Rails:

test/
  fixtures/
  functional/
  lib/
  unit/
  test_helper.rb
  Rakefile

Many plugins use fixtures/ for both test data and test ActiveRecord models. Some plugins drop unit/ and functional/.

Testing ActiveRecord plugins

If your plugin extends ActiveRecord, you need to create a suitable environment:

Require the ActiveRecord gem (and it the fixtures library)
Setup an ActiveRecord connection. Using in-memory or sqlite databases can minimise configuration requirements
Load the schema
Load the fixtures

Each unit test that requires ActiveRecord will have to do each of these things, so it’s probably best to wrap them all in a class. will_paginate does this by having test/lib/activerecord_test_case.rb (this mocks Rails’ unit test behaviour) and test/lib/activerecord_test_connector.rb (this manages ActiveRecord). Tests that need ActiveRecord functionality then require test/lib/activerecord_test_case.rb.

Another option is to try Plugin Test Helper, but be sure to carefully read the API before using it: it expects your plugin’s tests to be laid out in a specific way.

Bringing up ActiveRecord

Getting access to a database with ActiveRecord::Base.establish_connection is simple:


  require 'rubygems'
  require 'active_record'

  ActiveRecord::Base.establish_connection({
    :adapter => 'sqlite3',
    :dbfile => 'test.db'
  })

It may be advisable to loop through a few database adapter types, seeing as people will have different libraries available in their development environments. Good candidates are: sqlite3, sqlite and memory.

Schema magagement

The easiest and most portable way to define your test database schema is by using ActiveRecord::Schema. For example:


  ActiveRecord::Schema.define do
    create_table "users", :force => true do |t|
      t.column "name",  :text
      t.column "email", :text
    end
  end

A good place to put this is test/fixtures/schema.rb. This file can be opened with load in a suitable schema loading method called before running tests that require ActiveRecord.

Fixtures

Seeing as most plugins will only require a few models, it’s acceptable to load all of the fixtures before testing. Fixtures.create_fixtures can be called like this:


  require 'active_record'
  require 'active_record/fixtures'

  Fixtures.create_fixtures('your test fixture path', ActiveRecord::Base.connection.tables)

Testing ActionPack plugins

Testing controllers and helpers is easier than ActiveRecord. To test a controller:

require action_controller and action_controller/test_process
Create some routes
Create a unit test class
Create a controller class
Write the tests in the same style as Rails functional tests

To test helpers, the most obvious approach is to include your plugin’s helper class inside a unit test, and test each helper method. Since some helpers might expect models you might need to bring up ActiveRecord too, but you could create mock objects with a library like mocha or in some cases by creating suitable OpenStruct objects.

Automation with Rake

Most plugins that provide tests also include a Rakefile to automate running their test suite and generating documentation. Here’s a perfectly valid example from a plugin I picked at random, restful_authentication.


require 'rake'
require 'rake/testtask'
require 'rake/rdoctask'

desc 'Default: run unit tests.'
task :default => :test

desc 'Test the restful_authentication plugin.'
Rake::TestTask.new(:test) do |t|
  t.libs << 'lib'
  t.pattern = 'test/**/*_test.rb'
  t.verbose = true
end

desc 'Generate documentation for the restful_authentication plugin.'
Rake::RDocTask.new(:rdoc) do |rdoc|
  rdoc.rdoc_dir = 'rdoc'
  rdoc.title    = 'RestfulAuthentication'
  rdoc.options << '--line-numbers' << '--inline-source'
  rdoc.rdoc_files.include('README')
  rdoc.rdoc_files.include('lib/**/*.rb')
end

Some Ruby on Rails plugin stats

Alex Young — Mon, 4 Feb 2008 02:04:49 GMT

There are now almost 1000 entries in the main resource for Ruby on Rails plugins, Agile Web Development’s Plugins Directory. Of these, 596 have repositories listed that are accessible. I wanted to see how many of these plugins came with some form of tests, so I created a spider (using a web spider library) and performed some basic analysis on each repository.

After reading a few magazines, and watching two entire TV shows, the spider came back with a result: 54% of the plugins have tests.

It’s amazing to think that there’s almost 1000 plugins in one directory, and a good proportion have tests amongst those I could easily analyse.

Start using Test Driven Development today

Alex Young — Fri, 18 Jan 2008 21:05:40 GMT

Start using Test Driven Development today is a post I wrote over on my company’s blog. It covers how TDD has improved my work since I started Helicoid Limited, and how you can start using TDD right now.

Learn how to write basic tests in your chosen language – don’t worry about fully learning the test framework, start by copying examples
When adding a new feature, start by creating tests first. Write code to satisfy these tests
Refactor old code to work well with automated tests
Write test data carefully and patiently, using this as a design technique for exploring the quality of your data modelling
Find a mocking library so you can write encapsulated tests that don’t require external resources
Find a tool for producing coverage reports in your chosen language
Investigate automated testing triggered when deploying/releasing code

10 essential ruby gems

Alex Young — Tue, 8 Jan 2008 01:07:05 GMT

Despite leaving it for a while, I’m going to continue my previous article, “A taxonomy of Rails plugins”, relatively soon. I’ve been inspired by the excellent plugins by errfree and come up with a few ideas of my own during the heavy workload of 2007. In particular, I’d like to clarify testing Rails plugins. But more of that in the near future.

For now, have a look at 10 essential ruby gems. It’s hosted on my company’s new blog, where you’ll eventually find more articles by me with a greater emphasis on web design.