Foraker just posted my new blog article: “Why Rails?“. The key point:
Rails lets us focus on solving business problems. At the end of the day, our customers care more about results than about any particular technology. Using Rails as a common language for our team means we can spend more time wrestling with our customers’ business problems, and less time wrestling with the technology itself. Rails lets us get started quickly, work efficiently, and respond flexibly, helping us to focus on the real challenges of designing and implementing functional, usable, and reliable web applications for our customers.
Posted: June 11th, 2009 by Neal Enssle
Tags: business, foraker, programming, rails, work
No Comments »
The idea I’m exploring here is whether or not we can build a CMS (content management system) in Ruby on Rails that can dynamically build a CMS. In other words, can we write Rails code that writes Rails code.
It seems we can. This is pretty awesome, and somewhat frightening, because it apparently works. Here’s a method in, say, a “utils_controller.rb”:
def generate_scaffold
@results = `script/generate scaffold
Things name:string value:string`
end
Note the use of backticks around the shell commands to generate a scaffold. If you run that method in your browser, it actually generates the controller, model, migration, etc.
Then do this:
def migrate
@results = `rake db:migrate`
end
Yep. Now you just migrated the database and have new “things” table.
Eureka?
Obviously some issues here (like… OMGWTF! Run away! Do not try this at home!). But I’m a little bit excited…
Posted: October 10th, 2008 by Neal Enssle
Tags: code, howto, programming, rails
No Comments »
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!
Posted: July 21st, 2007 by Neal Enssle
Tags: code, howto, programming, rails
6 Comments »
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:
<html>
<head>
<%= javascript_include_tag :defaults %>
</head>
<body>
...
Next, create a form with your initial SELECT, and empty second SELECT, and set up field observer. Here’s a really simple example:
<form>
<select id="states" name="states">
<option value="0"></option>
<option value="1">Colorado</option>
<option value="2">Illinois</option>
<option value="3">Wyoming</option>
</select>
<%= observe_field "states", :update => "cities",
:with => "city_id", :url => { :controller => "test",
:action => "get_cities" } %>
<br />
<select id="cities" name="cities">
<option></option>
</select>
</form>
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 %>
<option value="<%= city.id %>"><%= city.name %></option>
<% 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.
Posted: April 12th, 2007 by Neal Enssle
Tags: ajax, code, howto, programming, rails
24 Comments »
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.
Posted: April 11th, 2007 by Neal Enssle
Tags: code, howto, programming, rails, tools
No Comments »
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:
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.
Posted: January 5th, 2007 by Neal Enssle
Tags: programming, rails, reading
No Comments »