First, a lot of interviewers want to ask about specific syntax issues…regardless of whether that skill was in any way relevant to the role. For example, I was talking to one place about a “project manager contract” role. Basic stuff, manage the schedule for the R&D Manager. It wasn’t something that I was interested in once I understood the role, but even less so after the questions kept coming back to things like “how would you implement something like Java’s Final class in C++?”.

There are two fallacies at play here. The obvious is that for the role we were talking about ANY kind of development skills were pretty much irrelevant. The other is the idea that knowing specific syntactical oddities of a language equate to knowing how to write good code. If the job is about writing C++ code, ask how you override an operator, what the challenges with multiple inheritance are and how you can avoid them, or ask the candidate to read a bit of code and explain what it does.

A second item I noticed is the “logic puzzle” question. I think this was really popularized by Google. Properly applied this can help an interviewer see how a candidate thinks about a problem separate from a specific language. One example is the Light Bulb Drop Problem. It can also help an interviewer evaluate how a candidate reacts to stress. I have two issues with this though. First, the problem usually has absolutely nothing to do with the job requirements except in the vague sense of “problem solving”.

The other problem I have is that every time I’ve been asked a question like this the interviewer doesn’t really understand how to solve it themselves. The question is something they read on the ‘net. They can repeat the solution they read but they don’t understand how to solve it themselves. I ask you, what is the point?

Another technique that is popular is to show the interviewer some snippets of code and ask them what they do. This can be really useful for evaluating candidates as long as the code isn’t written purposefully obfuscated. For example, one place had an extremely convoluted line of Ruby code — maybe 8 or 10 expressions all run together with a literal array of characters, regex, character substitution and so forth — and the question was “what will this return?” The, uhm, Canonical, way would be to drop into IRB and evaluate it. The return value from the expression was “Ruby Ninja”, honestly if I saw that kind of code in a real world scenario I would run (not walk) in the opposite direction! I wish I’d saved a copy of the snippet — it was a great example of BAD code.

More useful snippets for review would be things like these:

a = [1,2,3]

def a.[] (i)
  super(i-1)
end

What does that do? It’s basic Ruby code and it shouldn’t pose any problem to a developer that understands the basics of the Ruby object model.

class Foo
  def self.m (&block)
    class << self
      self
    end.instance_eval(&block)
  end

  def initialize
    self.class.m { @foo = 1 }
  end

  def foo
    self.class.m { @foo }
  end
end

This one is a bit more advanced, and you have to know something about Ruby Meta Programming to make sense of it.

In part 2 I’ll post a few of the programming tests I came across.

Of the thousands of articles I found, this one seemed fairly straightforward.  I liked that the HTML structure was fairly minimal, and the CSS straightforward.  I didn’t like the idea of firing up Photoshop every time I wanted a variation of color or corner radius, so I wrote a simple generator plugin.  This was a fun project, and it gave me an excuse to dig into plugin development and Rails core so it’s all good.

The plugin has two main elements.  First, the generator creates the CSS and image files based on your input.  Second, I wanted to avoid having to add a stylesheet_link_tag every time I added a new style, which lead to a small extension to stylesheet_link_tag so that it will find all of the CSS code generated by this plugin and gather it all up together.  I’ll dissect the plugin another time, there were several magic incantations that I needed to figure out to be able to extend not just the stylesheet_link_tag, but also to extend  the generator commands.

To get the plugin just install it from my github repository:

script/plugin install git@github.com:canonical/css_rounder.git

You will need to install rmagick if you don’t already have it, the plugin uses it to generate the necessary images (note: you don’t need it for this plugin in production, just for development)

Now run the generator:

>> script/generate rounded_div my_div_name white 15 chartreuse

************************************************************************************

Generating rounded div formatting with a corner radius of 15 and a color of chartreuse

  In your view template use the following markup:
  note: the structure of this markup must be followed for proper formatting

     <div id='my_div_name'>
       <h2> ... </h2>
       <p>
         ...
       </p>
       <p class="more">
         <a href="#">...</a>
       </p>
    </div>

Don't forget to include the generated stylesheet in your layout or view,
use the :pullquote symbol to automatically gather all of the generated stylesheets
instead of manually including each one (use the :cache=>true option)

  <%= stylesheet_link_tag :pullquote  %>

      create  public/stylesheets/my_div_name
      create  public/images/my_div_name
      create  public/stylesheets/my_div_name/pullquote.css
      create public/images/my_div_name/top-left.gif
      create public/images/my_div_name/top-right.gif
      create public/images/my_div_name/bot-left.gif
      create public/images/my_div_name/bot-right.gif

You will need to make sure you include the generated CSS into your layout or view.  The plugin provides a convenience method as an extension to stylesheet_link_tag.  Since each invocation of the generator creates a separate CSS file this extension will pull in all of the generated CSS.  I’d recommend using the :cache option on stylesheet_link_tag to gather it all into one file as well.

<%= stylesheet_link_tag :pullquote  %>

Then use the html markup structure in a view or layout somewhere and you’re in business.

     <div id='foo'>
       <h2> This is our heading </h2>
       <p>
         This is the body
       </p>
       <p class="more">
         <a href="#">and if we needed a link...</a>
       </p>
    </div>

You have to use this structure at a minimum as it’s structured to take advantage of the generated CSS selectors.  I’m sure you could change the selectors and the HTML structure if this layout is objectionable.  After getting this set up you can regenerate the same configuration (cleverly named “foo” here) or create additional configurations.

I expect I will be tweaking this as I use it on my current project, so if you like it you might want to watch the github repository (http://github.com/canonical/css_rounder) for updates.

But what if we have a domain where we need to represent relationships between these items?  In fact, it works just as you would imagine having three models and corresponding database tables.

Lets assume we’re building a application to sift through census population data, we might have a domain model like this:

To implement this in Rails we need a migration first:

class CreatePlaces < ActiveRecord::Migration
  def self.up
    create_table :places do |t|
      #data common to cities, counties and states
      t.string :name
      t.integer :population

      # foreigh key for associations
      t.integer :region_id

      # class type for STI
      t.string :type
    end
  end

  def self.down
    drop_table :places
  end
end

and of course the corresponding Model, nothing going on here – but that’s expected since this is not an actual part of our domain model, but a generalization of State, County and City:

class Place < ActiveRecord::Base
end

Now we need to set up our domain Model classes.  First, State at the top of the hierarchy:

class State < Place
  has_many :counties, :foreign_key => :region_id
  has_many :cities, :through => :counties
end

Then County, in the middle:

class County < Place
  belongs_to :state, :foreign_key => :region_id
  has_many :cities, :foreign_key => :region_id
end

and finally, City

class City < Place
  belongs_to :county, :foreign_key => :region_id
end

It’s just that easy.  If we fire up the Rails console we can verify the behavior:

>> cali = State.create(:name=>"California",:population=>33871648)
=> #<State id: 1, name: "California", population: 33871648, region_id: nil, type: "State">

>> santacruz = cali.counties.create!(:name=>"Santa Cruz", :population=>253137)
=> #<County id: 2, name: "Santa Cruz", population: 253137, region_id: 1, type: "County">

>> scottsvalley = sc.cities.create!(:name=>"Scotts Valley",:population=>11128)
=> #<City id: 3, name: "Scotts Valley", population: 11128, region_id: 2, type: "City">

>> santacruz.state
=> #<State id: 1, name: "California", population: 33871648, region_id: nil, type: "State">

>> scottsvalley.county
=> #<County id: 2, name: "Santa Cruz", population: 253137, region_id: 1, type: "County">

>> scottsvalley.county.state
=> #<State id: 1, name: "California", population: 33871648, region_id: nil, type: "State">

If we need to collect all places together it is as simple as Place.find :all.

But what if we want to share implementation code but not store all three entities in the same table?  That is, keep the inheritance part in Ruby but save our data to three separate tables in the database?  That only requires a few simple changes.  First, change the Place model to look like this:

class Place < ActiveRecord::Base
  self.abstract = true
end

Then we need to add migrations to create DB tables for State, County and City (and remove the Place migration). The self.abstract = true incantation tells Rails not to go looking for a places table.  This allows us to share validations and other code by keeping it in the Place model, but we lose the ability to collect all of the places together with a single query.  It is a design tradeoff, there isn’t any right or wrong approach.

(note: You can download the source code for this post from github)

Assume we’re building a micro-blogging app, I’m sure there is room for one more blog app after all.  We want users to be able to post a blog entry that is literal text — something they wrote, or post an image alone, or post a link to something else.  All three types of posts will have a title, author and timestamps, but the details are specific to each type, as it the behavior.  Our application domain might look something like this:

Simple enough, an abstract base class with three concrete specializations, one for each type of post.  Now, how can we stuff these into our relational database without having to jump through hoops?

First, we define a migration that creates a Posts table with a superset of these attributes.  The “image” attribute is actually expanded to several fields because we’re using attachment_fu to handle storing and re-sizing the image.  The “magic” is the definition of the type field, this will be used by Rails to store the post type so that the proper type of object is associated with each row.

class CreatePostings < ActiveRecord::Migration
  def self.up
    create_table :posts do |t|

      # if this thing is a LinkPosting, we use the URL
      t.string :url

      # if this thing is a LiteralPosting (text/embeded player) we use literal
      t.text :literal

      # if this thing is an AttachmentPosting we use attachment_fu
      t.column :parent_id,  :integer
      t.column :content_type, :string
      t.column :filename, :string
      t.column :thumbnail, :string
      t.column :size, :integer
      t.column :width, :integer
      t.column :height, :integer

      # common attributes
      t.timestamps
      t.column :title, :string
      t.column :author, :string

      # required for STI
      t.string :type
    end
  end

  def self.down
    drop_table :posts
  end
end

We’ll need an ActiveRecord class for Post of course:

class Post < ActiveRecord::Base
  validates_presence_of :author, :title
end

Notice that we only validate the common attributes on the Post model.  As far as post is concerned, everything else is optional.

Now we need ActiveRecord objects for the descendant classes, the ones our application will actually manipulate.  A few things to notice here: First, each one of these extends Post not ActiveRecord.  We only have the one posts table in the database after all.  Second, each model implements the validations specific to that type of post.  Any behavior that varies by the type of object (and that belongs in the model) can be handled like this.

First, a LiteralPost - nothing too surprising here:

class LiteralPost < Post
  validates_presence_of :literal
end

Next, the LinkPost:

class LinkPost < Post
  # this functionality is provided by a plug-in
  # it appears that some sites block this kind of validation at the root
  # eg. yahoo.com will fail, but a permalink to a news story at yahoo.com will work OK
  validates_http_url :url
end

Finally, the ImagePost.  The has_attachment and validates_as_attachment elements come from attachment_fu.

class ImagePost < Post
  has_attachment :content_type => ['application/pdf', 'application/msword', 'text/plain', :image],
                 :storage => :file_system,
                 :resize_to => "800x800>",
                 :max_size => 5.megabytes

  validates_as_attachment
end

If we were to draw a picture of our domain model as it exists in the database and in our application code we would see something like this:

It might strike you as odd (or perhaps “wrong”) to have all  the attributes on all of the entities.  A LinkPost is never expected to have an image associated with it, right?  This is a design trade off.  We’re not really wasting any space because the database is smart enough that it only uses a few bytes to keep track of null data.   A lot of things that are “best practices” in Rails tend to irritate experienced DBAs.  Such is life.

If we pop into script/console we can verify that this all works as expected:

As you can see, we can create concrete post types, and retrieve all heterogenous posts using Post.find.  This is great because we want to be able to display all posts in the same view regardless of the type of post.  In essence, we want to treat all of the concrete subclasses the same.

We’ll use a smidgen of Ruby dynamic programming to simplify things.  If we define partials for the editing and rendering of the details specific to each subclass then we can call the correct partial using something like this:

<% for post in @posts %>
    <div class="postbox">
      <h2><%= post.title %></h2>

      <p>created by <b> <%= h post.author %> </b> on <b><%= post.created_at %> </b></p>

      <!-- use the post type to determine the correct partial to render ->
      <%= render :partial => post.type.downcase, :locals=>{:post=>post} %>

    </div>
<% end %>

The “magic” is on line 8 in the above code.  It’s just a little tiny sprinkling of Ruby Dust, but it completely eliminates the need for conditionals to produce the desired output.   We’ve defined two partials for each concrete subclass, one for viewing and one for editing, and they are named using the name of the object itself.  For more details you can grab the code and look at it yourself.

The index view in the finished app show off our display of different post types nicely, one LinkPost, one LiteralPost and one ImagePost.

What if we need to have relationships between the various concrete subclasses?  What if if we really, really don’t want to store everything in a single table?  We’ll take a look at those issues in part 3.

In object oriented programming this is usually addressed with inheritance.  You define a base class that has the core attributes and behavior, then you extend it with classes that inherit from the base class and specialize the behavior.  Then your application code can work with objects in this class hierarchy without having special cases in the application code, it’s all tucked away in the objects instead.

If you have code in your controller that determines the behavior based on the class of the object it’s working with, or perhaps the value of an attribute, then you may be suffering from the type-of anti-pattern.  Ditto for view code that displays the object differently based on an indicator field.

I’d like to look at a simple example derived from a project I’m working on.  Imagine you were building a “micro blogging” site like tumblr where the blog entry can be a photo or something you write or something you link to.  One approach would be to define a type_of_post attribute.  Then in your model you can have your model check this value to determine which validations should be in effect.  And your view can have code that checks this value to see if it should display an image or a link.  This is completely lacking in object-oriented crunchy goodness.

Or you could have separate tables, one for image posts, another for text posts and yet another for posts that are a link to something else.  Then you have to deal with gathering all of these together and displaying them in the same views.  This sounds like a lot of dancing around.  Imagine the changes when someone has the bright idea that the application should support embedded videos from vimio and youtube?

In the bright and shiny world of object orientation this is often handled with inheritance.  Unfortunately, there is some dissonance between objects and the relational databases we store them in.  Databases don’t allow one table to extend another, and as Rails developers we don’t typically implement behavior in the database layer anyway.

Enter “Single Table Inheritance” as a simple solution.  Martin Fowler is the source for this design pattern. This is supported in rails, and it’s really easy to take advantage of.  I’ll post the specifics on how to use this, and an example app in part 2.

First, SelectorGadget is “an open source bookmarklet that makes CSS Selector generation and discovery on complicated sites a breeze”, it was written by Andrew Cantino and Kyle Maxwel.  In a nutshell, you launch it (it’s a bookmarklet), then cliick on the part of the web page you’re interested in.  It shows up with a green highlight.  Anything else on the page that matches the CSS selector will be yellow.  by clicking on them you can exclude them from the selector.  It will also ogive you the XPath instead of the selector.

Nokogiri is an HTML and XML parser that allows searching within the parsed document by CSS selector or XPath.  You can see where this demo is going…

Let’s assume that you want to grab the popular topics that people are tweeting about.  If we browse to twitter.com, start SelectorGadget and make a few clicks we have the basics to be able to grab the topics.  I’ve circled the CSS Selector it has built for us, as well as the button to get the XPath equivalent.

Now, with just a few lines of Ruby code we can grab these topics that has everyone all a-twitter.

require 'nokogiri'
require 'open-uri'

# Get a Nokogiri::HTML:Document for the page we’re interested in...
doc = Nokogiri::HTML(open('http://www.twitter.com'))

# Search for nodes by css
doc.css('div:nth-child(1) :nth-child(1) a').each do |link|
  puts link.content unless link.content == "Sign up now"
end

Running this will give us the following output:

Pretty slick!  Try it out, you’ll like it.

There are always many activities going on in a software project, the idea is to develop a pattern that helps establish the pace and predictability of the team.  Agile processes like scrum excel at this, but I like to see the rhythm played out in both micro- and macro-patterns.

Scrum establishes the overall process rhythm, demonstrated by the duration of the sprint.  More frequent activities within each sprint – like daily stand-up meetings and sprint review sessions – help emphasize the rhythm.

In my view, this is just a start.  Having a clear rhythm gets everyone’s expectations in alignment and establishes predictability.  While milestones are important, I don’t think they establish rhythm.

As an example, on a large project I managed we had the following layers of patterns at work:

The outermost pattern was the product release.  With waterfall models often this is the only marker that teams have to work with — not good!

Within the release cycle we had a specific number of “beta” releases planned.  For each we established a goal in terms of product capabilities and the level of quality.  Each beta had a specific target audience and raison d’existence.  For example, the first “beta” contained just the core features necessary to “tell the story” and the audience was an internal review team.

Of course within each “beta” cycle were a number of scrum sprints.  Because of the size of the team, the complexity of the technology and other factors the teams were using three week sprints.  Three weeks is longer than what I like to see, but this was the balance point that seemed to work best.

Within each sprint we had weekly formal releases to Q/A.  These releases had formal release notes that indicated bugs fixed and features that were ready for testing.

Because of the complexity of the system we had nightly formal full builds which were delivered to Q/A every morning.  These were deployed and “smoke tested”.  The smoke test touched each major function of the system to verify that it fundamentally appeared to work.  The test was performed manually and took about 30 minutes to carry out if everything went smoothly.  If the smoke test failed then the Top Priority for Engineering was to localize and fix the problem.  The smoke test had to pass every day, period.

Each check-in also triggered an incremental build and unit test run to catch errors.

Visually the rhythm could be depicted as shown below (this graphic is a little stiff, sorry).  It provided a set of clear expectations to the team and set a repeatable pace to a predictable release.  Like software processes, there is no “one size fits all” rhythm.  Any software engineering process has to take into account factors like the maturity of the team, their domain knowledge and the clarity around the end goals.

In Rails 2.3 some new features were added to simplify dealing with “nested forms”.  That is, a single form that manages a model and it relationship data (has_one, has_many, etc)  In the dark ages (last spring) it was necessary to add a faux accessor to accommodate this.  No longer.

If you surf the web you will find many examples, not all of the are current.  I just put an example on github that demonstrates a simple master-detail type of form.  In this case it’s an order that has_many line_items.  The app is purposefully bare-bones so that the essential aren’t buried.  Any real app would have more elegant page layout, data validations and a lot of other niceties.

This first example shows adding and removing detail records using AJAX.  There are two simple helper methods to facilitate this.

Check it out on github: http://github.com/canonical/OrderItemsExample

First, and you can quote me: WOW!

The number of new Rails tools and projects that have sprung up is amazing.

The last web shop I built I used an edge version of substruct.  It went fairly well, although I’m not a huge fan of Rails Engines.  I started exploring   spree.  It installed easily following the instructions and I had a demo site up in no time at all.  I started in on the training wheels tutorial and couldn’t get anything to work right.

After a bit of poking around I realized that I’d missed the admonishment that the tutorials applied only to edge Spree, not the released gem.  Rats.  So I installed git, grabbed the source, installed cygwin (don’t forget to include the optional “zip” tool!) and built spree.

Phase II, the tutorial works just fine, thank you very much.

After poking around for a while I’m really impressed.  There are some well thought out mechanisms in place for extending and customizing spree.  Spree appears to be complete enough for many small business sites, of course the advantage to building a Spree-based site is the opportunity to tailor the site to meet your specific needs.

Stay tuned.