During the dozen or so years I ran the Microprocessor Forum conference, I presented hundreds of seminars on microprocessors and PC technology. I enjoy teaching, and I’ve missed this aspect of that business.

Since I’ve been working with Ruby on Rails, I’ve been thinking about how it could be made easier for people to learn. I believe there are vast numbers of web designers and developers who would find Rails a very useful tool, and who could improve their productivity—and their satisfaction with what they’re producing and the process of producing it.

One thing led to another, and on February 20 and 21, my colleague Christopher Haupt and I will be presenting our first Ruby on Rails QuickStart seminar in San Francisco.

We’ve designed the seminar for web designers and developers with only minimal programming experience. We’re providing a pre-built site, which we’ll walk through during the seminar, that attendees can use as the basis of their own sites. We’re also very close to a deal with a hosting provider to offer free hosting for a month, so we can help attendees get their sites deployed before the seminar is over. We’ll provide each attendee with the NetBeans IDE, deployment scripts, and everything else they need to immediately build and deploy Ruby on Rails web sites.

I’m really looking forward to the seminar and hope some of my readers can join me there.

The early registration price of $695 is good until December 20. There’s details at the BuildingWebApps.com site.

I spent the earlier part of this week at Pragmatic’s Rails Studio, an intensive three-day Ruby on Rails training. This one was in Seattle; they are offered periodically at various locations around the country. (There’s not another one announced yet, but they’ll be posting a new schedule shortly; check their web site.)

Overall, I found this to be very worthwhile. It would have been a lot more valuable, however, if I could have gone a couple months ago, as I’ve spent the past two months building a couple small Rails sites, figuring things out as I went along. So a lot of it was review for me—something like 80% of the first day, 60% of the second day, and 50% of the third day. Nevertheless, it was very helpful in filling some gaps in my knowledge. I picked up quite a few tips, and perhaps most important, it gave me confidence that I’m on the right track and moving along pretty well. The presentations went well beyond the facts to explain the best way to approach things, why certain things in Rails work the way they do, and other useful bits of perspective that come from long experience.

World-Class Instruction

The instructors are Dave Thomas, the primary author of Agile Web Development with Rails and the proprietor of the Pragmatic Programmers publishing house, and Mike Clark, also an author and an active developer, and the head of Pragmatic Studio, a separate training company that shares part of the brand with Dave’s company. Both are outstanding instructors with deep expertise in the subjects covered. Chad Fowler was also there helping out, and he surely knows as much about Ruby as anyone in the U.S.

Dave Thomas

Mike Clark

The format of the Studio is an hour or two of lecture, followed by half an hour or so of programming on your own (you need to bring your own laptop). It’s an effective format, since you really don’t know if you understand something until you try to do it. Mike and Dave alternate speaking, providing different perspectives and variety in style.

The attendees were surprisingly diverse. There was certainly a local Seattle-area contingent, but there were also some who had traveled a long way. I went out to dinner one night and in our group there was one person from Alaska, one from Paris, and one from Mexico City. Some of the attendees were building Rails sites for their days jobs, while many were working in other technologies and seeking to move into Rails, either with their current employer, on their own, or with a new employer TBD.

Is This the Right Seminar for You?

If you’re looking for a jump-start in Rails development and are just getting started, I highly recommend the Rails Studio. If you’ve already done some Rails development, though, it’s a tougher call.

If you’re comfortable with the basics of the MVC separation, using migrations, creating and using associations, performing validation, and using views and layouts, this seminar will be mostly review. It covers the basics of AJAX with RJS templates and simple Scriptaculous effects, but nothing complex. One part that was most useful to me was the coverage of unit, functional, and integration tests, although the depth of coverage here too was necessarily limited.

If this Studio sounds like it would be mostly review for you, consider the Advanced Rails Studio (next offered in April in Dallas).

I’ll be adding a series of posts during the next couple days about some of the things I learned at the Studio.

My first built-from-scratch Ruby on Rails site is now live: www.newhorizonschool.info. This site is for New Horizon School and Learning Center, a wonderful small school that my son attends. They’re great folks, and they’ve made a big difference in our lives, so I was pleased to be able to help them out and build this site for them. And along the way, I learned a lot about building sites in Rails.

This is a pretty simple site, with mostly static content. Unlike your stereotypical Rails site, this is not a “Web 2.0” creation but just an old fashioned small business site. Nevertheless, I found the Rails environment to be very nice as a templating engine, and it made it easy to implement the small bits of database capability that are there:

• The Resources page is built from a database, so the staff can easily add links, categories, or descriptions through a web-based interface.

• The Alumni form adds records to a database. The staff will be able to download this to integrate into their Filemaker database.

• Contact messages are stored in a database, as well as being sent as emails to the administrator, so they are logged and can be reviewed by other folks.

• All the static text on the site is stored in a database, so the school’s staff can edit any of the text through a web interface. I considered using an existing content management system, but my needs were simple, and by building it from scratch I learned more and was able to make it do exactly what I wanted. The text is all stored in Textile. I hope to polish this up and release it as a plugin at some point.

Over time, I’ll be extending the site with some more sophisticated capabilities.

The banner was created by fellow parent Mario Zelaya. It sure adds a lot to the overall feeling of the site, especially compared to the solid-color box I had there!

I’d love to hear any feedback you have on the site. And if you want to help a great cause, just visit the Giving page and click on one of those Donate buttons at the bottom…

Today marks a milestone for the Ruby on Rails community: version 1.2 (actually 1.2.1) has been released. For many months, developers who can get away with it have been using the “edge” version because of all the features that have been added since the release of 1.1.6, the last “stable” version, last August (and 1.1.6 had mostly minor changes from 1.1, which came out last March). Now that 1.2 is out, everyone has a stable version with the new features and gains some isolation from the daily evolution of the framework. For people running production sites, it no doubt feels a lot more comfortable being able to move to a new official release than using edge, so the new features are now much more usable for them.

It’s interesting to note how long a time “since last March” seems in the Rails world. In the shrink-wrapped software world, it wouldn’t even be nearly time for a new release, and little or nothing would be known about what was going to change.

For a good rundown of the key new features, see DHH’s blog post. For some more details on specific new features, see:

• New in Active Record
• New in Action Pack
• New in Active Support

RESTful Goodness

Support for RESTful routing is one of the central features of Rails 1.2. In essence, this comes down to two things:

1. Using the HTTP “verbs” of GET, POST, PUT, and DELETE to enable a single URL to perform multiple functions
2. Using the Rails “respond_to” method to enable a single action to respond to requests for HTML, JavaScript, XML, RSS, and so forth

If you’re wondering what the point of all this is, I highly recommend watching DHH’s keynote from the mid-2006 RailsConf. You can view the video at ScribeMedia, though the video is really only useful for the audio, since it doesn’t show the slides. To follow the talk, you need to be looking at the slides, which you can get here. The slides really need the audio to go along with them, so I’d suggest looking at the slides while listening to the audio from the video.

For a detailed example of implementing RESTful routes, you can buy Geoffrey Grosenbach’s PeepCode Screencast for a mere $9. It’s well worthwhile if you want a nitty-gritty example, though I found DHH’s talk better for appreciating the “why” of all this. Geoffrey also offers a free cheat sheet.

If you just want to peruse the code for a complete RESTful example, check out the RESTful Product Tracker code from Zack Chandler.

For a more general description of what REST is about (with a bit of a Java slant), see REST in Plain English.

Books Covering Rails 1.2

Many of the current Rails books were written for 1.1.6, but the second edition of Agile Web Development with Rails is fully 1.2-compliant. (If you’ve been getting by with the first edition, it’s time to upgrade.) Also just out is Rob Orsini’s Rails Cookbook, which Rob held up for a few weeks so he could update it for 1.2.

Prototype 1.5

Along with Rails 1.2, version 1.5 of the Prototype Javascript framework (which is included in Rails 1.2) was released, along with a new web site and better documentation to support it.

I’ve been building web sites for almost 10 years, but I’ve only recently made the transition into more robust hosting accounts. For years, I got by with shared hosting, in which the host runs hundreds or thousands of web sites on a single server. These accounts are by far the most pervasive because they’re inexpensive (some as low as a few dollars a month, and most less than $20 per month) and they don’t burden the user with any of the complexities of server administration.

I began to outgrow shared hosting as my San Francisco Boating site, BoatingSF.com, started to become popular, and I started seeing failures because I was hitting database connection limits. I also added a feature that displays real-time boat positions, and to make this work I needed to be able to run background tasks and make socket connections. So last spring I made the leap to a virtual private server (VPS).

Virtual Private Hosts

A VPS is like having your own dedicated server, but instead of having the entire server to yourself, at a cost of at least $100/month and typically more like $200/month or even higher, you get a fraction of a physical server. Virtualization software, typically either Virtuozzo or Xen, makes the single machine appear as multiple, independent Linux boxes, one for each VPS account. Each VPS account has its own Linux installation, with its own Apache server, MySQL server, and so forth. You get root access to the (virtual) machine, so you have nearly complete control.

With this control, of course, comes more responsibility. The fact that you have root access means that not only can you change anything, you can also break anything. Depending upon the host, they may provide more or less assistance, but in general they expect you to be able to administer the server (though they will typically handle installation of the OS, MySQL, and other major applications).

Many VPS installations offer some kind of control panel as an option; cPanel and Plesk are the two most common options. These control panels give you a GUI interface, accessed via your web browser, that allows you to do most administration without knowing much about Linux or having to use a command line. The control panel makes it easy to add accounts and domains without having to know how to edit the Apache configuration file and administer user accounts. But I found that the control panel sometimes made it hard to understand what was really going on, and as I strayed from the straight and narrow there were things I couldn’t figure out how to do without getting down and dirty with Linux.

Hosting Rails

Moving to Rails added another complication. Rails hosting is a bit trickier than PHP, especially if you want the best performance and reliability. So while I left my PHP sites on my initial VPS, I got a Rails-oriented shared hosting account from Rails Playground. That’s where this blog is hosted as I write this. But I’m now preparing to work on several Rails sites, some of which I hope will have modest usage levels, and some of which will be deployed on behalf of businesses that expect high reliability. Even with this blog’s light loads, I’ve found page load times to be highly variable, sometimes extending to several seconds, and feedburner is sometimes timing out fetching the feed.

In pursuit of these goals, I decided to get another VPS account from a Rails-oriented host that I felt could provide good performance and reliability, and that would also have some help documents to guide me through the process of doing things right. My VPS for my PHP sites is at ServInt, and while they’ve been reliable and did eventually install Rails for me, they don’t really support it and certainly didn’t have much to offer in terms of advice.

I read some good reviews of Media Temple’s” Grid Server, which is sort of like shared hosting but across a large grid of machines instead of just one. They offer a Rails “container” at a reasonable price ($45/month with 256M RAM), so I gave it a try. But I quickly became disenchanted because of a few issues. First, as I read more blog posts, I discovered that the Grid was experiencing significant downtime. While it should, in theory, be more reliable than a single server, in practice it is a complicated setup that clearly is not quite mature. Second, because of the grid arrangement there’s a number of things you have to do specially, and you don’t have the level of control that a VPS solution provides. And finally, I found that they only offered a single Mongrel process for each Rails application, which is not recommended for sites that have significant load. So I decided to bail on Media Temple, even though the price was attractive. Once this solution matures a bit, it may be worth a second look.

Next, I decided to go for a solution that I was confident would be an excellent, robust Rails implementation. One of the best-known Rails hosts is TextDrive. To get beyond their shared hosting accounts, however, you’re looking at a minimum of $100/month, and they are not VPS accounts, so some of the things I want to do may be problematic. Engine Yard is another high-end host that seems to really know what it is doing when it comes to serious Rails performance, but their packages start at $250/month.

My Answer: Rails Machine

In the end, I decided to go with Rails Machine. At $75/month for their basic VPS account, it was about double the price of Media Temple’s Rails container, with similar specs, but I was a lot more confident about how it would perform. Rails Machine is a relatively new company that is focused on simple, robust Rails hosting. It is run by Bradley Taylor, who is the author of mongrel_cluster and created the railsmachine gem to streamline deployment. I like the idea of having this kind of talent at the hosting company—especially at a company small enough that Bradley answers support requests personally.

In the next couple weeks, I hope to have this blog switched over to Rails Machine. This is not a control-panel environment, so after 30 years in computing without significant Linux experience, I’m climbing up that learning curve. Much of the available hosting administration reference material assumes that you already know your way around Linux pretty well. And the Linux administration books typically aren’t oriented toward remote administration of an already configured machine and have lots of detail that you don’t need to know. The knowledge you need is spread across a dozen books and sites, with each containing lots of information you don’t need and none covering the whole spectrum of information you do need. But since I have time now to dive into this learning process, it’s a fun challenge.

I’ll be following up with a series of posts on what I’ve learned along the way, in the hope that I might be able to simplify the process for others.