Schrade.Blog

I converted my Subversion repository at work to a git repository recently, and today I had my first real "aha" moment.

I was working on a feature this morning when I realized that some code I checked in about an hour before had broken the build. In the old Subversion world, I would have needed to keep track of what I was changing to fix the bug, and then make sure to just check that in to ensure that none of my half-finished new feature got into the trunk.

Not anymore. Today I just did a:

git-stash

and it stashed away all of my changes in a temporary branch. Then I fixed the build, checked in my fix out main Subversion repo (using git-svn), and did a:

git-stash apply

to unroll my earlier changes back on top of the now fixed code. It's not the world's biggest saving of time, but it's one less thing that I needed to think about during development, and using git I'm seeing more and more little things that are starting to add up to a big change in the way I'm doing development.

Whenever I get I get tired of dealing with all of the disconnected layers of Rails, I think about how I should really write a decent component architecture that works well on top of it. Luckily, someone has already done it for me.

From the Cells homepage:

Cells brings the benefits of component-oriented development to the Ruby on Rails web application platform, without the performance problems that had been associated with Rails' own, deprecated, component subsystem.

Each Cell is like a little lightweight controller (with associated views) that you can embed anywhere in your app. I've been playing with it tonight, and while it's not on the level of say, Seaside, it seems like a fairly good baseline for building a more component oriented system for your apps.

I know from a mailing list that I'm on that some people are kicking around taking this and building a stateful component framework with real object binding underneath. That would really take Ruby web frameworks to the next level. (And be a ton of work to get right, I'm sure. :-) )

Hopefully that project will get started soon. I'm extremely interested in watching and helping it develop.

Today's 10.5.2 update to Mac OS X seems to have solved my issue of losing wireless connectivity every half-hour and having to reboot to get it back. I was about ready to throw my laptop out of the window with this one. How was I supposed to get work done when the internet was constantly going away?

I wasn't sure how much more I could have taken before I just installed Linux on this box to get back to work.

So thank you Apple for saving my laptop. And thank you for not making me go through the pain of dealing with a dual-boot Linux box once again.

Both of my last two companies have been involved in the aggregation of large data sets.

At the company I co-founded, Ten Ton Labs, we collected and normalized music reviews from across the web to support our music search engine, Squishr.

Our original plan, however, was to collect all reviews, of anything and everything, and then build an application that analyzed and tracked various metrics from the data to find out how consumers felt about certain products. We scaled the idea back to focus on music to allow us to continue building the underlying review platform and to have an easier application to implement on top of it to prove it out.

At my current company, Collaborative Drug Discovery we collect huge amounts of data about experiments in the field of chemistry (there are about thirty million known chemical compounds) and allow people to search through the data in various ways, as well as add their own data. Our users can use our toolset to keep their data private, but search across the aggregated dataset.

Both of these companies have a lot in common. When I was at Ten Ton Labs, our music search engine held a huge amount of short-term value for us. It was the cool thing that we could show to investors to get them excited about the company, and it gave us attainable short-term goals to go after. CDD is very similar, we currently put most of our effort into our cheminformatics application that runs on top of our data, because it's what we sell to people and show to our investors.

Long term though, I don't think that our music search engine or the CDD cheminformatics app is really where most of our value lies.

It lies in the cloud.

A huge amount of value is created by building tools to make it easy to get data into the cloud, and to make it easy for people to process the data and get it back out in a manner that they're used to. Once you have those tools, especially if you're allowing people to build applications and communities on top of your data, you're creating real value.

You've created an app that people will come back to everyday to see what's new.

And you've created an ecosystem around your data that won't allow it to die. People will build tools to interact with it in ways that you never even thought of, and again, more value will be created because of it.

I think that building a platform for data like this, not just a one-off application, is where the opportunity for huge value creation eventually lies.

My friend Jay wrote a few days ago:

I bet of you looked at the majority of Rails applications you would find empty test folders (or only the generated tests, which are never run). I'm quite sure that's true because I expect the conferences to attract the best of the Ruby developers, and several of the people I talk to at those conferences "simply don't have time" to write tests.

These people are idiots. Either that, or they don't have any sort of complexity in their apps and they're writing them in a far too simplistic and elementary way.

Quite often, doing a little meta-programming magic in Ruby can make you massively more productive and, in my experience, the only way to find the side effects of doing a lot of meta-programming is to have a comprehensive test suite. As this magic-level in your app increases, the number of side-effects of that magic will also inevitably increase.

Eventually, you will get burned by something if you're not ready for it.

Tests are your flame-proof suit in this case. They're not going to protect you against everything, but most of the time they do a damn good job of keeping you alive.

DHH wrote the other day:

We try to do a fairly good job at keeping our test suites current and exhaustive as well. Basecamp has a 1:1.2 ratio of test code (thanks to the persistence of Jamis!), Highrise has a ratio of 1:0.8 (bad me!).

At CDD, our current code to test ratio is 1:4.2.

Overtested? Undoubtedly.

However, we don't want to ever have to go in and fix the damage after someone tries to import 1,000,000 molecules to our system and something goes wrong. The repair work can take days in some cases, so we err on the side of caution.

I'll wrap this up with the following three easy points:

1. If you're writing a Rails app, write tests for it.
2. If someone who works for you "simply doesn't have the time" to write tests, fire them.
3. If a consultant tries to give a Rails app without a test suite, fire them (and don't pay them, if at all possible, what they've given you is pretty much worthless, and is going to be a nightmare to maintain).

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.