Mouse, louse, douse

I’ve started the home buying process. Color me crazy. It’s a down market, surely, and it looks like things haven’t tanked completely, but here in the tri-state area everything’s pegged a bit higher by Gotham’s vast influence. And we mean to stay, so I’m willing to weather the storm a bit.

That said, it is a nerve-wracking process. Simply looking at these vast sums of money written out on paper makes me queasy, and signing them requires continuous leaps of faith.

An initial here? Oh sure, bombs away.

Ultimately, however, I have faith. Millions of scruffy Americans have managed this before, and the recurring sentiment is “tough, but far from impossible”. I will fight for a good rate. I will call and pester with abandon. These are my creeds.

What’s missing? A great online portal for making this easier. I imagine a wondrous system that streamlines the tough choices by comparing quotes and costs as well as factoring in customer reviews. It would cover the whole stretch – realtor, lawyer, inspector, broker, insurer, etc. Essentially, a giant recommendation system with a lot of reliance upon customers, word of mouth, and trust… oh so 2.0.

A better birdie

Songbird dropped 0.6 recently and color me impressed, what a vast improvement from the buggy, alpha days of yore. Those early versions were tantalizing solely for blurring the distinction between local and remote music, letting you browse and play tracks from the web with ease. Annoying bugs, however, kept me from replacing Amarok or iTunes, especially since I craved hearty local music management as well.

What’s great about this release?

• It hasn’t crashed yet. That’s a full day, on two different machines (Linux and Mac), with zero swan songs. Sweet.
• Tabbed everything. Yup, your Library, playlists, web pages… everything in a different tab.
• Beautiful. It looks great, and in particular, I’d like to congratulate the person who decided to highlight metadata changes with yellow text, instead of stupidly confusing radio buttons.

Ultimately, it makes exploring music on the web a better experience, so give it a shot.

Moved

The blog has officially moved from blogforsamurai.com to blog.forsamurai.com. Note the dot. Makes all the difference.

Behind the curtain, the migration from Site5 to Slicehost is complete and I’m definitely loving the full control here. To keep Rails from bursting the 256MB ceiling, I’m throwing mod_rails (aka Phusion Passenger) and Ruby Enterprise Edition at it. There’s a purported 33% memory recoup which should surely help.

Future junk? I’m writing a quick blog app with Merb and DataMapper that I intend to replace this with, but progress is slow and I just may move it all to LimeSpot. Eating my own dog food, perhaps. You’d think re-writing this bare bones app would be quick (heck, no comments), but tracking edge has its price.

Mess your repo

Recently, on github, I forked something, committed, and sent a pull request. It was rejected, however, on valid grounds, and I fixed the problem by committing on top. Easy, right?

Well no. Now, the maintainer needs to pull two commits and merge an entire branch instead of a single commit. That’s messy.

Enter crazy git superpowers. It is entirely possible to return to the past and amend previous commits. The due warning, however – doing so can royally screw anyone who is forking or following you. So be nice. Do this if you know that no else is using your commits. I just did it and a little part of me gasped inside. Seriously.

Obviously, no such concerns exist if you’re simply modifying local commits that haven’t been pushed upstream.

Anyway, the author skipped a few things:

If you’re squashing, you may be confused by the workflow of git rebase. It stops at an edit, asks you to check it out… but hey, no squashing has occurred? That’s right. You’re simply confirming the state of the previous commit. Just go ahead and commit with any old message, then:

$ git rebase --continue

Now your squashed commit is applied and you can condense the verbose commit message into something more meaningful.

Finally, after all is said and done and you want to push this to your remote ref:

$ git push --force

Omitting the force option will cause git to complain about a non-fast forward commit. Exactly. So don’t make this a habit.

PDX to EWR

On continuing with ruminations about RailsConf:

Getting back to scalability, like I said, most of the advice wasn’t news to me, but one point was certainly hammered home – metrics. Any work on performance needs to be preceded with hard numbers and scaling is often a matter of detecting capacity problems before they happen. Logging and analyzing should be done on the whole stack: web server logs, Mongrel logs, indexer stats, profiling, benchmark scripts, and integration tests with an eye on performance. Covering all of this feels like a month of work, but I’d like to get back to New York and starts putting some effort into it. Features first though, features first.

Unfortunately, I missed the MagLev talk, but there’s been plenty of blogging about it. It’s a new VM, built by a Smalltalk shop, reportedly 8 to 60 times faster than MRI. More exciting, however, is talk about an object-oriented data store that’s massive, distributed and fast. Sweet. If they pull it off.

And that’s pretty much it.

Goodbye Portland

Ah, RailsConf is over and I might as well log a few thoughts before they disappear. I didn’t do the same for SXSW and where’s that blog post?

First, lots of people. That’s been expressed all over the place but apparently they didn’t even sell out. It’s going stadium show at this rate.

I need to stop going to scalability talks. It’s a concern that looms large, but everyone’s right – make your app behave properly first, then worry about scaling. Also, at this point, the advice is on a loop and I keep hearing the same things, boring myself in the process. Sadly, the scaling panel was a little light on concrete advice and more stuffed with fluffy talk and quips, in contrast to one I attended at SXSW that was amazingly packed with content. That one featured a great cross section of web luminaries, including Ezra from EngineYard, Cal Henderson from Flickr, and guys from Automattic, Media Temple and something else (sorry!), and they all provided a peek at their own scaling problems and techniques.

In general, I think I kept going to the wrong panels. The DTrace introduction was nice, but dry, and the laughter coming from next door only made it worse. ActiveRecord refactoring didn’t show me anything new and I could have skipped the DataMapper talk since I’ve already been following it pretty closely.

But there definitely were some highlights. The Skynet talk was great – I didn’t know much about it before so it was all new, the speaker was entertaining, loud, and well-paced (fast!), and the tech was damn cool. Briefly, Skynet is a map reduce framework for Ruby, with some improvements to the original implementation outlined by Google. Instead of master/worker roles for servers, everyone’s a worker, and the task of assigning code and data is just that… another task, so any worker can temporarily become a master. Peer monitoring, auto-discovery, fault tolerance, task versioning, task queue abstraction, production-ready… it’s simply packed with features and I can’t wait to make use of it.

Koz’s talk about optimizing the Rails framework itself was also fun. Again, he’s quick with words (I’m impatient) and it was nice to hear about the strategies and decisions that the core team makes with regards to optimization. It was also a quick overview of 2.1 features.

More later… breakfast time.