RORY HANSEN

Zebra-striped tables are tables where row colors alternate between a light color and a dark color and can be done both using server-side code (ie. Rails) or client-side code (ie. JavaScript). I posted a question asking for the most convenient way to create zebra-striped tables to the Rails newsgroup some weeks ago and the responses I received were actually quite scathing. I’ve normally done this type of thing using server-side code when working with other programming languages (ASP, PHP, JSP, ColdFusion, etc.), but many people feel that this is an extreme no-no (and aren’t afraid to tell anyone that’ll listen to them), as it muddles up the separation of business logic from presentation.

Anyway, my point is that, regardless of what others think, I want to continue doing this type of design using server-side code and a recent post on the Code Snippets website highlights a Rails helper tag called cycle that makes this very convenient. (The name will be familiar for those that have used the Smarty templating engine for PHP.) The cycle tag is exactly the type of suggestion I was looking for when I posted my initial question to the newsgroup. Before that, I’d been using some nasty combination of if statements and the mod operator to determine the row color and that had completely uglified my code.

This is how you use the cycle helper method:
<tr class="<%= cycle("even", "odd") %>">
... use item ...
</tr>

You can read more about the cycle helper method in the Rails API.

I’ve been meaning to write a more meaningful review of Kodomo 3.5 beta for Windows, but have decided to hold off until I can evaluate a non-beta version. My reason for doing this is because of the fact that it is still in beta, and so, I think it’d be unfair if I critique a product that may still have its functionality changed before the real release.

For example, I have successfully been able to use Kodomo to debug one of my actions. But, because it was so incredibly slow to debug this action through Kodomo, I’ll never do it again. At least, until the speed issue is resolved. And I know that it will be resolved eventually, as it is noted as a problem here in Eric Promislow’s blog.

There are other issues that I’ve encountered that I’m not sure are actually issues with the IDE or just with me as a user of the IDE. For example, I could not get the intellisense to work with my Rails models.

Anyway, when I get my hands on a non-beta version of Kodomo 3.5, I’ll write up a better review. Until then, I may continue to use it to write my Rails apps, but only in the same way that I’d use any other text editor.

ActiveState, a local Vancouver company that I’d only previously known about because of ActivePerl, has just released Kodomo 3.5, an IDE that now supports Ruby. Sadly, Windows and Linux versions are still only in beta, but I’ve signed up to beta test the IDE as I’m eagerly trying to replace Dreamweaver as my Ruby on Rails text editor.

The ActiveState highlights the following Kodomo 3.5 features:

• Fully-integrated Ruby support
• Ruby on Rails debugging
• Code intelligence
• Cross-platform
• Highly customizable
• Supports multiple languages

Of these features, the two I’m most looking forward to using are code intelligence and debugging. My current method for debugging my Rails apps is pretty amateurish, I’ll admit, as usually I’ll just output values to the console window to see what’s going on. I know that Rails has the ability to set breakpoints and debug in a more structured manner, but it all reminds me too much of GCD. I hope that the debugging facilities in Kodomo are more like those contained within VisualStudio.NET, as I’ve come to appreciate the convenience of using a nice GUI for debugging.

Anyway, the 28MB download for my Windows version of Kodomo 3.5 beta is nearly complete, so I’ll end this post here. I hope to have a decently complete review of my opinions of Kodomo online in a few days, so check back then.

After taking *many* weeks off of Rails programming, I’ve decided to begin work on a couple new projects. One of them will be using Duane’s Product Generator so that I can “productize” it. Basically, here’s the concept: Using the Ruby/Amazon library, I can easily consume the Amazon web services. By leveraging the code reuse that Product Generator facilitates, I can create many small online stores that “sell” Amazon products, and for each product I sell, I’ll earn between 5% and 10% in commission. Each online store will be specialized to a specific niche, such as haunted houses or water polo, etc.

Sound okay? I think so.

I already have some experience using the Amazon Web Services, as I’ve used them on my lyrics website. But now, these stores that I create will use the web services in greater depth, as visitors will be able to add items to their shopping cart or their wishlist, etc.

Anyway, I’ll keep you updated with the progress I’m making with Product Generator and Amazon web services.

It’s a common task to validate a form with JavaScript upon form submission. And validating whether or not at least one checkbox in a checkbox group is checked is often a basic requirement of this task. But, if you’re form is created dynamically and if the number of checkboxes in a checkbox group can vary from 1 to more than 1, then the JavaScript needed to iterate over the checkboxes is slightly different.

Say you have an HTML form like this:

<form name="frm" method="post">
   <input type="checkbox" name="parts" value="1" />Head<br />
</form>

Then, using JavaScript, you can check whether the checkbox is checked like so:

var isChecked = document.frm.parts.checked;

Now, imagine that your form has more than one checkbox in the same checkbox group:

<form name="frm" method="post">
   <input type="checkbox" name="parts" value="1" />Head<br />
   <input type="checkbox" name="parts" value="2" />Neck<br />
   <input type="checkbox" name="parts" value="3" />Arm<br />
   <input type="checkbox" name="parts" value="4" />Leg<br />
</form>

Then, the JavaScript code changes a little bit, as now you have to iterate over each of the checkboxes.

var isChecked = false;

for (var i = 0; i < document.frm.parts.length; i++) {
   if (document.frm.parts[i].checked) {
      isChecked = true;
   }
}

But. if you tried using the 2nd chunk of JavaScript on the first chunk of HTML, you’ll get a JavaScript error. This is because if you only have one checkbox, there’ll be no array to iterate over. So, you need to do a quick check before hand to see if there is more than one checkbox. If so, then iterate; otherwise, don’t.

if (document.frm.parts) {
   if (typeof document.frm.parts.length != 'undefined') {
      for (i = 0; i < document.frm.parts.length; i++) {
         if (document.frm.parts[i].checked) {
            isChecked = true;
         }
      }
   } else {
      isChecked = document.frm.parts.checked;
   }
}

This code first checks to see that there exists at least one checkbox. Then, it checks whether the length attribute of the parts variable is defined or not. If it is defined, then we know there is more than one checkbox. Otherwise, there is only one.

And there ya have it!

So, I’ve basically finished coding the “Google Suggest”-like web user control I was writing for the company I’m doing a co-op work term at. I’m now in the process of integrating it into an existing textbox control that they’ve developed, and that should be finished soon.

One part of the web user control is an iframe, which is used to counteract the much-documented z-index and select box problem in Internet Explorer. By placing the iframe directly below the div that the Google Suggest results are displayed in (as in one z-index less than the z-index of the results div), we can avoid this problem all-together.

But, to make the web user control as reusable as possible, I needed to be able to name this iframe uniquely, incase there are multiple instances of the control on the same aspx page. To do this, I needed to be able to specify the name of the iframe when it is rendered (or guarantee that it would be automagically named uniquely), and I figured out I could accomplish this by using two standard controls: PlaceHolder and HtmlGenericControl.

First, I create the HtmlGenericControl object that will eventually render as an iframe and specify whatever attributes this iframe will have:

// Create new iframe control
HtmlGenericControl searchFrame = new HtmlGenericControl("iframe");
searchFrame.ID = "searchFrame";
searchFrame.Attributes.Add("class", "searchFrame");
searchFrame.Attributes.Add("frameborder", "0");

Then, I can add it to the PlaceHolder’s controls collection:

// Add it to the Controls collection of the PlaceHolder control
searchHolder.Controls.Add(searchFrame);

Finally, I add the PlaceHolder control into my ascx document where I’d like the iframe to eventually be:

<div class="searchContainer">
   <asp:PlaceHolder id="searchHolder" runat="server" />
</div>

Now, an iframe will appear in the outputted HTML code where the placeholder once was. But more than that, since I used an ASP.NET control to actually create the iframe, the iframe will be named uniquely. We even know what it’ll be called: this.UniqueID + “_searchFrame”. This is beneficial to me since I can now reference that iframe by name throughout my JavaScript code and show it or hide it when necessary.

Yay! My copy of Agile Web Development with Rails came in the mail today from Amazon. Time to learn _proper_ Ruby on Rails now.

: )

My co-op work term is coming to an end at my current workplace and I’ve been given the opportunity to produce an ASP.NET web control that functions similar to Google Suggest which will provide me with something that I can write about for my end-of-term technical report. So, not only will I be coding all aspects of the web control, but I’ll also writing a techical paper that details the process that I followed to create the web control as well as the intimate details as to how it’s been implemented. I suppose this’ll give me a chance to practice the technical writing skills that I picked up last term in the 300-level technical writing course that I attended.

Since I’m relatively new to .NET, it should come as no surprise that I’ve never created a web control before, let alone create one that uses AJAX. But I have used AJAX in my Ruby on Rails site before, although I’ll admit that the experience won’t be all that much help unless I decide to use the Prototype javascript framework within my web control.

Anyway, I have already gently scoured the ‘Net for existing web controls that meet my requirements and, while there are numerous projects and code samples that contain bits that I’ll probably examine closer, I wasn’t able to find one that perfectly fits the bill. (I’m actually pretty sure there are some out there and that I was just not able to find them.) In any case, the most difficult part will probably not be the C# but rather the JavaScript, and with the abundance of XMLHttpRequest JavaScript snippets out there, I’m sure I’ll be able to appropriate (and credit, of course!) at least some of them into my work.

In any case, I’m excited about this project and am looking forward to starting on it this weekend. Like my other pet projects, I’ll probably document some interesting snippets of code here, so stay tuned. : )

If you’ve been hosting your app with Textdrive using Apache and FastCGI, you may have noticed that FastCGI seems to crash every few minutes with these kinds of error messages:

[Mon Aug 08 03:40:25 GMT 2005] Dispatcher failed to catch: SIGHUP (SignalException)
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each’
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each_cgi’
dispatch.fcgi:18
FCGI process 28217 killed by this error

[Mon Aug 08 04:07:55 GMT 2005] Dispatcher failed to catch: exit (SystemExit)
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:10:in `exit’
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:10
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:10:in `call’
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each’
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each_cgi’
dispatch.fcgi:18
FCGI process 38625 killed by this error

These crashes really don’t have _that_ much of an effect on your website, except that the next visitor to your website will have to wait a few seconds before anything appears while the web server caches some information. But my Ruby on Rails website gets quite a bit of traffic, so this happens to visitors every 5 minutes throughout the day.

So, I decided to move to Lighttpd from Apache, which should stop these types of errors from occuring.

The Lighttpd setup was extremely painless and I had everything setup within 30 minutes. The first step is to send a ticket to the support staff at Textdrive, requesting them to setup a Lighttpd port for you. In the reply from the Textdrive support staff, they’ll reference a couple great webpages that contain Lighttpd tutorials to follow. Specifically I followed these tutorials:

• http://wiki.rubyonrails.com/rails/show/DeployingApplicationOnTextdrive
• http://jlaine.net/blog/48/running-your-own-lighttpd-on-textdrive-and-keeping-it-alive-too-part-i

On the Deploying Application On Textdrive wiki page, skip halfway down the page and check out the section called Lighttpd For Idiots. This is a great tutorial that will get you nearly complete. (I did find one small problem with this tutorial though. When I ran the lighttpd command over SSH to start up the Lighttpd server, I got an error message saying that my lyricsdb.socket file didn’t exist. To fix this problem, just create a tmp/ folder in the lighttpd/ folder.

On you’ve completed this tutorial, head to the 2nd webpage that I linked to above. The 2nd link shows you how to set up a cron job so that your Lighttpd server starts every time the webserver is restarted.

Now, my Ruby on Rails website is being served by Lighttpd. I just hope that I didn’t miss anything, considering that my app was initially running over Apache and FastCGI. Do I need to turn anything off that I may have turned on to get Apache and FastCGI going in the first place?

I found this great post on the Ruby on Rails wiki that shows you how to run background jobs in Rails. Specifically, for the nightly maintenance that I’ll be doing on my website, I’ve chosen to follow the “Use cron or the like to run ruby code” method. There is some example code available on the wiki page that shows you how to access your Rails app from a script.

So far, all I’ve done is use the supplied example code as a base for my maintenance script. I’m in the process of adding the actual “maintenance” code at the moment and, as I do, am testing it by running the script from the command prompt: ruby nightly_maintenance.rb.

Are there any “gotchas” that I should be weary of when following this process?