Rails 2.1 removed the original scaffold generator and replaced it with a new RESTful scaffold generator.

Bummer.

I’m not talking about the dynamic scaffolding that comes from putting “scaffold :model” in a controller. That “dynamic scaffolding” was removed in Rails 2.0 and few of us miss it. I’m talking about when you type “ruby script/generate scaffold Model” from the command line and get generated model, controller and view files as a result.

While I understand that Rails is “opinionated software” and that they want to encourage everyone to get on the REST bandwagon, I think completely removing the old scaffold generator was a mistake for one simple reason:

It unnecessarily raises a barrier to entry for beginners.

When beginners first start on Rails there is a lot to digest. Installation issues, Ruby language, MVC architecture, ActiveRecord, Rails syntax, routes, migrations and deployment—just to name a few. In my opinion, asking someone eager to learn Rails—someone who may have a background in PHP but who still doesn’t understand code blocks or the basic Rails .find syntax—to also use REST from the start is only going to frustrate them and slow the growth of Rails adoption. They need to walk before they can run. We have added best practices for advanced users at the expense of the newbies.

Read the rest of this entry »

A student sent me email to ask: “In a general sense, when writing code, is there a sequence of steps or a pattern to the logic when writing the code?”

It’s a good question. Experienced computer programmers have learned these steps—either through intuition or experience—but beginning programmers are often mystified. Once you learn the language syntax, how exactly do you use it to approach a programming problem? Especially if you want to try to use good programming techniques and to solve the problem in a smart and efficient way.

The answer to the question “Are there steps to writing code?” is “Yes”. After the jump, I’ll give three ways to develop the logic necessary to write good code.

Read the rest of this entry »

Keeping with the theme of my recent JavaScript posts, here are a couple of simple JavaScript functions that are extremely useful for creating a clean user interface. The scripts themselves are simple, but together they allow you to create the effect of a div that expands and collapses to show or hide its contents.

Read the rest of this entry »

Writing about JavaScript the other day got me thinking about some of the other JavaScript code that has helped me solve design problems in the past. Below is a script that limits the number of characters in a text area to a maximum value and also displays the number of characters that can still be added to the text area. This is useful when text area data will be stored in a database VARCHAR field which has a 255 character maximum. It allows the user to craft their response to match the allowable length before the form is submitted.

The textCounter script runs once after each key stroke is complete (”key up”) and takes two arguments. The first is the field being monitored, the second is the target field that will be updated with the “characters remaining” value.

Note that we don’t add 1 and subtract 1 for each keystroke. Instead we use the current field length because it is possible to paste text into the field or to select and remove more than one character with a single delete keystroke.

I don’t write a lot of JavaScript. Every now and then I need it to use it solve a design problem. Recently, I needed JavaScript that would make sure that only three checkboxes could be checked at once. Here’s what I came up with in case it’s helpful to someone else.

Each time a box is clicked the script runs. If a check mark is being added then the script tests to see if the running total (current_count) is larger than the defined maximum (max_count). If so, then it undoes the checkmark and displays an alert, but if not, then it allows the check and adds one to the current tally. When a box is unchecked, the tally simply decreases by one.

Save the Developers! is hoping to make the lives of web developers easier, while also improving the experience for web users. Their current campaign is Say No To IE 6! which is an attempt to rid the world of Internet Explorer 6.

How? By getting developers to put a bit of JavaScript on their website. Developers can either link to their external JavaScript file or download the script and host it themselves. (I added it to this site.)

If the JavaScript detects the the user’s browser is IE 6, then a small window appears suggesting that they upgrade. Clicking takes the user to their website which contains links to the latest versions of IE 7, Firefox, Safari and Opera.

They acknowledge that it may take awhile, maybe even a few years, but their goal is to reduce IE 6 usage as much as possible to help usher it into permanent retirement. I think that’s a goal all web developers share.

It is simple, effective and—best of all—won’t bother most users because they won’t see it. Their website will let you preview the effect, even if you don’t have IE 6. If you don’t like the look, just modify the JavaScript to fit your site design. If you don’t want users leaving your site, you can adapt the JavaScript so that the window links to an upgrade page on your own site.

Remember: Every time you upgrade a browser, a developer gets his wings.

A List Apart, Issue #257, has two articles on Ruby on Rails. Both articles are targeted toward Rails beginners and curious designers who may have heard the buzz but few details.

The information may be old news for many developers, but both articles are up-to-date, well-written introductions that are still worth bookmarking. Save them for the next time a beginner asks you for an explanation. Forward them to co-workers who don’t understand what you’ve been raving about. Print them out and leave them laying around so your most earnest PHP/.NET/Java friends can sneak a peak at them when no one is looking. Maybe they can even help explain to your parents/friends/significant-other what you do for a living.

• Creating More Using Less Effort with Ruby on Rails by Michael Slater
• Getting Started with Ruby on Rails by Dan Benjamin

From the beginning, one of the weaknesses of Ruby on Rails has been the complexity of deploying a Rails application. Deployment was not difficult once you had done it once or twice, but it required several extra steps, learning about additional technology (like Mongrel or FastCGI), having a fair amount of server admin skills and a bit of patience. Most significantly, deploying a Rails application was much harder than deploying a PHP application.

With PHP, you can just drop your application files on the server, configure Apache to server up those files and you are done! It is possible to do this thanks to a module for Apache that allows it to serve up PHP files without needing a “handler” in between. This Apache module can be referred to as “mod_php”. This has been one of PHP’s strengths and one of it’s advantages over Rails.

Last week that all changed when Passenger was released by Phusion. Passenger is also referred to as “mod_rails” because, like mod_php (and mod_perl, mod_python, etc.), it is a module that allows Apache to serve up Rails applications without needing a handler like Mongrel or FastCGI. Once Passenger is installed, deploying a Rails application becomes as easy as PHP—simply drop files on the server and configure Apache to serve them.

It is notable that it is nicknamed “mod_rails” and not “mod_ruby”. mod_ruby is a different project whose development seems to have stalled in mid-2006. The difference also indicates that Passenger currently works only with Rails and not with other Ruby frameworks (like Merb or Camping).

Phusion made Passenger very easy to install and set up. Ryan Bates at Railscasts has a demonstration of how easy it is. Notice that he does not launch WEBrick, start up Mongrel or use FastCGI, he just restarts Apache and the application becomes available!

This is the first release of Passenger, so it is very possible that there will be bug fixes and improvements in the near future. There has already been some discussion about how to reduce the memory usage of Passenger (currently twice the memory usage of a single Mongrel instance). It has also been noted that if an application sits idle for a while it takes a little while for it to load again (I find that FastCGI does this too). Fixes, work-arounds and good advice will certainly be surfacing over the next few weeks as developers test it out on a wide range of web applications and server set ups.

One thing is for sure: the Ruby on Rails community is excited at the potential Passenger has for making deployment easier and thereby lowering a key barrier to entry for new developers. PHP took off once it became an Apache standard. Now Rails is poised to do the same.

It’s been a while since my last post. I’ve been busy on a few projects with upcoming deadlines. Harder still, I am working on both a Ruby on Rails and a PHP project at the same time and switching mindsets is challenging. (I can’t count the number of times I type self when I mean $this and vice versa.) It is like traveling between two foreign countries several times a day. I speak French to the German baker and German to the French butcher. (Or, most often, I am speechless in both cases!)

For the PHP project, I need to work with fractions of an inch in a few places. Not as decimals, but as fractions (1/5, 5/12, 3/64, etc.). Fractions are not an uncommon problem for developers. Since there seem to be very few discussions online about the subject, I thought it would be worthwhile to review some of the options. My example code will be in PHP since that’s the “country” I’m in right now, but the Ruby code is easy to extrapolate.

Read the rest of this entry »