Neal Enssle

How to turn a string into CamelCase in Ruby

neal — Sun, 22 Jul 2007 03:09:24 +0000

Here’s a function to turn any given string into a CamelCase “WikiWord” in Ruby:

def wikify(phrase)
  phrase.gsub!(/^[a-z]|s+[a-z]/) { |a| a.upcase }
  phrase.gsub!(/s/, '')
  return phrase
end

Voila. This turns “my dog has fleas” into “MyDogHasFleas”.

Note: I’m sure there’s a way to fix this so that it’s just one regular expression? Feel free to chime in!

How to dynamically update form elements in Rails using Ajax

neal — Thu, 12 Apr 2007 12:15:34 +0000

Here’s the situation: You have two SELECT elements on a form. When the user chooses an item out of the first SELECT element, the contents of the second SELECT element need to change and show different values based on the initial selection.

This used to take quite a bit of JavaScript wizardry. But it’s pretty straightforward in Rails using a bit of Ajax. Here’s how:

First, make sure you’re including the Ajax libraries (Prototype, script.aculo.us, etc.) in your layout like so:



       <%= javascript_include_tag :defaults %>


...

Next, create a form with your initial SELECT, and empty second SELECT, and set up field observer. Here’s a really simple example:





<%= observe_field "states", :update => "cities",
:with => "city_id", :url => { :controller => "test",
:action => "get_cities" } %>

Finally, you’ll need to set up a method to handle the call from the observer and a corresponding view page to generate the HTML content that will replace everything betwen the SELECT tags in the second SELECT. Here’s an example "get_cities" controller:

def get_cities
    @cities = City.find_by_state(:all)
end

And an example "get_cities.rhtml" file:

<% for city in @cities %>
    
<% end %>

And there you go. This much should dynamically update the "cities" SELECT element with new content every time the "onchange" event is fired on the initial "states" SELECT form element.

How to define multiple users in a Capistrano deployment file

neal — Wed, 11 Apr 2007 11:36:52 +0000

We’re just starting to get into Ruby on Rails at my work, and we’re close to deploying our first application to a production server with Capistrano.

Capistrano makes it easy for developers to deploy code to the production server from their own workstations. But we quickly ran into two problems:

It’s often the case that a developer’s username on their local workstation is different from their username on the production server. This requires you to set the developer’s server username in the “deploy.rb” file. Hard-coded.
Hard-coding a single username makes it difficult for multiple users to share a “deploy.rb” file.

Well, it turns out that Capistrano is better than all that. With a little bit of conditional logic and the ability for Cap to read environment variables, the problem is solved like this in the “deploy.rb” file:

if ENV["USER"] == "robert"
    set :user, "bob"
elsif ENV["USER"] == "elizabeth"
    set :user, "beth"
end

Voila.

How to be a business badass

neal — Fri, 23 Feb 2007 03:50:28 +0000

There’s some great stuff to be found at one of my new favorite sites: trizle.com.

Word.

Free Ruby e-book

neal — Fri, 05 Jan 2007 12:31:25 +0000

Courtesy of Lifehacker (a site I’m really starting to love):

“Interested in learning Ruby, the open-source, object-oriented programming language? Start with Mr. Neighborly’s Humble Little Ruby Book, a new e-book that teaches the basics and then some.”

In addition to Mr. Neighborly’s slim volume, my growing Ruby library now includes:

Programming Ruby: The Pragmatic Programmer’s Guide, by Dave Thomas (the “pickaxe” book)
Agile Web Development with Rails, by Dave Thomas and David Hansson (the long-awaited 2nd edition, no less)
Ruby Cookbook, by Carlson and Richardson (O’Reilly)

Most programming gurus recommend learning at least one new programming language per year. Looks like in 2007 it’s going to be Ruby for me assuming I find time to do something I only rarely managed to do in grad school: Actually read the books I buy.

End of an era

neal — Tue, 21 Nov 2006 12:21:21 +0000

As many of you know, I’ve decided to leave my current place of employment and pursue a new opportunity as Director of Web Development at a small web development shop in Boulder.

Both Tara and I are extremely excited about this opportunity. Foraker Design is a very small company (I’m employee number 9!), but they’re growing fast. In this role I’ll have a chance to do quite a bit more “hands on” programming than I was afforded at Insight (the breakdown should end up being about 75% programming / 25% managing), and since Foraker is job shop that gets business from all shapes and sizes, I’ll also get a chance to play with some of the technologies and languages all the “kids” are raving about: Ruby, PHP, ASP, Java, et cetera. And while several people have commented on how leaving the “safety” of a big corporate environment is borderline crazy, in many ways I feel much more secure in working for a company where the employees are more than just entries on someone else’s budget sheet, and where I’ll likely have more say in our collective direction.

Yet the parting is obviously bittersweet. After four and a half years, I’ve made many, many friends at Insight. I am enormously grateful for the support, guidance, and encouragement I received during my tenure. I had so many teachers, from every part and every level of the organization. I thank all of them for allowing me to learn as we helped grow this business together. I am especially grateful to the members of the Software Development team, whom I now leave in my successor’s exceedingly capable hands: Thank you for your support and friendship, for the opportunity to be a part of the most dynamic and talented team of developers on the Front Range, and for all that you have taught me over the last few years. It has been an honor and a privilege to serve you. I will miss you all.

I’ll start up again after the Thanksgiving holiday with a full belly and much enthusiasm for the new challenges that lay ahead.

How to be more efficient

neal — Tue, 24 Oct 2006 12:49:57 +0000

I’m reading another brilliant book by Tom DeMarco (author of the excellent Peopleware) called Slack. His basic point is that the drive toward superefficiency is costing us more than it brings in lost creativity and effectiveness.

Key is a quote by Tom Lister (I just posted this over at CodeQuotes):

People under time pressure don’t think faster.

More on this topic to come, but let’s just say that I’ve bought a couple of copies of this book for some colleagues and executives at my current place of employment.

How to roll your own Ajax

neal — Tue, 26 Sep 2006 11:54:52 +0000

A little while ago I decided I needed to get my head around this whole “Ajax” thing. From Wikipedia:

Ajax, shorthand for Asynchronous JavaScript and XML, is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This is meant to increase the web page’s interactivity, speed, and usability.

Mainly it was for a couple of issues we were having at work, but I’ve long been a fan of the “magic” behind sites like Amazon, Flickr, and 30boxes.

So, after quite a bit of searching around in books and blogs, I managed to cobble together a couple of extremely simple scripts that take most of the mystique out of Ajax.

In fact, we’re also taking the “x” (for XML) out of Ajax, since this routine works by having your page call a JavaScript function that passes a request to some server-side code which then returns pure HTML. This HTML gets inserted into a container div on the calling page.

So here we go with the tutorial. An Ajax “how-to” in three easy steps (you can also download the code):

First things first, you need to get a “request object” that handles sending your request to the server. So we need a JavaScript function (inside a script block):

// initAjaxRequest():
//    Create a request object, based on browser type:

function initAjaxRequest() {
    var request;
    if (window.ActiveXObject) {
        request = new ActiveXObject("Microsoft.XMLHTTP");
    } else {
        request = new XMLHttpRequest();
    }
    return request;
}

Next, you’ll need to instantiate the request object at some point (this happens inside a JavaScript script block but outside of any function):

// Set a variable to hold an Ajax request object:

var ajaxRequest = initAjaxRequest();

Finally, you’ll need a JavaScript function that you can call to actually send the request to the server. The following function (inside a script block) takes URL parameter (that’s the server-side module, servlet, or page that will produce some HTML for us), along with a second parameter (”container”) that tells us where to put the resulting HTML:

// sendAjaxGetRequest(url, container):
//    Send an asychronous request to a specific URL,
//    designating CSS container ID to hold the
//    response information (HTML).

function sendAjaxGetRequest(url, container) {
    ajaxRequest.open('GET', url);
    ajaxRequest.setRequestHeader("Content-Type",
        "application/x-www-form-urlencoded");
    ajaxRequest.onreadystatechange = function() {
        if (ajaxRequest.readyState == 4 &&
            ajaxRequest.status == 200) {
            document.getElementById(container).innerHTML =
                ajaxRequest.responseText;
        }
    }
    ajaxRequest.send(null);
}

Now, to actually use these JavaScript functions, all we need to do is:

1. Call the JavaScript sendAjaxGetRequest(url, container) function (perhaps via an “onclick” handler), specifying the URL of a page that “does something” on the server-side, and a “container”. For example:

Do something!

2. Make sure we have a “container” div on the calling page that will hold the resulting HTML. For example:

Note that “doing something” can be as simple as printing any HTML to the screen. For example, the “doSomething.htm” page could simply look like this:

I did something!

Of course, this target page could be far more complex, such as a PHP page, ColdFusion template, or Java servlet that updates a database. The point of Ajax is just that you’re now able to post a request to the server, do something, and get information back without having to refresh the page.

If you want to send form fields via a POST instead URL parameters via a GET, here’s a slightly different function:

function sendAjaxPostRequest(url, parameters, container) {
    ajaxRequest.open('POST', url);
    ajaxRequest.setRequestHeader("Content-Type",
        "application/x-www-form-urlencoded");
    ajaxRequest.onreadystatechange = function() {
        if (ajaxRequest.readyState == 4 &&
            ajaxRequest.status == 200) {
            document.getElementById(container).innerHTML =
                ajaxRequest.responseText;
        }
    }
    ajaxRequest.send(parameters);
}

This function takes a “parameters” argument, which can be an encoded string of form field parameters. For example:

var url = "doSomething.php";
var parameters = "myField=" +
    encodeURI(document.myForm.myField.value);
sendAjaxPostRequest(url, parameters, "responseDiv");

That’s mostly it. Enjoy! (Again: You can download the code).

The blog is back

neal — Sun, 24 Sep 2006 23:47:04 +0000

Recently, my homepage has been fairly lame, featuring only a couple of links to the family site, to the now-infrequently-updated CodeQuotes, and to my resume.

I’m thinking, however, that I’d like to post the occasional thought or two.

The blog is back.