Schrade.Blog

My new law of Ruby complexity:

For a Ruby application increasing in size at rate of X, with an amount of cleverness to cover up the complexity increasing at rate Y, the quantity Y is always greater than X, and Y eventually approaches positive infinity.

Working on Ruby projects has given me enough examples of "Where did that method come from?" to last a lifetime.

(Or, How I Spent My Martin Luther King Day Weekend)

Here are the web app frameworks I've been reading about and playing with for the last few days. As usual, they've got a bunch of cool ideas that we'll be seeing in mainstream frameworks in 4 or 5 years.

Weblocks: Weblocks is a continuations-based web framework written in Common Lisp. Think Seaside, in Lisp.

Ramaze: An MVC framework written in Ruby. Like Rails without all of the garbage and magic.

Check them out. Pretty cool stuff going on.

For the last twelve years I've been building web applications. During that entire time I haven't ever worked at a software company that hasn't, at one time or another, been concerned with prematurely optimizing the application we've been working on.

I think that we can all learn an important lesson from this study of gym users that was recently written up in the Financial Times (via Paul Kedrosky).

Two Californian academics, Stefano DellaVigna and Ulrike Malmendier, studied three US health clubs and discovered that 80 per cent of members used the gym so infrequently that they would have been better off paying the $10 fee for each individual visit. Many also left substantial gaps between their last visit and cancelling their membership.

This tracks well with my experience with subscription based software products. People inevitably sign up for more access than they need, and the difference between what they pay to use and what they actually use ends up going straight to your bottom line. Optimizing for expected usage never really pays off, because usage never lives up to expectations.

Also, get people on an auto-renew plan:

Some clubs attempt to limit the attrition rate by telephoning inactive members and asking whether there is anything the club can do for them. Mr Ratner never thought this was a good idea as it might remind them that they were wasting their money.

Lesson: People almost always use your software less then they, or you, expect. This is a good thing (for you, perhaps not so much for them).

Last Thursday I published a couple of blog entries and the next thing I knew my FeedBurner stats looked like this:

So I figured I'd ask the lazyweb. Anyone ever seen anything like this before? Is FeedBlitz just spamming my RSS feed?

Today marks the official beta launch of Triggit, the tech side of which is run by my friend Ryan Tecco (who co-founded Ten Ton Labs with me a few years ago).

So what's a Triggit? It's an easy way to insert images, videos, or text links into your blog, without downloading or installing any software.

All you have to do is add one line of code to your blogging software template. You can then use a cool Javascript based tool to insert objects into your blog on the fly. As you can see in the picture below, the Triggit interface just overlays itself on the top of your site to allow you to insert things:

You just select what type of object you want to insert and then drop it into the page wherever you want. For instance, I've used Triggit to insert this image, of Ryan dressed like a cow from Halloween a few years ago, into this post by searching for it on Flickr through their interface, and simply dropping it in below:

This is a game-changing sort of tool that will make your life as a blogger much easier. If anyone wants to try it out, I have 300 invite codes to the beta to hand out. Just use the access code 'kurt' when you sign up.

Update: More coverage at TechCrunch , GigaOm, and WebWare.

My coworker Krishna, inspired by Giles Bowkett's post Rails Debugger: Use RCov With Selenium, Watir, Or Just In Real Life, whipped up a little rake task that automates the process of checking code coverage using your Selenium tests:

desc "Measure coverage of selenium specs"
task :coverage do
  FileUtils.rm_rf "selenium_coverage"
  mongrel_pid = fork { exec("rcov script/server -o selenium_coverage --rails -- -e test -p 4000") }
  sleep(6) # wait for mongrel to start

  begin # selenium will call "exit 1" if there are failures
    Rake::Task["selenium:spec"].invoke
  rescue SystemExit; end

  Process.kill("INT", mongrel_pid) # triggers generation of rcov report
  Process.wait
  system("open selenium_coverage/index.html") if PLATFORM['darwin']
end

While we don't agree that this task, in any way, shape, or form, constitutes a debugger, it has been useful in showing us areas of our code base that our Selenium test cases aren't hitting.

This should work for just about anyone that has a rake task to run their Selenium (or Watir, or other in-browser testing tool) tests. Just replace 'selenium:spec' in the block above with whatever task you use to run your in browser functional tests and have at it.

Wow:

MacBook Air is 0.16" to 0.76"

There must have been some amazing engineering that went into that thing. I'm already drooling over it. I'm assuming that we'll see more info at http://www.apple.com/macbookair/ soon.