Monday April 26, 2004

Giants Beat The Braves! It's been a rough couple of weeks but having the Giant's hold back the Braves tonight is a good lift. Schmidt's obviously not at his best but even so, they did it.

We'll take these one-run games if that's all we'll get -- after some of the recent beat-downs from the SoCal division rivals, it's fine to just squeak by for the time being. What I'd like to see is Woody restore his good name, get a strikeout or two and maybe give the G's a little momentum with a win tomorrow. But for tonight, hat's off to V-rod and Herges for keeping them at bay in the end

Let's go Giants!

( Apr 26 2004, 10:17:00 PM PDT ) Permalink


It's not just far out, it's Groovy Does the programming world need another scripting language? There's already a ton of them and they all have their pros and cons and their adherents and detractors. Well, kick down your cobblestone and look for some fun: now there's Groovy.

I've always enjoyed the expressiveness and rapid development qualities of Perl, Python and Ruby. However, the proliferation of Perl's obscure idioms and linear of scripting tendencies of many of its users is enough to make you shudder. The absence of semi-colon statement delimiters is enough to always make me feel like I've forgotten something with the latter two. Then there's function-crazed languages like PHP and Tcl. Maybe the world does need a clean break from it all? Well, Groovy is definitely a departure of sorts. It looks a little like Ruby and a little Java with a dash of JSTL but not entirely like any one of them. And it compiles down to ye olde JVM's bytecode.

The Groovy website is loaded with examples for using SQL and writing servlets (um, make that "Groovelets") using the Groovy syntax. Support for regexp and xpath matching is in there. Reading through it, I'm impressed with the familiarity and yet the newness of the syntax. But I can't help wondering if I'd really use it to build any substantial software. In many respects, it took Java so long to mature as far as lots of those little things that matter to me like regexp support, cached prepared statements in the JDBC API and the various jax-foo API's -- all good stuff but a long time coming. So why start using Groovy?

Well, I thought of one place where I'd imagine using Groovy. When collaborating with GUI implementers on the web tier of an application, I have in the past found myself working hard to keep the communications loop tight between those dealing with the markup and the tags and on the other end those dealing with Action classes, servlets and filters. "The MonkeyBean has a Collection of Bananas... you can iterate over each of them to access their Peels..." Wouldn't it be nice if the folks working with the markup and tags could write their own beans and actions without having to know all of that Hard Java Stuff? Well, maybe. I mean if they're implementing a lot of the display logic with JSTL, why not give them an easy entry into the data-centric modules that the JSTL accesses?

Well, I don't know but I'm willing to be open minded about it and I guess the powers that be in JCPville are as well; Groovy has it's own JSR. There are a lot of important check-off items already in place:

• Groovy Eclipse Plug-in
• Ant driven compilation
• Unit Tests

The latter two are really important when your practicing continuous integration. Other stuff like XML-RPC support and embeddability, that's all nice too.

I can see the why Groovy might be more attractive that Jython or something like that that uses the JVM but isn't native to it. On the other hand, if I didn't know better were I hiring an engineer (and I'm not, please, no phone calls) and a candidate had "Groovy" listed on their resume, I might pass them by as a goofball. Although, knowing what I do now about what Groovy may potentially be good for, I might put that resume on top of the file.

I think I feel a song coming on:

Slow down, you move too fast
You got to make the morning last
Just kicking down the cobblestones
Looking for fun and feeling groovy
Ba da da da da da da, feeling groovy

Hello lamppost, what'cha knowing
I've come to watch your flowers growin'
Ain't cha got no rhymes for me?
Doo-it in doo doo, feeling groovy
Ba da da da da da da, feeling groovy

I got no deeds to do
No promises to keep
I'm dappled and drowsy and ready to sleep
Let the morning time drop all its petals on me
Life I love you, all is groovy

  59th Street Bridge Song

Sorry, I got carried away there. I couldn't help myself. ( Apr 26 2004, 09:25:52 PM PDT ) Permalink

Sunday April 25, 2004

New Toys: Treo 600 I recently received a brand spanking new Treo 600 PDA/phone and it's da bomb!

Due to some recent changes in my circumstance, I need to be available for SMS messaging across different carriers as well as by phone. The Treo 600 is chock full o' goodness: PalmOS means that it can run Top Gun SSH, it unites my palm address book with my phone (it's all in there) and the color display is excellent. The built-in web browser, Blazer, is good enough (but um, I'm not posting this blog entry from it); there's no built-in GPS but if you know where you are, you can always pull up a map to get you the rest of the way. The built in camera is, um, adequate. I mean, I wouldn't take the kodak-moment family photos with it, you're keepers warrant a real camera but hey, just to get a quick n' dirty photo, it'll work.

One word of caution I've received is that the wrong combination of 3rd party PalmOS apps can break it pretty badly. The recommendation I have is to get an sd/mmc flash card and a backup utility that will backup a full image of the OS and apps. Sounds reasonable; it'd really suck to crash your phone into a state where you'd lose everything. The other thing that is kinduva a let down is the lack of bluetooth. I'd heard that the Treo 610 with bluetooth would be out by April but obviously it's the 25th; we're still waiting. I would really like to synch this puppy up without a USB dongle but life's just unfair sometimes. Anyway, SprintPCS seems committed to not carrying phones with bluetooth capabilities (bastards), so I'm not gonna hold my breath.

I haven't been this excited by a PDA since I used OmniSky on a Palm V a few years back. In retrospect, that was pretty sucky but the high geek factor made it a lot of fun. I think this Treo gonna be fun and useful on a much more enduring basis. ( Apr 25 2004, 08:11:16 PM PDT ) Permalink

Wednesday April 21, 2004

Container? I don't need no stinkin' container! There's no denying it. A Boston Tea Party is swelling against Sun, the JCP and the way Java API's have been handed down from that Cathedral. Look at all of the bitchin' publications that've cropped up in the last few weeks and are expected in the coming weeks and months

Object-relation mapping without the container

A quick rundown of Hibernate, Spring Framework based transaction management plus a side order of DbUnit; more fun than you can shake a stick at.

Hibernate: A Developer's Notebook

O'Reilly has posted a sample chapter with a simple Hibernate example.

Hibernate In Action

The publish date on this is now listed as August 2004; I thought this was coming sooner but nonetheless seeing as how it's from the horses mouth, it should be a good read.

Java theory and practice: Coaxing J2EE out of the container
Projects like Somnifugi JMS blur the boundary between J2EE and J2SE

Discusses using JMS, JNDI and JMX for J2EE outside of the EJB container.

Expert One-on-One: J2EE Development without EJB

From the Spring Framework creator, Rod Johnson follows up on his fine 2002 publication "Expert One-on-One: J2EE Design and Development"

That's just the activity that's bubbled up through The Establishment. The J2EE blogosphere and TheServerSide is effervescing with stuff about Velocity, Tapestry, Jython, Java Groups, Pico, Hivemind, iBATIS and so on week in and week out. Struts and Ant are probably the prime examples of de-facto standards arising from outside of Sun but Hibernate has certainly opened everyone's eyes to the notion that the blueprints and the pet store aren't ominpotent and in fact, the whole "work inside our container API's and let the magic get handled for you" concept is pretty limited.

The bottom line for me is: I want to be able to easily test stuff outside of the containers and the mandatory interface implementations. Traditional J2EE, the practices promoted around it and the tools provided haven't accounted for that requirement. So the grassroots have.

Sun, consider yourself put on notice!

Due to space constraints, I couldn't get into it in my article about AOP (Aspect Oriented Programming: An Introduction) earlier this month but as I was looking around the landscape of AOP implementations and the related technologies (i.e. Inversion of Control) it's become increasingly apparent that Hibernate, Spring and an array of other projects that've gained momentum from the grassroots level are really the important story this year in J2EE, not Java Server Faces or EJB 2.1 or EJB 3.0 -- the J2EE developers in the trenches are tired of Sun groping around trying to get it right and they're pressing ahead with real-world solutions without Sun's official blessing. If useful standards can arise out of the open source ecosystem, then Sun's JCP, the insular and opaque JSR working groups and the Decisions From On High about what's important at JavaOne are likely to see their relevance ebb.

Hasta La Vista, Baby

( Apr 21 2004, 11:31:18 PM PDT ) Permalink
Comments [2]

Why Content Management Fails Jeffrey Veen of Adaptive Path published an essay, Why Content Management Fails, pointing out that all of the good technology in the world isn't going to provide a successful Content Management System (CMS) installation; getting the users on board is the real challenge.

Yes, you need a good software support system and competent IT help but if the users don't see themselves as publishers, if it's not ingrained in their psyche, it's not going to be a part of the core concerns. Dropping a bunch of tools in someone's lap doesn't necessary stoke their enthusiasm to use them. Creating structured content and collaborative creation is human activity that requires a mindset comfortable with the process. The tools are just there to help.

While Why Content Management Fails emphasizes CMS failures as a "people problem", IMO it also has a technical element: CMS developers aren't grokking their customer's requirements. Instead of imposing upon the users This Is How You Shall Work the toolset should be flexible enough to work the way the users want to use them. And Veen backs up my point

To have any chance of success, a content management project must follow the same user-centered design practices as any other project. Task analysis, rapid prototyping, usability testing - all of these methods are crucial to a CMS rollout. It is foolhardy to unveil a mammoth, nine-month project to an unsuspecting user community and expect adoption.

I predict that the proliferation of low end tools such as blogware (as in low cost, limited templating, story structure flexbility and workflow support) will drive increased awareness right down Main Street that the web is a read-write medium, that you can be a consumer and an author of content and that authoring will become just another part of how people think about their work and their lives. This will drive the demand for publishing tools more feature rich than blogware but without the bloat and absurd price points that most people associate with enterprise content management.

It used to be supposed that with Vignette's and Interwoven's fat market capitalizations in the dot boom daze that the CMS market is done, it's a solved problem. But look around and it's clear that it's still an open issue. The big enterprise vendors with their jumbo price tickets are in trouble. And the market is ripe for a new generation of tools. The writing is on the blog. ( Apr 21 2004, 01:47:51 AM PDT ) Permalink

Monday April 19, 2004

Nail Biter The Giant's had to keep you on the edge of your seat, ya know. After the string of one run loses, it just wasn't exciting enough to give the Pads the beat down.

With San Diego coming in with a 9th inning rally, bowling over the Giant's bullpen you just have to stare in disbelief as the three run lead that the Giant's enjoyed at the onset of the 9th evaporated into one. After coming off the high of Grissom and Bonds launching back-to-back home runs (and Bonds acquiring the number of man, 666), it's just inconceivable to have that victory snatched away. The rain pouring down was making it seem all the more grim.

But no need for dispair! It wasn't so bad. At the end of the night, it's another one run game but this time the G's were on the good side of it and the four game losing streak is snapped. Sighs of relief were audible far and wide.

	Runs	Hits	Errors
San Francisco Giants	4	7	2
San Diego Padres	3	8	1

( Apr 19 2004, 11:28:06 PM PDT ) Permalink


Perl6 and Apocalypse 12 Those wild and crazy guys behind Perl6 are at again. Larry Wall published "Apocalypse 12" the other day and it discusses many of the deficiencies of Perl5's object support.

There are a lot of funky things about Perl5. Paradoxically, sometimes these are beautiful things as well. But oftentimes, they're just funky. As I've said before "I suspect with Perl 6, I'll only hate it on Tuesdays". I could rag about the weak encapsulation and the lack of useful method signature support in Perl5. But since I've really come to love Java's use of interfaces to compose an object's capabilities and disallowed multiple inheritance, I was interested in reading about Perl6's roles. Yes, in Perl6 a class can have a bunch of different roles. Here's a little bit of Larry from Apocalypse 12:

Roles can encompass both interface and implementation of object relationships. A role without implementation degenerates to an interface. A role without interface degenerates to privately instantiated generics. But the typical role will provide both interface and at least a default implementation.

A little later, in discussing how roles are kinda like second class classes but not really, we see some hypothetical code:

If you want to parameterize the initial value of a role attribute, be sure to put a colon if you don't want the parameter to be considered part of the long name:

    role Pet[IDholder $id: $tag] {
        has IDholder $.collar .= new($tag);
    }
    class Dog does Pet[Collar, DogLicense("fido")] {...}
    class Pigeon does Pet[LegBand, RacerId()] {...}
    my $dog = new Dog;
    my $pigeon = new Pigeon;

In which case the long names of the roles in question are Pet[Collar] and Pet[LegBand]. In which case all of these are true:

    $dog.does(Dog)
    $dog.does(Pet)
    $dog.does(Pet[Collar])

but this is false:

    $dog.does(Pet[LegBand])

The universe is a big place. And it keeps getting bigger. I guess I'll wait for Damian Conway to chime in. If Larry Wall writes the bible; Damian has to write the talmud.
Shalom, Salaam, Shalom, Salaam ( Apr 19 2004, 11:06:01 PM PDT ) Permalink

Sunday April 18, 2004

My Baseball Weblogoscope Barry Bonds is a phenomenon. The recent rash of home runs is paradoxically accompanied by a losing streak for the Giants. After witnessing the San Fransisco Giants succumb to El Aye three times in a row in one-run loses, I realized that something must be done. Well, nothing I do is gonna make Woody a strike-out king or Neifi Perez into a long ball hitter. But there's no shortage of opinions on what must be done. There's a lot of talent on the Giants' roster, perhaps some of the rabble and babble sprinkling around the ether has some relavant wisdom. I decided to see if I could pull together the various blogs about the G's into a kind of meta-blog, a weblogoscope.

I could conceivably take on some other topics ("George Bush", "Iraq", "Lies and the lying liars who tell them" and so forth) but for now, I think I'll just enjoy the approach of summertime. And root for the Giants.

The weblogoscope is programmatically generated; it gave me a good excuse to take a close look at the rss, rdf and atom document data structures as well as mess with some of the stuff on CPAN for handling them. It's pretty funny how similar these structures are and yet how divergent their grammars are. And to top it all off, it seems like the timestamp representations are all over the road; the datelines have different elements representing them (why this isn't standardized on Dublin Core is a mystery to me), different formats and various timezone styles. I guess one of these days I'll research more closely how it got to be this way.

Or maybe that doesn't matter. Regardless, perhaps a weblogoscopic view of the baseball season might help the Giants. Maybe it's just another big distraction. ( Apr 18 2004, 11:03:13 PM PDT ) Permalink

Saturday April 17, 2004

What Is The Matrix? I just noticed that TheServerSide has posted a comparison matrix of J2EE servers.

TheServerSide apparently has had this little gem published for a while, their Application Server Matrix provides links to downloads, data sheets and product reviews. Great resource! ( Apr 17 2004, 10:28:29 AM PDT ) Permalink

Friday April 16, 2004

Dumping Java object contents If you've ever exploited Perl's Data::Dumper to inspect a Perl object, you know how useful it can be. For Java programmers, the reflection API provides tools to perform a similar interogation but the API has long lacked a higher level tool. The Jakarta commons-lang jar has a goodie to help.

I first ran across the ToStringBuilder class looking for a tool to standardise the formatting of toString() -- it's annoying to trace a set of objects' contents to a log file and find that they all implement toString() with different levels of completeness or with different formatting conventions. Well, this class has another little gem in one of it's static methods. Check this out:
  System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));
      <Emeril Lagasse>BAM!</Emeril Lagasse>
That's it.

By providing a higher-level wrapper API, ToStringBuilder makes using reflection to dump a Java object contents a little bit easier. Of course, seeing as how I started off talking about Perl, it's worth a mention that TMTOWDI'ness presents itself in this case. The Java bean API's XMLEncoder can be used to serialize a Java object to XML. ( Apr 16 2004, 10:59:39 PM PDT ) Permalink
Comments [2]

Wednesday April 14, 2004

PHP versus J2EE I don't like language wars, different languages and frameworks usually have a mix of strengths and weaknesses. However, I'm presently looking at some fixes (mostly resiliency issues) that have to be applied to a web tier built on PHP and am thinking about what's over the horizon for future scaling requirements.

I first used PHP in 1996 (it was called PHP/FI at the time) -- it offered a very innovative alternative to Perl and CGI generated content by making the execution flow out UI embedded logic. I liked it. The language was easy; very Perl-ish. But over the years, other frameworks have emerged that, despite the many improvements PHP has enjoyed, easily eclipse PHP.

PHP's primary strength is its enablement of rapid development of database backended web applications. For prototyping and providing "functional mockups", that's all well and good. But what I'm seeing is that as soon as you want to scale the application along some axis (runtime traffic, i18l, collaborative development, multiple presentation formats), it's difficult to justify sticking with PHP. From what I reckon, a J2EE web tier (servlet container, JSP w/jstl taglibs, MVC i.e. struts, etc) offers a lot of high level infrastructure and, when contrasted with PHP, is a clear winner:

	PHP	J2EE
Runtime scaling	There are opcode caching extensions but it's not a core component of the PHP runtime environment PHP is not thread-safe. You pretty much have to run PHP on a pre-forked Apache server. That's not too bad but it means that if you have a large Apache process pool, each process has to have its own connection to a database. If you have multiple persistent connections and a few hundred Apache processes, you're taxing the databases (because of the large number of open connections) and taxing the OS (because of the large number file descriptors open and memory consumption). And every forked process is an island of process space; sharing data between them is a PITA (you have to manage shared memory) and sharing resources is impossible (e.g. forget about pooling your persistent database connections).	Servlet container hosted runtime engines (such as JSP or Velocity) usually have code caching out-of-the-box. Higher level caches such as OSCache promise to provide even more to reduce the computational burden on the web tier. They easily take advantage of resources shared between threads such as database connection pools, external service interfaces (e.g. remote and/or local EJB factories; the home interfaces) and the container itself.
Content format scaling	If you want to co-brand a PHP site, plan on having conditional logic scattered and tangled all over the UI code. This quickly degrades down into a maintenance nightmare.	A J2EE MVC framework such as Jakarta Struts (with tiles) provides a centralized mechanism to declaritively and programmatically control how content is assembled for presentation.
Locale scaling	PHP allow you to extend the runtime with the GNU gettext framework. IMO, this is a difficult to use system; you have to manage PO files that have a peculiar file format.	The standard Java library has ResourceBundle support built-in with a simple file format (properties files) and, again, web tier infrastructure such as the servlet container, JSTL and Struts provides easy-to-use tools to access ResourceBundles.
Functional scaling	Extending PHP often requires recompiling the PHP runtime to statically link in different extensions. This results in closely binding your runtime requirements and your infrastructure compilation requirements. Maintaining persistence flexibility is difficult with PHP; while the PEAR abstraction layer provides a baseline of RDBMS independence the language is still bloated with database function calls with every backend you use. Furthermore, as outlined above, changing backends requires platform dependent code, perhaps recompiling PHP itself and then having client libraries installed where the runtime is executing.	Most Java libraries are available as "Pure Java" i.e. jni support, deploying OS-native libraries, isn't an issue. You never have to recompile Java to extend it. JDBC provides a standard interface to different database backends. While this won't help with things like SQL implementation differences, higher level tools like Hibernate's object-relational framework potentially will. Furthermore most database drivers are "Pure Java" i.e. there's no need to recompile anything and no need to, say, make sure LD_LIBRARY_PATH is set properly to enable your database drivers.
Collaborative scaling	The distinction between UI code and business logic is fuzzy and requires lots of developer discipline to keep it cleanly separated; there's little support in the framework itself. This pretty guarantees closely mingling formatting and display code with lots of logic. Yuck.	While it's certainly possible to write horrible applications with J2EE web infrastructure (i.e. the the fact that you can embed Java code, er, scriptlets, directly into a JSP is a terrible fact of life), the wealth of framework support (JSTL, Struts, etc) makes it easy to follow practices that keep the separation of concerns clean.

A clean separation of concerns is important. Collaborative web application development usually has different roles (the Java programmer providing business API's and beans, the UI layout coder developing the HTML structures, the UI logic programmer writing tag libraries and/or integrating them with the HTML structures) -- even if you're one person coding all of these out, having the different work elements clearly defined and cleanly separated will make your job easier. When you're working in a collaborative environment, the separation of concerns is essential.

There are other little things in the pro's and con's. PHP can support URL rewriting session tracking without doing anything special in the markup code -- nice that it can do that unintrusively but icky on other counts

• Markup has to parsed outside of PHP's normal tokenization; it's a post-processing of the markup
• It doesn't adaptively enable URL rewriting when cookies are disabled at request time, it has to set at runtime

I'd rather use a taglib in a servlet container to keep track of the URL rewriting needed, if any.

All of these points of contrast lay atop the basic structural differences between the PHP and Java languages: Java has Object Oriented Programming (OOP) as a core part of it's design, PHP has OOP as an odd afterthought. Java has real exception handling, PHP awkwardly provides function calls to register error handlers and function to trigger an error. OO is a core element of code modularization, reuse and extension.

Additionally, while I have my misgivings about EJB's and their misuse, EJB's are an established framework for separating the business and persistence tiers from that of the UI. Service oriented architecture (SOA) patterns are also well established amongst the J2EE development community -- this also better enables collaborative development and clean separations of concern, ergo, long term maintainability.

A final point of comparison and contrast is how closely bound PHP is to the web server in a typical architecture. It's nice to have the ability to scale the HTTP interface independently from the application layer. With PHP, the only option there is to run another webserver; a reverse proxy to offload all of the HTTP servicing. With a servlet container there are various options to connect the HTTP interface to the Java engine via a connector. For example with Apache and Tomcat, you can use mod_jk to connect them, and just to sweeten the deal a bit, mod_jk provides a bit of scaffolding to support load balancing.

It's not my intention to sweepingly indict PHP. For the simple stuff, I like it. And I know it's extremely popular ("50 Million Elvis Fans Can't Be Wrong!"). But when you get beyond needing "Server Side Includes On Steroids" and have to deploy a scaled up database backended application, PHP's weaknesses come to the foreground. Yea, yea... I know that Yahoo! uses PHP and I bet there's a lot to learn from their experiences with it -- I expect PHP creator Rasmus Lerdorf's employment with Yahoo! to drive a lot of innovation in PHP's future. But at this point in time, for the web application requirements I'm looking at, I gotta give it to J2EE.

Other links of interest

• Nukes: the Open Source Java CMS
• The word on the street is PHP
• PHP versus J2EE reagrding speed of developpers (sic)
• Another Performance Comparison of Middleware Architectures

( Apr 14 2004, 12:12:22 PM PDT ) Permalink
Comments [2]

Monday April 12, 2004

YAQPM: Debian's software package manager Over the weekend, I had my initiation with Debian's package manager(s). While I've never been in love with RPM's or Solaris packages, I wasn't particularly eager to have to contend with Yet Another Quirky Package Manager.

At first I started messing around with Debian's vt100 utility, dselect (which it turns out is just a cheesey wrapper around dpkg) hoping to find something of the same caliber of the FreeBSD's package manager. 90% of the time, the FreeBSD tool won't give you too many surprises, it JFW's. I was not so lucky with dselect, what a POS! If you misfire some selection keystrokes and then leave your dselect session, you'll never be able to just undo what was there -- you can item-by-item set flags to "hold" the current state of individual packages but there's no way to just say, "the current state of the packages is how it is, don't flag anything for installation, removal, holding or whatever."

In the end, I read the man pages for apt-get and apt-cache; between the two of them, it looks like everything you'd want as far as package management tasks are available. My next foible was realizing that an installation can have a mix of packages from stable and the amusingly named unstable streams of Debian's deliberate development branches. Geez, I just needed libperl5.8 so I could compile something that embedded perl but the requirement to go to a different branch wasn't readily apparent from the dpkg -l listing (i.e. it required poking around a little research to discover that unlike the rest of the stable goodies, perl-base was from unstable).

And while I'm bitchin about how braindead linux distro's can get, what's with having libraries and header files in separate packages? What's I recall being so righteous about FreeBSD's ports-n-packages was that when you installed, say, zlib, you got the libraries and the headers -- there should be no need to install zlib-dev or something just to get the header files! What, are we concerned about diskspace usage? Why not just install the ding dang headers with the base package??

I remember a few years ago celebrating the news that the Open Packages project was going to bring the ports-n-packages thing of beauty to Linux and hopefully do for Linux what it'd been done for the BSD's a long time ago: a consistent, reliable and yet flexible package management system. IMO, RPM, Debian packages and Solaris packages all fall short. ( Apr 12 2004, 09:03:53 PM PDT ) Permalink

Tuesday April 06, 2004

Technorati Rocks! I'm very pleased to join the fine folks at Technorati. I feel that the changes that are afoot with the way content is developed and published presents huge opportunities.

As the jack-of-all-tradesman in LAMP, J2EE and web operations, I'm confident that I will be adding valuable new capabilities to Technorati's business and great things will be upon us. The Technorati team is sharp, inspired and with those added special ingredients of timing and luck, on the cusp of greatness. ( Apr 06 2004, 04:05:45 PM PDT ) Permalink
Comments [2]

Monday April 05, 2004

Buy me some peanuts and crackerjacks I was busy with other stuff but the post-game reports on today's season opener sounds awesome.

While I'll miss Jeff Kent's contributions to the Giants, it's hard not to take a little pleasure in seeing a little late inning beat down with Bond's 3 run HR in the 8th (number 659 for his career, Say Hey!)

	Runs	Hits	Errors
San Francisco Giants	5	10	0
Houston Astros	4	9	0

It's the most wonderful time of the year: "Play Ball!"

Happy Opening Day! ( Apr 05 2004, 09:21:23 PM PDT ) Permalink