July 19, 2008
Thus concludes any feelings of affection I’ve retained for the Libertarian Party.
(Yes, I’ve been under a rock, and this is news to me.)
If Barr is really serious about reversing his position on…well, everything he ever advocated…he should do it within the Republican Party framework. Because it’s no good to spend decades doing damage with the weight of the federal government, then “repent” when a third party offers you an ego boost late in life. You have to reverse the policies you’ve helped implement, not just speak a few words that the mainstream won’t even take seriously.
And how the hell does a guy like that get accepted into the Libertarian Party, of all things? The party of “principle”? The party that would rather come in fourth in an election than give up an ounce of liberty?
I mean…are they all smoking dope?
July 17, 2008
The team I’m working with is in the process of moving from SQL Server to MySQL.
To ease the burden, we need all writes to the new MySQL databases to be replicated back into SQL Server, so that all of our back-end reports and what-not will continue to function. It’s short term, but not shorter than six months.
I can’t find any generic tool online to do this.
I thought about setting up a bridge MySQL instance with triggers that create a message queue, then reuse our existing Java DAOs to do the heavy lifting (they know how to read/write either SQL Server or MySQL). But, that quickly gets invasive and brittle.
My next thought was a lightweight wrapper around the
mysqlbinlog program which does essentially what the MySQL replication threads do: reads a portion of the binlogs, persists its current position, then replays the statements.
Then I thought, “well, if we’re doing that, why not just reuse MySQL’s replication code and build something around that core?”
You can see the hole I’m getting myself into.
Are there better strategies? Are there (free or commercial) tools that can replay replication logs on a MSSQL Server instance?
The lightweight Perl/Python wrapper seems the best solution. Anybody have experience with something like this (for SQL Server or otherwise)?
July 16, 2008
We’ve all been through this exercise a number of times: you’re partitioning your data set across multiple physical servers, which means you can no longer rely on your database’s built-in
One common pattern is what’s come to be known as the “hi-lo” strategy. This requires each component in your distributed environment to communicate with a central node (table) to generate an ID, usually by reserving a batch of available IDs for itself to reduce the communication.
(“Hi lo” isn’t exactly self descriptive, so I always use “externalized ID generation” which, despite being longer and more difficult to say, seems to be more descriptive for those not on your core team. Anyway…)
Another pattern that’s emerging is the use of UUIDs. These are 64-bit unique identifiers that can be generated in isolation by any component in your system without talking with a central node (table).
I’m going through this exercise again with a new team, and I’m debating whether I should step outside my comfort zone and try UUIDs. I’m having a hard time
seeing many advantages, however.
The disadvantages that I see are: longer IDs mean longer URLs (unless you go the “slug” route with SEO-friendly URLs), and they don’t play nice with clustered indexes.
The latter is a bit more damning in most scenarios, actually. It just blows away InnoDB’s clustered primary key, for example, which is going to be an issue even outside of web contexts.
The main problem with “hi-lo” is it still introduces a SPOF. In reality, it’s not going to be a bottleneck, since you can always adjust both the granularity and the number of IDs you reserve in each transaction (the “lo” part of “hi-lo”). But that lingering SPOF is a bit ugly.
The other advantages I see are: better use of the available ID space and ubiquitous implementations (even MySQL now has the
uuid() built-in). Many hi-lo implementations are specific to a given framework and/or broken for real distributed environments.
Are there advantages I’m missing?
The only situation that I can see where UUIDs offer a clear advantage is for aggregating content across the web, where the UUID can be based on a SHA-1 hash of the source URL, and you’re not clustering on primary key (or, indeed, may not even be using a relational database). FriendFeed seems to have gone this route, for example.
Now obviously, I’m talking about a narrow context. UUIDs are applicable in many other situations (device IDs, node IDs, etc.).
July 6, 2008
There’s an excellent Google TechTalk by Mary Poppendieck on the history of management/leadership organization, starting with railroads in the 1840’s and working through WWII and many of the buzzwords we soaked up in the 1990’s.
By the end, she brings it back around to software engineering teams and identifies two essential leadership roles. Well worth the 90 minutes.
July 5, 2008
As you almost undoubtedly know, American Greetings Interactive bought Webshots in October. Operational control transferred over to AGI in March, and with that switch, we lost a lot of talented people who had (to be politically correct about it) been lacking the tools to make Webshots what it should have been.
Most of them have landed on their feet and are doing well at start-ups of one stripe or another, or else taking time off to evaluate their next big thing.
As for me?
I’ve had maybe three full weeks in San Francisco since March.
In November, I accepted AGI’s offer of employment as an architect…in Cleveland.
Yinghua and I spent quite a bit of time meticulously calculating the move. There were certain assumptions about my position within the company, my career options, what the work would look like (would it be interesting?), what the team would look like, housing prices versus salary, quality of life, diversity of the food landscape, and so on, and so forth.
All of which was for naught because all the factors have changed.
There’s a lot of stuff I probably should not blog about, not least of which because some of it’s still in flux, but the most important change is that the position is now in Seattle.
As a result of all of this, I’ve been commuting between San Francisco and either Cleveland or Seattle. Thankfully, mostly I’ve been flying to Seattle.
Oh how I love love love Virgin America.
It’s been a great experience for me.
I’ve rediscovered my love of airplanes and airports. Many years ago, I considered jobs that involved a lot of travel. I was single, I was smoking crack (or something like that), and I loved observing people.
My health issues had made me claustrophobic and flying became quite stressful to me. But now I’m back to loving it.
Maybe it’s the cute, young, hip flight attendants at Virgin America? Or their delicious cuisine? (No, the flight attendants at Virgin America aren’t edible. Though that would be a good perk for their frequent flyer members!)
I’ve also had the opportunity to stay at some great hotels, and, until this month, it was all on the company’s dime. Who could ask for more?
So, yes, Virginia, I’m alive.
And, for this weekend at least, in San Francisco, with some time to relax (with my in-laws no less), start checking my e-mail (ahem), return some phone calls, …and, oh yeah, post to my blog. Which is the last item in priority, but the second I’ve taken action on (the first being relax!!!!).