Win a MacBook Pro!

Short version: design our new company logo and win a MacBook Pro!

Longish version: we’re starting a new OSS-based company. We already had our fair share of sleepless nights, spreadsheets and planning (with more facing at the horizon, you’re never done working!), now it’s time to think about decloaking, which requires a nice web site and, of course, a logo. We have been talking with a few local agencies and we gave it a shot ourselves, but lately we figured out that what we really want is being a bit disruptive, give the Lazyweb a try and see if we could find over there the cool visual identity we’re looking for: after all, on the Internet, the world is really a small place.

When thinking about the prize to award, the MacBook Pro became quite an obvious choice: given how much we’re drooling and dying to get our hands on one of these babies, we figured out that we wouldn’t be alone in considering Apple’s newborn child as cool stuff, worth a few hours sketching out a nice and creative idea. So, it’s your turn now: go read the brief, the contest rules and use your imagination!

Security control nightmares

A side effect of being a roadwarrior is dealing with a number of security checks on a daily basis. I’m getting used to airport security, which typically require waving my ID at least three different times to three different people per trip (I already had to tape it together a couple of times). I even learnt to live with the most obnoxious TSA controls in the USA (what? taking my shoes off?), no matter how getting fingerprinted and photographed every time doesn’t make me feel that welcome after all.

While airport security is clearly understandable, what’s bugging me lately is corporate controls: customer visits typically start with the reception desk nightmare which requires thorough understanding of a number of obscure security procedures that will make you feel like being on candid camera or acting in a Monty Pithon sketch (apart from the vikings choir, sometimes). The typical setup goes more or less like this:

  • you can be greeted either by a nice and professional looking receptionist. The nicest and professional she is, the highest the possibility she has no clue on what you should do to be let in;
  • as an alternative a grunting security guard with a clear steroid addition problem will welcome with a “myheah?” as his most sincere form of flattery. The bigger the muscles the highest the possibility he has no clue on why he should actually let you in since you clearly look as a terrorist being hired by the competition to steal corporate secrets, ashtrays and paper towels from the toilets;
  • next step is introducing yourself, shouting your name, affiliation and host through a shielded bulletproof display with enough acoustic isolation to let anyone behind it sleep in peace during a carpet bombing attack. The various misunderstandings can get really funny after a while, but usually you end up hoping for the best, figuring that Mr. Jones who’s picking up the receptionist call will eventually be able to understand that Mr. Rakeltrino is actually the Rabellino guy Ms. James he’s waiting for;
  • once the reception staff understands that the only one alternative to you camping on the premises is actually letting you in, you’re asked to show your ID, fill a form, authorize the outsourcing security staff to sell your name to a list of known spammers and wait for poor Ms. James to show up, tell the receptionist that yes, she’s actually the one waiting for you and that, yes, you is really you and she’s supposed to meet you, as per the three different emails and five forms she had to fill to put you on the list.
  • Eventually you’re allowed to enter the building, while the security guard looks strangely at you muttering something like “you won this time, but I’m looking after you”. Once you do this every day for a couple of years, sneaking in an exclusive Hollywood wedding will be a piece of cake.

Now, while the above list can be somewhat exaggerated and humorous, the following one is for real. One the places I visit most is home of one of the most famous BigCos in the IT field (sorry, I won’t name the sinner): these guys did invent possibly the most used technologies in the enterprise field, and have some serious products when it comest to digital identity, from directories to RFID solutions. Every employee of the company has a smart-card based badge which allows them to enter their sites anywhere in the world, head to the first thin client available, insert their ID and have their personalized desktop display popping up automagically in no time flat.

Visitors, however, are a totally different story: every time I get there, and I do get there pretty often, sometimes as much as two-three times a week, I’m requested to fill in a paper form which clearly comes from scissor-cut photocopied paper. I’m required to write down who I am, what’s my affiliation, who’s my host and what is my ID number, expiry date and issuer. Plus, I’m required to agree on specific T&C about my personal data being treated (uh? shredded, I assume, there’s no much you can do with that lousy piece of paper) and sign. The whole process takes at least five minutes and gets bothersome in no time flat, expecially when you have to do it day-in day-out, and sometimes twice (well, it’s not security’s fault if you went for a sandwich for lunch).

I asked a couple of times if it would have been possible to have one of those pieces of paper so that I could prepare a set of photocopies which I would sign in original every time. No luck: they’re not authorized to have those forms leave the building. I then questioned a few guys I know who are full time consultants over there, and they confirmed that the same procedure applies to them as well, no matter the fact they have outlived by far the typical security staff turnover: they know part of their job is filling in 200+ forms a year and they managed to just live with that. I wonder how much it will take to me to get over it: thinking how these guys have some of the most advanced software systems in the world and how actively they promote digital solutions and paperless office while forcing stupid forms down their visitors throat just makes me sick.

Guys, if you read me you know who you are: this is an official proposal to build you some piece of software that will make you look a bit less lousy in front of your customers. (Almost) for free. :-)

Wild pipeline API thoughts

(Note: this is a long post, and most certainly the syntax highlighter will make it look funny on your aggregator. You might want to visit the web page to get a better grasp of it)

In 2006 it will be roughly 6 years since I started juggling with XML pipelines. As my few fellow readers might remember, I’m starting to hate XML languages with a passion, but once again this doesn’t mean I don’t like XML anymore and, even more, this doesn’t mean my love for Cocoon is fading. I’m still convinced that pipeline-based processing is the way to go: the road to complex yet maintainable results clearly goes through decomposing the problem in a set of easy step to be performed sequentially and incrementally.

I’m also still convinced that XML is here to stay, for a number of valid reasons, yet I think that the overall scenario has changed since the original Cocoon vision. XML is possibly the most important player out there, but didn’t manage to pursue its Borgish ambition to assimilate everything else: there is a growing party of people who are realizing how the idea that everything could (and should!) be represented as XML is pretentious at least, and stupid at most.

This leaves us, however, with two important concepts: we need pipelines, and we need to steer clear of XML when it doesn’t make sense. To achieve the first goal what we need is a generic, easy and intuitive pipeline API. And it should be a programmatic API, because we need pipelines everywhere, and we need them to be easy enough to grasp for the average programmer (think Facade on steroids): what bugs me with the currently available pipeline API is how they tend to be clumsy and counter-intuitive. Think SAX as the perfect example of why we need a more generic and easier pipeline API and machinery: in the SAX world if you want to pipe events from foo to bar you just do this:

[java]
foo.setContentHandler(bar);
[/java]

Things however get complicated when baz and boo enter the picture. Now you have to:

[java]
baz.setContentHandler(boo);
bar.setContentHandler(baz);
foo.setContentHandler(bar);
[/java]

Which, counter-intuitively, means building the pipeline starting from the last component and going all the way to the first one. In addition to that, those statements are usually interspersed on code that contains other statements such as creation and configuration of the various pieces. Moreover, from a functional point of view the above code could be rewritten as:

[java]
foo.setContentHandler(bar);
bar.setContentHandler(baz);
baz.setContentHandler(boo);
[/java]

Which, even if it looks better from the user point of view (the pipeline steps are now ordered) it has no relation with the underlying model. In fact, you could actually obfuscate stuff when considering switching jobs:

[java]
foo.setContentHandler(bar);
baz.setContentHandler(boo);
bar.setContentHandler(baz);
[/java]

The above lines will still work as expected, but I dare anyone to understand who sends events to whom in a real life scenario where those statements might be ten lines away from each other. To me, this just doesn’t sound right.

Now enter Cocoon and see how, in its declarative sitemap, it shines from the user’s point of view:

[xml]

[/xml]

This just sounds right: pipeline steps are listed sequentially, as they should be, and everyone now understands who’s first and who’s next. But, heck, this is a domain-specific language by all means, moreover written in XML. No way this stuff can be reused in different context, and the “strong typing” nature of the Cocoon pipeline (where everything starts with a Generator and ends with a Serializer, assuming not only that the whole world will talk XML but actually that the whole world will talk SAX) makes things even more difficult.

Finally, consider what the Unix genius have brought us:

[code]
$ grep index.html access.log | awk ‘{ print $1 }’ | sort | uniq | wc -l
[/code]

I think there’s no better comment for the above solution than this:

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” (Antoine de Saint-Exupery)

Expressing the pipeline concept with just one character (the | sign) is a clear indicator of what could be achieved when thinking about simplicity: the concept is powerful, yet the user space view of it is as simple as it can get (admittedly, a bit opaque but it doesn’t take much to get used).

So, what do the above snippets bring to us? In this quest for a simple pipeline API we learn that simplicity is key and that the principle of least surprise suggests that the pipeline declaration should happen at once and in an ordered way. Sticking to Java, this leaves us with something like

[java]
pipeline.setupPipeline(List components);
[/java]

or (uglier, but sometimes just effective enough):

[java]
pipeline.setupPipeline(PipelineComponent[] components);
[/java]

Actually I’d much rather see the setup happening during the construction phase, but for the sake of interface design I’ll leave the convenience method for now. This means that our Pipeline interface becomes something like:

[java]
interface Pipeline extends PipelineComponent {

void setupPipeline(List components);

void start();

}
[/java]

Easy and effective: whoever knows the pipeline concept should be able to grasp how this API works in minutes. We need to talk about the PipelineComponent interface though, and this is related to the next wild idea: pipeline machinery.

(warning: shaky ground ahead, this is the part which needs *much* more thinking)

In the OO world things aren’t quite as simple as in a CLI environment, where all you have are basic pipeline contracts such as “whatever byte streams comes from the left side is pumped to the right side”. We have objects here, and I don’t want this generic pipeline API to be strongly typed as in being able to work just with – say – SAX events or other XML gibberish. What I want is an API which is able to work with many formats in a way that’s transparent to the user: this means that the various pipeline stages should be able to express their contracts in terms of required input and output format. It’s up to the pipeline machinery providing adapters and bridges so that, say, a pipeline component working with SAX events might be able to cooperate with another component working with streams. This could be accomplished either through some kind of PipelineDescriptor, with annotations or just through different interfaces: whatever keeps things simple, makes me happy.

Another nice solution comes (again!) from a chat with Sylvain reminding me of the IAdaptable approach in Eclipse. This solution fits like hand in glove with a world of interchangeable and heterogeneous pipeline component stages, even though I have a few concerns thinking about the added complexity for pipeline component writers in implementing an Adaptable strategy: if the first and foremost objective of this API is simplicity, then writing components should be as easy as possible.

Anyway, the final outcome of all this would be something like this during the pipeline assembly phase:

[java]
PipelineComponent current;
PipelineComponent next;

if (next.accepts(current)) {

current.setNext(next);

} else {

PipelineComponent adapter = next.getAdapter(current.class);

current.setNext(adapter);
adapter.setNext(next);

}
[/java]

With this mechanism in place, in theory, the pipeline is much more versatile: sticking to the XML world it would be possible to build pipelines using whatever mix of SAX, DOM, StAX, AXIOM and YouNameWhat. Moreover, it would be easy enough to provide adapters to the stream world, tees and nested pipelines (there is a reason for Pipeline to extend PipelineComponent after all).

Of course I expect the pipeline machinery to do much more than just adaptation: caching, logging, monitoring and management are vital to the pipeline deployer. But the real point of this effort is, once again, simplicity. Once I’m able to do this:

[java]
// Get the default pipeline implementation
Pipeline pipeline = PipelineFactory.getPipeline();

// Set up the pipeline with an array of PipelineComponents
pipeline.setupPipeline({reader, transform1, transform2, streamAdapter });

// grab the InputStream from the latest component
InputStream result = streamAdapter.getInputStream();

// start processing
pipeline.start();

// enjoy results
is.read()…
[/java]

or this:

[java]
// This time we use SAX events straight away
pipeline.setupPipeline({reader, transform1, transform2 });

// connect to the pipeline result
transform2.setContentHandler(myContentHandler);

// start processing and handle events coming in
pipeline.start();
[/java]

or, why not:

[java]
pipeline.setupPipeline({reader, transform1, transform2 });

anotherPipeline.setupPipeline({something, pipeline, somethingElse});

anotherPipeline.start();
[/java]

Then I could do this from within Cocoon:

[javascript]
function handlePage() {

var pipeline = cocoon.newPipeline({ file(“something.xml”, xslt(“foo.xsl”), forms(), i18n() });

cocoon.sendPipelineAndWait(pipeline);
}
[/javascript]

but also, when Cocoon is not an option:

[xml]
< %@ taglib uri="http://jakarta.apache.org/taglibs/pipeline" prefix="pipeline" %>
[/xml]

Conclusion: if you managed to survive this far, well, congrats and thanks for sticking: it’s been a bumpy ride and there are certainly a ton of rough edges, but the more I think about it, the more I’m convinced that a simple, painless and easy to use Pipeline API could be an invaluable tool. I’d love to use the incredible experience of Cocoon in building solid pipelines to factor out a new and fresh approach that allows anyone to enjoy the power of pipeline-based processing: it’s not going to be easy, but the goal is indeed worth the effort. Now, finding the time to make it happen is a totally different question…

A scary morning

Since a few days ago my PowerBook has been behaving strangely, with weird hisses and whistles coming from below the keyboard and an “ozonish” smell that I never noticed before. This morning, my fellow companion started to misbehave: the screen went flickering after a couple of hours spent working and eventually the whole thing froze. Upon successive reboots, things were just getting worse and the lifetime of my computer would decrease from ten to one minute.

This is not exactly what you’d call an ideal situation: first of all I couldn’t figure myself buying a new G4 PowerBook when in a matter of days we should be getting news from Steve about the long-awaited Intel shift. Then, when I started calling Apple shops around here to see if I could get it fixed, maybe getting a spare in the meantime, I noticed that January 2nd isn’t exactly a working day for Christmas-exhausted stores, with no one answering my frantic calls.

I decided to switch to friends, among others managing to bother Pier all the way to Japan (thanks mate! I owe you a Sashimi) and eventually finding a friend of a friend who gave me the right hint (yes Enrico, that’s you: just name the restaurant and be my guest): what seemed to be a quite typical hardware issue turned out – well, hopefully at least – as a software glitch.

Apparently the overheating symptom can be caused by the OS misreading sensors and mismanaging fans: he suggested to start with the Tiger DVD, keep the computer running for 30 minutes or so and, if all was well, proceed with an OS reinstall. Well, it took me the best part of my morning and a good deal of bravery to see the progress bar while fearing everything could break any second now, but in the end all went just fine. My PowerBook is back, even though it’s definitely backup & update time, and I feel much relieved overall: I could imagine a whole sleeve of better ways to start 2006, though.

Nice EJB3 introduction

If you, like me, have lost interest long ago in the whole J2EE stuff and don’t feel motivated enough to skim through EJB3 specs to see if there’s anything worth to look at, don’t miss what Filippo has been doing lately. In his three last posts (with more coming), Filippo (among others, co-founder of the Milano Java User Group) skims all the latest and greatest from the EJB world with a very clear and nice approach: good stuff indeed! Makes me want to play with EJBs again (well, almost….).

Disclaimer (and shameless plug, as well): in just a few days Filippo will join our team. I’m happy and proud of having him on board, helping us and our customers build solutions around the most interesting technologies around. Welcome, Filippo!

No one got fired for choosing IBM…

… but I should have been, and actually I might well be, deservingly so. Three out of four IBM machines (X335 and X336) crashed horribly during the past months. We are still recovering from two X335 frying the SCSI controller, which in turn b0rked the disks to no avail, and I have been stupid enough to buy a new X336 where we are currently running our main server. The sucker, barely two months old, has been hit by scattered hangs from the beginning, then started crashing every night and is now kernel panicking every few hours, muttering about something wrong during tcp_retransmit.

Thank god (and Emilio, who reminded me about it… my sysadmin skills are so rusty) we have the “panic=30” kernel option which should at least have the sore amount of crap come back to life by itself when stuff hits the fan, however I’m curious to see when we’re going to have the immense privilege of IBM support contacting us, after we called them last thursday. So far, no sign of intelligent life from the other side of the pond apart from a “we’ll call you back shortly” from trained monkeys, so it’s time to wrestle with backups and service migrations.

In any case, rest assured that I’m not going to buy even an IBM mouse pad for a long while. Dear Lazyweb, any suggestions for reliable 1U, 1/2CPU servers with decent support?

Update: the part got replaced today. It took IBM only 8 days and 3 hours to solve the problem. They say the delay was caused by our dealer failing to communicate the correct serial number. 8 days and 3 hours. That’s 195 hours, or 11.700 minutes. Am I supposed to believe such crap? Next time I bet it will be the tooth fairy to blame.