The Common Running idea suffered from some serious drawbacks. One of those was a cold start problem, where the functionality of the site for early adopters was limited until we had reached a critical mass of user input (a level the site never reached). Another was the problem of basic data; as long as we were soliciting reviews, we were obligated to maintain a comprehensive, high-quality database of current and recent running shoe models, and we were unable to meet that obligation while also performing paying client work.

We still hold out some hope for the CR technology model, perhaps with a plan in place to address the problems outlined above. For the time being, however, we won’t pretend the site is useful and will be concentrating our energy on other projects.

(Check the collection of Common Running posts for some bits of the two-year history of the site.)

Mimura, for example, made shoes for the 2000 Sydney Olympics gold medalist, Naoko Takahashi, with soles of slightly different thicknesses to compensate for a leg-length discrepancy of 8mm–less than a centimeter, about a third of an inch, according to reporter Jere Longman.

Longman, a longtime follower of the sport and sometime marathoner himself, concludes the article with a vivid simile from Mimura himself on the importance of running shoes:

“Samurai cannot fight without their swords,” Mimura said. “It is the same for runners and their shoes.”

La Cucina Italiana occupied a significant chunk of our March. Phase Two of that project, which will see the beginnings of that venerable publication’s massive recipe database becoming available on the site, is complete and is only awaiting editorial oversight of the recipes being entered in the database. Phase Three is under discussion, and is the most exciting part from our point of view, as it will allow the site’s readers to engage the brand directly on the site through comments, ratings, and discussion.

We’re drawing closer to the public launch of an interesting project we started last fall with Scott Soloway. We’ll tell you more about this site when it launches, but for the moment we’ll say that it’s a web service of a sort we’d never handled before, and it includes a strong machine-learning component, which we loved.

We learned just a day or two ago that we’ll be building a new iteration of the website for the Track and Field Writers of America (TAFWA), a professional organization Parker has actually belonged to since his days at Runner’s World. Like many professional organizations, TAFWA has a specific audience to address and clear goals and constraints for their site, but their skills tend not to lie in web development or HTML coding. Our goals for this site are to create a site which is easy for non-technical users to maintain but which will help TAFWA itself provide useful services for its members.

With all this contract work going on, you’d worry that our own projects are being neglected. To the contrary, both “common” sites have seen development activity in recent weeks, though not necessarily in visible ways. My post earlier this week sprung from work I’m doing implementing a machine-learning based shoe recommendation system for Common Running, for example, and we’re gearing up to refresh the shoe database with the latest models.

Common Kitchen got a typical update earlier this afternoon, in which we updated the process for adding cookbooks and magazines to the site. This involved ripping out a chunk of code and replacing it with the neater, tighter acts_as_amazon_product code from Netphase. Their code searches books only by default, so we tweaked the plugin a bit ourselves to handle magazines and other product types using an optional parameter. The difference is pretty slight from the user’s end, but it’s typical of the work we’re doing on Common Kitchen nowadays, where we trim, tighten and otherwise refactor the site’s code based on what we’ve learned since we started.

There’s more CMI work waiting in the wings, both some potential outside projects and some ideas we’re brewing for our own sites. We’ll try to keep you posted here!

Installing Ruby’s linalg linear algebra library on a Mac OS X system is problematic because linalg is built around LAPACK, the Linear Algebra PACKage, and OS X (at least the version I’m working with, 10.4.11) ships with a bastard version of LAPACK which is missing some important symbols for linalg. The way around this is to install a full version of LAPACK.

You’d think this would be easy, but LAPACK is written in FORTRAN, and the version of gcc included with Xcode doesn’t include a FORTRAN compiler by default. So before we can install LAPACK, we need a FORTRAN compiler.

There are at least two gcc-based FORTRAN compilers out there, and they both offer pre-compiled binaries for Mac OS X (Intel or PowerPC). You can build from source if that’s how you want to do it, but I want this over with, so I’m grabbing the Intel binaries and getting on with my life. LAPACK seems to have trouble dealing with the g95 compiler, so we went with gfortran. gfortran has a nice Mac-like .dmg installer, so you can just download that, click through the installation, and gfortran is ready in /usr/local/bin/ (which is hopefully in your $PATH). You can make a link so that the g77 command (the old gcc compiler for the FORTRAN77 standard) points to gfortran with this command:

sudo ln -s /usr/local/bin/gfortran /usr/local/bin/g77

Now you’ll want to start in on LAPACK. Download the tarball from http://www.netlib.org/lapack/lapack.tgz and store it in /usr/local/src/ as before. Unpack with

tar xzvf lapack.tgz

You’ll have created a directory named e.g. lapack-3.1.1. cd into this directory. What’s missing from LAPACK is the standard ./configure step; we’ll have to edit the make.inc file ourselves before running make to build the package.

Fortunately, Robert Hatcher builds LAPACK as part of his CERNLIB build, which means that the shell commands for creating a working LAPACK make.inc are available as part of that script. Here’s the relevant excerpt:

# customize makefile
sed -e 's/_LINUX/_DARWIN/' make.inc.example > make.inc
echo "" >> make.inc
echo ".SUFFIXES : .f .o" >> make.inc
echo "" >> make.inc

# go ahead and build - "all" will perform tests
make blaslib lapacklib tmglib > make.log 2>&1
if [ $? != 0 ] ; then
echo "*** Error in make blaslist lapacklib tmglib ***"
grep -i err make.log
fi

Now: this step will take a while. If you copied this all into a file and ran it as a shell script (the sane thing to do, I think), it will take a good while to run, on the order of ten or fifteen minutes; if you are keying in the commands line by line, it will pause long after the make blaslib lapacklib tmglib line. Don’t panic; this means it’s working. (If you’re paranoid and like seeing stuff stream across your screen to prove you’re compiling something, you may want to background the process and then use tail -f make.log to get the full output.)

Once it’s done, it’s time to put these files where they belong:

sudo cp blas_DARWIN.a /usr/local/lib/libblas.a
sudo cp lapack_DARWIN.a /usr/local/lib/liblapack3.a

(Note that it may be the case that there are faster BLAS libraries out there; if you’re squeezing every cycle out of your app, it may be worth looking into that, but it’s beyond the scope of this post.)

Unfortunately, we’re still not done. linalg still needs several libraries from the f2c package, which is quite hard to dig up. The best route I’ve found is to grab the package available through Fink. The trick is that Fink installs libraries in /sw/lib/ and we need them elsewhere (/usr/local/lib/ should work). Use a link to solve that:

sudo ln -s /sw/lib/libf2c.a /usr/local/lib/

Now it’s (finally) time to install linalg. Unfortunately, there’s no gem available for this that I’m aware of. (This may be because the package has been essentially “done” for four or five years, so it’s older than the widespread use of gem.) Download the tarball from the project page to /usr/local/src/ and un-tar it; you’ll get a folder named linalg-0.3.2. cd into that folder, and you should be able to use

sudo ruby install.rb

…but you can’t, actually. This builds most of the files you need, barring two; it will start the installation, but eventually stall because it’s missing two .so files, ext/linalg/linalg.so and ext/lapack/lapack.so. These are “Shared Object” files, akin to Windows DLLs, but the Makefiles in these directories defines the DLLIB macro as ending with the .bundle extension, and linalg.bundle is what gets built.

So, we brute-force it by breaking the process down into “make” and “install”, and in between we create those .so files.

ruby install.rb make
cp ext/linalg/linalg.bundle ext/linalg/linalg.so
cp ext/lapack/lapack.bundle ext/lapack/lapack.so
sudo ruby install.rb install

If you don’t trust this hack, put in ruby install.rb test before the install task to verify that everything works. I’m not sure why the package tries to install an .so file its own makefiles don’t build; if someone can figure that out and patch it, I’m sure the maintainers would love to know.

If you find any obvious errors in this, or see some steps we can stick, feel free to comment and we’ll make edits. Hopefully this will come in handy for someone.

Update, 7 September 2008: Be sure to read through the comments to where James Lawrence, linalg‘s maintainer, points out the new (as of yesterday) 1.0.0 release which resolves most of these problems. If you’re struggling with linalg and aren’t using 1.0.0, try that new version.

How? I went back to a listserv running community I belong to, where I’d asked for shoe ratings, to thank them for their help, and discovered one runner asking if there was a site which would let him check his current shoes and get a list of other shoes which were similar. Someone mentioned CR, and another list-member checked his shoes and reported back on the list of other models we reported as similar–including the other model he wears and likes.

We actually use a pretty lightweight algorithm to make those lists. It mentions the easiest possible models (the previous model in that line, and any descendants, so for the Asics GT-2120 we’d mention the GT-2110 and GT-2130), similar models by the same brand at different price points (e.g. for the GT-2120, we’d mention the GT-1130) and then models by other brands which are in that class (stability, motion control, etc.) and have a similar weight and price, like the Brooks Adrenaline GTS 7.

Each of these are easy SQL queries; the only reason the recommendations aren’t “perfect” is that our database isn’t comprehensive. And yet there’s no other site on the web that we can find which does this. There are sites where you can compare shoes by checking off a bunch and seeing them side-by-side, but this is simple and easy for the user. And it’s useful, even though we aren’t doing the kind of recommending we had planned yet.

Common Media’s next project, CommonRunning.com, is a “collaborative filtering” application, in which we hope to be able to suggest specific running shoe models to runners without asking the questions that always draw puzzled looks, like, “How much do you pronate?” or, “How high are your arches?”

Our idea is that if we can find other runners who liked some of the same shoes you liked, we can probably assume you are similar runners, and use that information to recommend shoes to you. Our problem is this: we need a collection of reviews to test our suggestions on.

So if you run, we’d love to have you sign up at Common Running and review your running shoes. The review form is simple (four buttons) and should take less than a minute for each model you review. If we don’t have the model you wanted to review listed, we want to know about that, too; there are probably between 300 and 500 different shoe models available, and we figure we have fewer than half listed so far.

If you can help us out now, we should be able to help you out by suggesting good shoes for you before very long. Thanks!