Wednesday October 20, 2004

I've used Eclipse extensively in the past but since there was kinduva a long hiatus in Java development for me, it felt both novel and familiar to install it on my powerbook for the stuff I'm currently working on. I think that liberated feeling of knowing that That Thing Works So I Can Move On Now is referred to as being "Test Infected." Which, unlike the flu, is a good kind of infection. One of the things I've been trying to be more consistent about is writing tests prior to, or if not, concurrently with, application code. I strongly recommend reading Kent Beck's Test Driven Development (who BTW appears to have a work in progress about Eclipse), TDD is a quick read but more than any particular valuable agile techniques per se it offers a good outlook on how to think about what you're doing when you sit down to write code.

Well, I was writing a few initial test cases for a class I was working on and noticed something new (to me anyway) when I clicked on an error that Eclipse flagged. The non-existence of the method in the called class was identified and Eclipse offered to stub it out on my behalf, this is a huge win as far as expressing an API in a test case and continuously filling in the functionality development "TODO" list. Everytime I want to add a new public method, I'll write a new test case and let Eclipse bootstrap the implementation.
Read it:	Now if I could get that level of simplicity and automation working with Perl, Python or PHP, I'd be jammin'! Sure, there are testing frameworks for each of these but Eclipse really streamlines that whole TDD cycle.

Forget about the flu shot hysteria, get "Test Infected"

Tuesday October 19, 2004

Sure, I have a rain parka but that's not the point, I wanted to avoid having my backpack get saturated. So after waiting about 10 minutes, a two car N-Judah rolls into Embarcadero station at aroun 8:40 or so with the robotic audio announcement "two car. mission bay. now approaching...." A crowd piles on; I don't think the MUNI scheduling people have realized that a lot of people work near the ball park.

Out on the surface streets at Harrison, the driver announces that it's the last stop and that the next N would arrive in 3 minutes! Why would they cut the route 3 stops short?! Everyone spills out into the deluge of wind and rain; the shelter there hardly has adequate room, so most of us are getting wet. BTW, that was train cars number 1481 and 1483, in case any MUNI hacks are reading this. Almost 10 minutes later, I ended up getting back on the first train as it showed up on the opposite side of the platform, going the other way -- I was getting concerned that the rain would soak through my backpack and get my powerbook wet. On the way back to Embarcadero station, I saw the "next train" -- it was packed; looked like there would barely be room for all of the folks who'd withstood the rain waiting for it. I finally got another train and got to the office by 9:10am. Thanks for the convenient adventure, MUNI!

Saturday October 16, 2004

The objections on principal may be technical

1. Intrusive inheritance hierarchy and mandatory interfaces, narrowing and recasting, gratuitous class proliferation and so forth (does the framework work for you or do you work for the framework?)
2. Container managed debugging nightmares

The philosophical objections are perhaps a general complaint about the Software Industrial Complex

1. J2EE is handed down from The Cathedral
2. JSR's and the JCP don't constitute inclusive openness, it's a "club" that you're either in or out of
3. Java is not open source

The practical problems of EJBs

1. Using the containers can be a morass of deployment descriptors and dependencies, slowing down project spikes
2. Component dependency on the container requires extra plumbing for testing, which also anti-agile. Specifically, if you want to use CruiseControl and Cactus together, get ready for a visit from an old friend named the OutOfMemory exception
.

While the practical problems of test-friendliness seem to be addressed by IoC, it sounds to me like some of the morass-of-deployment-descriptors problem are inescapable. Mapping services into POJOs declaratively (as Spring, Hibernate and Struts all require) isn't a walk in the park; until there's a linter and/or metadata/xdoclet support for easing how services can be mapped in given a specific runtime context, the pain of diddling XML config files and finding errors at runtime are going to be part of the landscape. Nonetheless, automated unit testing without cactus is a huge win in my book -- leaving CruiseControl to run unit tests and having Cactus runs reserved for manually-invoked integration tests sounds like the way to go.

I'll be steering clear of the traditional J2EE containers such as JBoss or Weblogic.

Thursday October 14, 2004

So many books, so little time

Hibernate in Action

If the slashdot review glowed any brighter, it'd spontaneously combust.

Agile Database Techniques : Effective Strategies for the Agile Software Developer

Weighing YAGNI against the PITA'ness of data model changes has bit me before. Data modeling and iterating over model revisions are often the hard part in agile development cycles. I'd expect Scott Ambler to offer useful insights into lightening what is often the heaviest part of a projects development.

The Innovator's Solution: Creating and Sustaining Successful Growth

As one who actively looks for opportunities in subverting the dominant paradigm, I'm interested in Clayton Christensen's follow-up to The Innovator's Dilemma.

Someday real soon, I'll build a little app with Amazon's ListLookupOperation to integrate wishlist items with my blog and perhaps fold it into an Attention.XML data source.

Friday October 08, 2004

See for yourself, Bush's mystery bulge I hope Kerry brings it up in tonight's debate, may be pat him down.

Master of Puppets

I will occupy
I will help you die
I will run through you
Now I rule you too

Come crawling faster
obey your Master
your life burns faster
obey your Master
Master
Master of Puppets I'm pulling your strings

The hackathon percolated a lot of interesting ideas. One of the bits of feedback that caught my attention was from Chris Fry:

There are some drawbacks however to not having a WSDL and to not using SOAP. (1) You are bound to HTTP; (2) If you version the contract how do you notify your clients? (3) Related to 1, no SOAP Headers; (4) No public contract other than your documentation.

This sounds great, getting Technorati developers out of the wire-protocol-awareness business (unless they want to be in it) is one of my goals for future development efforts with the Technorati API. The direction I'd like to take it is an "all of the above" implementation where API consumers can fiddle with the low level if they want to (via REST w/XML, REST w/XOXO, xml-rpc or whatever interface to du jour is desired) but also provide a SOAP interface for those who want to use WSDL to skip all of that.

We have some work to do internally at Technorati to get us to that point though.

Check it out:

Gmail Atom Feed Coming?

According to internetnews.com, Google is enabling feeds of gmail mailboxes to make feed readers lightweight mail clients (well, readonly clients). I'm imagining subscribing to mailing list digests through gmail and reading them through a feed reader will become an adopted practice. Additionally, gmail's search capabilities are getting some augmentation.

Google Searches Books: Google Print

As has been widely publicized, Google Print seems to be Google's response to A9 ...so far Google Print has been down half the time I've tried to use it but I wouldn't bet against them executing well on it.

Google queryable via SMS

I'm imagining all kinds of goodness out of this... querying Froogle for prices while you're shopping bricks-n-mortar venues, looking up local bars and restaurants (and Dodgeballing them!)

Gbrowser

John Doerr says that he doesn't see browser in Google's future but still, if it quacks like a browser builder, it's probably a browser building duck.

So what's next from Google? An Orkut that isn't all-Brazil-all-the-time?

Tuesday October 05, 2004

If you haven't checked it out, stop what you're doing and check out Mount St. Helens right now! ( Oct 05 2004, 10:03:09 AM PDT ) Permalink

Monday October 04, 2004

Sure, this is always the time of year when the weather gets a little colder, the sun sets earlier and the volume of junk mail catalogs arriving from the postal service goes up. But what makes this Bad is obvious: the Giants aren't playing baseball until the spring. I just can't wait until spring! Any claims that the lack of October play is Felipe Alou's fault is just silly. The last few years' bad deals with Sidney Ponson and Damien Moss and bad luck Rob Nenn have taken away payroll that coulda been used more productively -- those situations are more blameworthy. But hope springs eternal and this spring we should see Jessie Foppert and Jerome Williams in the rotation and if some good luck (and payroll availability is on our side) Moises should be a Giant and batting behind Bonds. ( Oct 04 2004, 10:04:14 PM PDT ) Permalink

Wednesday September 29, 2004

As reported on by Dave, the chaos really crescendoed last weekend with an electrical outage at the colo facility. The service is on the mend but we still have a ways to go. The database repairs are proceeding. The hardware upgrades are mostly completed and it looks like we're going to setup camp someplace that will be a huge step up from the ghetto colo we've been in.

Here comes the sun. It's alright.

Monday September 20, 2004

One of the recent hassles I've had recently was with a hardware migration that needed to proceed quickly. The clock was ticking down on the disk capacity utilization on some key database hosts. Now suppose one of the sysadmins wanted to perform "preventitive fsck's" and "table consistency checks" -- when you're dealing with over 100 GB (closer to 200 GB, actually) of data, these are not quick propositions. In fact, they might take days. Ergo, just not feasible. Given the time, would it be optimal to sanity check every subsystem's functionality? Perhaps. But when struggling to beat the clock, you just gotta say, "Not now, Poncho!" Sometimes the only effective action is fast action.

First of all, the only times I've ever needed to do a reiserfsck has been after a cold power loss (and reiser is usually fine even after one of those). So the fact that this sysadmin wanted to do a reiserfsck "preemptively" made even less sense. As far as doing a table consistency check, with innodb this is never needed on an anticipatory basis. In my experience, innodb either is able to keep itself consistent with its own journaling or it's just hosed... not a lot of grey in between. Again, the only exception has been in cases of a cold power loss. Sure, sometimes other hardware problems, low level disk defects, will manifest themselves as problems with the filesystem or a database's data file. But usually there are other indicators as well (kernel complaints in syslog, etc). But even with the dependency stack accounted for and checked, it's no guarantee against failure.

Sometimes the optimal course is just the fastest one between where you are and where you need to be. Choosing the deliberate and cautious route, dwelling on unnecessary optimizations, may in fact be the slow and steady road to.... failure! In this case, if we'd followed the course of doing every unnecessary system check possible, we'd have run out disk space and crashed these particular databases.

Stop optimizing. Just shut up and get it done already.

Saturday September 18, 2004

Although Apache 2.0 has been out for a while now, the risk for mod_perl and PHP based developers is still high.

I just ran into an interview I did with Linux Guru about two years ago. I was relatively upbeat at the time 'cause I expected that the innovations in Apache 2.0 would be sufficiently compelling that it'd drive mod_perl and PHP developers to "get on the bus." Sadly, that hasn't happened.

If you're serving static content or need to wire up an external application server (i.e. Tomcat via mod_jk), then Apache 2.0 is definitely the way to go. But the vast body of mod_perl modules on CPAN that work well with 1.x but don't with 2.0 does not bode well. Thread safe Perl and PHP development is really the key to Apache 2.0's success within that development community, it seems like it'd behoove RedHat, IBM and other vendors who've bet a lot on the open source integration market to spur this development.

Wednesday September 15, 2004

I'm fan of expressing business logic cleanly separated from display logic. It becomes especially important for managing CRUD cycles within an application. In j2ee-land, MVC with struts is the de-facto standard for doing those things and it works pretty well. However, in land o' LAMP, no such standard exists.

I'm currently looking at using Maypole with HTML::Mason. But it looks like (oy!) TMTOWTDI decisions are to be made there:

• Maypole::View::Mason
• Maypole::View::Mason (collision detection!)
• MasonX::Maypole

Tuesday September 14, 2004

I keep hearing from mercenary recruiters from Amazon about technology jobs requiring mod_perl and HTML::Mason knowledge (I tell 'em "No Thanks But Say Hi To Jon For Me" -- I doubt they ever do) . Hearing that one of the topics of conversation at this year's OSCON was the demise of mod_perl came as quite a surprise.

According to the Journal of jjohn, mod_perl's problem is that it's a CGI enabler (psychobabblisticly: it allows web developers to indulge in Bad Things). jjohn sez...

Now, it's not that mod_perl suck (it doesn't) or that it's not useful in some situations (it is), is just that MOST PEOPLE ARE SIMPLY DOING CGI CRAP. That's right, stupid CGI + HTML is a kind of universal Microsoft Fundation Class that works for programmers of all languages.

PHP is a terrible language. Perl has long suffered with the albatross of its highly syncretic origin and it's "organic design". However, PHP is a lot worse. It's a kitchen-sink language where crazy things like mysql routines and GD libraries are part of the core language. While objects were around in PHP 4, few PHP systems use OO style. To put a fine point on it, most of the PHP apps I've looked at are poorly written and a bear to debug.

And yet, PHP is frequently a better choice than Perl for web apps.

Besides the close association to the CGI aspersion, the big problem that Perl and mod_perl suffer from is that it's too damn easy to build templating web component frameworks. HTML::Mason, HTML::Embperl, Template Toolkit, HTML::Template, Apache::ASP and so on and so forth ("but wait! there's more..."). How many goddamned many of these do we need? The overlapping similar-but-different functionality borders on Not Invented Here neuroses. And so at a certain point, TMTOWTDI is a liability. As a programming language, PHP suffers from a similar TMTOWTDI blight. For instance, for file path values, there's pathinfo but there's also dirname and basename, which are completely redundant.

So if you're going to use a language and component system that sucks (and they all do), perhaps the thing to do is to use the one that sucks the least. Despite the OO additions to PHP language for PHP 5 (notably absent: real exceptions), it's a tough case to make that PHP sucks less than mod_perl. Maybe the PEAR libraries and the Smarty component system make it a little more usable. Maybe. Perhaps mod_perl's maturity and Perl's general usefulness inside and outside of the web environment is an enduring asset. But I'm not convinced one way or the other. Screw it! Use mono and ASP.Net!

OK, probably not.

In the meantime, I'm looking into combining Maypole and Mason to get a framework together to support the applications that MVC is appropriate for.

Monday September 13, 2004

I've been looking for a way to enable internationalization and localization ("i18n" and "l10n" as they say) uniformly for both Java and Perl code bases. I really like the simplicity of Java's ResourceBundles but it looks like a build tool will be necessary in order to maintain one master lexicon for it and for the Locale::MakeText Perl counterpart.

Currently reviewing Locale::Maketext::TPJ13 and java.util.ResourceBundle for some insight into how to keep it all together. Maybe there is a wheel that's been invented already here, if I have to invent it, it will be an ant task!