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!