Blog Inaction

Larry O'Brien said it better that I could ever formulate it, so here you go:

I've been busier than some metaphorical thing in some metaphorical place where things are really busy.

And here is what kept me and is still keeping me busy those days:

Silverfight

The Register is running what seems to be a balanced review of (the yet to come) Microsoft Silverlight (2.0).

It seems balanced because you have ten pros and ten cons, which might suggest that adopting Silverlight is merely a matter of taste (XAML is attractive) or politics (like for the NBC Olympics). But I think that, if you ponderate the different pros and cons, you might end-up with a balance that leans on a particular side (I let you guess which one).

The availability of designers' tools that runs on the Macintosh platform will certainly be critical if Microsoft wants to entice them out of the Macromedia world.

Similarly, the heroic efforts deployed in Moonlight to make Silverlight cross platform will be key to the overall success of this, otherwise proprietary, platform.

As of today, here is how a simple example comparing Silverlight and Flash runs on my machine:

Yep, this is a big empty white box with statistics about how fast Silverlight renders it in the status bar. If Microsoft is serious about dethroning Flash, which I am not entirely convinced of, they will have to go past this kind of... emptiness.

Just Read: Implementation patterns

If you are an aficionado of formal pattern books, you might be disappointed by the latest book from Kent Beck. This book is more about a mentor sharing his experience than a succession of diagrams, code samples and rules for applying or not a particular pattern.

In this book, Kent clearly took the decision to engage the reader in a direct manner: there is no fluff, just the nitty-gritty. Just years of experience and experiments summarized in less than 150 pages. I leave to your imagination to figure out how dense the book is. It is sometimes so rich that I came to wish that a little bit of code or a neat hand-drawn schema could be added here and there, just to make a particular pattern more edible for a slow brain like mine.

There is an intense tension in this book: I have been fulminating after reading some takes from Kent where he states counter intuitive approaches as far as defensive coding is concerned. And then I reached the last part ("Evolving Frameworks") and it striked me: so far in book, Kent was not coding for public APIs. And it striked me again: Kent is a master, he adapts his way of coding to the context.

Let Kent Keck talk to you: buy this short book and listen to what he wants to share with you.

GMail Auto-resizing Rules!

Just a quick "thank you" to GMail's team for the new auto-resizing feature that makes the edit box use efficiently the available screen real estate.

This is good.

Cuil Geared To Hidden Success

It took me a while to realize this but Cuil, the new flashy search engine that randomly displays porn and has a name that looks like the French word for an unspeakable part of the male anatomy, bears in its name the inevitable fate of a hidden success.

Let me explain. To succeed on the webernets, you need two Os in your domain name. Amazon made the risky choice of a M-separated-double-A and they surprinsingly do well, so far. But anyway, if we narrow down the field to search engines only, it is pretty obvious that the double-O is de rigueur for success.

So what on Earth did happen to the guys at Cuil? Well, you see, the trick is in the pronunciation. It is pronounced "cool". Here you go! The double-O, that was hidden in the domain name, becomes visible when you say it.

Consequently, a hidden double-O can only lead to a hidden success. Which is not a failure by the way.

Tainted Heroes?

I am perplexed by the recent Microsoft's {Open Source} Heroes campaign.

Believe me, I am working very hard to fight any bias against the stuff that comes from Redmond (just by respect to the great people they have and the cool stuff they are cooking in their labs). But for this campaign I can not help but smelling something fishy. Maybe because I am (lightly) active in the .NET open source community.

Anyway, for this campaign, Microsoft was granting a Hack Pack containing a trial copy of Windows Server 2008 and Visual Studio 2008 to open source developers all around the world. How is that going to help the .NET open source community? I do not have the faintest idea. But I can easily see how it can benefit Microsoft, especially when the trial period is over and the hero needs to buy a license.

I do believe there are real open source minded people at Microsoft. I also believe they are not allowed to come anywhere near the marketing department. They probably wear a special dress and have "to ring bells to warn people of their presence" too.

My open source experience in .NET land, compared to the one I have in the Java-lala-land, suggests that the last thing Microsoft developers need is yet another tool-lock-in scheme. I find .NET developers deeply engrossed with their IDE, sorry, with the IDE, to the extent that any project that is not formatted and designed for Visual Studio is a real challenge.

A few years ago, I made the choice to use SharpDevelop for developing NxBRE. The first versions of this IDE were pretty rough but I was immediately convinced by the fact a version of SharpDevelop was not tied to a particular version of .NET. This establishes the necessary distinction between the CLR and the SDK on one hand, and the development environment on the other hand.

So what about our heroes? Open source developers do not need time-trialed (or not) vendor specific tooling. They need 36 hours days and 2 extra arms, something for which Microsoft can not do anything. They also need a community of like-minded developers, something Microsoft should stop smothering and start fostering.

Ouch of the day

This book is built on a rather fragile premise: that good code matters. I have seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use. However, I still believe that quality of code matters even if it doesn't provide control over the future. Businesses that are able to develop and release with confidence, shift direction in response to opportunities and competition, and maintain positive morale through challenges and setbacks will tend to be more successful than businesses with shoddy, buggy code.

Kent Beck, preface of Implementation Patterns.

GR8 JRB MOO!

As this screen shot shows it, Mercury does not care if I have a 24" monitor. It is going to be 200 pixels and not one more, sir! Get over it, sir!



Has anybody tested this page? In the same vein: has anybody tested Outlook Web Access 2007? It behaves like a web mail from the early 2000s.

Why do expensive enterprise tools feel they must be sub-standard in their GUIs? Why is that that as soon as a product is deemed enterprise grade, the game changes and it suddenly is all about paying six figure license fees for something an open source project would feel embarrassed with.

Will vendors react or do they just try to milk the cow until it decides to kick them away? Or does the cow care at all? Maybe the cow likes arid and painful tools so they feel enterprisey?

Moo.

YAJIHP

I am currently going through an interviewing spree, which is both exhilarating and exhausting. We have established a pretty nice routine with my colleague Josh: he asks smart questions and I ask stupid ones with my outrageous accent.

I think I should share some tips that could be interesting to anyone planning to go through Java jobs interviews:

• Java 5 is not new anymore. Maybe the Fortune 500 company you have been working for is still on JDK 1.4 (or before) but please do not call Java 5 "new". In case you do not know it, it is already in its end of life transition period.
• Do not oversell you. If you grant yourself 9.5/10 on Java knowledge or title yourself Senior Something, expect advanced questions on threading, concurrency or the JVM memory model. If you have not read Effective Java or Java Concurrency In Practice, either postpone the interview or consider refactoring your displayed proficiency level.
• No CS but no BS. We are not Google, so we will not question you on Java Data Structures and Algorithms. This said, we expect you to know the core collections and what they are good for, even roughly. Even if software engineering is closer to plumbing than computer science, this kind of basic knowledge is necessary.
• Out of your past box. If you have been consulting for a large corporate, you have certainly been exposed to the home-grown Mother Of All Frameworks. That is great but we do not really care because, even if you have use the Mother Of All Frameworks for eight years, it is disposable knowledge. Do not refer to it as an answer to the question we ask.
• Idle the IDE. It is great that you have been using this particular plug-in of this particular IDE but an IDE is a tool and there are many of them. Never ever give the impression that your IDE has been driving your development activity. It sure supports it, like with refactoring aids, but your first answer should not be "with this plug-in...".
  

I might update this post in the future after going through some more interviews.

Oh, YAJIHP? Yet Another Java Interview Hints Post.

De Majestic Car

I have no interest at all in cars: they are boring transportation means that make me lose my time and sometimes my temper.

But I knew that my neighbor had this in his garage:

And since he is selling his place and will move soon, I figured out that this week-end was a good time to dare asking a discovery tour!

Needless to say that, even without flux capacitor or Mr. Fusion, my eyes were all sparkling at the silver gray splendor, and that was not all due to the stainless steel body.

Life is like this: one achievement at a time. "Get acquainted with a DeLorean" is now ticked off my list.

Gnirps is Bliss

Four years ago, I was spending most of my day time job helping people moving away from proprietary J2EE application servers in favor of the JBoss platform. It was such a relief on many aspects: financially, as millions of Euros of per-CPU licensing were saved ; support-wise, as the typical three-level-of-escalation inane support was replaced with a geeky efficient one ; and technically, as closed-source monoliths were replaced with the elegant micro-kernel architecture of JBoss. Of course, there were glitches, like the Unfixable (universal?) Class Loader, which were compensated by great features (like the dynamic proxy client invocation stack). And better, way better than any documentation, the source code was always accessible.

Nowadays, I am spending most of my day time job finding ways to part from JBoss in favor of lighter approaches like Spring and Tomcat. And it is a relief because, despite the thin nature of its kernel, JBoss turned into the tightly-coupled bloatware J2EE seems to mandate as the ideal server platform. I find very ironic that what was hip and enjoyable four years ago, has turned into such a subject of pain and wrath today. But yes, there is no doubt that thinner, simpler and lighter is the way to go. Scarcity makes code better. Loose coupling makes platforms better.

So what is next?

Let us pretend we are in 2012. SpringSource has been bought by ${boring-company}. Like Marc Fleury, Rod Johnson came back to its true passion: music. They might even have founded a band together (name is: La Cucumber Picante). We are now moving away from Spring to Gnirps, a project that has been founded by some dissidents after ${boring-company} decided to change the cover image of the love book.

Gnirps is both a language and a framework, which runs on the JVM (there is still no better cross-platform execution environment). The language is a fusion of Nice and Einstein, with concurrent and distribution concepts borrowed from Erlang. The framework is still heavily based on Spring, which has been freed from all the J2EE compatibility layers and classes. It is now mainly focused on OSGI and SCA, and has kept only one way of doing things for which Spring used to support three or four ways back in 2008.

Aahh, finally, thanks to Gnirps, life is such a bliss.

Wait. Until the new and improved version of...

Breaking The Pipe

I needed to generate broken pipe exceptions on one of my server. But how to do so without resorting to fiddling with a browser?

I have written the following, which does the trick and consistently generate at least one broken pipe exception when it hits the passed URL.


private static void pipeBreaker(final URL url) {
for (int i = 0; i < 50; i++) {
try {
final HttpURLConnection connection =
(HttpURLConnection) url.openConnection();

connection.setReadTimeout(1);
connection.setDoOutput(false);
connection.setDoInput(true);
connection.setRequestMethod("GET");
connection.connect();
connection.getInputStream().read();

} catch (final Exception e) {
// ignore
}
}
}


All this code does is give the server the impression it is going to drain the response, but times out very quickly and does this in a repeated manner.

That is how I break my pipes. Now, how do you break yours? Do you have a better way?

Generate, Then Degenerate?

My friend Celso Gonzalez and some guy named Scott Ambler (just kidding Scott, this is an old Marc Fleury joke) have released a thought provoking article in the June issue of Better Software named "Agile Model-Driven Development".

Despite using formal models as bootstrapping artifacts for TDD, so it can scale or survive team distribution, one key aspect of AMDD resides in the skilled transformation that happens in the generation chain.

This is a subject dear to my heart. My very first published article was about a model to code generation tool and I had the chance to initiate and gravitate around the roll-out of a pragmatic MDA framework (notice the emphasis on pragmatic: I have not drunk the MDA kool-aid).

To make this skilled transformation happen, you have to capture architectural decisions so a model will translate in an application that is layered according to some standards.

But what happens after that? Developers' hands still have to run over their keyboards and, as business decisions will come and go, they will be likely to take shortcuts and alter the original architecture vision to satisfy some imperious needs. From there on, all bets are off... The original architectural intention will be compromised sooner or later. What was generated will degenerate.

We do have some pretty nice analysis tools to help us ensure that code will keep on satisfying pre-defined coding standards, will avoid common bugs or will shoot for acceptable levels of test coverage.

But what about architecture?

The June issue of Computer talks about a tool, named SAVE, which could help... saving the day! SAVE, an acronym for Software Architecture Visualization and Evaluation, started as a Fraunhofer-supported thesis in 2004 and looks really promising.

I have tried to find the Eclipse update site of the SAVE plug-in but to no avail (a generic term like "save" does not hint Google much about what I am really looking for).

Does anybody know where to get this tool? And does anybody know if it is possible to run SAVE in the build process, like other code base analyzers? Indeed, I think it is important that any IDE tool has a counterpart that is usable at build time.

Architectural verification sounds tasty. Is it too good to be true?

JCR Transport 2.0.0-M1 Released!

I am happy to announce the first milestone release of the upcoming JCR Transport for Mule 2.

Though there are still open tasks in the roadmap of the 2.0.0 final release, the transport is already able to support all the features of the 1.x branch.

Alongside the specific JCR XML schema for the configuration, you will also appreciate the improved support for streaming.

Enjoy the full distribution or the Maven artifact. And please report glitches to JIRA.

Its name is JBound

I needed a little tool to torture with boundary values the public domain model objects of a project I am working on. There are excellent test generator software like Jtest or late AgitarOne, but I needed something really scaled down that would act as a complement to existing unit tests.

There came JBound, a mere six classes utility, whose sole purpose in life is to inject unfriendly values, like extremes and nulls, in the constructors and setters of a class. It also calls getters and standard methods like equals, hashcode and toString, just to be sure that the created object is not completely ravaged inside.

Using JBound is easy:

    @Test
public void fullyExerciseBeans() {
    JBound.run(new Exercises() {
        {
            forClasses(MutableBean.class, ImmutableBean.class);
        }
    });
}

By no means, JBound should be used as an artificial mean of creating high test coverage. You still need to write sensible tests, especially for methods like equals, if your object identity is strictly controlled. Moreover, it is debatable if JBound is useful for non-public APIs, as internal classes are less prone to be exposed to end-user abuses.

Is JBound original? Not at all! But, as I have been baffled by the amount of glitches this tiny tool has found in my project, I thought it could be interesting to share it. Maybe JBound will prove useful to you to. Maybe you will even feel you can make it better. If this is the case, please explain me how and I will welcome you aboard!

Oh Management

Sure enough, the fact that software industry is crippled by technologically-challenged project managers is mind-boggling. But I have been recently flabbergasted by the shameless disclaimer of such a manager who, in the middle of a crucial meeting directly concerning her project, announced: "Sorry, I am not technical". Hence all this discussion was sheer geeky mumbo-jumbo to her and she could not grasp that her project was going astray.

This is sad. Not even funny. Just plain sad. Direct management of software developers can not be that clueless.

But I have prepared my childish revenge. Next time a manager will ask for estimates, I will pretend not to understand and will feign the following excuse: "Sorry, I am not managerial".

A Zephyr is blowing

My attention has been recently drawn to a new tool named Zephyr, which dubs itself as "The Next Generation Test Management Tool".

My very first impression is that the Zephyr team has done a great job putting on-line a complete workable demonstration environment. This is great to quickly delve into what the software is really about and getting assured that "it works on my machine", which is crucial nowadays as the corporate IT landscape is much more diverse than the traditional Windows + Internet Explorer desktops environment it used to be.

As far as platforms are concerned, Zephyr seems to run "on standard Windows desktop" (sic). I reckon they meant "Windows server", though I have seen production systems on desktops! Hence, I could not test the ease of install nor investigate the technologies used. Neither could I estimate its capacities to scale or work across a WAN.

The second impression is that the graphical interface is compelling, if not mind blowing. These guys did a great job of making arid forms filling an almost bearable task. Indeed the tool is brainy enough to avoid manual data copying and is able to pre-fill or filter data according to the context of the task.

Zephyr is also smartly aware of agile principles, as the notion of Scrum's sprint is hard wired into its dashboards. And dashboards is where Zephyr really shines. I love dashboards of all sorts, even complicated ones. But Zephyr's are truly awesome:

The dashboards and workspaces are tailored to the user profile, which makes navigation easier because you do not have to filter out a lot of non-relevant features. The tool does a great job at integrating and aggregating all sorts of QA related data, including the ones coming from defect tracking systems.

And I think this is where one of the challenges Zephyr will face resides. It currently connects to Bugzilla only, but there are many others out there. Moreover, companies have developed an habit of using their defect tracking system as a management tool for QA. How is Zephyr going to convert these users to this new platform? How disruptive for the practice would it be to move from the use, say, of JIRA to using Zephyr?

The thing that really truly bugs me about this tool is that it does not go further than the traditional "QA monkey" work, in which a human beings are presented a list of actions to perform and report the results thereof. That a tool with an agile penchant does not incite people to evolve their QA practices to more automation is flabbergasting. Where is the Selenium integration? Where is the FIT connector? Though manual QA will never be fully replaced, at least supporting a blend of automated and non-automated tasks would be a great first step. What the software industry really needs is lazy QA teams who mainly use their brains to work on automating their tasks!

To finish on a positive note, Zephyr takes integration seriously. It exposes JSON and REST APIs, the assurance that if you opt for this tool, you will not end up with yet another instant legacy application. This is something I would like to see more in so-called enterprise grade applications!

If you are looking for ways to improve your QA management, I can only recommend that you get Zephyr now, as the free 3 users licenses will allow you to see what this "Next Generation Test Management Tool" can do for you.

UPDATE 31-MAY-2009: Zephyr version 2.5 now comes with test automation features that include the ZBot technology.


ZBot allows you to execute testing scripts on remote machines and aggregate all results back in Zephyr. This is a great move, which addresses my concerns about the lack of support for automation in the previous releases.

Best. Game. Ever.

Ok, so I am an old timer and there are plenty of great games nowadays, so it is probably no the best game ever.

But Carrier Command is a true jewel of playability combined with a perfect mix of strategy and action. This is rare. Moreover, it the only game I have played 11 hours uninterrupted: it was 20 years ago and I still remember this all-night session!

Article: Building Content Oriented Integration Solutions With Mule and JCR

The Server Side has just published my article presenting all the features of the JCR Transport for Mule in action!

It is called: Building Content Oriented Integration Solutions With Mule and JCR.

Just Read: Dreaming in code

Dreaming in Code is a scary book, the kind of book that makes you wonder if it is really wise to keep pursuing the vain ambition of writing software. By telling the storing of Chandler, an open source project aimed at revolutionize Personal Information Management tools, the author takes us deep in the moving sands of software development.

The most daunting aspect of the book is the following: if the best developers in the world gathered together under the supervision of a level 5 leader (Mitch Kapor) struggle to build software like the rest of us mortals do our pesky daily jobs, then is there any hope?

Maybe hope is in the unintentional software we build while intending to build something else? We got Ruby on Rails, Blogger and Flickr that way, after all.