Now, I get to introduce you to Teru’s latest project, Basetrack. Teru’s put together a team of experienced, professional journalists, each of whom spending a significant part of this year directly embedded with the 1/8 (First Battalion, Eighth Marines). The battalion is over a thousand Marines, engaged in deployment across southern Afghanistan. Teru and his team are with them, sending back photos and updates.

With funding from the Knight Foundation News Challenge, Basetrack is an online platform for that experience. The photos and updates go into a visually arresting map, and immediately insert itself themselves into the fabric of our everyday communication tools: Facebook, Twitter, RSS. Minutes later, people around the world — and their families — are seeing it, commenting, and in a totally new way, themselves experiencing the Afghanistan war in realtime.

See Basetrack now, and if you are so moved you can make a direct donation to November Eleven, our 501(c)3 public charity to support this and future such projects.

Seven years ago, IM was the “glue” that finally brought me and Teru together as professionals  (and I suspect this is true of many, many other projects). We’re now entering an age of “social” where the same principle is writing itself large — we are, millions of us, talking and sharing in real-time. Basetrack is playing on that level. The principles it represents will become far huger than we can anticipate.

Who are you? Especially if you’re reading this as a designer or developer, I would love your feedback and help. Basetrack is in its very first iterations, and you are its audience.

Homework:
Check out Basetrack on Facebook, and follow them on Twitter. It’ll elevate your experience of both those platforms.

We talked about Foursquare, of course, and Shawn observed this: Foursquare creates this hope that after checking in somewhere, one of your contacts will see your check-in and spontaneously join you, and technology will have magically expedited real social engagement. However, it very rarely happens that way. I agree; I think I’m relatively active and connected on Foursquare, but it’s not happened for me either.

The more I think about it, though, the less I see it as a failure. In fact, I see this as a valid part of their product. They create promise, and indulge my hope that such spontaneous “happenings” are both possible and desirable. In part, my use of Foursquare is a statement of belief in this promise, and this in itself is valuable.

A separate example of a product which offers “promise” as a benefit is Basecamp, I think. In my years working with clients, I don’t think I ever fully realized the promise inherent in Basecamp: that two organizations, mine and my client’s, would come together in a beautiful orgy of planning and communication. But the tool’s total indulgence of this fantasy helps bring me closer to it.

Both examples — Basecamp and Foursquare — indulge dreams, and are designed on ideals we’ll rarely achieve. I think this is not only not a failure, but a kind of success I’d like to see in every product I develop.

I know how to avoid this mistake and in a moment, so will you!

Writeboard and Basecamp are actually separate products, much as Highrise and Campfire are separate. Basecamp provides Writeboard integration, and most people I know just think of it as a Basecamp feature (which is fine).

See, this is actually a Writeboard URL, and we’re not in Basecamp right now.

If you copy-and-paste the URL from the Location: field, you’re actually capturing a link to your Writeboard account, and not your Basecamp project. That’s why 37signals provides the “Share this Writeboard” link. If you want to link to this document Basecamp-wise, you must right-click the “Share this Writeboard” link, and select “Copy this link” (on a Mac, that is). You do not want to copy the 123.writeboard.com URL.

This is oddly inscrutable for a 37signals product and I hope it gets improved someday. In the meantime, we’ll just have to suck it up and make ourselves remember to link to Writeboards the right way and not the wrong way.

New Relic is the best way to track a Rails app’s performance, no question, but it still confounds me at times. Here’s something I learned today.

New Relic reports the number of instances per host; until today, I was reading this as the size of our mongrel pool.

It’s not, actually—it’s more like the ideal size of the mongrel pool. New Relic is actually counting individual instantiations of mongrels, which is to say the number of mongrels which have run. If you’ve got a pool of 8 mongrels (who could ask for more?), and 2 of them have restarted, then New Relic is going to report that you had “10 instances”.

It makes perfect sense in retrospect, but I didn’t realize this until Justin at New Relic pointed it out to me. They’re very responsive at their support site.

I haven’t had the opportunity to see how New Relic displays instance counts for Phusion Passenger deployments; if you have anything to add, please post in the comments!

"You don't have permission to access / on this server."

After spinning my wheels for a little while, I discovered it was because I had turned on FileVault (in Snow Leopard, but I believe it’ll happen the same way in Leopard).

The fix was simple:

chmod +a "www allow search" /Users/username

I hope this saves some Googler  a few minutes…

One problem you may have seen is during a deploy — when all the mongrels are restarted at once, haproxy ends up running around in circles, unable to find anyone to serve the latest request. In such a situation, you might get the dreaded 503 Error.

Here’s a cool workaround — have Capistrano reboot one mongrel at a time, so that haproxy always has something to hang its hat on:

namespace :mongrel do
  desc <<-DESC
  Rolling restart: 1 mongrel at a time.
  DESC
  task :rolling_restart do
    for i in 6000..6004 do
      ENV['HOSTS'] = ""
      find_servers(:roles => :app).each do |server|
        ENV['HOSTS'] = "#{server.host}:#{server.port}"
        puts "Restarting #{i} on #{server.host}:#{server.port}..."
        sudo "/usr/bin/monit restart mongrel_thepoint_#{i} ; true"
        puts "Sleeping 30 seconds before the next mongrel."
        sleep 30
      end
    end
  end
end

namespace :deploy do
  desc <<-DESC
    Deploy, with a rolling restart
  DESC
  task :rolling do
    update
    mongrel.rolling_restart
  end
end

There are two things you'd want to adjust here for your particular environment -- the number of mongrels in your cluster, and the number of seconds to wait between each restart request. (In this example, 5 and 30, respectively.)

There's a catch here -- this won't work if you have migrations to run, because you probably don't want stale mongrels hitting your newly-migrated database.

For now, we're just using this when there are no migrations, and using a conventional deploy:long when there are.

Can anyone suggest a way to adapt this approach in a way that could accommodate migrations?

Credit is due to Engine Yard, of course, for pointing us in the right direction. Thanks krutten!

Long-time client and all-around mensch Jeff Chang has relaunched Can’t Stop Won’t Stop with a new look:

http://cantstopwontstop.com

If you don’t already know, Jeff is an acclaimed hip-hop scholar and mad Twitterer — start following him now if you want to stay current on hip-hop history and activism.

The blog is a collaborative feat by Kuwayama Design, 226 Design, and the man himself. Check it out, and be all the cooler for it.

John talks a bit about Eight Bit Studios, of which I’m fortunate to be a part. I’ll post more news when it comes; in the meantime, follow Eight Bit on Twitter if you want the real skinny.

via Flash ‘n’ SEO Indexing – Google, Yahoo, MSN and Adobe Flash Crawling Experiment .