Archive for March, 2006

Bubble Bursting Web 2.0

Rich over at Basement.org has a great post on why it’s important to take a step back from all the buzzwords and think objectively about Web2.0. In it he looks at some traffic stats from a few Web2.0 players and wonders how many of the hundreds out there are even getting noticed (much less turning a profit).

I don’t think he’s trying to downplay the importance of things like AJAX, Ruby On Rails and other cutting edge innovations. But it’s good to hear someone trying to get a little perspective on the situation.

Especially when you start seeing postings like this on the Ruby Jobs list:

Looking for rock star to join rocket ship startup

Don’t get me wrong, maybe it’s a great job (or maybe they’re just being tongue-in-cheek), but “rocket ship startup” is not the kind of thing that, for me at least, inspires confidence. (Note to rocket ship startup: dude, call me)

Anyway, here’s the part that I found really interesting. Rich uses the following graph to illustrate how CNET is still way ahead of guys like Engadget, Boingboing, Techcrunch and Lifehacker (CNET’s in aqua):

chart6.png

Ok, so CNET’s way ahead. But what I find interesting is that everybody got a big bump somewhere toward the end of 2005, and that increase has been sustained thus far in 2006. So what’s going on in the tech/IT world that is making people more interested in technology in general?

I’m not sure what it is. And I agree with’s Rich’s caveats about buzzword intoxication. But I think that bump is a good thing.

Ruby Users of Minnesota meeting

Tonight’s RUM meeting was a great one, with better attendance than last month’s meeting. Tom gave an overview of the file_column plugin for Ruby on Rails (and also has a meeting summary on his blog). It has just about everything you need to handle file/image uploads built-in, including resizing, thumbnails and cropping (if you have RMagick installed, of course, for which I’d recommend using Locomotive).

We talked a little about PDF generation, and I promised to post some links to libraries I’ve been researching. Promise fulfilled:

Then Luke (last name? site?) gave a presentation on Sparklines and the only Ruby implementation that looks usable: Geoffrey Grosenbach’s Sparklines. I love the way these things look but still haven’t found a compelling reason/justification for including them in an app. But I’m still looking.

Speaking of Geoffrey, his Gruff library was a breath of fresh air when I was looking for something to help me do graphs for Teacherly.com. His CSS graphs library doesn’t look half bad either.

Charlie Nutter talked about the latest milestone release of JRuby, which sounds wonderful even though I don’t really understand it. At one point he was talking about a similar project that was “trying to implement Ruby in Ruby” and I just kinda got stuck in that loop. Still cool though.

Lastly, Dan Grisgby gave us a summary of what he saw at Etech, which you can read about on his blog. Suffice to say that multi-touch user interfaces are way cooler than anything anyone anywhere is working on (except the multi-touch user interface people). As soon as this is implemented for the web I’m sure it will bring browsing for porn (isn’t that what the web is for?) to a whole new level.

I’ll be out of town (Brazil and Argentina) for the next meeting, but I’m looking forward to talking a little about Feedmarker at the May meeting.

Rails 1.1 is Out

Check out DHH’s post describing all the changes. With so many fixes and cool new features, it’s kind of amazing this is just a minor release!

The difficult (and great!) thing about Rails is that every time a new release comes out I have the urge to completely rewrite all of my applications. Just browsing through some of the RJS examples, I can see how using these would have made developing Teacher! a lot easier and cleaner.

Something like this:

page[:average_grade].replace_html :partial => "student/average_grade"

would have been about ten times simpler than the pure Javascript I’m using right now.

Over at Scott Raymond’s blog there’s a more in-depth guide to what’s new, including this beauty:

%w(1 2 3 4 5 6 7).in_groups_of(3) {|g| p g}
["1", "2", "3"]
["4", "5", "6"]
["7", nil, nil]

How awesome is that? No more setting up a counter and checking wether it’s divisible by three on each loop. So I can just do something like:

@students.in_groups_of(3) { |group|
group.each{|student|
render :partial => 'student'
}
}

That’s cool.

One last thing I’m excited about: calculations. Where before I had to do a bunch of queries and insertions and array manipulations to get a student’s average grade for a group of assignments, now I can just do:

Assignments.average(:grade, :conditions => ["student_id = ?", @student.id])

I can’t tell you how much easier this makes my life. Seriously.

So, congrats to the Rails team for pushing out another release so soon after the big one-point-oh! And I’m sure there’s more to come…

Lessons for Rails Deployment

Found an article called Real Lessons for Rails Deployment today via Peter’s blog, (although I think I may have come across it earlier while searching for help getting my Rails apps under control). In my experience, the hardest thing about developing an application in Rails is actually launching it on your server.

There are a ton of options, but from what I’ve read, the best ones require a dedicated server or a VPS. Like most people, I can’t afford that; I’ve got shared hosting. Unfortunately, Rails is tricky to deploy on a shared server.

The best option I have on my host (I suspect this goes for a lot of people) is to use FCGI with Apache. Lighttpd and SCGI apparently are much better and more stable, but my host doesn’t support them for shared accounts.

The problem with FCGI, despite it’s speediness, is that it’s unreliable. This details of this are a bit beyond me, but from what I’ve read, the library is a bit stale (hasn’t been updated in a while) and has some wierd quirks that make it go bonkers if it runs too long.

I run two Rails apps on my shared account, Feedmarker and Teacherly. If I don’t periodically kill my FCGI dispatchers, they’ll just grow and grow and eat up memory until the server crashes. This is bad.

When I noticed this happening, I set up a bash script to find so-called “zombie” dispatcher.fcgi processes and kill them. I run this via cron every half hour. Ever since I started doing this, both apps have been humming along fine, and the load on my server is far lower.

Links: