Late to the Party: Tag 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.

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 || {});
  }
});

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.

Subversion Externals and Typo blogs

chris.a.williams@gmail.com (Chris) — Wed, 09 Nov 2005 15:33:40 +0000

I've been running Typo as my blog engine for some time now, and keep my blog under version control with Subversion. I have some minor modifications and configuration changes in my copy, but I strive to keep in tune with the Typo subversion trunk. So my question is: is there any way to set it up so that when I do an update that the core of my blog gets updated to the latest Typo code, but that my themes, modifications and configuration remain under my own version control? I assume there's some way to do it with svn:externals, but I'm not very experienced with that.

Originally, I had minor modifications to the core Typo code in the views to customize some HTML output which may have made this more difficult (resorting to SVK perhaps?), but now that themes can override views, I'll likely only have configuration (i.e. database.yml) and themes differing from the Typo core.

Tutorial on implementing REST web services in Rails

chris.a.williams@gmail.com (Chris) — Fri, 04 Nov 2005 16:31:28 +0000

Just a quick pointer to a nice article about implementing REST web service interfaces with Rails. The code snippets don't format so nicely, so it seems a little scary, but actually it does appear to be rather easy.

Rails tip: Get Sneaky and cache pages with many parameters

chris.a.williams@gmail.com (Chris) — Wed, 02 Nov 2005 21:03:00 +0000

So you're the coolest cat in town. You've been using Rails for like, at least a month now. Heck, you've even started getting caching working on your coolest new site. But wait a second. Your zeitgeist page has 4 fields which are passed around as parameters and you need to start caching the results badly, because Slashdot just posted about how brilliant your new site is. So what do you do?

You watch as your site goes down in flames and weep uncontrollably.

No! Well, OK, maybe the first time. But after reading this you may be one step closer to avoiding the shame of sobbing like you just watched Dancer in the Dark and thought no one would be home for at least another hour.

We'll use Typo and my own site, pervwatch.org as examples to see how it's been tackled so far. Let's start with Pervwatch since that implementation is a little simpler. First, some context. Pervwatch is a Google Maps mashup. It combines Google Maps, geocoder.us data, and state sex offender registries to plot the location of sex offenders on a map. It allows you to see them all in one glance visually, where most sex offender registry websites show a single offender at a time on a map. The problem I had to tackle was that the pages for a number of the most populated counties in large states like California had too many results coming back. The pages became huge and the map was filled with too many markers. It slowed down users browsers, ate up browser memory, and took a long time to render on the server side. I could cache the results to eliminate the server side slowdown, but clients would still have problems. The easy solution is to paginate the results, right?

Yes. But then what happens? If you paginate the results with Rails handy pagination methods, and combine that with simple caching the first page rendered (and cached) will always be shown, no matter what. Why? Well Rails caches based on the URL, which doesn't include the extra parameter that pagination introduced (yet!), so requests for each of the following will resolve to the same cached file:

http://www.pervwatch.org/counties/map/152
http://www.pervwatch.org/counties/map/152?page=2
http://www.pervwatch.org/counties/map/152?page=12523

Not so great. So how can I get around this? Easy, use Rails named routes! The default route is to assume URLs of the form:

'/:controller/:action/:id'

We can add a new route which is smarter and realizes that my county map pages may or may not be paginated. To accomplish this, we add the following to our RAILS_ROOT/config/routes.rb file:

  map.connect 'counties/map/:id/:page', 
    :controller => 'counties', 
    :action => 'map', 
    :requirements => { :page => /\d+/},
    :page => nil,
    :id => /\d+/

Fancy, huh? Here's what it means. Assume any URLs that match the format http://www.pervwatch.org/counties/map/id/page get resolved to the controller 'counties_controller', the action 'map'. Make sure the third part of the URL, is made up of digits only, and at least one (so make sure its a positive integer) - then assign that the the :id key in the params hash the 'map' method receives. The fourth part of the URL is optional (:page => nil), and if available, is also made only of digits - assign it to the :page key in the params hash passed to 'map'. Phew. That was a lot. Let's take a peek at the 'map' method to see what that means.

  def map
    @county = County.find(params[:id])
    @pages, @offenders = paginate_collection(@county.offenders.find(:all, :include => :address, :order => 'addresses.latitude DESC'), :page => params[:page], :per_page => 250)
    # ... some more code
  end

Counties don't have any easy unique field to identify them, so we stick with passing around the auto-generated primary key id (in params[:id]), as you can see in the first line. That seems to be the same as we've always operated. Now check the next line. Ignore the :include, :order stuff. See what we're doing? We're explicitly passing the params[:page] value into our paginate method. So now you see how the route looks, and how the action looks. But how does this help us any? We just want to cache all our pages uniquely.

Take another look at the routes. You see, now when we pass in a 'page' parameter, Rails will compare against our routes and will automatically match our new rules, expanding the page parameter value right into the URL if it exists! Lets do a side by side comparison of what the URLs used to look like and how they'll look now.

Resolution of parameters to URLs with different routes.

params => {:controller => 'counties', :action => 'map', :id => 152}

Old: http://www.pervwatch.org/counties/map/152
New: http://www.pervwatch.org/counties/map/152

params => {:controller => 'counties', :action => 'map', :id => 152, :page => 2}

Old: http://www.pervwatch.org/counties/map/152?page=2
New: http://www.pervwatch.org/counties/map/152/2

params => {:controller => 'counties', :action => 'map', :id => 152, :page => 12523}

Old: http://www.pervwatch.org/counties/map/152?page=12523
New: http://www.pervwatch.org/counties/map/152/12523

Aha! Nirvana. Now when Rails caches all the different pages for a given county, they won't all resolve and refer to one file! So hopefully by now you get the idea behind this. To be able to cache pages with more than the normal :controller / :action / :id parameters, you need to push the parameters into the URL. Now, let's look at a slightly more complicated example from Typo.

Typo is blogging software built on Rails. In fact, this blog is running Typo. It's great, I love it. Typo had to tackle the pagination issue itself with routes, but they've also done some more complex neater things, such as finding all articles given a date, and to be able to cache the resulting page. They also can do this at a year level, monthly level and down to the exact date. So we could find everything in 2005, or everything in August 2005, or everything on August 18th, 2005. Neat idea, but we want to cache the results. This means we need to push those params into the URL. The side benefit allows for neat looking URLs that users could guess if they wanted to try and poke around.

Here's what Typo stuck in their routes for this:

  map.connect 'articles/:year/:month/:day',
    :controller => 'articles', :action => 'find_by_date',
    :year => /\d{4}/, :month => /\d{1,2}/, :day => /\d{1,2}/
  map.connect 'articles/:year/:month',
    :controller => 'articles', :action => 'find_by_date',
    :year => /\d{4}/, :month => /\d{1,2}/
  map.connect 'articles/:year',
    :controller => 'articles', :action => 'find_by_date',
    :year => /\d{4}/

This is a truncated version, they have more dealing with paginated results for the URLs like above, as well as many other different types of routes. So in their scheme, they're allowing for someone to specify year, month, and day (in that order) in the URL for the first route, and doing checking that the year must be four digits, the month one or two digits, and the day one or two digits. The second route allows the user to drop off the month parameter from the URL and still enforce the four digit year, and one or two digit month. The last allows just entering a year with four digits in the URL.

I'll spare you the implementation code in the action and model. The idea behind it remains the same as with our pagination example. When you want to cache the results of a page which has important parameters that aren't :controller, :action or :id, then make a nice new route for it and specify the parameters inside the route. It's not only the easy way to get caching working right again, it also tends to lead you to better looking URLs for your users.

How does this affect url_for, link_to, etc?

Good question. Now when you write your link_to's you can switch your style just a little. Before you'd probably right like so:

<%= link_to 'Page 2', :controller => 'counties', :action => 'map', :id => @county.id, {:page => 2} %>

Now that can become:

<%= link_to 'Page 2', :controller => 'counties', :action => 'map', :id => @county.id, :page => 2 %>

Think of it as a parameter getting "promoted" to URL member. It gets mentioned in the URL when we define the route, it gets grouped in with the other big guys like :action in our link_to, and it gets reflected in our cache. The parameter is getting a promotion.

RadRails 0.2 Released, and RadRails' ancestry

chris.a.williams@gmail.com (Chris) — Tue, 04 Oct 2005 20:22:02 +0000

I'd noticed the launch and subsequent talk of the new Ruby on Rails IDE, RadRails. The idea intrigued me, especially since I'm one of the lead developers on RDT and we'd heard a number of folks who had wanted to spin off their own Rails IDE separately or on top of RDT. The interest has been piqued yet again by today's anouncement of RadRails 0.2.

RadRails is fairly impressive. It's a nice fully self-contained copy of Eclipse with the relevant plugins installed so all you do is unzip and double-click the executable. It has custom loading graphics, Rails project generation and all sorts of neat little helpers. So where did it come from and how'd they get a full Rails IDE up so fast?

So, I took a peek inside the zip and I was slightly irked by one thing. RadRails is built on top of RDT as well as the Subclipse plugin. You wouldn't know that by their webpage, but they did mention us in the about dialog under the help menu. Not for nothing guys, but if you're building on top of RDT and Subclipse (not to mention Eclipse), it'd be nice to share the attribution and love. RDT could always use the support to drum up usage or more developers which in turn would help your own efforts...

OK, personal rant aside, I do see a lot of improvements that they should consider. First, you have these wizards for generating new controllers or models. But they're hidden. You have to right click in the Rails Navigator, select Other... and then open the Rails folder to find these wizards. They should have nice big clickable icons up top on a menubar. Next, If I enter the name AccountsController in the controller wizard, you should be able to recognize that I typed Controller as a suffix and strip it out of the name before running the generator so I don't get accounts_controller_controller.rb generated. Third, try using the latest RDT 0.6.0 - it looks like you're running an old nightly build under the hood there because Rakefile and the Rails scripts are all not recognized as Ruby files and syntax highlighted, which they ought to be with 0.6.0. Fourth, the RI view we have in RDT? It doesn't look or work too well where you guys have moved it to be default. It should be fairly big like the console view in the bottom left, otherwise you can't read anything. Fifth, there should be shortcuts to show the other views RDT has such as the Test::Unit view or the Regexp view. They're still useful when developing a Rails project.

Rails Tip: What goes where (directory structure) - A cheat sheet

chris.a.williams@gmail.com (Chris) — Mon, 19 Sep 2005 19:59:00 +0000

I work with Rails on a pretty much daily basis in my day job. While I own Agile Development with Rails, am subscribed to the Rails mailing list, and read a number of blogs where the authors touch on Rails I've been slow to pick up some of the subtleties of using the framework.

A few coworkers also have all those resources available, but can't seem to wrap their heads around how the project is stuctured.

What Goes Where (or the Rails framework structure)

Rails defines a whole hierarchy of folders when you first generate a project. While some are very noticable in their intent, others can be confusing. Here's a simple breakdown of what goes where:

Rails Cheat Sheet (89.1 Kb)

While a lot of this should be simple and straightforward to pick up, I've found that I generally tend to get a little sloppy about my division of code between app/models, lib and vendor. Remember, if you didn't write it, it goes in vendor. If you wrote it and it doesn't derive from one of the big base classes of Rails (ActiveRecord, ActionMailer or Actioncontroller) it probably goes in lib - even if it is considered a "model" class. At least I like to try and follow that rule. Otherwise in complex apps you'll either end up with two undesirable results - you'll place tons of code in the controllers which could be encapsulated in lib models; or you'll end up putting all these custom models which have nothing to do with the Database in app/models and 'pollute' the folder - making it difficult to discern which models are DB abstractions and which are non-persistent.