The sixth screencast is posted and should be propagating to iTunes and our email lists now. In this episode we do something quick (show setting up acts_as_textiled), then show something else that should be quick, but turns in to a reality check.

Michael walks through “dropping in” in-place editing to our simple CMS, and quickly demonstrates what happens when you have to scratch the surface of Rails: things don’t work as documented, things may not have documentation, plugins can quickly drift out of sync with the current releases of Rails (edge or otherwise), you may have to sift through Rails bug reports to find “just the right patch”.

Blue Oyster Cult may have gotten it right with Hot Rails to Hell.

The great thing (???) is that almost certainly someone has had to cover this ground before and a little targeted use of Google will yield a clue. The thing that absolutely sucks is that almost certainly someone has had to cover this before, proposed a fix that is gathering dust, and you have to dig for it.

Of course, that’s where we hope to help…trying to expose the rough, dark edges AND help provide useful documentation/links/screencasts that will smooth those corners.

Spurred on by Clay Shirky’s talk at Web 2.0, I picked up his new book Here Comes Everybody, subtitled The Power of Organizing without Organizations. I’ve just finished it, and I can’t recommend it highly enough.

There’s been a slew of books on the social and business implications of the Internet, from Wikinomics to Web 2.0: A Strategy Guide, but for the most part I’ve found them a little dry and not especially thought-provoking. I got a lot more out of Here Comes Everybody, and enjoyed reading it more.

The book paints a compelling picture of how the the Internet has demolished barriers to publishing and forming groups. While this is hardly a new observation, I found the book’s exploration of the implications of these changes to be thought provoking, even though I’ve read an awful lot in this domain.

This week’s screencast (lesson 13) rounds out the Admin pages refactor tasks we started in lesson 12. When we were recording the original lesson 12, it ran way over our typical target of 25 minutes or so, so we broke it into a part 1 and part 2. I’m not a good enough video editor to fix up the prompts you see in the lesson 13 screencast in post-production, so yes, they still say lesson 12. Sorry for any confusion!

Behind the scenes, we are still working on our tool set and are discussing the best way to deliver the videos. Right now, we provide the full Quicktime movie for either download or playing directly in your browser/iTunes/RSS Reader. I’m contemplating putting zipped up versions online too, so those of you who download the movies for local/offline play can benefit from smaller downloads. If this interests you, drop me a line here or via our BuildingWebApps contact form.

-Chris

It’s interesting to see how widely browser stats vary among sites. Here’s the data for this site and two others I operate, for the past 30 days:

Breaking down the IE usage between 6.0 and 7.0 also shows a lot of variation:

So for BuildingWebApps, we’re just about at the point where we’re not going to worry about IE 6—it represents less than 5% of our traffic, and it’s shrinking every day. But for the other sites, IE 6 unfortunately remains a big part of the audience.

When we add blog articles to our database, we like to identify the author to give credit where credit is due. We also need to be sure that posts that we find through Google searches are still relevant.

It’s amazing how often it is difficult, and sometimes impossible, to find the full name of the author, and how frequently posts are undated.

So here’s two suggestions for technology bloggers:

• Make sure each post is dated. Especially if you’re writing about a fast-moving framework like Rails, knowing when a post was written is essential.
• Include your full name somewhere! Nicknames are fine, but if you care about credit for your work, put your full name in the footer, or at least include an “About Me” link that provides your full name. Unless, of course, you don’t want anyone to know who you are…

The fourth screencast in the Learning Rails series is now available. In this lesson, we fill in the missing pieces of the user management system that the restful_authentication plugin doesn’t provide, such as the ability to list, edit, and delete users.

We’ve been getting great feedback on the screencasts, and we now have more than 3,000 people receiving the lessons via RSS or email. More than 20,000 lessons (audio podcasts + screencasts) were downloaded in the last 30 days.

If you haven’t yet signed up, you can sign up to receive the lessons from the start, or skip the eight audio podcasts that cover the basic concepts and start with the screencasts. We’ll send you an email every three days with a link to the next lesson.

Just after the end of last week’s Web 2.0 conference and expo, the Silicon Valley WebGuild has posted an outrageous diatribe against Tim O’Reilly.

WebGuild created an event that they called the Web 2.0 Conference & Expo, which does sound quite a bit like O’Reilly’s Web 2.0 Expo. WebGuild argues that the Web 2.0 term is generic, and that they have every right to use this name in their event.

I can sympathize with their viewpoint, and I think the right answer here is not at all clear. But then WebGuild organized another event called Future of Web Apps, which just happens to exactly match the name of a Carsonified event. This starts to look an awful lot like a pattern of mimicking the names of well-known events. It smells like deceptive advertising to me.

Now Google has withdrawn their backing from WebGuild, and will no longer sponsor their events or provide meeting space for them. In response, WebGuild’s Daya Baran posted an article titled Shame On You Tim O’Reilly, in which he lashes out at the individual at Google who delivered the message, and at Tim O’Reilly, whom he accuses of pressuring Google managers to drop their support of WebGuild.

I understand their anger at losing Google’s support, but their response is unhelpful and inappropriate. Rather than being driven by pressure from Tim, I think it is far more likely that Google simply did not want to be associated with an organization with a pattern of deceptive marketing.

Among the gems in this post are the sentences “When I met him, I cordially introduced myself, however, O’Reilly was a despicable individual. He is a dinosaur whose time has past.” This goes way over the line. Personalizing business disputes in this way helps nothing and just makes WebGuild look bad.

I’ve had the good fortune to know Tim casually for a long time. (When I moved the Microprocessor Report business to Sebastopol in 1990, O’Reilly was already here.) Although I have no business relationship with him, I’ve always found him to be a straight-shooter and someone of great insight. I don’t think anyone who really knows Tim would make this kind of statement. He has every right to defend the conference business that he has made a substantial investment in creating. If I were in his shoes, I’m not sure I would go after other organizations using the Web 2.0 term in event names, but he has every right to try.

It’s an interesting question just how far others can go in using phrases like “Web 2.0 Conference & Expo,” but it’s crystal clear to me from WebGuild’s pattern of event naming, and the way they chose to deal with Google’s withdrawal of support, that this is not an organization I would want to associate with.

The folks at Five Runs have been doing a series of interviews on their blog, and one with yours truly was posted last week.

While I hold down the development cave this week with a broken foot (long story), Michael is representing us at Web 2.0 in San Francisco this week. If you are there, look him up!

InformationWeek did a quick interview with Michael to ask about Ruby on Rails. Besides that blog post, there is a YouTube video of Michael talking about both Ruby on Rails and what we are doing at BuildingWebApps.com as well the bigger story behind Collective Knowledge Works, Inc.

Digg the interview if you like.

This week’s Learning Rails online course screencast covers authentication and walks through using Rick Olsen’s restful_authentication plugin (and plugins in general). We are taking our time through each of these topics to try to provide as much general information as possible without making the pace too slow. Comments on the episodes seem generally positive, but we’d always like to hear more.

We have a general outline for the various future episodes, but we are also incorporating feedback from viewers and starting to incorporate a “refactoring” portion of the ‘cast to fix up or explain something that may have been less than clear. We’ll also use watchers/listener feedback to influence future episode content, so keep those comments coming.

On the back-end side, a few updates.

As we improve our skills on screencasting (blame the editing on me! I’m the videographer in training), we will play around a little with making the visuals as clear as possible. We are close to finding our “final” tool set, and I’ll blog about that in the next few weeks once things settle down. We are still trying to record some of the content concurrently, with Michael and I in different cities. Sometimes, we still need to record separate takes and I merge them in post-production. This week we’ve been trying out Adobe’s Acrobat Connect as the cross-platform (at least Mac Friendly) screen sharing solution.

Leopard’s iChat screen sharing is really nice, but hasn’t been working for us lately (reasons unknown). Also, since we both run on dual monitors (or more), iChat is a little annoying in that it can’t target specific screens for sharing. If anyone has a hack to work-around this, I’d love to hear it. Acrobat Connect allows you to share a specific screen, which is nice.

Satish Talim is running a free online Ruby programming course that is a great companion to our own free online course in Ruby on Rails for folks who are serious about learning Ruby. More than 3,000 people have participated since the first offering in the fall of 2006.

Unlike our course, which is self-paced and open to join at any time, Satish’s course runs on specific dates to encourage discussions among the students. The next offering starts May 6, so sign up now if you’re interested.

Satish also recently published an interview with me on the RubyLearning blog.

We’ve just posted the second screencast in our free online course in Ruby on Rails. I think it came out pretty well—but what counts is what you think! Please leave a comment here or on the Lesson Page if you get a chance to watch it.

We continue to evolve our tool setup and fight with our Macs. This time we could not get screen sharing through iChat to work reliably, so we gave Adobe’s Acrobat Connect a try. It worked flawlessly.

We’ve had problems on both Christopher’s Mac and on mine with horrible distortion spontaneously showing up in the audio track, and we ended up recording the audio multiple times and trying all sorts of different setups. For my side, I ended up just recording it on a stand-alone Zoom H2, which worked well once I got the hang of its somewhat clumsy interface.

We’ve added a couple of small software utilities to help out with the video recording process:

• The freeware Think utility provides an alternative app switcher that blacks out all the apps except for the foreground one, which helps minimize distractions.
• Artis software’s shareware Small Screen puts a box on the screen of whatever dimensions you specify, which stays on top of other applications. This makes it easy to set up the various apps to be appropriately sized for the screencast dimensions. We’ll probably spring for the $26.95 for xScope, which combines this tool with lots of other useful screen utilities.

We’re putting the screencast files on S3, which delivers higher bandwidth than our regular host so your downloads should be quick. For working with S3, I’ve been using the free S3 Browser, which is a simple open-source app that provides a GUI interface to the S3 storage buckets. I’ve started using Bucket Explorer, which costs $29.99 (after a 30-day free trial) but is considerably more capable.

On to Lesson 11…

As I described in an earlier post, in January I made the move from Windows back to the Mac. And, as described in another post, Windows has some serious issues as a Ruby development platform.

The MacBook Pro is physically a well-designed machine. There are lots of benefits to having Unix just below the skin. And a lot of things on the Mac work very well.

That said, I’m incredibly frustrated with the MacBook Pro and with Apple support, and at this point I simply could not recommend it. Other models and other usage patterns are apparently much more robust, but after a short period as a convert I’ve come to feel that the machine and the company are just untrustworthy.

There are three problems that have eviscerated any potential productivity gains for me:

• The machine occasionally, randomly, decides that it won’t acknowledge any external display resolution other than 1440×900. The problem persists until I reinstall the OS.
• It does not reliably go to sleep or come out of sleep.
• When recording audio via the USB interface, it frequently adds horrible noise to the signal.

These are not problems specific to my machine. Searching the Apple forums finds many other people with the same problems and a very high level of frustration.

Christopher has a completely different audio setup and is seeing the same audio problems. It doesn’t matter what audio hardware or recording software you use. USB audio recording is simply unreliable.

I’ve spent hours on the phone with Apple support. Most of it has been with “Tier 2” support, and there’s no place to go after that. Their solution to the display problem is to reinstall the OS, something that I thought was a Windows-specific disease. Surely there’s just one or two files that are getting corrupted, which would be easy to restore, but no one seems to know which ones (and they aren’t the obvious ones).

The support staff, while friendly and generally knowledgeable, was completely unaware of the display problem, despite widespread reports on the forum. After weeks of back and forth with three different support people, I finally got a message that engineering is aware of the problem, and that at this point they have no fix. But since I’ve had the machine more than 30 days, they won’t take it back. And since it isn’t a hardware problem, there’s no point in sending it in for repair. Summary: I’m stuck with a defective, two-month-old, $3000 machine, that I can’t trust to hook up to a projector for a presentation.

This week Apple released a firmware update for MacBook Pros, and some people on the forum reported that it solved their display and sleep/wake problems. But for some people it does not. And it won’t install on my machine; it says my machine “doesn’t need it”.

Apple support never responds to my follow-up emails. They don’t specify what the updates are supposed to fix. They don’t acknowledge (and seem genuinely ignorant of) problems that are widely reported. They don’t respond to anything in the forums.

I hope that eventually there’s software updates that fix these bugs, and I’ll probably stick with the Mac because of the Unix underpinnings and the investment I’ve made. But at this point it is definitely a love/hate relationship, with a strong dose of hate, in which I feel trapped. And I’m completely fed up with the poor quality of Apple’s driver software and the company’s approach to supporting it.

Update 4/29/08: Last week, Apple finally released a firmware update that would apply to to my MacBook Pro. So far, the display recognition problem seems to have been fixed, but only time will tell if this issue recurs.

As for the USB audio problem, Chris and I have both simply abandoned USB audio after losing far too much time suffering with Apple’s bugs. I dumped my USB mic and got a mic with an analog output, and an M-Audio Firewire interface, and so far that’s working well. Chris already had a mic with an analog output, and his mixer provides an analog output, so he’s using the analog input of his MacBook Pro.

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.