My Mephisto install was 0.7.3- 0.8 doesn’t have any huge feature changes but there are some bugfixes and small enhancements, as well as a performance boost (speed, memory use) from using rails 2.0. My install was from a tarball, and I don’t want to move my production server to a git checkout (yet?). Like other Mephisto users I’ve got theme customizations and maybe even some things in the public directory.

I need to upgrade, not reinstall. The Mephisto folks didn’t write a real upgrade guide, but this is Rails and it’s not too hard to figure out. Almost any rails app could be updated this way:

• Back Everything Up
• Create & Apply A Patch
• Stop Your Server & Clean Up
• Patch Code & Migrate The Database
• Crack Open A Beer

As a side project I’ve helped some friends launch Liquidware, a simple storefront for their Arduino modules and other open/hobby hardware. They created a decent amount of buzz about their launch by saving up a bunch of content and pushing it out the same weekend. Blog posts, video, images, all that good stuff:

• YouTube
• Flickr
• Blogspot

That was good noise, and it got them enough traffic to sell out of a few stocked items (woohoo!). But after the launch bubble a steady stream of sales needs to come from Google. I’ve been experimenting with the SEO on Liquidware’s site and learned a few smart tricks for your next storefront.

So just two days ago Obama swept Hawaii for his 10th Democratic primary win in a row. Barack in particular has been beat up for lacking real content in his message, though I personally think his actions have spoken loudly (he taught constitutional law, supported Net-neutrality, and helped push the ethics reform bill). Using tag clouds for visualizing messages has been done before, with pretty interesting results

That example was nice for a snapshot of each candidate, but I’m looking to dig into the data for a single candidate a little more. I want to compare tag clouds for Obama to see how his message has changed over time.

A few days ago we walked through writing our own mootools-based table sort in the Joy of a Minimal, Complete Javascript Table Sort. A poster going by “hello there” raised a good point about performance:

“would be nice to see the example with several hundred rows - performance in sorting is a huge issue, and looking at the zillions of libraries out there… many of them konk out completely, taking 5 seconds to sort a table with 1,000 rows.”

Right. Javascript should be used to enhance a user’s experience. 5 seconds of wait times for a table sort is completely asinine. Let’s look at some quick ways to optimize our code, and uncover a slick way to double the speed of our sorting.

When you’re done poking through this, take a peek at how you can double the speed of this script in The Joy of an Optimized, Complete Javascript Table Sort

Ah table sorting. There are few problems that have been solved as many times as you have been. Unfortunately, some of the nicest solutions, such as mootable, are also pretty overbearing. Check out this feature list:

1. Total re-styling of your table.
2. Editable table cells.
3. Loading table contents from JSON.
4. Loading table contents from JSON over XHR.
5. Server-side sorting using the above.
6. Client-side sorting.
7. Re-ordering of columns, column options.
8. Nice fade effects.
9. Event hooks.

Whoa, too much. Over at ICA we needed something way more lightweight. I was pretty much looking for this:

1. Client-side sort of various formats (like mm/dd/yy).
2. Zebra or striped tables.
3. Support sorting with hidden rows on the table.
4. Be fairly fast.
5. Use mootools (which we already use).
6. Use a table already on the DOM.

Let’s take a look at how to make a javascript table sort that follows best practices, is relatively minimal, and fast. Nothing here is completely new stuff, but hopefully walking through it will help you write a better table sort next time you need just a table sort, and not all the overhead of a library. I’ll be using mootools sort of aggressively, but the core ideas and practices here are portable to any environment.

Here we go!

Oh Ferret, how lovely your speed, how confusing your documentation. Maybe we’ll go over that in another post, but for now, let’s see how we can make Ferret a bit kinder to normal users by better understanding their queries.

Over at FindYourDoc we’re searching not only a large number of records, but a large variety of fields. When we get a query such as:

  Doctor in Nashville TN

You and I know the user has given us a lot to go on, but Ferret doesn’t. When humans look at that query we pull out a human understanding.

• Doctor - a type of care provider
• in - a throwaway word
• Nashville - a city
• TN - a state

So if I were a programmer (imagine that), I would form the same query using Ferret’s query syntax:

  type:Doctor city:Nashville state:TN

Well great, but our visitors are not programmers, they’re grandmothers and dog trainers, patients and college students. Let’s look at that query again, and see how we could break it down:

• Doctor & TN - These are phrase that look for a match in specific sets.
• Nashville - matches data in a very large set.
• in - throwaway word.

So let’s see how the raw query might be moved closer to my programmers query.

Geocoding is like a spicy pepper, it provides an impressive kick, but should normally be sprinkled in moderation. Now that rails has GeoKit, it’s even super-easy to do.

Once you fight your way through the API-only documentation.

But lucky you, we’re going to walk through a basic GeoKit set up modeled after what we used over at FindYourDoc (we launch next week-ish):

1. Install GeoKit
2. Find out where a visitor is from and stuff it in a cookie
3. Test our geocoding (‘cause duh, you’re testing, right?)
4. Use javascript to put it somewhere

At the end of this you’ll be customizing pages for visitors based on their location, but without killing off your action_caches. Won’t that be a ball?