Late to the Party: Category Rails

Aptana Studio 1.0 Released!

chris.a.williams@gmail.com (Chris) — Tue, 30 Oct 2007 12:41:00 +0000

Wow it's been quite a while since I last posted. In the meantime I've been working hard on RDT and RadRails at Aptana and the job has been great. I'm very lucky to have found a way to work on the open source projects I love full-time.

In that vein I'd like to announce that we've released the 1.0 of Aptana. This release is important for a number of reasons. First, we think the product is good-to-go for everyone. Second, we're announcing a Pro version of the IDE. This version is for users who want to support the project so we can keep going, or who want the extra features and perks that come with a license: nightly build access, priority support, IE Javascript Debugger, SFTP/FTPS support and all sorts of other goodies. The support, nightly builds, SVN access also apply to the other components of what we're now calling Aptana Studio: RadRails, iPhone, PHP and AIR. So if you want to be on the bleeding edge of RadRails/RDT development you'll probably want to look into getting a license.

Keep in mind that while we do offer a pro version for those who'd like to support us or the extra stuff, we are still shipping the same codebase (minus the commercial features) as an open source project under GPL. And we plan to remain an open-source company with an open source product. Here's hoping that model will work for us!

Aptana backs RDT, hires me

chris.a.williams@gmail.com (Chris) — Sat, 21 Apr 2007 16:41:00 +0000

I'm proud to announce today that Aptana has hired me to work full-time on RDT, RadRails and integrating that work with their existing Aptana IDE which focuses on CSS, HTML and Javascript.

This announcement means that RDT will now have commercial backing (but will remain open-source and free!) and that you should see RDT and RadRails move forward at a much quicker pace than in the past.

This is also great news for RadRails users and Rails developers in general as integrating the two will give you code completion, outlines, help, debugging and much more across the entire stack - from model to controller to the HTML, ruby code, CSS and Javascript that make up your views.

Patterns in Ruby: Decorator revisited

chris.a.williams@gmail.com (Chris) — Tue, 26 Dec 2006 18:38:00 +0000

A while back I wrote an article describing some possible ways to implement a Decorator pattern in Ruby. I've stumbled across several mentions of yet another idiom used so often in the Rails codebase that they've extracted it into the latest ActiveSupport. That idiom is alias_method_chain, and it's a good example of a decorator implementation.

This idiom is a codified example of using the alias approach I briefly mentioned in the earlier article. In that article we aliased the original implementation with anew name, and set up a new implementation of our method (often delegating to the original) with the original's name. A quick example makes this clear:

class Window
  def draw
    # do some drawing here...
  end

  # some code...

# creates a 'copy' of draw method, but gives it
# the name/selector 'original_draw'
  alias :original_draw :draw 

  def draw
    draw_vertical_scrollbar
    original_draw
  end
end

`alias_method_chain`

In Rails 1.2 (ActiveSupport specifically), the Rails core team found many instances of this pattern and codified a new method on the class Module, alias_method_chain. This class-level method encapsulates this pattern of wrapping existing methods with additional behavior.

Here's a specific example, showing how they would wrap rendering with layouts:

alias_method :render_with_no_layout, :render
alias_method :render, :render_with_a_layout

In this small code snippet, they are creating a small chain of methods to wrap the existing render behavior. Now calls to render will be routed to render_with_a_layout and then on to the original render implementation (which is now aliased to render_with_no_layout). So they coded up alias_method_chain which simply does the wrapping for them (using naming conventions):

class Module
  # Encapsulates the common pattern of:
  #
  #   alias_method :foo_without_feature, :foo
  #   alias_method :foo, :foo_with_feature
  #
  # With this, you simply do:
  #
  #   alias_method_chain :foo, :feature
  #
  # And both aliases are set up for you.
  def alias_method_chain(target, feature)
    alias_method "#{target}_without_#{feature}", target
    alias_method target, "#{target}_with_#{feature}"
  end
end

Please note that if they were to replace their existing two calls to alias_method above, they would need to tweak the naming a little (the methods would become render_without_layout and render_with_layout as opposed to render_with_no_layout and render_with_a_layout respectively).

Multi-stage deployments with Capistrano

chris.a.williams@gmail.com (Chris) — Fri, 29 Sep 2006 12:56:00 +0000

I'm seeing a recurring theme in my feed reader today - multi-stage deployments with Capistrano. It seems that those of us working in larger companies have all hit the same issue - we have some form of user acceptance, staging or other system which mirrors the production in configuration; and we want to use Capistrano to deploy to it as well as production. I know that my current company has a 5-stage process for pushing out releases (we're in financial services, and very paranoid. Whether they'd ever accept Capistrano is another issue).

So here are my lazy pointers to the discussions:

Ola Bini, who's been doing some great posts on ruby metaprogramming, calls out his need for a "production_test" environment.
Simon Harris shares some snippets of deploying to his staged server running mongrel.
Jamis Buck, the creator of Capistrano, weighed in a while ago on multiple deployment stages

Update: Michael Buffington shares his Mongrel deployment for multiple stages

Prototype based Tag Autocompletion

chris.a.williams@gmail.com (Chris) — Tue, 19 Sep 2006 15:12:00 +0000

I've been working on a website that uses tags internally. The acts_as_taggable plugin has been great, but it only takes care of the ActiveRecord portion of tagging. One of the pieces of functionality I needed was to create an autocompleter for users to enter a list of tags on a record. Below is a pure copy-paste dump of my implementation. I'm not claiming it's good code or the right way top do things, but for those looking to use an autocompleter for a text field holding tags might find it useful. The implementation is close to that used by delicious in the tags field on posting new bookmarks.

Here's an example usage:

<label for="tags">Tags</label>
<%= text_field_tag 'tags', @tags.join(' '), :size => 80, :autocomplete => "off" %>
<div class="auto_complete" id="tags_auto_complete"></div>

And the prototype-based class in javascript. You'll probably want to stick this in your application.js file if you're using Rails.

String.prototype.trim = function(){ return this.replace(/^\s+|\s+$/g,'') }

Autocompleter.Tag = Class.create();
Autocompleter.Tag.prototype = Object.extend(new Autocompleter.Base(), {
  lastEdit: '',
  currentTag: {},
  initialize: function(element, update, array, options) {
    this.baseInitialize(element, update, options);
    this.options.array = array;
  },
  
  getCurrentTag: function() {
	if(this.element.value == this.lastEdit) return true // no edit
	if(this.element == '') return false
	this.currentTag = {}
	var tagArray=this.element.value.toLowerCase().split(' '), oldArray=this.lastEdit.toLowerCase().split(' '), currentTags = [], matched=false, t,o
	for (t in tagArray) {
		for (o in oldArray) {
			if(typeof oldArray[o] == 'undefined') { oldArray.splice(o,1); break }
			if(tagArray[t] == oldArray[o]) { matched = true; oldArray.splice(o,1); break; }
		}
		if(!matched) currentTags[currentTags.length] = t
		matched=false
	}
	// more than one word changed... abort
	if(currentTags.length > 1) {
	  // hideSuggestions(); TODO Fix this!
	  return false;
	}
	this.currentTag = { text:tagArray[currentTags[0]], index:currentTags[0] }
	return true
  },

  getUpdatedChoices: function() {
    this.updateChoices(this.options.selector(this));
  },
  
  onKeyPress: function(event) {
    if(this.active)
      switch(event.keyCode) {
       case Event.KEY_TAB:
       case Event.KEY_RETURN:
         this.selectEntry();
         Event.stop(event);
       case Event.KEY_ESC:
         this.hide();
         this.active = false;
         Event.stop(event);
         return;
       case Event.KEY_LEFT:
       case Event.KEY_RIGHT:
         return;
       case Event.KEY_UP:
         this.markPrevious();
         this.render();
         if(navigator.appVersion.indexOf('AppleWebKit')>0) Event.stop(event);
         return;
       case Event.KEY_DOWN:
         this.markNext();
         this.render();
         if(navigator.appVersion.indexOf('AppleWebKit')>0) Event.stop(event);
         return;
      }
     else 
       if(event.keyCode==Event.KEY_TAB || event.keyCode==Event.KEY_RETURN || 
         (navigator.appVersion.indexOf('AppleWebKit') > 0 && event.keyCode == 0)) return;
    this.lastEdit = this.element.value;

    this.changed = true;
    this.hasFocus = true;

    if(this.observer) clearTimeout(this.observer);
      this.observer = 
        setTimeout(this.onObserverEvent.bind(this), this.options.frequency*1000);
  },
  
  updateElement: function(selectedElement) {
    if (this.options.updateElement) {
      this.options.updateElement(selectedElement);
      return;
    }
    var value = '';
    if (this.options.select) {
      var nodes = document.getElementsByClassName(this.options.select, selectedElement) || [];
      if(nodes.length>0) value = Element.collectTextNodes(nodes[0], this.options.select);
    } else
      value = Element.collectTextNodesIgnoreClass(selectedElement, 'informal');
    
    var lastTokenPos = this.findLastToken();
    if (lastTokenPos != -1) {
      var newValue = this.element.value.substr(0, lastTokenPos + 1);
      var whitespace = this.element.value.substr(lastTokenPos + 1).match(/^\s+/);
      if (whitespace)
        newValue += whitespace[0];
      this.element.value = newValue + value;
    } else {
      tagArray = this.element.value.trim().split(' ')
      if (!this.getCurrentTag()) return;  // We had a problem getting the current tag, just return?
      tagArray[this.currentTag.index] = value;
      this.element.value = tagArray.join(' ');
    }
    this.element.focus();
    
    if (this.options.afterUpdateElement)
      this.options.afterUpdateElement(this.element, selectedElement);
  },

  setOptions: function(options) {
    this.options = Object.extend({
      choices: 10,
      partialSearch: true,
      partialChars: 2,
      ignoreCase: true,
      fullSearch: false,
      selector: function(instance) {
          var ret       = []; // Beginning matches
        var partial   = []; // Inside matches
        var entry     = instance.getToken();
        
        entry = entry.trim().split(' ').pop()
        
        var count     = 0;

        for (var i = 0; i < instance.options.array.length &&  
          ret.length < instance.options.choices ; i++) { 

          var elem = instance.options.array[i];
          var foundPos = instance.options.ignoreCase ? 
            elem.toLowerCase().indexOf(entry.toLowerCase()) : 
            elem.indexOf(entry);

          while (foundPos != -1) {
            if (foundPos == 0 && elem.length != entry.length) { 
              ret.push("<li><strong>" + elem.substr(0, entry.length) + "</strong>" + 
                elem.substr(entry.length) + "</li>");
              break;
            } else if (entry.length >= instance.options.partialChars && 
              instance.options.partialSearch && foundPos != -1) {
              if (instance.options.fullSearch || /\s/.test(elem.substr(foundPos-1,1))) {
                partial.push("<li>" + elem.substr(0, foundPos) + "<strong>" +
                  elem.substr(foundPos, entry.length) + "</strong>" + elem.substr(
                  foundPos + entry.length) + "</li>");
                break;
              }
            }

            foundPos = instance.options.ignoreCase ? 
              elem.toLowerCase().indexOf(entry.toLowerCase(), foundPos + 1) : 
              elem.indexOf(entry, foundPos + 1);

          }
        }
        if (partial.length)
          ret = ret.concat(partial.slice(0, instance.options.choices - ret.length))
        return "<ul>" + ret.join('') + "</ul>";
      }    
    }, options || {});
  }
});

RailsConf and Rails 1.2

chris.a.williams@gmail.com (Chris) — Mon, 26 Jun 2006 17:50:00 +0000

I meant to blog as the Rails Conference progressed, but the wireless network (and my own shame of my Wintel notebook) kept me from doing so. So here's my very quickly summarized notes on what I saw...

The keynotes that stuck out most for me were Paul Graham's, Nathaniel Talbott's and DHH's. The first two were not technology focused, so much as people-oriented, and DHH's was very much about the future of Rails as he sees it.

Paul Graham's Keynote

Update: Looks like Paul already has posted this essay online.

First I should mention that Paul Graham is even more entertaining in person than his essays, which is saying quite a bit.

Paul Graham's keynote focused on technology and startups, particularly on the concept that being marginal/specialized is a great quality to pursue, and leads to most innovation. The talk was essentially about the fact that the conference attendees were highly marginalized in their technology choice - Ruby and Rails - but that being at the leading edge and risking yourself was the best way to get ahead. I guess the crux of it was that too many people play it safe in too many ways, not just about technology choices, but also in careers. The talk was really an extension of his series (and Y-Combinator), prodding us alpha geeks to go out and try our hand at becoming the next big startup.

Nathaniel Talbott's Keynote

Nathaniel's speech was actually quite similar to Paul's. Their speaking styles and the analogies they drew were quite dissimilar, but their basic aim was the same: to urge us to strike out on our own and pursue our passion.

Nathaniel drew analogies between homesteading in the 1800's to creating your own business in modern times. The technology we have now allows us to create services and business with minimal overhead and a very, very small team - similar to the way the Transcontinental Railroad gave way to east coast workers to strike out, stake some land and begin a new life.

The analogy I most enjoyed, that was added from a suggestion when he gave a preparatory run through of his talk at a local user group, is the idea of "barnraising" (yes that site got up over night after his talk). The basic premise being that we have a lot of smart rails geeks here, why not help start actually implementing one another's ideas? The idea isn't particularly unique, but the concept of the Rails community helping one another out in launching their businesses really hit home for a lot of attendees. I know I've personally got about 20 small Rails projects that I started quickly and scrapped just as quickly because I didn't have time, or needed encouragement. I'm really interested to see if this has sparked any groups of attendees into hacking up some quick projects (a la Railsday).

DHH's Keynote

David's keynote focused on a couple things:

First, that Rails was successful because it often said "no" where other frameworks would say yes in terms of accepting functionality. So the calls to improve and extened various parts of Rails to help extend it into the corporate/enterprise world were alluring but if heeded too blindly or easily would lead to feature creep and bloat to the point that we'd begin to start looking like the frameworks we were leaving in the dust.

Second, he talked about the immediate future for Rails, Rails 1.2. Rails is embracing REST. Really, really embracing REST. This means new routes like so:

map.resource '/person'

Which would give RESTful URLs, which would automagically map to the conventional controller method names.

Let's look at a controller in this scheme, with the URL mapped to the method it would invoke:

class PeopleController < ApplicationController
  def index # GET /people
  end

  def create  # POST /people
  end

  def edit # GET /people/1;edit
  end

  def new # GET /people;new
  end

  def show  # GET /people/1
  end

  def destroy  # DELETE /people/1
  end

  def update  # PUT /people/1
  end
end

We're moving beyond GET and POST in Rails 1.2 - it'll be done by doing some hacking in terms of setting an HTTP header with the HTTP method we want to actually invoke (since HTML doesn't actually support PUT and DELETE).

Neat stuff, wqe're trying to move more towards convetniosn in our controller and views - and embracing the single URL approach of an URL as a resource and handling representation in different ways. There's also a new mime type idea, where we start using the URL's extension as the clue as to which format we'd want back. (We pushed to drop extensions long ago because .jsp, .php, or .asp didn't mean anything to the user - they were leaking the implementation language. DHH wants to re-introduce extensions as a means of letting the server know what format we want the representation in). Let's look at an example:

class PeopleController < ApplicationController

  def show
    @person = Person.find(params[:id])
    respond_to do |wants|
      wants.html # renders 'show.rhtml' template
      wants.js # renders 'show.rjs' 
      wants.xml { render :xml => @person.to_xml }
    end
  end

end

Now we can add extensions to recognize using their mime-type and use that to determine what to return to the user.

Building on all of this, David wants to create a new way of convention over configuration in web services: Enter ActiveResource. When we have REST APIs, everything gets pretty simple, we can start doing things across web services almost like ActiveRecord.

Person = ActiveResource::Struct.new do |p| 
  p.uri "http://www.example.com/people"   
  p.credentials :name => "dhh", :password => "secret" 
end

#Issues GET http://www.example.com/people/1
matz = Person.find(1) 
matz.name # => "Matz"

No more SOAP, no XML-RPC, no nothing. Just grab the XML representation and translate it back into a Ruby object.

The talk certainly worried a number of people, but the promise of this is incredible. We're getting nice simple web services, and we're getting URIs that really represent resources, and it's becoming very easy to do multiple representations quickly. Really exciting stuff here.

Switchtower changes

chris.a.williams@gmail.com (Chris) — Mon, 19 Dec 2005 18:11:11 +0000

Just a note to people who may have run into the same problem: I had been running an old version of Switchtower (from back when it was announced but only available via SVN), and recently upgraded to using the gem. Here's the process of migrating for any of you who had been on the bleeding edge and want to get up to date now:

Remove the vendor/switchtower.rb and vendor/switchtower directory. (I'm assuming this is where you installed it - it should have been.)
Remove scripts/switchtower
Download and install the Switchtower gem
Make a backup copy of config/deploy.rb just in case.
Run 'switchtower --apply-to your_rails_app_dir' - Do NOT overwrite your config/deploy.rb recipes!

You should be ready to go. However, the first time I deployed I ran into some weirdness in my custom deploy task. I was referring to current_release to do some symlinking and chmodding. If your old switchtower labelled releases with an integer number and you refer to current_release in your customized tasks, you may run into the same problem. Switchtower was picking up one of my old release directories as the current_release (it was something like 355), I'm assuming because numerically it looks "more recent" than the release it just checked out (into the new timestamp format - something like 20051214XXXXX). I had to rename the old release directories so they wouldn't be picked up as "newer" _and I also modified my task to refer to release_path instead of current_release (since I was using it for the path anyhow).

First Rochester Rails / Ruby Group Meeting

chris.a.williams@gmail.com (Chris) — Mon, 19 Dec 2005 17:25:23 +0000

This past Thursday saw the very first meeting for the Rochester Ruby and Rails group. We met at the Golisano College of Computing and Information Sciences at RIT, and had a significant RIT student and alumni contingent. As far as logistics go, it looks like we'll be meeting there regularly on the first and third Thursdays of each month starting up January 19th.

The group seems to be more dominated by those interested in Rails, but I'm hoping as we go along they'll want to learn more about the underlying langauge - after all, to get some of the significant gains in productivity they'll have to exploit language features like blocks and meta-programming. Happily, the format we decided on devotes time to two interactive discussion/presentations per meeting - one Ruby-language focused and the other Rails focused. It was a bit of a strange night - the Rochester area had a nice coating of slick ice (though I won't call it an "ice storm" because of the true Ice Storm when I was a kid. We lost power for two weeks!) - and almost no one brought their laptops. I suppose we all figured it was just our first meeting so it would be a meet and greet.

I'm also proud to say that the Rochester Ruby and Rails group has the entire RadRails development team as members as well as myself from the RDT developers. So we have a nice showing of ruby related eclipse experts ;)

Rails 1.0 Released

chris.a.williams@gmail.com (Chris) — Wed, 14 Dec 2005 18:36:24 +0000

Hey! Rails 1.0 is now out. Man, I really should get out from under my rock more often...

New Rails templates for AJAX

chris.a.williams@gmail.com (Chris) — Tue, 29 Nov 2005 19:11:21 +0000

Those of you who are doing some heavy AJAX with Rails should check out Cody Fauser's post about the new RJS templates supported by Rails. This allows you to extract all the javascript actions that should take place (effects, insertions, changing HTML dynamically) into a single template file. The concept is a bit different for those used to current templates. The current notion for templates is to produce some XML or HTML to present to the user. These templates allow you to define methods in the controller (that are called by AJAX calls, like link_to_remote) which handle traversing your model, just like in normal actions, but instead of placing your javascript code inside the RHTML template, you place the intended AJAX effects into an RJS template with the same name as the AJAX method/action in the controller. This may sound rather complicated, but it is actually easier to handle complex interactions with AJAX. The current helper methods tended to limit you to updating a single element as a result of various callbacks in the lifecycle of the AJAX method invokation. These templates will make it easy to define all the intended AJAX effects and results into a single place. Please note that this is in Edge Rails - the trunk of the subversion repository for now, so those wanting to try this out will need to download the trunk.