Jenkins/Hudson

Caveat

VMWare

• Clients (consisting of different target OS/Browser combinations
• Application Servers (consisting of the supported OS/Application environments
• Database Servers (consisting of supported back-ends)

1. Ideally, you have enough physical RAM to hold all VMs in memory without swapping.
2. Drives which have fast IOPs reduce disk contention (important for Windows VMs which like to swap)
3. CPU allocation should not exceed actual number of Cores/Threads

Supplementary Services

DNS/DHCP

NTP

HTTPS

Ant

Pre-automation

1. Set the test build to use for the clients.
2. Set the app build to use for applications.
3. Execute application config pre-conditions such as setting configuration information.
4. Start the VMs in the order of their dependencies; usually the database first, followed by the application server, and lastly the client VMs being used. Ant allows for the use of the elements and . Generally, database and application starts occur sequentially, but client VMs can be started in parallel.

Test Execution

1. Execute tests on client VMs.
2. Collect test artifacts and results and publish them to a known location.

Post-automation

1. Suspend all VMs in parallel.
2. Revert the VMs to their base snapshots. This step ensures that the VMs are ready for the next test execution run

• propertyregex - Performs regular expression operations on an input string, and sets the results to a property.
• timestampselector - The TimestampSelector task takes either a nested element, or a path reference, and sets either a named property, or a path instance to absolute pathnames of the files with either the N latest or earliest modification dates
• sshexec - Runs a command on a remote machine running SSH daemon.

Miscellanea

TODO : Grid and Automation in the Cloud

• application URL
• username & password
• browser type

Reference Datasources

Test Organization

JUnit

JBehave

Versioning

Test Context

What's Next?

• Firefox
• Chrome
• Internet Explorer
• Opera

Acceptance Tests

Smoke Tests

Specification Tests

Regression Tests

Performance Tests

One and the Same

Domain-specific Languages (DSL) To The Rescue

1. Specifications can be written in plain text.
2. Specifications use a structured syntax that clearly expresses pre-conditions, steps, and expected outcomes.
3. Specification encourage stories to be written in the point-of-view of a User of an application. This allows allows for specifications to be defined for different perspectives given a User's role within an application.
4. Instead of tests expressing operations at the component (Element) level, instead they describe functionality in the context of individual user operations (Scenarios) grouped by functionality (Stories).
5. Stories are reusable a pre-conditions of other stories.
6. Parameterized steps allow for table-driven input. This effectively removes the need for tools like Fitnesse. Both input and output can be specified with the test.

Caveat Emptor

The Grid

What's Next?

WebDriver is an API

This is the role of the framework; to support automation using reusable abstractions against an evolving application.

Web Application Automation Concepts

The Reusable Element

XPath is Regex for the DOM

The Reusable Page

The Hierarchical Application

The Process Oriented Application

The Case Against WebDriver.PageFactory

Putting it All Together

The Case For the Use of Fluent Interfaces

Degrees of Freedom

"Everything should be made as simple as possible, but not simpler."

The Application Changes : An Element is added/modified/removed

The Application Changes : A Page is added/modified/removed

The Automation Framework Changes

The Target Web Browsers Change

What's Next?

Part 1 - Plan for Change

Part 2 - Testing for the Common Man

Part 3 - Organization is Key

Part 4 - The Automation Environment

Subversion

Subversion running locally on my MacBook Pro requires that the Remote Login privilege be enabled to support svn+ssh secure tunneling mode. For some strange reason, the upgrade to OS X 10.6 disabled this privilege breaking my ability to connect to my subversion server. Luckily, my installation notes reminded me of this requirement and after a visit to System Preferences -> Sharing, I was able to restore access.

PostgreSQL

As I documented with my previous post, the custom PostgreSQL user I created to run the database was deleted by the upgrade. This oversight did not extend to the database installation itself, but recreating the user did not automatically restore database functionality. After a bit of digging around, it seems that my previous PostgreSQL user was assigned a different user id. A peek at the ownership privileges on the database files and directories revealed ownership permissions which did not correspond to a valid system user. A quick chmod -R fixed the permission problem and allowed PostgreSQL to be started correctly.

Fink Commander

I've been using Fink Commander to manage packages I've installed on my system over the last two versions of OS X and encountered no obvious upgrade problems when migrating to newer versions of OS X. This changed with Snow Leopard. After upgrading to 10.6, I noticed that despite having updated Fink via the command line, Fink Commander refused to display any package information. Despite an exhaustive search when I first upgraded to Snow Leopard, I was thwarted; I had no clue how to fix this issue. Jump forward a few months and it seems that I was not alone: a solution was finally posted. Due to the number of different perl binaries packaged with OS X, an explicit path to the older perl binaries was required. Under Fink Commander 0.5.5, this path can be set by navigating to Preferences -> Paths -> Paths to Perl. For OS X 10.6, this value should be /usr/bin/perl5.8.9. The original post can be found here.

Mysteries solved.

After upgrading to Snow Leopard (OS X 10.6), I noticed that the PostgreSQL user I created for development using dscl had suddenly disappeared. Apparently any users that are not created through System Preferences -> User Accounts are excluded during the upgrade process. Strangely, the group associated with this PostgreSQL admin user was still present after the upgrade. It was trivial to restore functionality, but a bit irritating. At least I wasn't stung by the Guest user fiasco that has been finally fixed in 10.6.2.

Now that's out of the way, why is my subversion launchd entry being ignored? Hrmmm ...

IR/EyeTV Oddities

Another thing I noticed was the complete miscommunication between the IR Remote that came standard with older Macs and EyeTV. IR controls were either mismapped (resulting in strange interactions with EyeTV) or completely non-functional. Thankfully, this was resolved easily with the installation of Candalair - an alternative driver for internal Apple IR Receivers. By enabling Leopard Compatibility Mode, things were back to normal. This is obviously a known problem given the very existence of a compatibility mode, but why won't Apple actually fix the problem?

Printing?

One of the primary reasons for me considering OS X a few years ago was the tight integration of device drivers (for things such as printers) with the OS. I was tired of trying to configure PS emulation for standard photo printers in Linux. Printer configuration was by far the biggest PITA under free *nix varieties. Being able to install a printer painlessly was, for me, a true measure of usability.

Boy, have times changed. Where as my initial experience with 10.4 was the pleasant surprise of "wow that worked the first time", Snow Leopard has changed this process into an all too familiar experience of disappointment. Broken driver support for a slew of existing printers formerly supported by Leopard (10.5) was painful, to say the least. The process of upgrading the drivers with Apple's driver fix failed to notify users that existing print queues would NOT function until they had been recreated was completely obtuse in a way reminiscent of Windows. Oh well, so much for the usability advantage.

To see just how badly this process has devolved, try setting up a Canon Pixma 420 for wireless network printing. A friend of my got one of these with his new iMac, and nothing short of a herculean effort got this printer to work with OS X. Can you say "obscure"?

Quicktime X Black Screen

A new and improved Quicktime was supposed to be a boon to Snow Leopard. Unfortunately, right out of the gate, Quicktime X support in Front Row was broken for almost all files. Attempting to play any media files in Front Row resulted in a black screen with no audio or video. 10.6.1 at least restored the ability to play .avi files, but I had to wait until the recent 10.6.2 update to finally have support restored for .mkv's. What happened to releasing a functional product? Given legacy Quicktime support is available in Snow Leopard, wouldn't it have been prudent to wait until this version of Quicktime was ready for prime time before releasing it for public use? At the very least, it shouldn't have broken existing functionality. Where are the QA regression tests?

At What Cost?

I understand the primary motivation behind any public company is profit and Apple is no exception. But what is the cost of relentless push for greater market share if they start to diverge from their core philosophy of "just works"? From a consumer standpoint, there are increasingly compelling reasons to question Apple's current strategies, specially if it comes at the cost of keeping existing customers satisfied. I purchased Apple products because I did not want to contribute to the cycle of "disposable" electronics. Little did I know that by design, this is exactly what I've ended up with.

Hackintoshes are looking better every day ...

Another case in point; the iMac I bought around the same time as my Macbook Pro began to exhibit extreme instability due to the faulty cooling design of the GPU in the enclosure. I only found out about this when I attempted to replace the GPU itself. While I can appreciate the design chops that it takes to design increasingly thinner computers, what about actual engineering chops to ensure that the thermal envelope of the enclosure does not lead to premature component death? At the heart of the problem was a single measly cooling fan responsible for the passively relocated heat generated from the CPU and GPU. Active cooling should have been applied separately to the CPU and GPU to ensure adequate cooling. At the very least, the GPU heat sink should have been placed before the CPU heat sink in terms of fan proximity; after all, the CPU is not always busy, but the system cannot function without a working video card. At first, I thought that this problem could have been attributed to faulty capacitors in the NVidia 7300 GT GPU; an issue that has already been addressed in the Mac Pro versions of these cards. But a quick look in the Apple forums revealed that this is a problem endemic in ALL Merom based iMacs (the 20"/24" white plastic varieties manufactured around 2006/2007).

After spending 4 hours disassembling the iMac, I came to the realization : these machines are DESIGNED FOR OBSOLESCENCE. From the obscure torx screws, to the insanely difficult access to components, I got the message loud and clear. These machines do not have field replaceable components. Without this fundamental capability to recycle existing functioning components, what I was left with was a two and a half year old computer that I'd paid a huge premium for that was designed to be rendered unusable by simple hardware failure that is easily remedied in your run-of-the-mill PC.

Luckily, my local Mac dealer was willing to get me a replacement GPU and with a little elbow grease, I was able revived my machine. Consider what would have happened if someone else without a technical background was affected. The cost of the replacement card was +$200. Once labour and taxes have been factored in, it would have cost $600 to fix the iMac with a video card that is laughable by today's performance standards. Whether you are discouraged by Apple through the inability to repair your machine with FRUs or the exorbitant cost of an out of warranty repair which makes buying a new machine a "feasible" alternative, the result is the same : electronic waste with a huge environmental impact. My only recommendation going forward for all Apple purchasers is to buy the extended warranty. It is cheaper than a single out of warranty repair, but still seems like an unnecessary cost considering the price premium we initially pay which should equate to "a more reliable" machine.

With any luck, the iMac issue will be addressed in a class action suit or a public acknowledgment and an out of warranty replacement/reimbursement. At the time this article was written, Apple still has not acknowledged any culpability with regards to this issue. If you too are facing this issue, add your voice here at PetitionSpot.

Shame on you Apple; the greenwashing of environmental issues is a blight on your record. If this is the cost of your current popularity, I smell a worm.

Unfortunately, traditional means of discovery have been increasingly tainted by commercialism. Thankfully, the Net is a big place with lots of great alternatives. One podcast that I'd like to recommend is NPR's All Songs Considered with Bob Boilen. I can't say I agree with all of his choices, but a few have been bang on. As a tribute to this new find, I'm finally updating my current listening list:

• Asobe Seksu - Transparence
• Alistar Blaik Bundale - The Day
• The Gaslight Anthem - The '59 Sound
• Mesmer - Teenage Dreams
• White Lies - Taxidermy
• Gooseflesh - Still Wild
• Bad Lieutenant - Sink or Swim
• 5 Cent Theatre - Shifting Sands
• Mumm-Ra - She's Got You High
• Chambers - Sea Mistress
• Kurt Vile - Overnite Religion
• The Coast - Nueva York
• Kanute - Not Sleeping
• The Love X Nowhere - Northern Time
• Phantogram - Mouthful of Diamonds
• Beat Radio - Memoir of Lightening
• Land of Talk - May You Never
• The Exploding Boy - London
• New Found Land - Leave It Behind
• Goyte - learnalilgivinanlovin
• Brite Lite Brite - I Just Want U 2 Myself
• Miracle Fortress - Hold Your Secrets to Your Heart
• The Pains of Being Pure at Heart - Higher than the Stars
• Bye Bye Bicycle - Haby Baby
• Evan Voytas - Getting Higher
• Ou Est Le Swimming Pool - Dance the Way I Feel
• Red Wire Black Wire - Compass
• Downtown Union - Bright Idea
• Wild Beasts - Brave Bulging Buoyant Clairvoyants
• The XX - Blood Red Moon
• The Ties and the Lies - August is for City Lovers
• Choir of Young Believers - Action Reaction
• Gossip - Music for Men
• The Swell Season - Strict Joy
• Oliver Schroer - Camino

Added to my regular rotation of Muse and Kings of Leon, these tracks ensure that I don't suffer from listening fatigue.

I've been ghosting YCombinator's Hacker News and one of the most interesting articles I recently read was by Martin Fowler on the idea of Technical Debt. Coined by Ward Cunningham, the idea is simple - taking a quick and dirty approach to a solution burdens a project with technical debt. This debt is the future effort required to refactor existing code into something more elegant, and ultimately more useful. While the concept explains why people may choose trade-offs in the name of expediency, what struck me most about the metaphor is how the role of testing in the development process could offset this technical debt as a form of "insurance". Tests preserve the original requirements without necessarily committing a developer to a specific implementation. So long as the implementation preserves the requirements, this technical debt can be managed.

One of the most direct measurements of software productivity is the ability to deliver on schedule. By accumulating technical debt, part of your development time is spent either servicing the costs of that debt (by having to code around the original hacks) or paying down the principle (by refactoring). This is the true cost of technical debt. When this debt begins to dwarf the principle value of an application, it is all to easy to default on this debt by slipping deadlines. While tests do nothing to reduce this debt, they prevent it from accumulating additional interest. Without tests, the situation quickly becomes untenable. Instead of Insurance, what you have is a Credit Default Swap. At this point, productivity is a synthetic derivative which has no bearing in reality. All productivity is lost in Complexity.

Put another way, is it possible to pay down technical debt without tests? I'm inclined to think not.

Since we're using economic metaphors, I'll use the prophetic words from the Oracle of Omaha which illuminate the cost associated with testing:

Price is what you pay, value is what you get.

The price incurred for having to implement and maintain tests far outweighs the value they provide for your application. The only certainty in development is that requirements will change as a program evolves. Tests are insurance against these "known unknowns".

As with all my articles, comments (not spam) are welcome.

So I'm 8 episodes into season one of BSG when the first glaring discontinuity raises it ugly head. Faced with the dilemma of finding a method for being able to detect Cylon infiltrators, the BSG crew serendipitously find a live copy of one of the two known Cylons/Human chimera in existence. Instead of using the Cylon to verify their screening procedure, they eject him out of an airlock. WTF!!! Using Boomer as the first beta candidate could easily have been attributed to a false positive, but comparing the outcome of her test against a live Cylon baseline would have given them the ability to identify both another Cylon in their midst and repudiate the unsubstantiated claim that Adama was a Cylon. What were the writers thinking?

In general, I like the whole re-imagining of the BSG universe with the Manchurian Candidate take on the Cylon infiltrators and the moral quandaries faced by the survivors, but this type of oversight does not bode well for the rest of the series. Hopefully it won't be quite as bad as the season finale I had the unfortunate privilege of watching out of context. When Boomer returns to the Viper without a helmet, the jig's up. Doh!

It took me a while to figure out how to get Fink to install ImageMagick and the RMagic gem for use with attachment_fu and I thought I would share my method. From the #rubyonrails channel on freenode, it seems that I am a Luddite; most users prefer MacPorts. As I've written before, I think there is value in understanding the ports system you are using in OS X and that there be a clear separation between system binaries and those you add yourself. Polluting the /usr directory with unsupported 3rd party code can only lead to heartache. It also helps to acknowledge the underlying software dependencies in case your production environment varies from development (which is my case). That being said, I've provided the link for those who just have to use MacPorts.

ImageMagick & Fink

Before the rmagic gem can be used, ImageMagick needs to be installed on the machine. Fink is great at being able to build from source and resolving dependencies, but in this case, it took a bit of coercion to get ImageMagick installed. At various points during dependency resolution (for ghostscript and dbus-dev), I was required to abandon FinkCommander and issue the following commands from a Terminal:

# fink scanpackages
# sudo apt-get
# sudo apt-get install ghostscript=8.61-5

# fink scanpackages
# sudo apt-get
# sudo apt-get install dbus-dev=1.2.6-1

I'm assuming that order is important in the dependency resolution process, so I included both sets of commands which needed to be run separately at different points in the installation process.

This eventually installed ImageMagick, but unfortunately, the default configuration included the dreaded --enable-hdri option. Fixing this required digging into Fink source code management internals. By default, Fink keeps ports metadata information in .info files which are arranged based on stable/unstable trees as well as by function. For ImageMagick, the relevant files were located in the /sw/fink/10.5/unstable/main/finkinfo/graphics directory. A grep against the ImageMagick files revealed that imagemagick-nox.info and imagemagic.info both contain the option. Simply removing it from these files and rebuilding the ImageMagic port resulted in an rmagic compatible installation.

# fink rebuild imagemagick

There are a number of supplementary packages that are required to build rmagic; I've included a list of the required ports:

# imagemagick
# imagemagick1-dev
# imagemagick1-shlibs
# imagemagick1-svg

In particular, be sure to have the imagemagick1-dev port installed, otherwise Magick-config will not be installed which is required for gem installation.

scripts/plugin fail

I usually try to follow the path of least resistance - In this case, it was to use the built-in plugin managment utility in Rails. Unfortunately, no matter how I spelled rmagic, the plugin could not be found in the sources packaged with 2.2.2. I even tried to find the plugin with rapt. C'est la vie.

RMagic Installation from Source

Although the preferred method of installing Rails components is by using gem, OSX's fonts break the rmagic tests that run when documentation examples are being generated. This leaves the method of last resort - installing from source. The trick is to change the allow-example-errors=no parameter to yes in the .config located in the source directory. Once this is done, run the following commands:

# sudo ruby ./setup.rb
# sudo ruby ./setup.rb install

Presto! At this point RMagic should be installed on your system. You can verify by running the following commands (as per the MacPorts installation doc):

# irb -rubygems -r RMagick
>> puts Magick::Long_version
This is RMagick 2.9.1 ($Date: 2009/01/12 23:08:35 $) Copyright (C) 2008 by Timothy P. Hunter
Built with ImageMagick 6.4.1 02/25/09 Q16 http://www.imagemagick.org
Built for ruby 1.8.6
Web page: http://rmagick.rubyforge.org
Email: rmagick@rubyforge.org

All in all, the process is not unlike a contortionist attempting to pick their nose with their pinky toe .... doable, but certainly uncomfortable. Comments welcome.

You can't really follow the the Test Driven Development methodology without writing tests as you develop. While the ROR documentation is fairly complete to get started on building an application, the organization of the documentation (as well as most reference material) seems to put testing at a lower priority in the context of the learning the Rails platform. It would be nice if the documentation illustrated TDD within the examples as well.

Fixtures

Rails provides a facility for quickly creating reproducible testing data through YAML fixture files. The key point of using a fixture as of 2.2.2 is that it is essentially a fully fledged ActiveRecord. When you run a test against a feature, one of the first things that happens is that Rails populates the database table with the fixture information. It is important that your fixture YAML file is syntactically correct - if the data specified in the file references an undefined column or violates a database constraint, Rails will fail to run the test and generate a whack tonne of arcane error messages. Don't do this unless you like to read stack traces.

Strange Boolean Behavior. If validates_presence_of is placed on a boolean attribute, it can only be assigned true values within the fixture. Attempting to assign false to the fixture attribute will break unit tests with the following error:

Attribute_name can't be blank.
 is not true.

In addition, when assigning boolean values within tests, you cannot use the false keyword. Doing so will create an invalid record. The numeric convention to assign true or false is to use 0 and 1 respectively.

Validation of Date versus DateTime Objects. Fixtures can use eRB to embed ruby code within the fixture itself. Unfortunately, when it comes to Date / DateTime attributes, the object returned by the fixture record is database dependent. In most cases, to validate date/time attributes requires using the strftime comparison. There is no way to get a Date object from a DateTime object. Seems intuitive, but Rails does not provide this facility. For simplicity, I've included the format parameters for posterity:

%a - The abbreviated weekday name (``Sun'')
%A - The  full  weekday  name (``Sunday'')
%b - The abbreviated month name (``Jan'')
%B - The  full  month  name (``January'')
%c - The preferred local date and time representation
%d - Day of the month (01..31)
%H - Hour of the day, 24-hour clock (00..23)
%I - Hour of the day, 12-hour clock (01..12)
%j - Day of the year (001..366)
%m - Month of the year (01..12)
%M - Minute of the hour (00..59)
%p - Meridian indicator (``AM''  or  ``PM'')
%S - Second of the minute (00..60)
%U - Week  number  of the current year,
        starting with the first Sunday as the first
        day of the first week (00..53)
%W - Week  number  of the current year,
        starting with the first Monday as the first
        day of the first week (00..53)
%w - Day of the week (Sunday is 0, 0..6)
%x - Preferred representation for the date alone, no time
%X - Preferred representation for the time alone, no date
%y - Year without a century (00..99)
%Y - Year with century
%Z - Time zone name
%% - Literal ``%'' character

t = Time.now
t.strftime("Printed on %m/%d/%Y")  
    #=> "Printed on 04/09/2003"
t.strftime("at %I:%M%p")            
    #=> "at 08:56AM"

Attempting to resolve the fixture issues highlights one of Rails glaring deficiencies - the lack of authoritative, comprehensive documentation. From IRC, to the blogs I researched to troubleshoot these issues, it was apparent that everyone had rather unsubstantiated opinions regarding built-in testing facilities on Rails which were largely incomplete. No application is perfect, but this is a rather obvious omission.

testhelper.rb

By default, the testhelper.rb file has the fixtures :all parameter enabled. If your scaffold YAML files are not valid, this setting will only throw a lot of unintelligible errors. To build up your test suite one model at a time, it might be useful to simply have a script with ruby commands to run tests you've already finished. For example, I have a file that I've chown to be executable which contains commands to run individual tests.

ruby unit/model1_test.rb
ruby unit/model2_test.rb

The testhelper.rb file is not all bad. In fact when used in it's primary capacity, it's quite useful. For example, instead of writing custom assertions for my unit tests, I placed a bunch of these in testhelper.rb. This allows you to follow the DRY (Don't Repeat Yourself) principle an simplify test suite creation. Combined with TextExpander, it's positively stunning how quickly you can create a fairly thorough test suite for a model. I've included some of my custom assertions so that others don't have quite the barrier to entry that I encounter:

def assert_not_valid(object, 
    msg="Object is valid when it should be invalid")
  assert(!object.valid?, msg)
end
alias :assert_invalid :assert_not_valid
  
def assert_presence_required(object, field)
  # Test that the initial object is valid
  assert_valid object
   
  # Test that it becomes invalid by removing the field
  temp = object.send field
  object.send "#{field}=", nil
  assert_invalid object
  assert !object.save, 
    "Cannot save record with invalid #{field}"
  assert object.errors.invalid?(field), "Invalid #{field}"
   
  # Make object valid again
  object.send("#{field}=", temp)
end
     
def assert_has_attribute(object, field)
  assert object.has_attribute?(field), 
     "#{object}.klass is missing #{field}"
end
	
def assert_doesnt_have_attribute(object, field)
  assert !object.has_attribute?(field), 
    "#{object}.klass is includes #{field}"
end 
	
def assert_has_readonly_attribute(class_type, field)
  attribute = class_type.readonly_attributes.find { |attr| attr == field }
  assert_not_nil attribute, 
     "#{field} read only attribute was not found."
end
	
def assert_required_length_less_than(object, field, length)
  duplicate = object.dup

  # Valid at length-1
  duplicate.send "#{field}=", "a"*(length-1)
  assert_valid duplicate

  # Valid at length
  duplicate.send "#{field}=", "a"*length
  assert_valid duplicate

  # Invalid at length+1
  duplicate.send "#{field}=", "a"*(length+1)
  assert_invalid duplicate
  assert duplicate.errors.invalid?(field), 
    "Invalid length of : #{field}"
end
	
def assert_inclusion (object, *list)
  assert list.include?(object), "#{object} not in #{list}"	
end
	
def assert_numerical(field)
  assert Integer(field) || Float(field), 
    "The field is not a number."
end
	
def assert_positive_number(field)
  assert_numerical field
  assert field > 0 , "The field is not a positive number."
end
	
def assert_negative_number(field)
  assert_numerical field
  assert field < 0 , "The field is not a negative number."
end
	
def assert_uniqueness_of(object, field)
  duplicate = object.clone
		
  assert_invalid duplicate, 
    "The #{field} attribute must be unique."
  assert duplicate.errors.invalid?(field), "Invalid #{field}"
end
	
def assert_inheritance(object_class, object)
  assert_kind_of object_class, object, 
     "#{object} is not a kind of #{object_class}."
end

Pluralization Conventions

One of the things that I needed to get used to was the use of pluralization of objects in Rails. From table names in migrations, to polymorphic has_many associations, being able to specify either single or multiple objects requires being aware of when rails expects plurals. As I mentioned in a previous article, pluralization is controlled through inflections.rb. This is something to reiterate again, unless you want to learn the hard way.

Counter Cache attributes. A counter cache attribute added to a model, is expected to be a pluralized (and possibly inflected) name. For example, to add a Comment object counter cache to another object requires the comments_count attribute to be present.

Limitiations of Single Table Inheritance

The implementation of object inheritance in Rails can only be described as extremely rudimentary. As per Fowler's description of this pattern, a single table is responsible for all base and subclass data. While this is great for subclasses that simply add attributes to a base class when they are subclassed, this does not work so well when derived subclasses have different attributes.

Lack of Class Attribute Encapsulation. Essentially, Rails implementation of STI does not allow subclasses to specify which attributes belong exclusively to themselves. An attribute that is available from one subclass is automatically available to all sibling subclasses. There is no mechanism to disable attribute accessors for certain classes, and enable them for others. It seems the only advantage of STI in rails is to provide convenient way to encapsulate methods and provide a mechanism for storing an object Class name in a table. Not exactly what I would consider Object Oriented .... While it has been suggested that attribute accessors can be overridden within the models, this seems like too much of hack that could have unintended consequences with regards to ActiveRecord behavior. The trade off is to probably code in logic in the classes to ensure that only certain attributes have valid values - the lesser of two evils.

Storage of Class Name as the Base Type in Associations. If polymorphic associations are used in conjunction with STI, the association_type by default must be the base Class name. If it is the actual class name, the association will fail. There are hacks that will allow the actual Class name to be stored by overriding the association_type attribute, but doing so is less than all encompassing. For example, having :dependent => :destroy conditions on the association will fail when this hack is implemented. This would then require manually destroying associated objects. Not really a great compromise in my opinion.

Miscellaneous

Sometimes things just don't work the way you expect them to. In most cases, it's probably just a case of the documentation not being updated with changes in the code. One particularly pernicious bug was the way in which ActiveRecord deals with obj.clone versus obj.dup.

• ActiveRecord handling of obj.dup vs obj.clone

Limitations actually a Good Thing?

• Enterprise Rails

While these limitations suggest that these areas of Rails are under developed, Martin Fowler has an interesting take on the rigidity shown by the core rails team to solving "enterprise" problems. In his article he suggests that Rails resistance to antiquated conventions which give strength to the existing system. This goes to prove just because you can do something, doesn't mean you should (such as attempting to create an Object Relational Mapper for Rails - RHibernate anyone?).

I reserve the right to withhold judgment ...

Cornerstone

I can't say enough about Subversion, but trying to keep track of changes between commits and doing diff comparisons with your working set versus the last revision is nothing short of a PITA. Thankfully, there is mature, stable graphical Subversion client for OS X - Cornerstone. It does a great job of abstracting various Subversion operations and does not suffer from extreme featuritis. Give it a try if your tired of looking up man pages to get just the right svn syntax.

Araxis Merge

While diffing files is old hat, the output is just barely human readable. Too much effort is expended by the user trying to visually grep the output. They say a picture is worth a thousand words, in the in spirit of "Ut pictura poesis" I would have to agree when using a visual diff tool. Having side by side comparisons greatly improves the ability to use diffs in a more coherent manner. Thankfully, Araxis has ported their flagship Merge tool to OS X. Like Cornerstone, the features are implemented with minimal clutter. This allows it to integrate cleanly into an XCode based work flow. With its seemless integration with Cornerstone, checking working copy diffs to a source code repository can't get any easier.

O'Reilly Safari

Do your self a favor and forget the forest of books that inevitably become obsolete and sign up for a Safari subscription. Technical books have a limited shelf life. Prevent become antiquated and get the latest documentation without the hassle of having to lug around a dead tree. It's not that I don't like physical books, but the rate at which technical documentation evolves makes it unrealistic to have a well stocked reference library without having to spend a fortune. Combined with the BookBag iPhone app, you can have your cake and eat it too.

Required database.yml parameter : database

The database.yml file requires the database : parameter in order to establish a valid connection to the database for a given user. This parameter was not present in earlier versions of the database.yml configuration file. See below for more details documentation regarding the PostgreSQL connection adapter parameters.

Database Adapters: pg versus postgres

At the time of writing this (against rails 2.2.2), there still seems to be a preference in the Rails framework for the pg driver over the postgres driver. Without the pg driver installed, the following error is displayed to the user :

/Library/Ruby/Gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:74:in `establish_connection': Please install the postgresql adapter: `gem install activerecord-postgresql-adapter` (no such file to load -- pg) (RuntimeError)
	from /Library/Ruby/Gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:58:in `establish_connection'
	from /Library/Ruby/Gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:53:in `establish_connection'
	from /Library/Ruby/Gems/1.8/gems/rails-2.2.2/lib/initializer.rb:392:in `initialize_database'
	from /Library/Ruby/Gems/1.8/gems/rails-2.2.2/lib/initializer.rb:139:in `process'
	from /Library/Ruby/Gems/1.8/gems/rails-2.2.2/lib/initializer.rb:112:in `send'
	from /Library/Ruby/Gems/1.8/gems/rails-2.2.2/lib/initializer.rb:112:in `run'
	from /Users/mel/Documents/Workspace/vuespace/src/config/environment.rb:13
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
	from /Library/Ruby/Gems/1.8/gems/rails-2.2.2/lib/commands/generate.rb:1
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
	from ./script/generate:3
aleph:src mel$ gem install activerecord-postgresql-adapter
ERROR:  could not find gem activerecord-postgresql-adapter locally or in a repository
aleph:src mel$ sudo gem install activerecord-postgresql-adapter
Password:
ERROR:  could not find gem activerecord-postgresql-adapter locally or in a repository
aleph:src mel$ sudo gem install activerecord-postgresql-adapter
ERROR:  could not find gem activerecord-postgresql-adapter locally or in a repository
aleph:src mel$ sudo gem -r install activerecord-postgresql-adapter
ERROR:  Invalid option: -r.  See 'gem --help'.
aleph:src mel$ sudo gem install -r activerecord-postgresql-adapter
ERROR:  could not find gem activerecord-postgresql-adapter locally or in a repository

To install the correct the correct pg gem, use the following command:

# sudo env ARCHFLAGS="-arch i386" gem install pg

There seems to be a version difference between the two difference postgres adapeters : pg (0.7.9.2008.10.13) versus postgres (0.7.9.2008.01.28). Only time will tell if this will lead to framework incompatibilities.

ActiveRecord

To use the scaffolding in any meaningful manner requires a clear object model that can be used to represent system objects. The ActiveRecord::Migration class provides detailed usage information that is required to generate these classes and the associated database types. However, details such as the rails type to database type mappings are not easily found in Rails API. The following links highlight the most important features of ActiveRecord objects which will hopefully allow more informed use of this fundamental Rails object.

• ActiveRecord::Aggregations - useful when representing attributes as value objects.
• ActiveRecord::Associations - describes the use of object associations such as many-to-many, inheritance, and polymorphism.
• ActiveRecord::Base - describes the base ActiveRecord object and its associated methods and properties.
• ActiveRecord::Calculations - describes calculation methods available to ActiveRecord objects.
• ActiveRecord::Callbacks - describes the callbacks available during the lifetime of an ActiveRecord object.
• ActiveRecord::ConnectionAdapters::ConnectionHandler - describes the use of a ConnectionHandler to distribute an object hierarchy amongst different databases.
• ActiveRecord::ConnectionAdapters::ConnectionPool - describes ConnectionPools which can be used to synchronize thread access to a limited number of database connections. The Options section describes the use of the :pool and wait_timeout parameters in the database.yml configuration file.
• ActiveRecord::ConnectionAdapters::PostgreSQLAdapter - describes the database.yml configuration parameters for PostgreSQL as well as the native datatypes the adapter maps the migration datatypes to.
  • :primary_key - serial primary key
  • :string - character varying(255)
  • :text - text (upto 1GB of multi-byte characters
  • :integer - integer
  • :float - float
  • :decimal - numeric (can be specified with :precision and :scale
  • :datetime - timestamp without time zone
  • :timestamp - timestamp without time zone
  • :time - time
  • :date - date
  • :binary - bytea
  • :boolean - boolean
• ActiveRecord::Errors - describes the errors associated with ActiveRecord object operations and how to access them.
• ActiveRecord::Migration - migration specifics.
• ActiveRecord::Observer - describes Observer configuration for ActiveRecord objects which implement lifecycle callbacks.
• ActiveRecord::Reflection - ActiveRecord object reflection methods.
• ActiveRecord::Serialization - methods which support ActiveRecord object serialization.
• ActiveRecord::Transactions - describes atomic database transactions and their ActiveRecord implementation.
• ActiveRecord::Validations - describes ActiveRecord object field and condition validation methods.

Object Associations

As ever, the initial challenge when creating an application is to create an object model that reflects the system being designed without imposing unnecessary limitations. There are a number of relationships that can be modeled through Rails, but it is important to understand both the usage and limitation of these mechanisms.

• Rails only supports Single Table Inheritance - By default only Single Table inheritance is supported by Rails. Essentially, different subclasses are represented by a :type field in the database table. To avoid confusion, treat type as a Rails keyword an only use it when you want to model Inheritance.


• Polymorphism is supported through the :has_many :has_one/ :as mechanism - common functionality can be shared amongst objects by implementing an interface. This requires the implementing object to have interface_id:integer and interface_type:string columns within their database models.


• The difference between :has_one and :belongs_to is largely where the foreign key resides. - The :belongs_to implementation should have the corresponding foreign key to the referenced object.


• Many-to-many relationships can be modeled in a number of ways. Direct relationships can be modeled using has_and_belongs_to_many. If the association needs to be manipulated independently, the has_many :through relationship will do provided a join table is created to associate the two models.


• Secondary associations using :through. Both the has_one and has_many associations support secondary references through intermediate objects.

Object Hierarchies

There are built-in mechanisms with Rails to model ordered lists, trees, and hierarchies.

• :act_as_list - allows a collection of object to function as an ordered list. This requires a position column within the model.
• :act_as_tree - allows a collection to behave as a tree. Requires the parent_id column within the model.
• :act_as_nested_set - allows a collection to behave as a hierarchy. The advantage over :act_as_tree is that individual nodes can be retrieved with their dependent objects. This model requires the use of the following columns : parent_id, lft, rgt.

Validations

Data sanitation is paramount to preventing a whole host of database injection attacks. Always assume that any publicly submitted data can be used to compromise the system. To mitigate these types of attacks, ActiveRecord supports validation of conditions and fields (see above). It is highly recommended that validations be exercised in the testing framework to ensure their proper functioning.