Welcome to the BuildingWebApps.com Blog. In the blog you'll find our musings and mutterings about Ruby on Rails, building this site, and building the business. If you're looking for technical articles, click one of the tabs above.
If you are a subscriber to our free online course or a regular listener to our LearningRails podcast (via iTunes or another RSS feed), we just posted Episode 9 (now also called Lesson 9). This is our first crack at capturing visually the complete walk-through of building a Ruby on Rails application. We’ll be taking it slowly, and iteratively, to try to explain all of the basics for beginners.
From a production point of view, we are still working on our technique. Unlike the podcasts, where Michael and I would record our parts separately and then edit them together, we wanted to make the screencasts a bit more “live” and conversational. Given that we live in cities a couple of hours apart, we are experimenting with tools to find the right combination for our needs.
Currently, we are using two Macintoshes (running Mac OS X 10.5) and using the new screensharing ability built in to Leopard. Michael has our slides prepared in Preview, has Macromates’ TextMate sized for our window, and iTerm.
We use Ambrosia’s Snapz Pro X to capture Michael’s screen and narration while I watch via the screen share. We originally tried to capture my ‘shared’ voice (which Snapz can do), but the quality wasn’t that great given our bandwidth.
On my side, I originally recorded my voice using a copy of BIAS’ Peak LE 5, but the quality was flaky on my machine. I’ve used it before without problems, so this was troubling. I ended up capturing a good take with Garageband.
During the whole session, we were also monitoring each other over the phone.
With the raw materials, I edited things together, giving Adobe Premiere Pro for Mac a try. I have used Premiere for years on Windows, and was happy that it came back to the Mac. My experience, however, was just so-so this time. I had some troubles with importing the source materials and then getting things tweaked. Even got a hang one time. Sorry for the slight “slow motion” effect in this first episode. We can work around that next time by capturing our source material with slightly different settings. I’m also going to look in to trying Final Cut Studio once I save my pennies for it.
We look forward to your comments about the content or the production in general.
We’re sorry to announce that we will not be presenting our Learning Rails seminar on April 29-30, as originally planned. There’s a variety of factors that led to the difficult decision to cancel it, led by the fact that we had a relatively small number of registrations to date.
So we’ve decided to focus our Rails training, for now, on our free online Ruby on Rails course. We have published 8 audio podcasts so far, and in just a couple days we’ll begin releasing screencasts in which we’ll build a simple Ruby on Rails application, step by step. Although the RSS feed is still available, we’re asking people to sign up for the email list to receive announcements of lessons as they are published. If you want to receive mailings for the screencasts only, sign up here.
It’s possible that we’ll offer an in-person seminar in the fall, but we’re not going to make that decision until sometime this summer.
Having switched from Windows to Mac a couple months ago, I was interested to see the long series of comments on this post by Peter Cooper on the Ruby Inside blog—Is Windows a First-Class Platform for Ruby. The predominant answer, from many developers with substantial experience, seems to be “no, but it should be.”
My take-aways from this (and from my own experience):
- If you’re a serious Ruby developer today, life is easier if you can avoid Windows
- It’s hard for the Ruby community to keep everything working smoothly on Windows, because most of the senior developers don’t use it
- Like it or not, the majority of the world is on Windows, and for Ruby to achieve the degree of adoption it deserves will require more work on the Windows side
The SD Forum has opened registration for the third annual Silicon Valley Ruby Conference, to be held April 18-19 in San Jose. While this is a Ruby conference, not specifically a Rails conference, many of the talks are Rails-related.
Christopher and I have been helping out on the program committee, and we’re excited about the list of speakers that the group has assembled. It is likely to be the largest Ruby gathering of the year in the San Francisco/San Jose area.
The speakers range from startups and leading consulting firms to giants Microsoft, IBM, and Sun:
- Tim Bray, Sun: The Rubies in Context
- Alex Le, Friends for Sale
- Parker Thompson, Pivotal Labs: DRYing Up Application Development: Components That Don’t Suck
- Jon Lam, Microsoft: The Borg discovers Ruby and Open Source
- James Lindenbaum, Heroku: Cluster Management with rush, the Remote Ruby Shell
- Tom Mornini, Engine Yard
- Anant Jhingran, IBM
- Jason Hoffman, Joyent
- Joel Dudley, Stanford University: Ruby at the Edge of Biology and Medicine in the Genomic Era
- Ryan Garver, ELC: Ruby features for Open Social Networking
- Blaine Cook, Twitter
The topics span from developments in Ruby interpreters to deploying high-traffic Rails applications. As at any Ruby or Rails conference, many of the speakers are from small companies, but the addition of IBM and Microsoft is worthy of note—clearly Ruby is no longer a fringe language.
We hope to see you there. Conference details and registration.
This week, we’ve relaunched our Learning Rails podcast as a free online course. What’s the difference between an online course and a podcast? Content and delivery.
In the Learning Rails audio podcasts, we focus on the concepts that underlie Ruby on Rails. We like audio podcasts because we can listen to them anywhere, and it’s a fine medium for explaining concepts.
But when you get to coding details, audio obviously doesn’t cut it. So now that we’ve covered all the core concepts in the eight episodes of Learning Rails, we’re switching to screencasts. In the screencasts, you’ll see our screen as we build a Ruby on Rails application, starting from scratch. We’re excited about the possibilities here and we’ll be releasing the first screencast within a couple weeks.
When you want to reproduce what you’ve seen in a screencast, it’s very helpful to have access to all the code being used. So we’ll be publishing the code under an open-source license and providing a repository that everyone can access.
We’ve recast the “show notes” pages as “lesson pages,” and we’ve enabled commenting on these pages. So participants in the course can post questions on each lesson page, and we’ll answer them there.
With this combination of features, we feel that “online course” better conveys the gist of what we’re offering than does “podcast”.
You can still get all the podcast and screencast episodes by subscribing to the Learning Rails feed using iTunes or other software. But there’s a couple limitations with this:
- Feeds are oriented toward showing the most recent episodes first, which is fine for a news podcast, but for a tutorial series you really want to see the episodes in chronological order. Some feed readers only show the first few items on the list, so if we put the lessons in order then some users will never know there are new ones.
- The audio and video files delivered by the podcast don’t provide active links, so it’s harder for us to point you to the code repository and other resources.
So we’ve added an email delivery option, which we’re encouraging everyone to sign up for. By signing up for the course via email, you’ll get a message for each lesson, so you’ll get them in order. And with each lesson email, we’ll provide other relevant links, and set some context for the audio or video.
There’s two signup forms, depending on whether or not you want the audio podcasts and then the screencasts, or just the screencasts:
- Learning Rails Course Signup—sign up here and you’ll get all the lessons, starting with the audio podcasts and then moving on to the screencasts. You’ll get one lesson every three days.
- Learning Rails Screencast Course Signup—sign up here if you’ve already listened to the audio podcasts, or if you feel comfortable with the concepts and want to go straight to the coding. You’ll get the first screencast as soon as we release it in early April, and they you’ll get them as fast as we can put them out.
We love feedback!
We’d really like to know how the course works for you. You can leave general comments here on the blog, or post questions or comments on specific lessons on the lesson page.
As part of the LearningRails morph from a plain podcast to an online course, we are transitioning over the next couple of weeks from audio only to screencasts and other supplemental materials. This week’s release of lesson 8 is all about setting up a new development machine so you can follow along with the course.
We wanted to have a set of instructions for the common OS platforms that we could tweak from time to time as needed for the online course and the in-person seminar. In February, we shared with our students a very basic outline and then pointers to some of the better blog posts and articles out there. Unfortunately, we learned that little things change with various OS patches and software releases, typically faster than these external articles are reviewed (if at all).
Long story short, we just published four articles, one each for Mac OS X 10.4 (Tiger), Mac OS X 10.5 (Leopard), Windows XP, and Windows Vista.
After scratching out and running through these articles multiple times trying to get the bugs out, I’m dreaming about installers now. Please take a look and pass on any suggestions or problems you might have when trying these out.
We’ve enabled comments on article pages now, so if you have a good tip to share (or a bug), please add it to the appropriate page. You can find the current comment entry pod on the right side of the article, near the top (better UI is coming!).
Michael and I will be speaking at this month’s San Francisco Ruby Meetup on March 25th. We’ll be talking about BuildingWebApps.com, why we are building it, how we are building it, and hopefully, get some feedback from the audience around the question: “What does the the web development community, particularly Ruby and Rails practitioners, need in a resource and teaching site such as our own?”
If you are one of the first couple of people who come to the meeting and mention this post to me (personally), you can get one of our collectible hats.
We’ve just opened up registration for our next introductory Ruby on Rails seminar, which we’re now calling the LearningRails Seminar, to be held April 29-30 in San Francisco. (We decided to drop the RailsQuickStart name, to emphasize the connection to our LearningRails Podcast.)
We learned a lot ourselves at the seminar in February, and we’re refining the content to make the seminar even more effective for Rails beginners. We think we’ll have the best training available for web designers and web developers who are new to Ruby on Rails.
As at the first seminar, we expect to provide a complete deployment solution, including a trial hosting account and Capistrano scripts. We’ll be announcing the hosting partner in a couple weeks.
We have a few other sponsorship slots open, so send us a note if your company is interested.
If you’re going to South by Southwest in Austin (which starts on Friday), we’d love to buy you a beer, or a cappuccino, or whatever, and hear what you’re doing with Rails and what you’d like to see in the future from BuildingWebApps. I’ll be arriving Friday afternoon, Chris is coming in on Saturday, and we’ll both be there through Tuesday.
We’re the guys who are twice the age of the average there, and we’ll (mostly) be wearing our exclusive Ruby on Rails hats (dark blue caps with a red train). Ask for one and you can have you very own, while supplies last.
If you’re trying to track me down, call 888.670.6793 extension 2, and it will forward to my cell phone. Or send an email through the Contact page. You can also follow us on Twitter (chaupt and mzslater).
One of the things I enjoy about teaching seminars is that it gives me a chance to interact personally with people who are learning the subject. This experience provides a perspective that I think would be helpful for some of the Rails core team, which made one decision in Rails 2.0 that has caused a lot of unnecessary pain for people learning to use Rails.
In Rails 1.2, the “scaffold” generator takes the name of an existing model and generates a controller and views for the basic CRUD (create, read, update, destroy) operations. Almost every introductory book uses it, and most of the online tutorials use it.
Rails 1.2 also introduced a new generator, scaffold_resource, which produces a RESTful controller and corresponding views. It is a conceptual replacement for the original scaffold generator. But it works quite differently. It doesn’t take an existing model as a parameter; instead, it takes the name of a model to be created, and a list of attribute_name:attribute_type pairs, much like the model generator.
So far so good. Everyone keeping up with the leading-edge ideas started using scaffold_resource instead of scaffold.
But then, with Rails 2.0, the old scaffold generator was relegated to the dustbin, and scaffold_resource was renamed simply scaffold. The result: nearly every book and online tutorial now fails, without any error message. Countless people trying to learn to use Rails are left needlessly frustrated and confused.
I understand the thinking that led to this: the core team wants to push RESTful design, and they wanted scaffold_resource to become the primary scaffolding tool. That’s fine. And for experienced developers the change in the scaffold command is not a problem.
But taking a feature that is almost universally used in introductory tutorials, and creating a new feature that works in a fundamentally different way but has the exact same name, is just a bad idea. If the core team was determined to dump the old scaffold, they should have replaced the generator output with a message that you should use scaffold_resource instead, and explain that it works differently.
Of course this is all water under the bridge, but I hope the core team thinks about the unnecessary pain this caused for many people trying to learn the platform the next time they consider redefining what a feature does. Please don’t reuse existing names to make them do different things in silent and confusing ways. And give some thought to the difficulties that may be creating for people attempting to learn the platform from the existing tutorials, and how you might mitigate those difficulties.