Tuesday June 08, 2004

They were diverting traffic and congregating on the freeways (which looked surreal... the cops appearing pretty bored, "Here I am, guarding this stooopid freeway ramp..."), lots of pissed off drivers but I didn't see a single protester.

Maybe the cops were the protesters.

( Jun 08 2004, 09:21:39 PM PDT ) Permalink


Setting up Movable Type Earlier today, someone was asking me "How hard is it to setup Movable Type?" I don't know, I haven't set one up but I bet it's not hard.

Indeed, builder.com has confirmed my hunch, setting up Movable Type with a vanilla configuration looks pretty ding dang easy.

( Jun 08 2004, 09:09:14 PM PDT ) Permalink


The Index Macarena is Done It's been previously reported, Google has in the past has had an episodic updating cycle. Apparently, they've retooled for small incremental cycles.

The Google Dance has had it's last hurrah. The Google search machine is now updated piecemeal. ( Jun 08 2004, 10:17:19 AM PDT ) Permalink

Sunday June 06, 2004

"How many google machines" makes a plausible estimate of the range. More of the technical nitty gritty of google is published but whether it's enough to really infer an accurate picture isn't clear. But I bet the avid google-watchers are pretty close. ( Jun 06 2004, 09:00:32 PM PDT ) Permalink

Saturday June 05, 2004

Apparently, one component of the Secret Sauce is the Google File System. Some have even gone on to extrapolate some projections of how they do what they do from the SEC filings. The challenges of managing gigabytes terabytes are impressive, indeed. ( Jun 05 2004, 11:58:01 PM PDT ) Permalink

Friday June 04, 2004

But seriously folks, there are a lot of things that are just toyish about MySQL. In the same way that programming language features like Object Oriented Programming shouldn't be sad after thoughts as it is in Perl and PHP, basic database functionality (foreign keys, transactions and subqueries) shouldn't be the "new features" for a database. I've always liked PostgreSQL for its more complete SQL implementation but it just doesn't seem to have the momentum behind it that MySQL does.

Anyway, my favorite MySQL bug (this is on MySQL 4.0.18) has got to be the silent failure of replication. There are slave database instances whose replication status I assumed were monitorable by doing "SHOW SLAVE STATUS" and observing "Slave_IO_Running" and "Slave_SQL_Running" (each attribute represents a thread that manages the binlog IO and SQL execution on replicated units, respectively) on each of them. Well guess what? That's not sufficient. Both threads can claim to be running and you might even observe the execution positions changing in sync between master and slave. But lo and behold, the real measure of whether or not the MySQL replication is working correctly is to query your application data! For instance, if the timestamps and/or sequences for some key tables are advancing in the master but not the slave, you're hosed. You might need to myisamchk the slave's tables. You might need to simply restart the database slave instance. You might need to ceremonially sacrifice a chicken. Perhaps a little bitch slappin' and sweet whispers will get it going. I dunno. The bottom line is: MySQL might report that it's replication threads are running and its positions are changing but *SURPRISE* your data isn't really updating on the slave! I need replication support for high availability and read concurrency but bugs like that just suck the big one.

So what is to be done? Does MySQL 4.1 fix this crap? Do InnoDB tables replicate more reliably than MyISAM? Is PostgreSQL even an option here? I don't know anybody using PostgreSQL replication. Sometimes when I read the comparisons between MySQL and PostgreSQL, it just makes me wanna throw my hands up in the air and move over to the The Dark Side (AKA Oracle).

Here are some links:

• PostgreSQL vs. MySQL vs. Commercial Databases
  more general fluff that hard core comparison but still not a bad read
• Oracle, MySQL and PostgreSQL comparison
  even though that can't manage to spell the latter correctly, this isn't a horrible report
• Comparison of Oracle, MySQL and Postgres
  another pretty good side-by-side comparison, though it's pretty dated
• OpenACS wants ACID
  out of date and don't even talk to me about Philip Greenspun (I feel sorry for his dog)... I mean, some of my best friends are into TCL but it all seems so trite.
• MySQL Gotchas
  silent failures cases like the "Whoops, no InnoDB table support" one are the sorts of things that drive me nuts

( Jun 04 2004, 01:54:11 AM PDT ) Permalink
Comments [2]

Thursday June 03, 2004

Back in those days that I cared a lot about metal, Herr Umlaut and myself were making a lot of it happen. These days, I'm not really in the loop anymore (damn, I don't even know who the hell these people are) but it's still plenty fun to hear the echoing reverberations of all that crap that's irrevocably changed pop-culture.

Welcome to the blogosphere, Umlaut!

( Jun 03 2004, 01:29:49 AM PDT ) Permalink

Thursday May 27, 2004

I've known Wade Grubbs for years but I guess I never really knew him 'cause if I did, I'd have known that he was into Stratocasters; I have an oldie but goodie that looks a lot like that.

At least he has time to play his. Cheers to you, Wade! ( May 27 2004, 12:08:27 AM PDT ) Permalink

Wednesday May 26, 2004

The 540i interior is relatively cramped compared to some of the other rides I've had lately but the seats are still fine enough. Ya know, BART's seats aren't bad by public transit standards but the leather seats in this ride will beat that anyday. ( May 26 2004, 11:34:17 PM PDT ) Permalink


Better pictures on the Treo 600 I flipped the settings on my Treo's camera, the pictures it takes are a lot better now.

In the Picture's application, if you go into the menu and flip the "Picture Size" option in the preferences from "Small" to "Large" you get a little jump in quality (and "Large" is hardly big at all -- I think it's only a .3 megapixel camera anyway).

So, check out this sign I spotted downtown for a lost dog, sad but true! But at least you can read it! ( May 26 2004, 11:23:52 PM PDT ) Permalink

Tuesday May 25, 2004

I recently grabbed Class::DBI (v0.96) off of CPAN to help me wire up some simple objects with lots of database attributes. Now, when roughing out objects in Perl, I typically find it quickest to declare a package in the file scope of my working code -- it's like having a runnable test for the package's code write there in fornt of you. Most of the time, that's just fine and dandy -- as the code matures or gets unwieldy, migrating it out into its own .pm module files is fine. But I noticed that with Class::DBI, all kinds of weirdness can ensue if you declare your packages outside of the .pm module file world. I'd seen goofiness with older version complaining about not finding 'db_Main' in the package and yaddada yada. This time around, I tried putting everything in the file scope i.e. so it looks like this:

#!/usr/bin/perl

use Class::DBI;

my @britons = Criminy->retrieve_all;
map { print $_,$/ } @britons;

package Criminy;
use base 'CriminyDBI';

Criminy->table('criminy');
Criminy->columns(All => qw(id foo bar));

package CriminyDBI;
use Class::DBI;
use base 'Class::DBI';
# someday, I'll have a dog and name him Django Hendrix
CriminyDBI->connection('dbi:mysql:test','django','hendrix'); 

But this totally fails...

Criminy can't SELECT 
FROM   criminy
: DBD::mysql::st execute failed: You have an error in your SQL syntax near 
'FROM   criminy
' at line 2 [for Statement "SELECT 
FROM   criminy
"] at /usr/lib/perl5/site_perl/5.8.0/DBIx/ContextualFetch.pm line 51.
 at ./criminy.pl line 5

CREATE TABLE criminy (
  id int(11) NOT NULL auto_increment,
  foo varchar(32) default NULL,
  bar varchar(32) default NULL,
  PRIMARY KEY  (id)
) TYPE=MyISAM;
INSERT INTO criminy VALUES (1,'Led','Zeppelin');
INSERT INTO criminy VALUES (2,'Black','Sabbath');
INSERT INTO criminy VALUES (3,'Deep','Purple');

Monday May 24, 2004

And the comfy leather upholstery was certainly a big step up from other recent rides, sometimes casual carpool just rules! Check out the BMW interior. Next year for my birthday, can I get one of these? I'd like the black exterior, tan interior, please. ( May 24 2004, 09:35:57 AM PDT ) Permalink


Moblogging with my Treo 600 The PictureMail service that SprintPCS has always seemed a little bass akwards. It doesn't allow you to send pictures directly to someone but instead can only send them a link to view it on SprintPCS' web server.

That might not be a bad thing per se but when I first wanted to setup my blog with a little procmail magic to post pictures, I was stymied by the limitations of PictureMail. Well, it turns out that Buzznet's moblogware supports fetching the fetching the PictureMail content and posting it!

So I'm gonna give it a go, I'm posting stuff from my Treo 600 there in separate blog simply named Pictures on my Treo 600 (hey, who says these things have to have clever names?).

( May 24 2004, 01:08:36 AM PDT ) Permalink

Sunday May 23, 2004

Google already has a lot of Secret Sauce in their page rank heuristics. Presumably they've already got some automated Google bomb detection but I sure would be interested in knowing the specifics of how they accomplish that. ( May 23 2004, 01:47:00 PM PDT ) Permalink


Further Ruminations on Blog Index Spam Every time I think of easy ways to squash blog index spam, I can think of countermeasures that They Who Eat Their Young might employ to circumvent those efforts.

Perhaps the Vote Links is a bad idea after all (sorry, Kevin). It would be trivial for blog index spammers to catch on and merely add their thumbs-up vote in the links in the content they're clogging the ping stream with. Perhaps there's a sunnyside to this issue, in the same way that comment spam can provide fodder for anthropological amusement, maybe there's something valuable in blog index spam.

Well, no. All spammers should deserve to be treated to a merciless onslaught of pain. Period. ( May 23 2004, 10:54:38 AM PDT ) Permalink