Joe Stelmach

Zenbe Lists + Gizmodo

2010-07-22T00:00:00-04:00

I've had the pleasure over the last few weeks of rewriting the already awesome Zenbe Lists iPhone app, and porting it over to the iPad.

Two days have passed since the inital release, and I'm happy to say that we've received a beyond flattering mention on Gizmodo.

Thank you Gizmodo!

Natty Date Parser

2010-05-28T00:00:00-04:00

It was bound to happen sooner or later — a new blog post! (only took me 1,207 days.)

Anyways, I'd like to talk a bit about a project I've been working on to extract dates from their natural language representation. The project is called natty, and Ive decided to open source it under an MIT license.

What natty does is attempt to define a formal grammar describing all the crazy ways people refer to dates that are relative (or not) to the current date. Some typical examples are: monday of next week, next tuesday, or the 28th of february at 6pm. The casual observer may suggest a series of regular expressions to do the job, but will soon find that the grammar describing such things is far from regular, and tends to be quite ambiguous.

ANTLR fits the bill nicely as we can use syntactic predicates to deal with ambiguities (by enabling infinite lookahead,) and semantic predicates to deal with the parts of our grammar that inch towards context sensitivity.

Defining the grammar is one thing, but actually extracting meaningful information is another. To solve this, I'm using ANTLR's abstract syntax tree (AST) rewrite rules to build an intermediate representation that defines the date as a generic, tree-like structure. Once built, this structure can be walked, invoking common date manipulation methods along the way to arrive at the correct date.

This approach has several advantages over a more naive, non-grammar based approach. The most significant of which is the ability to offload the generation of messy parsing code to a code generator instead of a human. We still have to deal with a complex grammar specification, but the grammar is infinitely less complex than the generated code, and will prove to be far less brittle when making future changes.

Another significant advantage is the theoretical ease at which the parser can be ported to a new language — choose a new ANTLR target, implement a few generic date manipulation methods, and call it a day.

More information about the project is available on the natty website, and the source can be found on GitHub. Enjoy.

Ajax Busy Indicators Part 2

2007-02-06T00:00:00-05:00

Just a follow-up to my last post on Ajax busy indicators, where I described how to implement a single image/callback to indicate the status of all the Ajax requests on your site. The limitation was that the image had to always be placed in a pre-defined spot on the page, which is less than desirable. This can be overcome by dynamically changing the position of your image based on which link/button was pressed. Consider the following javascript:

function setBusyNextTo(link) {
  linkPosition = Position.cumulativeOffset(link);
  linkDimensions = Element.getDimensions(link);
  imageHeight = Element.getDimensions('busy_img').height;
  x = linkPosition[0] + linkDimensions.width;
  y = linkPosition[1] + (linkDimensions.height / 2) - (imageHeight / 2);
  $('busy_img').style.top = y + "px";
  $('busy_img').style.left = x + "px";
}

You can hook this up to your ajax links (or buttons) using the after callback:

<%= link_to_remote("Action", {
  :url   => {:action => "ajax_action"},
  :after => "setBusyNextTo(this)"})%>

This will place the activity indicator directly to the right of the link that was clicked. The code in my previous post will take care of actually displaying the indicator (via a generic callback.) Note that this code makes no assumptions as to the physical size of the indicator image - The image will be vertically centered next to the link. This makes it possible to try out a bunch of different indicators by simply changing the src attribute of your indicator's image tag. The vertical positioning will be taken care of, but the horizontal positioning may be a bit trickier. You will have to make sure that your link or button has enough empty space to the right of it to avoid placing your indicator on top of something.

This idea can be taken a step further by adding the positioning functionality to our links and buttons unobtrusively (say, in the body's onload handler.) This can be accomplished with the following beautiful piece of javascript:

$$("a").each(function(anchor) {
  anchor.onclick= function() {setBusyNextTo(this)};
});

Be careful with this method though, as this will only affect those dom elements that were originally created at the last browser page load (as opposed to the last javascript dom manipulation.)

Ajax Busy Indicators

2007-01-25T00:00:00-05:00

If someone told me back in 2002 that animated gifs would one day be popular again, I wouldn't have believed them. The image of a construction worker shoveling next to a road-block to indicate a site is 'Under Construction' still brings on a feeling of nausea. However, animated gifs are now proving to be useful and sometimes even necessary in modern day web apps. The difference is that now they have some usability characterstics instead of just looking cute. Since Ajax requests are made behind the scenes, the browser itself doesn't offer any form of visual feedback to indicate that a request has been made and a response is pending. Therefore, we're on our own with letting the user know something is happening and that the application isn't just sitting there being stupid.

So how do we do this? The easiest way is to place an image on the page and set it's display property to none. Then when an ajax request occurs, we simply show the image by setting it's display property to 'inline' or 'block', and hide it again once the request has finished. We can actually forget about the css completely by using the prototype Element methods instead.

Somewhere in your rhtml:

<img src="images/spinner.gif" id="busy_indicator"
  alt="busy" style="display:none" />

<%= link_to_remote("Click Me", :url => {:action => "action_name"},
  :after => "Element.show('busy_indicator');",
  :complete => "Element.hide('busy_indicator');")%>

I'm using the after callback in this example, which might generate some confusion. The after callback is invoked after the request has been made and the browser is awaiting a response. This differs from the before callback which is invoked before the request is even attempted. I guess the jury is still out on this one, but I feel that the after callback is more appropriate since it will display the image only if the request was actually made. If we use the before callback and the request fails for some reason, then the busy indicator will be sitting there spinning and the user will just sit there and wait. Using the after callback will not display the busy indicator in this situation, and the user will most likely click the link again since they see nothing is happening.

In this simple example, we might also have some style rules associated with the image to place it in a well defined position on the page:

#busy_indicator {
  position:absolute;
  top:300px;
  left:100px;
}

Now, what happens when I have lots of Ajax calls on my page and I'd like the busy indicator to be shown for each one? Using the solution above would require the very un-DRY-like repetition of the after and complete callback code for each link_to_remote, form_remote_tag, etc. Luckily, there's an easy solution to extracting this code into a common place.

The prototype library allows you to register generic callbacks that work across all Ajax requests (those invoked through prototype, ofcourse.) This makes it painless to show our busy indicator at the proper time. Add the following to your application.js file:

Ajax.Responders.register({
  onCreate: function() {
    if($('busy_indicator') && Ajax.activeRequestCount>0)
      Element.show('busy_indicator');
  },
  onComplete: function() {
    if($('busy_indicator') && Ajax.activeRequestCount==0)
      Element.hide('busy_indicator');
    }
});

Note that we are simply just moving our previously defined after and complete callback code. Those callbacks no longer need to be defined in the previous link_to_remote call (or any other Ajaxified link for that matter.) Also note that the before callback described previously is not possible at this level, since onCreate is invoked after the request is created, not before. This code will display our busy indicator as long as there is at least 1 outstanding Ajax request awaiting a response. This is accomplished by looking at the prototype's Ajax.activeRequestCount, which is updated each time an Ajax request is made through prototype (this is actually implemented in the prototype library by registering a callback, just like we're doing here!)

So this is a pretty good solution, but the thing I hate about it is the inability to move the busy indicator around on the page. Sometimes I'd like the indicator to display next to each link or button that I click. However, I don't want to have an image tag sitting next to every single link. That would suck. So what can we do here? One solution would be to still place only a single image tag on the page, but change it's position each time a link is clicked. We may even be able to take this one step further by walking down our dom and generically inserting an onclick handler to position the indicaotor next to each link/button that we press so we don't have to define the onclick handler ourselves each time a link is added. Also, I think it may be benificial to insert the image tag into the dom via Javascript, since the busy indicator is useless outside of an Ajax/Javascript context.

More on Object Graphs in Active Record

2006-12-30T00:00:00-05:00

As I said in my last post, I can't help but to think there is a better way to persist object graphs in Rails applications. The solution I outlined last time seems to stray from the DRY principle (Don't Repeat Yourself,) and just seems to leave a bad taste in my mouth. Don't you wish there was some way to leverage the meta-programming capabilities of Ruby and Rails to solve this problem in a generic way? Me too. Consider the following sketch of a solution:

def update_object_graph(root_entity, entities_seen = [])
  # return if we've processed this entity already
  return if entities_seen.include?(root_entity)
  entities_seen << root_entity
  errors = []

  parameter_name = root_entity.class.name.underscore
  # if paramaters are given for the root entity, then we update it
  if params[parameter_name]
    keys = params[parameter_name].keys
    index = keys.index(root_entity.id.to_s)
    root_entity.attributes = params[parameter_name].values[index]
    errors += root_entity.errors.full_messages unless root_entity.save
  end
    
  forward_associations =
    root_entity.class.reflect_on_all_associations -
    root_entity.class.reflect_on_all_associations(:belongs_to)

  forward_associations.each do |association|
    # ignore acts_as_versioned association tables
    next if(/::Version$/ =~ association.class_name)
    raise unless root_entity.respond_to?(association.name)
    # Deal with has_one associations
    if(association.macro == :has_one)
      assoc_entity = root_entity.send(association.name)
      new_errors = update_object_graph(assoc_entity, entities_seen)
      errors = errors + new_errors if new_errors
      # Deal with has_many and habtm associations
    else
      association_entities = root_entity.send(association.name)
      association_entities.each do |assoc_entity|
        new_errors = update_object_graph(assoc_entity, entities_seen)
        errors = errors + new_errors if new_errors
      end
    end
  end
  errors
end

The idea here is that we first update the current entity with any corresponding values in the parameters hash. Then we attempt to save the entity and collect any errors. Remember, since the save method is called on the actual instance of the entity in question, it's erorrs collection will be populated and used when rendering the page. Now things get interesting - we discover the associations of the entity, and then use reflection to obtain references to the actual objects that represent those associations. Now we recursively call persist_object_graph on each of these objects.

Makes perfect sense right? Let me first say that this code doesn't actually work: it is just a sketch of a solution and has lots of oversights (no support for composed_of aggregations, it makes assumptions about the names of things, etc.) However, I was hopeful that I could take this idea and run with it. Unfortunately, this solution hits a brick wall when we back up and take a real close look at the Active Record design pattern. Can anyone spot the subtle but major flaw here?

Persisting Object Graphs With Active Record

2006-12-29T00:00:00-05:00

If given a choice between simple and complex, Rails will always lean towards the simple (actually, it crashes into the simple side of things.) Most of the time this is a nice, refreshing change from the J2EE world, whose committee seems to get off on adding complexity into every nook and cranny of the J2EE spec. However, sometimes there are real complexities in the problems we are trying to solve. Consider the following domain model:

Now, let's suppose you would like to display the rendered html version of this entire object graph to the user on a single page with only one form. If you've done any rails development in the past, you're probably thinking "It can't be that bad". After all, Rails almost enforces that you follow domain-driven design, so how hard can it be to satisfy this requirement? update_attributes to the rescue! Take a look at the RDoc:

Updates all the attributes from the passed-in Hash and saves the record. If the object is invalid, the saving will fail and false will be returned.

Sounds great right? But wait - what if the method fails? Can we still access the error messages as if i called the save or valid? method directly on each object? Will the framework know which properties have errors associated with them to insert the proper 'fieldWithError' class names while rendering the response? Unfortunately, the answer is No. The update_attributes method is therefore worthless to me, and exists as nothing more than an absolute tease. However, I'm sure the Rails core developers will argue that they were just 'keeping it simple'. I applaude that. But I still have to satisfy this requirement that goes against the seemingly conventional Rails wisdom of a single object per page.

So what options are we left with here? I could refactor my interface to break the object graph into multiple screens, but that would add lots of complexity to my user interface, which I believe should remain simple at all costs (even if it means adding complexity to the back-end.) So refactoring the interface is out. I suppose I could just walk the object graph and populate and save each object directly, collecting any error messages that arise as we make our way to the bottom of the graph. Populate and save you say? That's what update_attributes is for. So maybe we can validate each object on our way down, and then use the update_attributes on each object. Sounds good right? Wrong again. update_attributes maintains its own transaction, which means that once an object is updated, it cannot be rolled back if another object's validation or save fails. The entire group of saves needs to be wrapped in a transaction. It looks like the optimal solution in this case is to use the attributes= method to populate the attributes from the parameters hash and the save method to do the persisting, all within one transaction.

This solution will work (and does work for a couple apps I have written.) However, the complexity of the save operation increases for each entity you add to your domain model (luckily, this seems to be only a linear increase.) But seriously, I can't help but to think there's a better way to do this...

Javascript Trivia

2006-12-18T00:00:00-05:00

I guess I should have learned this a long time ago - but when a tiny piece of code kicks my ass this bad, I like to share it with the world :) How many times do you expect the following Javascript to alert 'hi'?

function x() {
  for(i=0; i<8; i++) {
    y();
  }
}
function y() {
  for(i=0; i<2; i++) {
    alert('hi');
  }
}
x();

The answer - An infinite number of times! Believe it or not, when the Javascript interpreter comes across a variable without the var keyword in front of it, it automatically creates a global variable with the given variable name. Fun stuff.

New Jersey

2006-12-06T00:00:00-05:00

This has to be the funniest Jersey joke I've heard in a while (From the movie 'Just Friends')

Are you kidding? You're Chris Brander. You're Hollywood; you date models. He's Jersey; he skis in his jeans.

Comment Spam

2006-12-02T00:00:00-05:00

I hate comment spam. As if a mailbox full of solicitations to buy cialis soft tabs is not enough, now I have to deal with my blog posts being barraged with comment spam. What's the solution? I obviously can't go on accepting all of these spam posts, so what's a guy to do? Here are some options:

Captchas: You know, the funny looking skewed letters that you have to try and decipher to buy tickets on Ticketmaster. The idea here is that it will block most spam bots from guessing correctly, yielding a high percentage of human-only comments. The downside: they are a pain in the ass. Accessibility issues aside, I just don't like these things - half the time even my human eyes can't decipher what they say.
Ajax-only comments: The idea here is simple: only accept comment requests that ride in on the Ajax bus. Apparently, most comment-spam bots are designed to blast your site with regular old-school requests. For a rails-based web-site (which this is) the implementation would be simple given the availability of the xhr? method on the request object. However, I have to ask: won't someone figure this out and start writing bot programs that makes Ajax requests? What about the more obvious problem of eliminating the user's of non-Ajax browsers from posting comments on your site? Not so much a fan of this solution either.
No anchors: The simplest scheme yet: don't allow anchor tags in your comments. Since the evil spammers are looking to place links on your page, you should be able to take care of the majority of the problem with this approach. The problem, however; is that this goes against the founding principles of the web: The ability to link from one page to another. I think it's great when someone leaves me a link to a site that's relevant to the conversation at hand. It would be a shame to allow the pillars of the web to falter at the mercy of these evil people writing spam bots.
Dictionary: How many times does a comment truly need to contain the word 'viagra' (especially in the context of software development.) Probably never. The dictionary approach uses this concept to weed out human vs. bot comments by not allowing comments to contain certain words. Generating this dictionary to get reasonable results would probably not be that hard, but the dictionary would be in constant need of change as new drugs, gambling games, and cures for baldness come about.

The solution I chose? No anchors. I know - that last bit about pillars and faltering is quite dramatic, but I just have to beleive that this is the best solution for me right now. A regular expression based implementation was put into place and seems to be working well so far. Leave me a comment if you disagree with my position here - just be sure not to leave me a link :)

Browser Back Button

2006-10-20T00:00:00-04:00

I have a question. Why does the browser have to be so stupid about its back button? I realize that http is an overly simple protocol, but I just can't help but to think that we can implement a better back button. With the advent of sending http requests via ajax, the back, forward, and refresh buttons have gotten to be just about pointless. This is unfortunate since most people find the back button to be invaluable (try counting how many times you hit it in one day.)

The problem is that each state in the browser is represented by a complete page load. So when we go through an entire ajax request/response cycle, the browser is not pushed into the next state. My question is, why not? I realize that the browser is properly implementing the http protocol, but I can't help but wonder how much nicer the web would be if we could change this behavior. I also don't know that it would be that hard.

Consider the following sequence of events:

Send an ajax request
Receive the response
Take a snapshot of the current DOM
Manipulate the DOM as intended by the programmer
Push the browser into the next state

In other words, imagine all of these steps completing, and then the user pressing the back button. The browser sould reload the DOM exactly as it was represented in steps 1-3. I realize I'm being an idealist here (I tend to be,) but I can't stop thinking about how cool this would be. We could make the browser truly event-based instead of page load based by simply caching each snapshot of the DOM on each request/response cycle (ajax or traditional.)

Ofcourse, this idea may not be perfect. We still have a problem with the URL being the same across multiple events (or 'states'.) One of the main complaints against using ajax (or even dhtml in general,) is that bookmarking becomes impossible. But wouldn't it be great if you could bookmark a page after making several ajax requests? Maybe the browser could actually remember how it got back to the state that was bookmarked by remembering the sequence of events that occured after the last complete page load (I'll admit, this would be hard to implement, especially when we start mixing get and post requests.) But would it really be impossible. Do we really need a new protocol to handle this?

Value Object Aggregation in Rails

2006-09-27T00:00:00-04:00

Aggregation is an important concept that should arguably be applied to any domain of reasonable complexity. While this statement is certainly open for discussion, I feel that it's important to study what aggregation is and discover the benefits of making a distinction between true Entities and things that are just Value Objects. An Entity can be defined most simply as something that needs to maintain it's own state, whereas a Value Object is just a certain value (or collection of values) that has no state. Consider the following portion of a domain model:

In the example shown, both distributor and customer have an address. I would consider the address to be a Value Object since it has no state. Please realize that there may be some application domains where an address should be modeled as an entity, I just don't feel that this domain is one of them. Another way to think about this is that the address has no identity outside of the context of either a distributor or a customer. Therefore, we refer to distributor and customer as Root Entities. A value object should not be accessible without first going through a root entity. So, theoretically speaking, you should never be able to write the following code:

address = Address.new
address.save

The problem with the above code is that it refers to the address as it's own entity, which we said is probably not a good idea. We should only allow access to a value object through an owning entity like so:

address = Address.new
customer = Customer.new(:address => address)
customer.save

The difference here is that we are assigning the address to a customer and then saving the customer. So again, the address only makes sense within the context of a customer (or distributor) object. There is another subtle point going on here. Since an address has no state of its own, we should never be allowed to modify the address object - the address should be Immutable. This means that if the customers address changes, we would need to create a new address object and associate it with the customer and re-save the customer. Calling customer.address.zip = 08080 doesn't make sense (from a pedagogical point of view anyways.)

OK, enough theory - lets talk about implementation. Active Record has direct support for aggregation through the use of the composed_of keyword. Lets assume the following migrations are used to create the Customer and Distributor tables:

class CreateCustomers < ActiveRecord::Migration
  def self.up
    create_table :customers do |t|
      t.column :customer_name, :string
      t.column :phone_number, :string
      t.column :email, :string
      t.column :address_1, :string
      t.column :address_2, :string
      t.column :city, :string
      t.column :state, :string, :limit => 2
      t.column :zip, :string, :limit => 10
    end
  end

  def self.down
    drop_table :customers
  end
end

class CreateDistributors < ActiveRecord::Migration
  def self.up
    create_table :distributors do |t|
      t.column :distributor_name, :string
      t.column :distributor_region, :string
      t.column :phone_number, :string
      t.column :email, :string
      t.column :address_1, :string
      t.column :address_2, :string
      t.column :city, :string
      t.column :state, :string, :limit => 2
      t.column :zip, :string, :limit => 10
    end
  end

  def self.down
    drop_table :distributors
  end
end

Now, what we'd like to do is abstract the address columns into their own Address class. This will allow us to say things like customer.address.address_1 after Active Record has retrieved a collection of Customer objects for us. To further clarify, the following code should not run once we're done: distributor.address_1. The real benefit here is not just the syntactic sugar of adding 'address' to the reader method, rather we can now implement certain address related functionality (like calculate_distance,) and have that functionality be shared among multiple root entities of address objects.

First, we need to tell the Distributor and Customer classes that they should be composed of an Address:

class Customer < ActiveRecord::Base
  composed_of :address,
    :class_name => "Address",
    :mapping => [
      [:address_1, :address_1],
      [:address_2, :address_2],
      [:city, :city],
      [:state, :state],
      [:zip, :zip]]
end

class Distributor < ActiveRecord::Base
  composed_of :address,
    :class_name => "Address",
    :mapping => [
      [:address_1, :address_1],
      [:address_2, :address_2],
      [:city, :city],
      [:state, :state],
      [:zip, :zip]]
end

In the above two class definitions, the mapping and class_name attributes are optional. The class_name attribute isn't needed if the class name is the camel-cased version of the composed_of value. Additionally, the mapping attribute is not needed if each value pair contains identical values (as they do in this case.)

Now we can go ahead and create our Address class:

class Address
  attr_reader :address_1, :address_2, :city, :state, :zip
    
  def initialize(address_1, address_2, city, state, zip)
    @address_1 = address_1
    @address_2 = address_2
    @city = city
    @state = state
    @zip = zip
  end
end

Since Address objects will be immutable, we create only attribute reader methods. The attributes can only be set at initialization time. Rails further enforces immutability by freezing the value object once it has been associated with an entity.

So now that I've shown you how to implement such a thing, let's talk about the abundant shortcomings of this.

Duplication:

As you can see, there is a fair amount of duplication going on here. Not only are we re-defining all of the address attributes in each table that will be composed of an address, but we are also duplicating the mapping and class_name values in both the Customer and Distributor classes.

Validation

This is the deal breaker. Value objects in rails are completely dis-associated from ActiveRecord, which means they cannot use the wonderful validation framework provided. To be quite honest, this pisses me off. I believe this will make value objects in rails unusable in all cases where the value objects don't contain reference data. Yes, I'm aware of workarounds for this problem, like tricking the value object into thinking it's being handled by ActiveRecord, but to be honest with you, its not quite worth the hassle. I'd much sooner just make the value object an entity of it's own and lose the theoretical correctness of not maintaining the state of the object. But wait, that would bring up another problem: How do I associate an entity with more than one kind of other entity? The answer lies in one beautiful addition to Rails 1.1: Polymorphic Associations...

Model Versioning in Rails

2006-09-12T00:00:00-04:00

Versioned data is common to many applications. Consider the case of an online store selling products. A simplified view of the product data might consist of the upc, description, volume, and price. Let's suppose a customer purchases a product on September 12th for a certain amount, then we update the product info to reflect a price increase. If we dont keep a snapshot of the product data before the price increase, the customer's order history will be generated from the new product data instead of the product data at the time of purchase.

Ok, so we basically need a parallel product table to append a new entry to each time a product's data is updated. The main product table will always hold the current data. In Rails, this means that we need to somehow hijack the ActiveRecord call flow and intercept any updates to all product instances, append a new entry to the versioned table with a timestamp, and then somehow tell active record to resume its updating of the original product, making note of the version that was just appended. That sucks. I thought about using an observer, or maybe a callback...but there is definitely a better way - the acts_as_versioned plugin.

Let's go through the basic setup to getting this working.

Install the plugin:
```
prompt$ gem install acts_as_versioned
```

update the product model to use the plugin:

class Product < ActiveRecord::Base
    acts_as_versioned
    ...
end

Create your database tables.
```
Class CreateProducts < ActiveRecord::Migration
  def self.up
    create_table :products do |t|
      t.column :version, :integer
      t.column :upc, :integer
      t.column :description, :string, :null => false
      t.column :volume, :float, :null => false
      t.column :price, :decimal
    end

    Product.create_versioned_table
  end

  def self.down
    drop_table :products
    Product.drop_versioned_table
  end
end
```
Note that we are required here to add a version column to the main product table that will automatically be updated with the current version on each update (sequential, starting at 1.) You can use the version_column option to the acts_as_versioned declaration if you would like to rename the column. Also note that we use the create_versioned_table class method that was added to the Product class with the acts_as_versioned declaration. This method will automatically create a product_versions table with a product_id foreign key column, an updated_at datetime column, a version column, and a colum for each column in the products table. The drop_versioned_table class method will drop the table generated by the corresponding call to create_versioned_table.

Now you can start adding products and updating them, and you will see the versions magically appear in the product_versions table. There are a couple of problems here though. First of all, we are versioning all of the columns from the original model. In our example here, once a product is created, I know that the UPC cannot be changed, therefore there is no point in wasting a column for every version of every product. It turns out that the plugin will refer to the non_versioned_fields class method to determine which columns to generate in the migration and which columns in the versioned table (and corresponding object methods) to populate on each update. If we add our own columns to the array returned by non_versioned_fields, we can exclude certain columns from being versioned:

class Product < ActiveRecord::Base
  acts_as_versioned
  non_versioned_fields.push "upc"
end

Note here that you pushing symbols onto the array will not work, you must use strings. I have to admit that I'm a bit skeptical of the correctness of my implementation here, so please let me know if something seems a bit funky with the column exclusions (or anything else for that matter.)

The other problem is that by default, a new version will be appended to the versions table on every update. This means that if you change nothing on your product object and call update, a new version will be added. We can correct this using the :if_changed option to the original acts_as-versioned declaration.

class Product < ActiveRecord::Base
  acts_as_versioned :if_changed => [:description, :volume, :price]
  ...
end

This means that a new version will not be appended unless the description, volume, or price column has changed. The plugin also supports more complex version checks with :if and version_condition_met?.

I have to say that I'm pretty excited to start using this in some of my projects. At first I was a bit worried about the fact that the most current realease starts with a 0, but hey - its probably a hell of a lot more solid than anything I could come up with :)

Live Search Thinking

2006-08-16T00:00:00-04:00

An old live search post of mine generated a comment the other day regarding the feasibility of searching all of your records on each keystroke made by the user. This is one area of the post that I admittedly gave little (or no) attention to partly because it was out of the scope of the post (the usual excuse,) and partly because I didn't have any good answers to the problem (the real excuse.)

The first thing that needs to be decided is if there really exists a problem. I say this in both the performance sense (is your live search noticeably slow,) and the usability sense (does it make sense for your 'live' search to wait until your done typing to be submitted.) I personally feel that there should be a very short delay between the time the user starts typing and the time they see some results. Otherwise, we would just stick a submit button on there and be done with it. However, there is a point to be made in that each keystroke could potentially fire off a rather expensive http request, which in turn will search through a potentially large number of records and return a potentially large response to the user.

I think its safe to say that we have a problem here. We want results, we don't want to wait for them, and we want to include a lot of records in the search. I'm sorry to say, but something has to give. On this puny little blog, its no problem for my live search to perform an sql 'like' search of all my blog posts and render the results on each keystroke with a very short delay. For some people (and possibly for me in the future,) this will not be possible.

There is actually an interesting phenomenon going on here. If the response is not finished being prepared until after the next request comes in, then we are placing an extreme load on our server. By increasing the delay, we could potentially see no performance improvement from the user's perspective, but considerably reduce the strain on the server. It seems that there would be some kind of 'sweet spot' here for the value of this delay. The calculation of this value may be harder to come up with than the realization of its existence, but I think the following would need to be considered:

Average number of simultaneous requests on your web server
The number of total records to be searched
The average length of each record
The performance of the search algorithm (which may be hard to quantify for our purposes here)
Network traffic on the internet

Any number that could be calculated would certainly be based on heuristics, since things like network traffic on the internet are extremely hard to model.

After all this babbling, I have to wonder if any of this is even worth the effort. If your live search is too slow, you probably need to re-think what your search is doing. Maybe you need to index your entries with search keywords. Maybe you just have too many entries for a live search. I guess I don't have a whole lot of motivation here since at the current time my blog consists of only 40 entries. However, if the concept of 'live search' really catches on, then I believe research on this topic will be inevitable as clients like The New York Times want to add a live search to their home page (available only to the registered users of their site ofcourse.)

Superiority Complex

2006-08-04T00:00:00-04:00

I came across this post this morning written by Luke Welling, author of 'PHP and MySQL Web Development'. The post attempts to classify the superiority of programmers by their language of choice. I beleive Luke meant this as a complete joke, but the comments section is full of incompetence. I have always found this to be a nonsensical and meaningless topic, so I do realize that I am fueling the fire of bullshit here, but I feel the need to post my own classification of programmers:

Fiona Apple at Central Park

2006-07-27T00:00:00-04:00

I was lucky enough to see Fiona Apple and Damien Rice play at the central park summer stage last night. Definitely not the clientele you'd find at a Pearl Jam concert on the Camden Waterfront. Besides the fact that my sexual preference was very much in the minority, these people were reading between sets. That's right, I spotted at least 5 people reading a book while waiting for Fiona to come on stage. These books ranged in topics from Psychology to LSAT practice exams to Shakespeare. Weird shit.

My lasting impression after seeing Fiona for the first time is that I wouldn't mess with that chick. She comes off really cute and sweet and then gets really pissed off and appears to be having a seizure on stage. While I could do without the bouts of trembling and hitting herself, the emotions she has tied up in her music are quite evident and genuine.

One thing I really enjoyed about watching Fiona perform is that her music's true sound is present and easily discerned from her studio recordings. It's obvious that her record producers have a large effect on the way she's allowed to sing in order to produce a successful album (We all know that Extraordinary Machine wasn't even supposed to be released due to poor sales projections.) Music is too much of a wonderful thing to succumb to those dollar counters in suits.

Have you ever heard someone say 'you can tell this band is good since the concert sounds just like the CD.'? Nothing annoys me more than this statement. If you want to hear the studio recording, then play it on your iPod and save yourself the 50 dollar ticket and over-priced beers in the process. When you see an artist live, you really get to see what they are about, what makes them tick. If they're a good artist, they might even bring it to the point of appearing to have seizures on stage.

Dusk and Summer

2006-07-19T00:00:00-04:00

It's obvious that Chris Carraba went through some life balancing experience while writing the songs for the So Impossible EP (Which happens to be my favorite offering from Dashboard.) This EP paved the way for A Mark, A Mission, A Brand, A Scar with the 'Hands Down' single. In my opinion, the addition of the full band tainted many of the songs, but we all know about the inescapable need of an artist to play around with their sound from time to time.

That being said, the songs prior to So Impossible are where I believe Chris picked up most of his fan base. After a casual listen to The Swiss Army Romance, you are left feeling like you just had your heart broken and the shit kicked out of you (why this is an enjoyable experience, I cannot describe.) Even more impressive is that this state of 'enjoyable depression' (for lack of a better word,) is achieved with only acoustic instruments.

When the band released 'Vindicated' for the Spider Man 2 soundtrack, I was very much impressed at how they took the sound of A Mark, A Mission, A Brand, A Scar and went a little farther into a direction which I believe sounds much better. Dusk and Summer, in my opinion, is an entire album based on the sound of 'Vindicated'.

I think the album is solid and have been listening to it constantly for the past two weeks. The addition of Adam Duritz to 'So Long, So Long' certainly adds some luster. Fans of Swiss Army Romance and The Places You Have Come to Fear the Most may be a bit disapointed, but I think most fans will agree that this album is still worth owning.

Active Record Object Identity Part 2

2006-06-26T00:00:00-04:00

Well, it turns out that my last post was in fact fueled by my own mis-information. While browsing through David Black's Ruby For Rails book this afternoon, I stumbled upon a discussion involving the somewhat colorful history involving object identification in Ruby.

It turns out that there are actually 3 methods on the Object class used for identification.

Object#id

A more careful look at the Rdoc specifies that this method is soon to be deprecated (why didn't i see that yesterday!?) I believe that this was traditionally used for unique identification, but was found to be over-ridden too often to be reliable. Object identification is far too ubiquitous to be left into the hands of such a popular method name as id, which leads us to...

Object#__id__

This obscure looking call was added as an additional means to getting at the object id. The idea was that since the name is so obscure, it is unlikely that anyone would ever want to over-ride it (does Ruby have no concept of final!) I guess the name was too obscure to be usable though, since the next method was added later on down the road.

Object#object_id

The (hopefully) last addition to this saga which is yet another means at getting to the object id. I suppose this is the preferred method to use these days as it is left untouched by ActiveRecord.

My only question is, what happens if you over-ride all three of these?

Active Record Object Identity

2006-06-25T00:00:00-04:00

When compared to Hibernate, ActiveRecord is the clear winner for ease of use, but the clear loser for configurability. For most of the projects I work on, I'm happy to trade one for the other and go with ActiveRecord (not to mention all the other perks I get from using the rest of the Rails Framework.) However, I'm a bit disappointed (or maybe simply misinformed,) when it comes to object identity in ActiveRecord.

The Hibernate framework has a clear and understandable separation between object identity and the primary key of an entity. Object identification is the job of the JVM, and Hibernate guarantees that objects created within the same hibernate session will have a one-to-one correspondence to database records (meaning there won't exist two objects with different ids and the same primary key.) There is a clear distinction between the concepts of primary key and object id, and I think hibernate does a good job at keeping them at a reasonable distance from each other.

ActiveRecord, it appears, operates by enforcing the one-to-one correspondence between objects and database rows all the time. It does this by hijacking the id method of the Object class and returning the entity's primary key. Coming from the java world, this is confusing. I would think that pure object identification should be the job of the ruby interpreter, and not involve ActiveRecord at all. The problem with this approach is that disconnected new objects have no id - calling Object.id returns nil. But the object must have some identification within the interpreter, no?

I have to admit that the guarantee of never having two objects represent the same entity regardless of the 'session', (although the session concept doesn't really apply in ActiveRecord,) is appealing. But the problem I have is that there is no way to compare disconnected new entities unless we provide an == method, which I guess isn't a bad idea, but we'd be comparing natural candidate keys which won't be effective 100% of the time.

I have to ask you the reader (if anyone is in fact reading this,) to take a look at the rdoc for the Object#id method:

Returns an integer identifier for obj. The same number will be returned on all calls to id for a given object, and no two active objects will share an id.

Well, I guess it depends on how you define 'active' objects, but I would think that nil would never be returned here given this description.

Update - 6/26/2006 - All of this babbling is cleared up in this follow-up post

Live Search With Ruby On Rails Part 4 - request.xhr?

2006-05-09T00:00:00-04:00

After receiving some excellent advice from someone named Ivan, I've decided to revisit the topic of live search in Ruby on Rails yet another time. In this post written way back in February, I outlined the steps necessary to gracefully degrade the Ajax-style live search for browsers that have Javascript disabled. This required two distinct methods in the search controller: one for Javascript enabled browsers that would render the search results directly within the target element, and one for non-Javascript enabled browsers which would return the users back to the page they invoked the search from. To re-iterate, here's the search controller listing:

def search #Javascript-enabled search
  get_search_results #implementation not shown
  render :partial => "search"
end

def search_no_Javascript #Javascript-disabled search
  get_search_results #implementation not shown
  redirect_to :back
end

Admittedly, this design leaves a lot to be desired. The biggest concern here is that the code does not directly address the scenario of the user's browser having Javascript enabled, but not being able to support the XmlHttpRequest object (I say not directly since the code will still work if the user submits the form with the enter button, since no search button will be present.) The other (more theoretical) issue is that we have written two methods to do exactly the same thing, where the second method exists solely for graceful degradation of the view.

Well, it turns out that we can actually fix the latter. The framework provides us with request.xhr?, or the arguably nicer alias of request.xml_http_request?, which decides if the request has come from an Ajax-style call. The Rails API states that this decision is based on the 'X-Requested-With' header containing 'XMLHttpRequest', which is apparently done automatically by the framework whenever an Ajax request is made. This seems useful at first glance, but just remember that since this relies only on header information, it is possible that this could be simulated by any request.

OK, since I'm starting to look a bit too far into this now, let's see how this new discovery allows us to completely remove the un-needed second search method from our controller:

def search
  get_search_results
  if request.xhr?
    render :partial => "search"
  else
    redirect_to :back
end

Also, the implementation of get_search_results can be placed directly in the search method if you prefer, as the extraction of this code is no longer necessary.

This still leaves us with the problem of Javascript support without XmlHttpRequest support. Some would argue that this scenario will effect a negligible number of users, but I'd still like to figure out a way to get around this.

What an Idiot

2006-05-08T00:00:00-04:00

I understand that some people are brighter than others, but this guy should definitely win some kind of award for being a moron. I can't believe I actually got on the subway today with the sole purpose of witnessing this nonsense. What an idiot.

Live Search With Ruby On Rails Part 3

2006-05-01T00:00:00-04:00

In my previous posts on Rails Live Search (1, 2) I outlined some reservations I had regarding a typical live search implementation. One outstanding issue was that the framework provides a text_field html helper that seems unusable due to the fact that all form elements must be backed by the model. As tomtoday pointed out to me, this is simply not true. The Rails framework does provide a facility to render form elements that are not backed by the model using the _tag helper elements (text_field_tag, select_tag, etc.)

Many thanks to tomtoday for pointing this out to me. There's even a big fat section in the Agile Web Development With Rails book titled Working With Nonmodel Fields on page 366. Exactly how did I miss that!?

Error Styling in Struts

2006-04-19T00:00:00-04:00

In light of my last post, I'd like to discuss a new facility available in Struts to apply error styling to your form fields. Since Struts 1.2.5, all form elements now have the optional errorStyle, errorStyleClass, and errorStyleId attributes. These are meant as a means to define the styling of particular form elements that have failed validation (which I think is a pretty good idea.) Imagine the following form definition:

<html:form action="/processForm">
  User Name
  <html:text property="userName">
  Password
  <html:text property="password">
  <html:submit>
<html:form/>

Now, lets suppose we wanted to place a 2 pixel red border around each text field that fails validation. This can be accomplished by adding the desired error style attribute to the text fields, and defining the corresponding style. In our example here, we'll use the errorStyleClass attribute, which means that the framework will apply a class="fieldError" attribute to the rendered input field. Alternatively, we could use the errorStyleId and errorStyle attributes, which will apply the id="fieldError" and style="given style rules" attributes respectively.

<html:form action="/processForm">
  User Name
  <html:text property="userName" errorStyleClass="fieldError">
  Password
  <html:text property="password" errorStyleClass="fieldError">
  <html:submit>
<html:form/>

And in your css file:

.fieldError {
  border:2px solid red;	
}

Now, lets suppose the password field has some crazy requirement that is has to be between 4 and 5 characters, the first two characters must be digits, the third character must be a 'special' character, and the remaining characters can't be digits. (I know, its a bit of an exaggerated example.) The user has forgotten all of these rules and enters an invalid password. The following html will be rendered:

<form action="/processForm.do">
  User Name
  <input type="text" name="userName">
  Password
  <input type="text" name="password" class="fieldError">
  <input type="submit">
<form/>

Thus applying the fieldError style rule to the password field and drawing a 2px border around it. Simple right? Yes its simple. It's too freaking simple! I'd like to vent a bit about the following frustrations I have with this:

- The error style attribute has to be applied to all individual fields

At first, I thought this must be a mistake. I'm sure the following question has crossed at least some of your minds upon reading this post: You mean I have to add errorStyleClass="fieldError" to ALL of my form elements? Yes, you do. And yes, ITS RIDICULOUS! I just want all failed validations to include the class="fieldError" attribute when rendered. Is that so much to ask? Why can't I apply errorStyleClass to the top level form element and have ALL the fields on the form inherit this attribute (like the disable attribute?)

A possible solution to this might be to add a custom implementation of the struts html tags that will apply this class for you. I personally don't think that this is a good idea, but it would work.

- The errorStyleClass and styleClass attributes are mutually exclusive

That's right boys and girls. If you apply a style to your form element using the styleClass attribute, they will be forgotten in favor of your errorStyleClass definition upon failed validation. COME ON! There is no reason why the struts developers couldn't have simply added the class definitions given in the errorStyleClass attribute to the list of classes given in the styleClass attribute. This must be a product of 'design by committee'. Because of this obscure behavior, we now have to use unique error style class names for each element that already defines a style class. Not to mention duplicating the style rules across both class definitions.

If you take the above approach to alleviate yourself from adding the errorStyleClass attribute to every form element, it may also help in this situation. Your custom implementation could check if a style class or list of style classes was given, and simply add the error style class to the list. Again, this is possible and will work, but I'd hate to be the one to maintain it and explain it to new developers.

Web Form Usability

2006-04-10T00:00:00-04:00

After about 20 minutes of really trying to register at AMD's support site, I've come to the conclusion that it's just not possible. No matter what values I place into the form, I am always brought back to the same page with the *=required field message. I finally broke down and called them on the phone. Of course, I wasn't able to talk to a real person until an automated message walked me through all of the great, easy, convenient, and time-saving features available at their newly re-designed web site.

I have a feeling that I'm not alone in my frustration.

Web forms should be easy. There is no excuse for a web designer (or a developer given the task of designing the usability and look of a form, which too often is the case,) to design something like this. This is not 1995. We have tools, we have experience, heck - we're even getting paid more than ever (OK, not as much as 1999, but you know what I mean.) Did these people not try their final product? Did something else break that's causing the application to act stupid? Maybe I'll never know the answer to these questions, but I now keep this experience in the back of my mind when I'm given the task of designing a web form.

Feeling the need to write something about the simple usability of web based forms seems a bit odd to me, as we have all been using them for the past 10 years. But apparently, this type of writing is still warranted, as non-usable forms like those found at AMD are still being developed today. And we all know that AMD of all people should have their shit together.

What's missing from AMD's forms?

Well, besides the fact that they don't work, the user isn't given any feedback. Feedback is the most essential element when trying not to frustrate a user. Keep in mind though, that too much feedback is almost as bad as no feedback at all. So we need to find a happy median. A simple combination of textual and, more importantly, visual feedback will have our users keeping their heads on straight.

Textual feedback

This one is easy. Just give the user a list of things that's wrong with the form. This requires that each field is given a label (a good idea anyway.) Let's set up an example form that loosely follows a typical account creation form:

Now, some would argue that some instruction is warranted at this point. For example, letting the user know that the e-mail address must be in the xxx@xxx.com format, or that the telephone number must be in xxx-xxx-xxxx format. Let's see how something like that would look:

Admittedly, some of these examples are a bit extreme (like the 100 character limit,) but the point is that this clutter is simply not necessary. If they enter the e-mail address in the wrong format, we'll let them know at that point. 99% of the time, we won't get to that point. The only place I feel this is warranted in our example here is the password field. Since the higher-up, figure head, pointy haired people come up with the craziest requirements for what they see as an acceptable password, we should let the user know ahead of time what will fail validation.

Imagine the following situation:

It's pretty obvious what's going on here. The user is notified of the exact problem locations. This is good. A lot of sites fail to even get this far.

Visual Feedback

On our simple form, the textual description might be enough for the user to find and correct the problem in a short amount of time. But what if the form was complex (think IRS 1040.) How can we make the location of the problem incredibly obvious? How about this:

If you can't figure out what the problem is now, then its hopeless. This is where we want to be. To the point where the user simply has no doubt how to proceed. I'm sure there are many alternatives to what I've described above that will have the same effect. Just make sure your form is dummy-proof. It's easy. It's cheap. And it will make for a much more enjoyable on-line experience for your users.

p.s. I do realize that this post has a complete disregard for any and all accessibility issues (like color blindness.) I have no experience in this area, and am not one to give advice regarding it.

Live Search With Ruby On Rails Part 2

2006-02-28T00:00:00-05:00

In a previous post, I outlined the steps necessary to implement live search functionality in a Ruby On Rails application. That post brought forth some reservations I had regarding the semantics and accessibility nuances associated with the ajax-style search that I hope to (mostly) remedy in this post. Let's review the major problems I had with the original implementation:

We use an <input> tag that isn't wrapped with a <form> tag.
Rails provides a text_field html helper that seems unusable.
The observe_field kind of just hangs out on the page.
The search results are not persisted in the session.
A client's lack of Javascript or XMLHttpRequest support will cause serious confusion and a lack of any search functionality.

After reviewing these things for a couple of days, I was able to eliminate points 1, 4, and most of point 5. I'm happy with this since I feel that these are the biggest showstoppers (especially point 5,) as I've come to realize that point 2 and 3 are debate able, subtle, and probably not that important in the grand scheme of things. That being said, let's jump in and give our search functionality some enhanced accessibility.

As I said previously, I'm not a big fan of web sites that limit the core functionality (especially those that just sit there and act stupid,) when the user has Javascript disabled. There are lots of reasons why people would disable Javascript: corporate office policy, too many pop ups asking to buy porn, or maybe Grandma did it by accident when she was tinkering with the IE preferences trying to make the font size bigger. Whatever the reason, I feel that we need to accommodate non-Javascript users with very basic site functionality such as a search feature. I'm not advocating that we stop innovating and pushing the envelope of Javascript-only features like auto-spellcheck or auto-save, I'm just saying that being able to search never required Javascript in the past, and it shouldn't require it now or in the future.

Let's go ahead and iterate through each point and see what we can do to correct things.

- We use an <input> tag that isn't wrapped with a <form> tag.

This is easy enough to fix. Just wrap the thing in a form element. No harm done, and this will also set us up for point number 5. While we're at it, let's go ahead and add an action and a submit button to the form, as we'll need those for step 5 as well.

<%= start_form_tag :action => 'search_no_javascript' %>
  <input type="text" id="search" name="criteria" />
  <%= submit_tag 'Go' %>
<%= end_form_tag %>

- Rails provides a text_field html helper that seems unusable.

I'm still at a loss on this one. I suppose the Rails framework assumes that all form elements will correspond to something in the data model. In our example here, a search function should certainly not be a part of the data model. I'm sure there are other exceptions, so either I'm missing something that the framework provides, or I'm being a bit too anal here and need to stop looking so deeply into these things.

- The observe_field kind of just hangs out on the page.

Once again, I'm probably looking a bit too deep into this, but I do feel that the observers for an ajax-heavy site should probably be declared in a central, easily maintainable place, rather than in the actual markup. However, I admit that the jury is still out on this one, and we are dealing with only a single observer here, so let's forget about this for now.

- The search results are not persisted in the session.

This could be regarded as a matter of personal preference, but I believe that a persistent list of search results will make it easier for the person searching to find what they are looking for. This is especially true in our case here, where we are showing the titles of blog entries that contain the search criteria in the blog's actual contents, but not in the title.

The fix for this is pretty obvious: use session variable instead of instance variables. The only thing we need to be careful about here is handling the difference between no results, and not submitting any search criteria. The subtlety is in the fact that submitting no search criteria will in fact return no results (admittedly, this is based on your search implementation,) but we probably don't want to show the user any information regarding the results if no criteria has been sent.

To better coincide with our next topic, I've implemented the search results as a partial named _search.rhtml:

<%if session[:items] != nil &&
  (session[:mark_term] == nil||session[:mark_term].length> 0)%>
  <dl id="searchResultsDl" class="linkList">
    <dt>
      <%= session[:items].length %>
      Result(s) for
      <% session[:mark_term] %>
    </dt>
    <% for blog in session[:items] %>
      <dd>
        <% session[:mark_term] ? highlight(blog.title,
          session[:mark_term]) : h(blog.title) %>
      <dd>
    <% end %>
  </dl>
<% else %>
  &nbsp; #this represents the subtlety mentioned above
<% end %>

- A client's lack of Javascript or XMLHttpRequest support will cause serious confusion and a lack of any search functionality.

We now arrive at the heart of the matter. How do we gracefully degrade this thing? We started by wrapping our search criteria input field with a form element, assigning it an action of search_no_javascript, and adding a submit button. As you've probably guessed, we're going to implement an action in our controller to be used when the user has Javascript disabled. The search functionality will be identical to the standard Javascript-enabled search, so you can go ahead and extract that implementation into a separate private method called something like 'get_search_results'. What concerns us here is the final rendering decision of the action.

Previously, we rendered our search results directly into the searchResults div element with no layout. We're gonna change that a bit here so the Javascript and non-Javascript versions will play nice together. As I stated before, the search results rhtml has been moved to a partial named '_search.rhtml', instead of being inside a 'search.rhtml' file to coincide with the 'search' function:

<div id="searchResults">
  <%= render :partial => "search" %>
</div>

Note that this implementation is also a bit more semantically correct than our previous implementation, which displayed an empty div in the markup.

Now let's take a look at our two search actions in our controller:

def search #Javascript-enabled search
  get_search_results
  render :partial => "search"
end

def search_no_javascript #Javascript-disabled search
  get_search_results
  redirect_to :back
end

When Javascript is enabled, the search method is invoked from the observer, and the results are rendered using the partial _search.rhtml within the searchResults div. But wait, the _search.rhtml partial has already being rendered within the searchResults div, since we specifically placed it there. However, this rendering happens only on the page load. Once you give an observer a target element, the contents of that element will be replaced with the result of the action given to the observer. So in our case here, its kind of like we are hitting the refresh button on just searchResults div (which I must admit, is quite bizarre when you step back and think about it.) When we throw persistent search results into the mix, this method works beautifully, as hitting refresh will render the most current search results within the searchResults div.

Now, what happens when grandma turns off Javascript while trying to make her fonts bigger? Well, since we added a form and a submit button, she can go ahead and submit her search criteria the old-fashioned way: by hitting the submit button (I can hear the 'When I was your age' stories now!) This will invoke the search_no_javascript method in our action, which will gather the search results in the same way as before, but instead of rendering the results instantly within the searchResults div (which we realize is impossible without Javascript,) we simply re-direct her back to whatever page she was looking at when the search was submitted. A re-direct will cause the browser to make a new request for the page, thereby re-rendering the search results we just stuck in the session.

We're almost done here, but we have a couple more things to discuss. We don't want our users to see a search button if they have Javascript enabled. Similarly, we might want the label of the search field to say 'Live Search' when Javascript is present, and just plain 'Search' when it is not present. This can easily be achieved by initially setting the label to 'Search' and adding a small script just after the form element:

<script type="text/javascript">
  document.getElementById("searchSubmit").style.display = "none";
  document.getElementById("searchLabel").innerHTML = "Live Search";
</script>

This piece of script will run only when Javascript is enabled (obviously,) and will swap the label to 'Live Search' and hide the submit button. Some would argue that this should be placed in the body's onload attribute, as it should run when the page is loaded. However, the onload method requires the entire page to be loaded before the script is invoked, which causes a delay in its execution. This means that the user can actually see the label change and the button disappear.

One last point and then I'll shut up. We still haven't touched on the scenario of having Javascript enabled but no XMLHttpRequest functionality. As we all know, most recent browsers do in fact have this support, so I don't view this as being a big deal. However, since this is a post about accessibility, I should add that those users will still be able to use our search by entering their criteria and hitting enter, which will in turn submit the form. The only thing we lose is the visibility of the submit button, and the generic 'Search' label. I think I can live with that.

Update - 5/1/2006: I've added a followup to this post here.

New York City Snow

2006-02-15T00:00:00-05:00

Yes, snow can be beautiful. Skyscrapers glisten through unique flakes of frozen crystals as they lay fresh white blankets across the urban landscape. Then, those blankets are mixed with salt and dirt, causing them to melt into a never ending stream of substance that amounts to the dirt, grime, and waste of the millions of people, cars, dogs, even horses that pollute the streets and sidewalks each day. I hate the city when it snows.

Lava Lamp Builds

2006-02-13T00:00:00-05:00

The benefits of an automated build/test/package system are, in my opinion, quite obvious. But sometimes it takes a little bit more than statistical evidence to get you motivated. At my current project, we've been thinking about setting up such a system for some time now, but it wasn't until a colleague of mine stumbled upon the system described in Mike Clark's Pragmatic Project Automation that we realized we could include Lava Lamps and home automation devices to display the status of the current build. Fun stuff!

I'm happy to report that the system has been functional for about a week now, and I don't know how we ever lived without it. The Lava Lamps (or 'Extreme Feedback Devices' as Mike Clark calls them,) are very effective. As soon as someone sees the red light come on, they immediately look to see who made the last change to the code base so they can begin their tormenting. The system truly makes you want to keep your code base clean and your unit tests running without any errors.

If you're thinking of implementing a similar system, here's a list of things you'll need to get things rolling:

X10 FireCracker home automation kit
CruiseControl automated build system
An Ant build script for CruiseControl to invoke
The X10 Publisher for CruiseControl written by Mike Clark
Two Lava Lamps to indicate the build status

Extensive documentation is available in the book and on the book's website to fit these pieces together, but a few snags and surprises were discovered along the way that I feel should be documented.

The Java Communication Library (in its current version of 3,) is not available for Windows. Therefore, if you're forced to work on a windows machine, its up to you to find a copy of the old version 2 Library. I found a copy of it here.
The X10 devices don't seem to work as advertised through our building's electrical system. We found that the transceiver and the lamp module have to be plugged into the same power strip. This presented a problem for us, as we wanted to have a single transceiver with multiple lamp modules scattered around the cubicle farm. We were able to get around this by using a transceiver and a lamp module at each cubicle. I don't know how far the transmitter will work, but we tested it up to about 12 cubicles away without any problems.
CruiseControl gives you the ability to automatically send e-mail to certain people whenever the build breaks. We thought this was such a cool feature that we just couldn't wait to throw a bunch of e-mail addresses in there. Be warned that as soon as your manager starts receiving these, he/she will get all kinds of crazy ideas ("Let's integrate this thing with PeopleSoft and include it into our monthly report to the steering committee!")

If I run into some spare time in the near future, I'm gonna see how hard it would be to get this thing running within a Ruby On Rails development environment. If that day ever comes, I'll be sure to post my findings. In the meantime, be sure to hit me up with any suggestions!

Live Search With Ruby On Rails

2006-02-01T00:00:00-05:00

Gone are the days of actually submitting your search query and waiting for an entirely new page to be rendered. The 'Live Search' era is upon us, and I'm here to welcome it with open arms. My first encounter with a Live Search type of form was some time in 2005 when Google launched Google Suggest. I was so blown away that I figured only a giant company full of PhD's could figure out how to implement this. Boy, was I wrong.

I'm here to discuss a step-by-step procedure for adding a live search feature to your Ruby On Rails application, and some of the peculiarities you may encounter while walking through the steps. The wiki on the Rails site is the only real resource I could find regarding live search, and it will be the basis of our discussion here.

Implementation Steps

The steps to adding live search to your Ruby On Rails app are as follows:

Include the default Javascript files in your page
<%= javascript_include_tag :defaults %>
OR
<%= define_javascript_functions %>
Both of these will give you access to the ActionPack Javascript libraries. The difference is that define_javascript_functions will place ALL of the ActionPack Javascript within a <script> tag on your page, where the javascript_include_tag will simply link the external ActionPack Javascript files to your page. (HINT: use javascript_include_tag)
Create a text field for your users to enter their search criteria. We'll use 'search' as our id and name attributes, but feel free to use any value you want.
<input type="text" id="search" name="search" />
Create an image to be used as a status indicator while the search is being performed. Be sure to set an id and add an inline style rule to force the image to not show initially.
<img id="busy" src="/images/spinner.gif" style="display:none" />
If you're looking for some images to use on your site, some are available here. Also feel free to use the modified spinner indicator I'm using on this site.
Create an empty div where you would like the results of the search to be rendered. Be sure to give the div an id.
<div id="searchResults"></div>
Create an Ajax observer to observe the text field while the user is typing. The value of the first parameter should be whatever you chose as an id in step 2.
```
<%= observe_field 'search',
  :frequency => 0.5,
  :update => 'searchResults',
  :url => { :controller => 'blog', :action=> 'search' },
  :with => "'criteria=' + escape(value)",
  :loading => "document.getElementById('busy').style.display='inline'",
  :loaded => "document.getElementById('busy').style.display='none'" %>
```
This is where we get a first glimpse of the power inherent in the Ajax helpers. To implement this directly through the XMLHttpRequest object would be much more difficult, error-prone, and messy. Let's take a look at each of the expressions we're using here
- :frequency - The frequency, in seconds, that you would like the field to be observed
- :update - The id of the element where the search results should be rendered. This is the id you chose in step 4
- :url - The controller/action that implements your search functionality (see step 6)
- :with - Used to pass a parameter called 'criteria' which will be set to the value of the text field at the time of the observation. The call to escape ensures that any special characters in the input are escaped. Note that we are breaking out of the traditional form-submission process where a request parameter is automatically created for a form element when the form is submitted. We technically don't have a form in this case (more on this later.)
- :loading - used to display the busy indicator image you created in step 3. The Javascript placed here will be executed when the search results element is being loaded with data
- :loaded - used to hide the busy indicator once the search results element is done loading.
You should also be aware that any options available in link_to_remote are also available to you here.
Create an action in the controller of your choice that will provide the search facility. Let's assume we have a model called 'Blog' with the blog's contents being stored in the 'content' column.
```
def search
  if 0 == @params['criteria'].length
    @items = nil
  else
    @items = Blog.find(:all, :order_by => 'title',
      :conditions => [ 'LOWER(content) LIKE ?',
      '%' + @params['criteria'].downcase + '%' ])
    @mark_term = @params['criteria']
  end
  render_without_layout
end
```
This search function will perform a simple sql like query on the blog's criteria column. Depending on the size of your site and the volume of content you have, this may or may not be a sufficient way to search. For our purposes here, this method works just fine. Once the results have been gathered, we render the search results (using no layout) with the page you will create in the next step. Also note that we have set an instance variable, @mark_term, that we can use to highlight our search criteria within the rendered search results.
Create a search.rhtml view page to display the search results.
```
<% if @items && @items.length > 0 %>
  <ul id="searchResults">
    <% for blog in @items %>
      <li>
        <%= link_to
          @mark_term ? highlight(blog.title, @mark_term) : h(blog.title),
          :controller => "blog",
          :action => "show", :id => blog.id %>
      </li>
    <% end %>
  </ul>
  <% elsif @mark_term && @mark_term.length > 0 %>
    No Results
  <% else %>
    &nbsp;
<% end %>
```
If @items is not nil or empty, then we display our search results as a list of links to each blog entry's 'show' action, highlighting the given search term within each link. If you would like to change the appearance of the highlighting, simply add a style rule for the class 'highlight' in your style sheet. If the @mark_term is not nil or 0 characters, then the search must not have returned any results, so we simply display 'No Results'. Otherwise, we show nothing since this would indicate that the search field has been cleared.

In just 7 painless steps we were able to create a piece of functionality that I wouldn't have dreamed possible back in 1999. I have to admit that my initial reaction to such a cool feature (given so little code) was nothing less than a giddy feeling of amazement. However, there are some things I do feel uncomfortable with here, and this being my blog, I'm gonna go ahead and discuss them.

We use an <input> tag that isn't wrapped with a <form> tag.

I'm not sure if I should be as bothered by this as I am, but it just doesn't feel right to have form elements without a form. Let's take a look at the W3C's definition of form elements:

Form elements are elements that allow the user to enter information (like text fields, textarea fields, drop-down menus, radio buttons, checkboxes, etc.) in a form.

The last part is what gets me: in a form. Form elements allow you to capture data in a form. But we have no form here. I suppose you could argue that wrapping the input tag with a form element will do no harm here and will make the page more semantically correct, however; the action attribute would be left empty (or useless, since we have no submit button,) and that would open up a whole new basket of worries.

It is at this point I realized that Ajax functionality may come at a cost.

Rails provides a text_field html helper that seems unusable

There is built in support for generating html form elements, but I find them to be unusable in this case. The html form helpers seem to work only when the form is backed by an actual model object. If I am missing something here, please let me know.

The observe_field kind of just hangs out on the page

I find it to have no semantic meaning or proper place. Perhaps all of the observers should be registered in a single place, but I'm not sure if that makes sense either. I suppose you could argue that the <script> or <style> tag is just as semantically incorrect. In any event, it bothers me.

The search is not persisted in the session

I'm assuming this can be fixed. Perhaps this will be the topic of a later post.

No JavaScript For You!

I personally feel very strongly against limiting a site's core functionality when the user has Javascript disabled. I can see this issue becoming less and less prominent as more mainstream sites are depending on Javascript for core functionality, however; I still see the need to support browsers sans Javascript (Certainly in the case of search functionality.)

If Javascript is disabled in our example here, the user has no way of knowing how to search. They'll enter some text, hit enter, wait, and then get frustrated and leave. Therefore, a button should be displayed for the user when Javascript is disabled (or when the XMLHttpRequest object is not available on the user's browser.) At first glance this problem does not seem to be trivial. There are many factors to consider here (one being the previously stated absence of a form tag and submit button.) This will be the topic of a later post.

Browser Support

I tested this code on all of the browsers I had laying around. I realize this is in no way an exhaustive list, but I found the following browsers to be supported:

Safari 2.0
Firefox 1.5 Mac
Firefox 1.0.4 Linux
Firefox 1.0.4 Windows
Mozilla 1.7.8 Linux
Konqueror 3.5
Epiphany 1.6.0
Opera 8.51 Mac
IE 5.5 Windows
IE 6 Windows

and these browsers to be unsupported:

IE 5.2.3 Mac
Opera 7.5.4 Mac

Update - 3/13/2006: I've added a followup to this post here.

Update - 5/1/2006: I've added another followup here.

Bittersweet Nostalgia

2006-01-18T00:00:00-05:00

As a deterrent to my infinite boredom, I've decided to digitize my reminiscence of concert experiences. In other words, I've taken the time to scan all the old concert tickets I have laying around. The oldest ticket I found is from a 1999 Dave Matthew's Concert at Veterans Stadium in Philadelphia. Since then, Dave and company have released 4 more studio albums, I went and saw them 11 more times, and Veterans Stadium has been imploded and is now a parking lot. I feel old.

Web 2.0 Whining

2006-01-17T00:00:00-05:00

I have nothing but the utmost respect for Mr. Jeffrey Zeldman. If it wasn't for him and that beautiful orange book he wrote back in 2003, I wouldn't be half as motivated to create clean content for the web. That being said, I'm a bit disappointed that he has fallen victim to the nonsensical whining of anti-web-2.0 zealots. I don't see the point and I wish it would all just go away.

As I've said before, I'm not a fan of buzzwords and there's nothing I hate more than a middle manager with a head full of technologies he knows nothing about. But let's forget about all that and think about what it is we are trying to accomplish. I don't know about you, but I would like to make better web sites. Web sites with better usability.

Let's face it, Tim Berners-Lee never fathomed the web would be used the way we use it today when he was sitting behind a NeXTcube. The HTML protocol was just not made to support rich e-mail clients that check our spelling as we type, or maps that allow us to drag them around transparently fetching more information from the server in the background. I don't see how anybody could disagree with the fact that these features enhance a user's experience on the web, and they would simply not be possible without AJAX or some other still undiscovered technology.

I'm also sick of hearing that AJAX provides nothing new. That AJAX is the same old javascript with fancy API's written on top. This is simply not true. AJAX is a collection of technologies that, until recently, nobody thought to stick together. Nobody is claiming the javascript to be interesting. It's the way javascript is being used to invoke other available resources, namely the XmlHttpRequest object, that makes things interesting. I will agree that these technologies were available in some capacity since Internet Explorer 5, but who cares! Do we disdain AJAX as a technology just because it is a collection of existing technologies that nobody had the mental capacity and creativity to stick together before now? I think not.

The sooner people stop complaining about the improper use of 'Web 2.0' buzzwords and start thinking about what this technology (or concept, or collection of technologies, or whatever you wish to call it,) gives us as web developers and how we can embrace it and enhance it, the better off we will be, and the better off the users of our sites will be. I don't care if venture capitalists are backing a hundred Ruby-based AJAX-driven social networking sites. I don't care about the money involved or the possibility of another dot-com bubble. I just care about the technology. I'm excited about what this technology offers us and I look forward to watching it shape the future of the web.

Portable Time Zones In Rails Applications

2006-01-05T00:00:00-05:00

It seems like such a simple concept: I live in New Jersey; therefore I would like all of the dated material on my site to be displayed and managed in the Eastern Time zone. I'm sure some of you are wondering why I'm wasting my time writing about such a simple concept. Set the server time zone to US/Eastern and all should be well, right? Not so fast. Suppose your server is in California and you don't have the option of changing the time zone.

This is the situation I encountered recently while putting this site together to be hosted by Dreamhost. After thinking way too long about how to solve this problem, I'd like to discuss my solution for maintaining flexible, time zone independent dates in Rails applications.

The Problem

Let's take a look at what we're trying to accomplish:

Time.now and mysql>sysdate() will produce times in the Pacific Time zone, but we would like to store and display these times in the Eastern Time zone.
We would like all of our dates to be managed in the Eastern Time zone.

That's it. Seems simple enough right?

What most people will probably do at first

OK, the server is on Pacific Time, so all dates generated on the system clock will be in Pacific Time. The Pacific Time zone is exactly 3 hours behind the Eastern Time zone, so the problem can be fixed by simply adding 3 hours to all the dates being generated by the System clock. Your SQL will change to: mysql>date_add(sysdate(), interval 3 hour);
and, more appropriately for a Rails application, Your Ruby code will change to:
time_in_eastern = Time.now() + (60 * 60 * 3)

So we're close to coming up with a solution: our users will give us all times in the Eastern Time zone, and all system clock generated times will be converted to the Eastern Time zone by adding 3 hours. In researching message boards and articles on the subject, it seems like this is probably the most popular solution (not necessarily only for Rails apps, but in general.) However, we should consider the following drawbacks to this solution:

strftime("%Z") will still display the Pacific Time zone by default for any dates retrieved with ActiveRecord.
Your application will be hard-coded with a 3 hour interval difference. What if webspace becomes ridiculously cheap in Russia and you'd like to move your application? (Hey, music is, so why not web space?)
If you decide at a later time that you would like to work with your dates in some other time zone, say Central time, you will need to change the time interval in your code to 2 instead of 3, and subtract an hour from all the dates that have been stored already. Not exactly portable.

Where does this leave us?

OK, so strftime("%Z") is displaying Pacific Time, even though we are sure that all of our times are stored as Eastern Time. Believe it or not, this can be fixed with a simple configuration of your application. Whooaa! A configuration...In a Rails app? But that's impossible!

The Rails team prides itself on 'convention over configuration,' and for the most part, following the conventions will lead to predictable results. However, in this situation, the convention is for ActiveRecord to default to using whatever time zone your server is in when retrieving dates. This is a problem for us, since we would like to work with our dates in some other time zone. The solution requires us to add an entry to the bottom of the environment.rb file (under the /public directory):

ActiveRecord::Base.default_timezone = :est

This will tell ActiveRecord to retrieve all dates as Eastern Time Zone dates, regardless of the server's actual time zone.

Now all of the bases are covered, and we have come up with a first run solution to the problem. If this solution works for you, and you are happy with keeping track of all these conversions, then go for it. I personally would like a better solution. A solution that would allow me to move my application, or my database, to a server living in a different time zone. I would also like the freedom to change my mind as to what time zone my application prefers to work in (think about selling your application to a customer. Shouldn't they choose the time zone?)

Enter UTC Time

UTC, or Universal Time Code, is a modern day synonym for Greenwich Mean Time (they are not exactly the same, but for our purposes here, they can be thought of as the same.) If we store all of our dates in UTC, then we have the freedom of moving our application and our database to servers in any time zone. Additionally, we can use an environment variable to tell our application what time zone to use when generating timestamps off of the system clock. The Ruby Time API is written to transparently handle all of the conversions between our local time zone dates, and the UTC dates we will be storing in the database.

Let's Implement

First we'll edit our environment.rb file to inform ActiveRecord that our dates are stored in UTC:

ActiveRecord::Base.default_timezone = :utc

Now, we'll add an additional entry to the environment.rb file to set up an environment variable informing rails that the local time zone should be Eastern Time:

ENV['TZ'] = 'US/Eastern'

And thats it! Our application is now configured for portable time zones. As a best practice, I would recommend appending '_UTC' to the end of the database column name responsible for storing your dates. This will make it obvious to anyone viewing the table that the dates are stored in UTC.

Common Usage of The Time API

Our app is now configured and ready to roll, so lets look at how we can easily work with our new portable dates with the use of the Ruby Time library. For the following code snippets, let's assume we have a 'Blog' model with a column 'date_added_utc'

Time.now -> The current timestamp in Eastern Time.
Time.now.utc -> The UTC representation of the current timestamp. This should be used to convert times to UTC before being stored in the database.
Blog.find(id).date_added.utc.localtime -> The Eastern Time zone representation of the date_added_utc field. This should be used when retrieving dates from the database.
Blog.find(id).date_added_utc.utc? -> Evaluates to True. Use this method to test if dates are in UTC form.

Aren't We Forgetting Something?

When discussing the problems with time zones, we said that mysql>sysdate() generated times in the wrong time zone. We haven't said a word about it since. I personally feel that you shouldn't ever have to use this in your Rails apps, since you would be straying from the ORM-driven path provided by ActiveRecord. However, I realize that some developers might wish to use straight SQL in their applications, so I'm here to help. If you would like to generate current UTC timestamps in sql, you can use the convert_tz construct (If your using MySql, this is only available in versions 4.1.3 and greater.) The syntax is as follows:

mysql>convert_tz(systime(), 'PST', 'UTC')

This will return the conversion of the current system time from Pacific Time to UTC time. Remember, we are once again at the mercy of the location of the database server. In order to make this a bit more maintainable, we could use a sepaarate environment variable to specify the time zone of the database server so it won't be hard-coded in our application. But again, my advice is to not use database-generated timestamps in favor of working directly in Ruby. If you disagree, then this should give you some direction as to how to use them practically to keep your application maintainable.

New York City Randomness

2006-01-02T00:00:00-05:00

New York City is filled with so much absolute randomness, that I often feel the need to document some things as I go through the day. This picture surely speaks for itself, but I think it helps to point out that the price tag is $250.00. I have to concede I did take part in some fashion crazes during the late 80's and early 90's (Z cavaricci anyone?) But at least I can say I was just a stupid kid back then. Grown women are buying these things! Weird.

The Daily What The F%@!

2005-12-29T00:00:00-05:00

When people get depressed, it sometimes helps to remind them of certain situations that are worse than the one they are currently in. If I'm saddened by the fact that I got sick and had to miss the Dave Matthews concert, its easy for me to come to grips with reality when I'm reminded of the fact that some people are sick all of the time, not just for a few days.

The same concept is certainly valid in the jungle of software maintenance. If your buddy is given the task of adding some functionality to a piece of obfuscated code, it might help to remind him of some code that has much more serious problems. This easy to do, given the large collection of nauseating code samples available at The Daily WTF. A simple click of this link, and I assure you that your buddy will be feeling better in no time.

I will leave you with the sole inspiration of this post. An error message that I hope to never see again during the rest of my career:

Ipod Love

2005-12-23T00:00:00-05:00

I love when this happens...You're wandering along mindlessly listening to your iPod on random play, and you realize, "I haven't heard this song in the longest time." Then it all comes pouring back. The posters that were hanging on the wall in your old bedroom. The 'best friend' that you haven't spoken with in years. The girl that broke your heart. Everything. These memories come streaming from this song. This music. This chaos of analog waves bouncing around in your head. The feeling really is amazing.

So if you haven't guessed it, I was fortunate enough to have this experience the other day. The song was Hurt by Nine Inch Nails, which was released on The Downward Spiral album back in 1994. It's probably been about 6 years since I last heard this song, so I was content with the fact that my iPod chose to play it out of the thousands of choices it had. But when it rains it pours, right? A couple days later, I learned while reading Spin Magazine that Johnny Cash did a cover of the song in 2002 on his American IV: The Man Comes Around album.

I'm here to say that the Johnny Cash version is amazing. I love how a song can lead multiple lives between artists. The emotional differences between Trent Reznor in his 20's and Johnny Cash in his 70's is a lot of fun to compare and pick apart. Download both versions - you won't be dissapointed.

The Joys Of Rails - ORM and MVC Under One Roof!

2005-12-20T00:00:00-05:00

Well, my foray into Ruby territory has led to a complete re-write of this PHP based site (this marks the first post under the new publishing system.) As I've posted here before, I'm quite impressed with the Rails framework and it's ability to lessen the development of web applications down to implementing what the application actually does, instead of wasting time implementing system-level details. These details are not trivial - mapping relational database tables to objects and creating an MVC environment for your code to operate in is a significant undertaking, as most developers would agree (If you disagree, I'd love to chat.)

But wait! Rails isn't the first framework to offer these conveniences. What about Struts, Hibernate, blah, blah, blah. I've used them. I even like them. But seriously, configuring these frameworks to work with one another can be mind numbing. Let's not even go into the initial steps involving the inclusion of 8,369 jar files into your project - can you say 'ClassNotFoundException'? The fact that Rails includes an ORM implementation AND an MVC implementation, both under the SAME project, is something very special. Let's look at some pitfalls that Rails makes a thing of the past.

Java Beans

Plain vanilla Java beans are a great way to store, access, and transfer data in the object domain. This is not rocket science and has been well known for a long time. The problem is that everyone wants their own slice of the pie. Both Hibernate and Struts want to use their own set of java beans, even though they both describe exactly the same data. What's even more annoying is that Struts requires its java beans to ride the short bus to school: they can only store String objects (Okay, and Boolean, but that doesn't really help.) This means that your data needs to be continually shuffled between the Struts beans, your business objects, and the beans used in your persistence layer.

Many developers, including myself, feel that multiple sets of java beans are a redundant waste of time, code, and money. This is the topic of many flame wars, and can be compared to the Eagles playing the Giants. The bottom line is that I don't want to write any java beans. getThis(), setThat(), how about forgetItAllAndUseRails().

XML

I've been writing J2EE applications long enough that editing XML configuration files has become second nature to me. If someone is touting that their jar file will make your life easier, you can expect that it needs at least one XML file. This isn't exactly a bad idea, its just that it may be an unnecessary step and can lead to lots of headaches during maintenance.

Okay, now its time for another flame war: Rails circumvents XML files by having the developer follow naming conventions. Yes, this means that you must name things in certain ways if you want them to work properly. This rates right up there with Emacs vs. Vi. I can't count the number of times I've gotten into an argument over the naming of different things:

"We shouldn't use underscores in the table and column names, your waisting a character!"
This table should be plural since the cardinality of the relationship is one to many!"
That variable name is descriptive, but its way too long!"

It turns out that there are no absolute rules when it comes to naming these types of things, and I might not agree with all of the naming conventions chosen for Rails, but at the end of the day I really don't care. Those conventions make sense to some people (very smart people actually,) and I can live with them if it means that I don't have to waste any more time editing XML files. I think in most cases (not all cases,) XML is an application band-aid, especially when the XML is being used for configuration. The only problem is that the application never heals, so the band-aid is never removed.

Conclusions

I'm not convinced 100% that Rails will take over the world. But I am convinced that ORM and MVC should be available in a single framework (Not to mention the other great features of Rails like the testing module.)

<action path = "convert"
    type = "com.joestelmach.actions.StrutsToRubyConverter"
    input = "struts.jsp">
  <forward name="rubyConversionSuccess" path="theJoysOfRuby.jsp" >
</action>

Ruby Suggestion

2005-11-25T00:00:00-05:00

As I inch my way towards the Ruby conversion of this site, I can't help but to stop and think about how cool this stuff really is. If you are a web developer, I suggest you try the following:

Buy a copy of Agile Web Development With Rails. (Don't walk, RUN.)
Open the book to page 385 and read the chapter on Ajax support titled The Web, 2.0.
If you are not completely blown away by what you are reading, then I have some doubts as so how much web development you've done in the past.

Let me say that I'm not a big fan of buzzwords. In fact, I loathe them. One of the biggest dangers to a company's software development is a bunch of middle-managers with their head's full of buzzwords ("We need to move all internal database access to a web service with SOAP built on top of SOA with a Portlet view ASAP!") However, after reading this chapter, I feel strongly that AJAX will help to lift the 'Web 2.0' buzzword to industry-altering status.

"I remember the days when a web form needed to be submitted to an actual web server to be processed. Your typing wasn't even spell-checked for you!"

Guster At Nokia Theater

2005-11-22T00:00:00-05:00

Guster has got to be one of the most unique bands of our time. Sure, lots of people have never heard of them, but seriously, how often do you get to experience a band play with a drumstick-less percussionist? I've had the oppurtunity several times now, all of which were at a Guster concert.

The most recent of these experiences was this past Saturday night, when Guster played at the Nokia Theatre in Times Square. Wow. What - A - Venue. This place was ridiculously fancy for a concert like this. When I think of Guster, I think of places like The Electric Factory and Irving Plaza, not some place with stained hard-wood flooring and chandeliers. More importantly, the acoustical properties of the stage were spectacular.

The show itself was great. More evidence of Guster's uniqueness was displayed as Chewbaka (from Star Wars,) was brought onto stage in between songs. This reminds me of a particular Guster show in Philly that happened to be right around the start of Hanukkah. A request was made to play the Dredyl Song, which the band granted, but with a Guster-esh twist. The Philadelphia Eagles mascot was brought onto the stage to light a giant menorah with a plunger. Never a dull moment.

The band treated us to a second encore, which consisted of a completely acoustic performace of Jesus on the Radio. Let me re-iterate here. A completely acoustic performance. In all the shows I've seen (lots) I've never experienced a band give an all-acoustic performance to a couple thousand people. When does Guster play again?

Hurricane Wilma

2005-11-12T00:00:00-05:00

As I sit on this turbulent plane flying back to Philadelphia, I can't help but to think how lucky I am to live in New Jersey (I know, that sounds funny.) But all kidding aside, the aftermath of hurricane Wilma is a lot worse than most people in the northeast imagine in their minds. The media's coverage of this hurricane doesn't come close to describing the destruction I've witnessed these past few days while driving from Ft. Lauderdale to Key West. Imagine throwing most of your belongings (including major appliances that were once a permanent fixture of your home,) out to the curb to be collected by some government agency.

I don't doubt that hurricane Rita was a bit more devastating than Wilma, but I find the lack of media attention to Wilma to be a bit startling. The media absolutely loves to go crazy over life-threatening events. Consider the New York subway scare that happened last month (Remember, someone was supposed to blow up the subway with a baby carriage.) I witnessed at least a half dozen news trucks parked out front of Penn Station for several days during the scare to do their news casts. They were just sitting there, almost waiting for fire and smoke to come pouring out of Madison Square Garden so they could get the best ratings on the 11 o'clock news. But unlike the subway scare, hurricane Wilma produced actual death and destruction. I don't get it.

I think the Ft. Lauderdale cab driver was quite articulate in his description of the hurricane: 'So much damage my friend, no more trees, no more coconuts'.

Why The Lucky Stiff

2005-10-27T00:00:00-04:00

I've spent my bus ride this week reading through The Best Software Writing I, which consists of a bunch of weblogs and essays that have been selected and introduced by Joel Spolsky. I'm a big fan of Joel's writing and overall beliefs when it comes to software development, so I figured the book would be worth my time. While the entire book is worth reading, I'd have to say that the last entry, which is titled A Quick (And Hopefully Painless) Ride Through Ruby (With Cartoon Foxes), is by far the most entertaining piece of writing on software development that I've ever come across.

The first indication of this article's uniqueness has to be the fact that the author's name is given as 'why the lucky stiff'. While I'm still unsure of what that means, I do know that I learned more about Ruby in the 15 minutes I spent reading this article then I did in a week working through the tutorial in the Agile Web Development with Rails book. The cartoon idea has been used successfully before, like in the Head First Java series of books (which I happen to love by the way,) but this article really brings it to the next level. Here, we are crossing the line into politically incorrect software writing, and I believe the result is fabulous and incredibly effective.

I was overjoyed to learn that the selection I was reading is just the first chapter of a work in progress that's available here. The author (whose name I still do not know,) also has a weblog. It would be worth your while to add it to your collection of RSS feeds.

Chuck D From Public Enemy

2005-10-17T00:00:00-04:00

I was just skimming through this month's issue of Spin Magazine, when I stumbled upon an interview with Chuck D from Public Enemy. When the interviewer asked how he can defend the artistic legitimacy of something like Ludacris' "Move Bitch," Chuck D responded with:

"You can't defend it. How do you defend rock groups throwing TVs out hotel-room windows? You can't; they're just assholes."

I couldn't agree more with Chuck D's position here. This comment makes me want to go download some Public Enemy music.

Weezer and Foo Fighters @ Continental

2005-10-15T00:00:00-04:00

Ok, so I'm starting to feel a bit like a concert junkie here. I went and saw Weezer and Foo Fighters last night at Continental Arena in the beautiful Meadowlands. The best part - VIP floor standing tickets, which I am still in shock for being able to buy. As you can see, we were pretty damn close.

This marks the third time that I've seen Weezer in concert, and I have to say that I was a bit disappointed this time around. I can think of a few reasons for a lackluster performance:

Rivers needs to have sex. Celibacy is just no good for a rock star.
The pressures of being a Harvard student must be fairly difficult to deal with. Maybe Rivers has a mid term next week.
Maybe the band (and me,) is just getting older. It's not 1995 anymore.

Foo Fighters on the other hand, whom I've never seen before last night, were just incredible. Simply put, David Grohl is amazing. He flows flawlessly from guitar to drums to screaming his lungs out. I don't remember ever being this impressed with a band after seeing them for the first time. When referring to illegally downloaded music, Grohl said something to the effect of: "I don't care how you heard it, I don't care if you took the song from your friends ipod, I just care if you know the song and would like to hear me play it." Those are the words of a musician who cares more about music then about money. Unlike some other bands we know of (cough, cough - Metallica.)

Ruby On Rails

2005-10-13T00:00:00-04:00

All this talk about Ruby on Rails - A List Apart is now using it, a multitude of users on The Server Side and other message boards are using it, and they are all saying the same thing - it's the hottest new thing in web development. What's next? Will I read on Slashdot tommorow morning that Amazon.com and ebay have switched over to a Ruby on Rails system? Not likely, but my interest has been stirred enough to install the framework and work through the basic tutorial involving the creation of a thrilling recipe book application. After completing the tutorial, which took about 20 minutes once I got past some installation headaches, I have to say that I am highly impressed. I am so taken aback by the results that I'm thinking of moving this PHP-based site over to Ruby on Rails immediately (cold weather is coming soon anyway, I'll need a winter project.)

The framework is not without flaw though. Documentation is sparse, and as I mentioned before, the installation on my powerbook was a bit of a struggle (Admittedly, I didn't look all that hard for help outside of the documentation, but should I really have to?) The trouble started while working through the recipe tutorial. All was going fine until about page 3, when it came time to start up the web server and test the application, which resulted in the following strange error:

ActiveRecord::StatementInvalid in Recipe#new
No database selected: SHOW FIELDS FROM recipes script/server:49

After a bit of frustration, I realized that I had never installed the framework's mysql component. I attempted this with the following command, as per the documentation:

gem install mysql

Which resulted in the following nasty output:

pbook:/Users/joe/Rails root# gem install mysql -- -with-mysql-dir=/usr/local/mysql
Attempting local installation of 'mysql'
Local gem file not found: mysql*.gem
Attempting remote installation of 'mysql'
Building native extensions. This could take a while...
ERROR: While executing gem ... (RuntimeError)
ERROR: Failed to build gem native extension.
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/mysql-2.6 for inspection.
ruby extconf.rb install mysql -- -with-mysql-dir=/usr/local/mysql\nchecking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... no
checking for mysql_query() in -lmysqlclient... no

I decided to try and install from source, noting from the manual that this must be done with gcc 3.3 as follows:

sudo gcc_select 3.3
ruby extconf.rb install mysql -- --with-mysql-config=/usr/local/mysql-standard-4.1.12-apple- darwin7.9.0-powerpc/bin/mysql_config

All was happy after this. I still can't get over the amount of work I didn't have to do to get this thing to do something interesting. No sql strings leading to concatenation-hell, no connection management, no form processing, and barely any code at all. Pretty cool.

Third Eye Blind and David Gray

2005-10-09T00:00:00-04:00

I think I broke a personal record this past week for the most concerts seen in a one week period. Following the Pearl Jam show on Saturday, I went and saw Third Eye Blind for the first time at the Starland Ballroom. Once I got past the fact that the only people in the audience older than me were there with their kids, I had an awesome time. Hearing Motorcycle Drive By live in a little Jersey Bar like the Starland was nothing short of spectacular.

The following night I was fortunate enough to see David Gray from the 15th row at Radio City. Quite a different crowd and performance compared to the night before. He played his new album, Life In Slow Motion, basically in its entirety. I was a little dissapointed that I didn't hear much off of White Ladder, but he did play Babylon, which was pretty much the only song that got that old crowd off its feet. Like I said, a bit different than the Third Eye Blind concert.

I'm gonna rest up the next couple of days so I'll be ready to see Weezer and Foo Fighters this Friday at Continental Arena. I think that the only benefit to being done with school is that I can now afford to see lots of shows.

Pearl Jam @ The Borgata

2005-10-03T00:00:00-04:00

By some brilliant stroke of luck, I was able to get tickets to see Pearl Jam last night at the Borgata. Yes, the Borgata, whose seating capacity is just shy of 3700, hosted Pearl Jam, who has no problem selling out crowds of 25,000 or more. Such a big band in such a small place.

We got there just before Sleater-Kinney came out to open up the show and were greeted by Eddie Vedder performing a cover of Bruce Springsteen's Atlantic City. How appropriate. As he walked off stage, he said to the crowd 'I hope I didn't mess that up too bad, but if I did, I'll have the entire evening to make it up to you.' As the night went on, the concert was nothing but the typical Pearl Jam style: Drink lots of wine and play for a really long time.

Listening to them play the old stuff like Alive, Porch, and Evenflow really brought me back to the days of baggy pants and skateboards. I think I'm getting old.

Back to School this Fall

2005-09-28T00:00:00-04:00

Going back to school for my Phd in Computer Science has certainly crossed my mind plenty of times. The working world I'm currently immersed in is simply not cutting it for me in terms of mental stimulation. Since a Phd is not likely at this time due to not having a topic I'd like to pursue, and not being in a position to be broke for the next four years, I decided to go back to school to get in touch with my creative side instead. I'm taking a course in Black and White Photography at the School of Visual Arts. So far, it seems like a Phd might have been cheaper and maybe even easier! I had no idea what I was getting myself into.

This picture should give you an idea as to how much stuff I needed to buy just to get started with this course. If you're wondering what all this stuff could possibly be used for, let me just add that all the film taken for the class will be developed at home. This process begins by popping open the film, cutting it off the roll, and threading it onto a spool. This wouldn't be all that bad, except for the fact that it all must be done inside a lightproof bag (yes, there are holes in the bag for you to stick your arms through,) which means you can't exactly see what you're doing. The film is then developed in the bath tub and hung on the shower curtain to dry. Like I said, I had no idea.

I think the course will prove to be valuable even for a geek programmer like myself. Creativity during coding is very similar to, if not the same thing, as an artist's creativity. I firmly believe that combining the talents of an artist and a coder can offer some fresh perspectives on any programming project.

I'm sure some people, including most of my colleagues, will either disagree with me on this point or tell me that a programmer has no right being creative in the first place. I think most of these people have never been exposed to any kind of artistic activity. Some of the most talented people in Computer Science (people like Paul Graham , author of Hackers and Painters comes to mind,) have studied some form of artistic expression in the past. Whatever stance you take on this, I'm sure you'll agree with me on one thing: This old school Nikon FM2 film camera is HOT!

Reflections of a Ti

2005-09-20T00:00:00-04:00

As I wait patiently for my shiny new Beemer to arrive, I thought it necessary to reflect on how truly awesome my '96 318ti was at one time, even if it has been burnt to a crisp and sold off to salvage. The image you see below represents the ti's true heyday, the year that the car was invited to compete at the IASCA World Finals in Greenville, SC. The year was 1999, and the amplifiers in the trunk were polished brighter than the wheels. For some reason I doubt I will ever have a trunk that looks like that again. But who knows.

My Love For Vi

2005-09-19T00:00:00-04:00

There are certain things in life that I wish I had: a Porsche 911 turbo, a two bedroom brownstone in Hoboken, and a full featured vi text editor. My love for vi started sometime around the Spring semester of 2001, when I was a sophomore in college. The phrase 'Pico makes you dumb!' was constantly thrown at me by my squeaky-voiced unix guru of a professor. Ever since then, I've found myself to be much more productive using the vi keybindings. This wasn't a problem for the rest of college and grad school, as this practice was acceptable and even encouraged by my professors and peers. Then came the real world I am now stuck in, full of WordPad using, vi hating (or vi oblivious,) point and click loving co-workers.

These people wouldn't learn vi if they were paid double time to do it. 'It's so cryptic, how could you ever use that' they say, as I shake my head in disagreement. 'Where's the tabbed interface?' they ask. Now I'm cornered. I start to explain how the editor can handle multiple buffers at the same time, but then I realize that they're right. I would like a tabbed interface. I would like to have multiple vim windows running under OS X (without having some stupid helper application that sits on my Desktop where I drag files to.) I wouldn't mind a file browser with a native view of the file system.

It doesn't seem likely for a application like this to emerge, even with the seemingly endless number of hardcore programmers that would rather die than use a different editor. Maybe some of these programmers don't need or even want the cute bells and whistles I'm hoping for. Or maybe the real world is turning me into a softie. One thing is for sure: If I ever become a WordPad user, then I'm taking up a career in art.

Coldplay

2005-09-05T00:00:00-04:00

I Went and saw Coldplay at The PNC Arts Center this weekend. Here's a few things that I learned:

Kingdom Come was written by Chris Martin as a tribute to Johnny Cash, but was not recorded until after Johnny Cash died in 2003.
The Scientist is more of an amazing song than I thought it was before.
Hearing them perform Fix You is one of the most amazing concert experiences possible.

Needless to say, we had a great time. I highly recommend seeing these guys if you ever get the opportunity.

The Wait Begins

2005-08-30T00:00:00-04:00

My search for a pre-owned 330ci somewhere in the New Jersey region has come to an end. It didn't seem likely that a black on grey manual trans. would show up anytime soon, so I placed an order for a brand spankin' new 325i. Black Sapphire Metallic, Sport Package, Premium Package, Xenon Lights ... I'm getting giddy just typing about it. I'll have the car sometime in mid-October, which is a hell of a long time from now. Patience.

Further Seems Forever

2005-08-23T00:00:00-04:00

I've been a pretty big Dashboard Confessional fan for the past three years, and their new album couldn't be released soon enough. While browsing around at the iTunes music store tonight, I somehow came across an album by a band called Further Seems Forever. Apparently, Chris Carrabba was the lead singer up until 2001, when they released the album The Moon is Down. I'm not gonna lie, I'm pretty excited about this. If you're a Dashboard fan, you should definately check it out.

Good Bye Buddy

2005-08-16T00:00:00-04:00

Well, I thought the day would never come. My beloved 1996 BMW with 160,000 miles has finally bit the dust. Not because the engine died. Not because something has worn out that's too expensive to fix. The reason is that Prestige Auto Body in Fort Lee New Jersey does not know how to fix cars.

Back in May, some guy in a mini-van ran through a stop sign and dented my rear quarter panel. I took the car to the geniuses at Prestige and waited almost two months to get the car back. Two weeks later I was waiting at a red light by my apartment when the driver side tail light bursted into flames. Imagine the sadness I ensued while watching the Edgewater Fire Department put out a fire in the trunk of the car I've had for the past 6 years. I loved that car. Check the photo section soon for some more pics. I see a 330ci in my future.