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 View blog reactions


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 View blog reactions

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 View blog reactions

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 View blog reactions
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 View blog reactions

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 View blog reactions


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 View blog reactions

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 View blog reactions

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 View blog reactions

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 View blog reactions
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 View blog reactions
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 View blog reactions

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 View blog reactions
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 View blog reactions


Building software could be like layering a cake, which could be good I did a little write up on Aspect Oriented Programming (AOP), titled "Aspect Oriented Programming: An Introduction," I'm more than just a tad stoked that it's the lead story currently on CMP/TechWeb's DeveloperPipeline (ya know, I'm just having a great day today, there's lots of good stuff happening).

Anyway, I believe we are entering an age of non-intrusive frameworks (unlike traditional J2EE) that serve as lightweight application servers, or lightweight containers, if you will. AOP isn't a piece of software or a container, it's a different and complementary approach to ye olde Object Oriented Programming. AOP is about layers. It's about being able to layer on supporting functionality and weave it into your core functionality. AFAIC, Sun is put on notice: your big overdone API's for J2EE aren't necessarily the best way to develop all of the components for a scalable OO architecture.

A lot of the things that J2EE provides (such as security and persistence) might be better served as application aspects, layered onto the core OO model. And technologies such as Hibernate are here to help as well.

Layers involve complexity, but that's not a bad thing. Why, there are even bits of wisdom on the matter to be found in everybody's favorite DreamWorks feature film:

SHREK: For your information, there's a lot more to ogres than people think.
DONKEY: Example?
SHREK: Example? Okay, um, ogres are like onions.
DONKEY: [Sniffs] They stink?
SHREK: Yes. No!
DONKEY: They make you cry?
SHREK: No!
DONKEY: You leave them out in the sun, they get all brown, start sprouting' little white hairs.
SHREK: No! Layers! Onions have layers! Ogres have layers! Onions have layers. You get it? We both have layers. [Sighs]
DONKEY: Oh, you both have layers. Oh. [Sniffs] You know, not everybody likes onions. Cake! Everybody loves cakes! Cakes have layers.
SHREK: I don't care... what everyone likes. Ogres are not like cakes.

Who can argue with that? ( Apr 05 2004, 08:55:55 PM PDT ) Permalink View blog reactions


Deadwood: a heavy metal western

I'm not a big TV watcher but I really dig HBO's new series, Deadwood, it's such a departure into the heavy metal underbelly of human tendencies and vices, I can't stop watching it.

The dialogue gets a little tiresome with the "f*ck'ing this" and "c#ck s*cker that" every other sentence. Don't get me wrong, I can cuss like a sailor, when inspired to (I have colleagues who can attest to this fact), it just gets a little old having it be such a dominant aspect of the script. I could complain that the ugly people are really damn ugly and the pretty/handsome ones are too much so but overall, I think it's a great show. The cinematic mise en scene of Deadwood is truly awesome: tough, gritty and grueling.

The next thing I'd like to see on Deadwood is a role for Ian Kilminster (AKA Lemmy), it'd be perfect!

( Apr 05 2004, 11:37:28 AM PDT ) Permalink View blog reactions

Friday April 02, 2004

Content Event Listeners Content publishing events should be like the ripples of a stone landing in a pond. Concentric circles of information modulation should eminate from the blessed event when new content is born.

Discovering that a stone has penetrated the surface of the water has traditional been discovered by scanning the bottom for new debris. What a waste of effort! Publication is an explicit, active event, why is it sufficient to discover its occurance after the fact, passively? These are the days of miracles and wonders indeed, we can tell those who have a registered interest in knowing that a publish even we should be concerned with has happened. Content event listeners will make it happen.

Metadata is your friend, my friend. It will be used to enrich us. ( Apr 02 2004, 05:49:22 PM PST ) Permalink View blog reactions
Comments [1]

Thursday April 01, 2004

Content Management Systems in the 21st Century Building a general purpose CMS isn't easy. My last effort at it was carried forth after my departure from Salon.com and eventually turned into Bricolage.

These days, there are so many open source content management systems, it's difficult to keep 'em all straight. When I'm evaluating these things, the first thing I look at is how close is the CMS to the content serving? If they're closely bound, then any efforts at scaling one function (say, serving content) has to be considered for it's impact on another (such as, inputting and managing the content). This is why I outright refuse to deal with products such as Vignette. And yet a lot of products seem to follow that same "the appserver is the content repository, serving engine and workflow manager" model that makes Vignette such an awful product.

I understand that Plone is similarly modeled, albeit on top of a Zope app server. A lot of the blogware (such as the one that I'm using now) that masquerade as CMS' also closely couple the data management with the serving of templatized content output.

I say: get with it. It's the 21st century already -- we know better than to mingle our high request rate content with our low request rate administrative interfaces, don't we? The talk I gave at the O'Reilly Open Source Conference in 2000 is posted online and there are loads of other resources out there. And yet people are still ponying up huge mega-buck deals for Interwoven and Vignette, they're rolling their own one-off solutions, they're making compromises by limited their content to blog-style articles and it's sad. The fact that crap that requires an application server closely bound to the CMS functions to deliver the content are still being developed and deployed tells me that the CMS problem is still a wide open issue. It's my opinion that the there's huge uptapped market there.

If someone wants to hire me to re-write Bricolage in Java so it can be more easily boxed up and sold, I'm available (insert evil grin here). ( Apr 01 2004, 03:23:33 PM PST ) Permalink View blog reactions

Wednesday March 31, 2004

Take me out to the ballgame! I'm gonna be in The City tomorrow evening for some stuff; when it's all said and done, I'd love to take a trip down to PacBell^H^H^H^H^H^H^H SBC Park to see the San Francisco Giant's return home in a night game against the Texas Rangers.

I don't understand how anyone can find baseball boring. Sure, some games are more exciting than others but when you've got a got a guy throwing a ball between 85 and 95 MPH through a little window in front of the batter and the batter's job is to launch it past the squad that he's facing, it's great! I mean, damn, you try it sometime! Baseball is the perfect mix of strategy, psychology and the boundaries of human athletic abilities.

I'm so glad spring time is here! Now if any readers happen to have an extra ticket to the game, I'm all over it, lay it on down :) ( Mar 31 2004, 10:41:31 PM PST ) Permalink View blog reactions


Gimme some linkin' love Criminy, I just checked how much love I'm getting according to Technorati. The news isn't good. I mean, I realize I only launched this blog a little over a month ago but I thought I'd start getting a little lovin' by now.

So here it is, in all of it un-glory, my Technorati rank. rank. Jeez, it's pathetic; maybe I should stay home and watch re-runs of the "Love Boat" and "Gomer Pyle."

OK, screw that. But if you link to me, I won't complain. Maybe I should make a business plan for my blog, set some objectives for my Technorati ranking. I can probably post pictures of Paris Hilton or something to get some links. Yea, that's it. ( Mar 31 2004, 05:07:24 PM PST ) Permalink View blog reactions

Tuesday March 30, 2004

Software Development Team In A Box I was musing yesterday about off-the-shelf tools that, when put together, provide the basic needs to make a software development team productive.

Here's my list:

source control with commit notifications

It might seem obvious but when changes are happening all engineers who have any interaction (direct or indirect) with the altered component may need to know about it. Thankfully, getting emails out of CVS is a piece of cake. Other source control systems usually have hooks for this as well.

bug tracking

Identifying issues and keeping tracking track of them so that narrative descriptions, conversations and related media (screen shots, log files, etc) can be associated with the issues is crucial. Bugzilla is E-Z 'nuf.

reproducable builds

If a lot of steps that have to be manually triggered is required to build a software project then development is going to be intrinsically slow. The build cycles should generate reproducable results and do so in a scripted framework that can ultimately kicked off with one command.

unit testing

I'm a big fan an keeping as much business logic as possible out of the web runtime environment. If a web server,servlet container, EJB container and/or database is required to be running with your code deployed to run the tests, then you've been writing integration tests, not unit tests.

integration tests

Of course, your code has to work in the runtime environment of your application, so "in-container" tests such as Cactus are crucial.

functional tests

Ultimately, an end-to-end test that goes from HTML and HTTP, through the business logic and frameworks and down to the database is important to validate the system as a whole. This is where things like HTTPUnit come in.

automation

If you use something like Cruise Control to take care of updating from source control, kicking off builds, running unit tests, integration tests and functional tests with as high a frequency as possible, you've got a pretty robust development environment.

test coverage calculation

Not everything requires a test but there whenever there are semantics, the business logic should be tested and whenever there are environments to deploy to, there should be a level of integration testing -- I don't know what tools will effectively give you that stuff (send it to me if you know!).

a wiki

It's useful to have a central repository of facts about the project. Best practices, HOWTO do weird things type documents and stuff like that should be kept as authoritative documents.

a blog

A lot of software design decisions are made in face to face conversations and email threads. It's difficult to retrieve the original intentions and the pro's/con's discussed in that way. I've seen email threads pasted into bugzilla reports and wiki pages as a work around. However it seems to me that if the wiki pages and bugzilla reports instead linked to the blog entries where these conversations took place, they would be easier to keep track of, search for and so forth. Of course, a lot of decisions are still going to be the outcome of face to face and email conversations but they can still be synopsized and made into blog entries.

So here's the money shot: if I were the VP of Engineering or the Director of Software Development or the Grand Pooh Bah of Code Artifact Creation at SoftwareCo Incorporated, I'd want easy insight into all of these things. A kind of portal that contained summaries of software development metrics:

• How many software commits has each engineer made?
• How many different files were they commiting changes to?
• How many bugs were created?
• How many bugs were closed?
• How complete (percentage wise) is our test coverage?
• How many broken code artifacts were checked in (i.e. put the code base in a state when it wouldn't even compile)?
• Who did it (are there any grossly flagrant offenders)?
• How many builds with all tests run have completed successfully?
• How many failed?
• For the failures, what was the average time to resolution?

...and so on. A lot of pointy-haired-boss metrics like lines of code and code to comment ratios are nice, I suppose for amusement value, but likely uninformative about anything important.

In the end, I think getting all of these parts working together will render a whole greater than the sum its parts. Getting a collaborative environment functioning isn't easy but a lot of these tools are readily available off the shelf to help it along. ( Mar 30 2004, 03:04:12 PM PST ) Permalink View blog reactions

Friday March 26, 2004

HOWTO's make the world go around I rediscovered some old HOWTO-type materials I'd had around, stuff I'd forgotten about for ages but I realized might still be useful to some folks. And then again, it might not.

The first one was a little bit about tricks with server side includes ("SSI's") and some of the crude things you can accomplish with them that, while falling short of a "real" programming language, are surprisingly powerful. The browser detection stuff is very old and yet still very pertinent today when folks want to determine on the server side which CSS style sheet to send the browser. The other HOWTO is some notes I'd had about messing with HTTP cookies.

So I performed some minor updates on these things and reposted them:

	The SSI Mini-Tutorial
	The HTTP Cookie Mini-Tutorial

Open source and the internet were built on people sharing tidbits; techniques and hacks to leverage technology. So these are some small contributions. Have Fun! ( Mar 26 2004, 08:50:43 PM PST ) Permalink View blog reactions

Wednesday March 24, 2004

I want free WiFi without 128 bit WEP (or maybe "I need to get a new WiFi card") This is my last rant of the day. I think. Sometimes when I'm downtown, I sure would like to be able to sit down, plug my laptop in (for power, I have a sucky battery) and just get a little bit done.

I went to Golden Gate Perk where they have free WiFi for paying customers. Great! I ordered a chicken pie but sat down to realize that my wireless card (I have an old Orinoco "Silver" card which only supports 64 bit WEP) wouldn't work, they only support 128 bit WEP. Well, the chicken pie was good.

If you go to Google's search results for WiFi downtown, there's no way to refine the search to show

1. which ones are free
2. which ones support 64 bit WEP (or are open, I'm using SSH and SSL for important stuff anyway...)

In the meantime, I guess I'll keep an eye on the Cheese Bikini page for this stuff. And if anybody has an Orinoco "Gold" card (are these credit cards or NIC's?) that they feel like sending me, donations are gladly accepted! ( Mar 24 2004, 11:17:25 PM PST ) Permalink View blog reactions