Boldly Open

Thanks to the great guys at Jetbrains, Apache committers are entitled to a free IntelliJ IDEA license for their Open Source development. Today I found my license in the inbox, and I rushed to an install: I remember trying out Idea a few years ago and being more than impressed at how cool the product was.

Mind you, I'm not an IDE guy: possibly the most used software on my powerbook is Terminal.app and Vim. Vi is just faster than everything else (Emacs lovers don't need to comment, I really did try to use it, but it just gets way too mych on my way): since most of my time is spent fixing problems and finding issues on other's code, I'm much more productive with ten fingers and a shell rather than with a mouse and a (bloated?) IDE. However, IDEs are unvaluable when I'm starting from a clean slate and I have to actually code some stuff: whenever I start missing code completion, TDD tools, remote debuggers and the like, I understand it's time to go grab a coffee while Eclipse starts up.

With my fresh Idea license, I started playing around with the IDE. After a few hours (and an overly annoying amount of "force quit"), my first impression is that Idea is definitely cool stuff, but in the past few years Eclipse has played the catch-up game pretty well: I would say that Idea is still ahead of the pack (refactoring is sweet, code folding works well, the UI is snappy despite being Swing), but they basically don't have the killer features monopoly anymore. So far I tend to say that Idea outperforms Eclipse more or less on everything, but only of a slight bit. Whether that bit is worth the price tag is still something to consider: for now, I'm stuck in trying to make Subversion work, then I plan to give Idea a serious try trying to accomplish some of my geeky objectives for 2005.

Se mi serviva un'ulteriore riprova che i classici vanno fatti leggere con moderazione durante l'adolescenza, questo libro mi ha definitivamente convinto. Baricco mette in prosa una traduzione moderna dell'Iliade, testo che ho discretamente odiato durante il ginnasio al punto che di fatto mi limitavo a sapere che parlava della guerra di Troia e che a un certo punto c'entrava il cavallo di legno. Forse ma forse mi ricordavo qualcosa su Achille, Ettore e Patroclo, ma allo stesso modo in cui ricordo che in greco ci sono l'aoristo e il duale o che l'orbitale P2 ha la forma di una scamorza (o era il P1? Giusto per fare capire a quale livello si studia scienze al liceo). Però sono tuttora in grado di recitare a memoria e in greco le prime righe dell'Encomio di Elena che mi ero preparato per la maturità: direi che è un evidente indizio di arteriosclerosi incipiente.

Oh, d'altra parte io sono sempre stato per il massimo risultato con il minimo sforzo: dopo che avevo capito che il professore di italiano non aveva cuore di interrogare la gente su Dante, ho pensato bene di toglierlo dall'imbarazzo e andare volontario per tutto il liceo sulla Divina Commedia. Complice la sua lentezza, da una interrogazione all'altra avevo al massimo uno o due canti da preparare, e a momenti ne sapevo più io di lui: una buona memoria e una discreta faccia da culo facevano il resto, e mi conquistavo il mio sette e mezzo declamando a memoria terzine dantesche. A tutto c'è un contrappasso però: non chiedetemi cosa sia successo nella letteratura italiana dopo l'Ariosto: nonostante la maturità classica, penso che confonderei con leggerezza non solo Pascoli e Carducci, ma probabilmente anche Cecco Angiolieri e Moravia.

Ma torniamo al libro: ben scritto, anche se come per tutti gli autori "televisivi" nel leggerlo ti figuri Baricco a leggerlo alla sua maniera affettata, il che comporta una certa sensazione di fastidio. Sulla storia c'è poco da dire, è immortale quanto basta, e Baricco ne evidenzia alcuni punti estremamente interessanti e che fanno pensare. Come minimo, direi che "Omero, Iliade" dovrebbe diventare una alternativa ufficiale al bignami di turno, ma se si vuole capire perché a distanza di millenni stiamo ancora leggendo i versi di un vecchio greco cieco, beh, il libro di Baricco è un ottima risposta.

... and counting. This is another snippet of my life that went down the drain thanks to Microsoft (not to mention how my candidate sleepy snowy sunday afternoon turned into a living hell).

Today my parents asked for some assistance, again due to their smart card woes I've been muttering about already. This time they had a brand new, and assumingly supported, SC reader, but they were unable to install it. I logged in via VNC and started uninstalling previous versions of various softwares, in order to start from the cleanest possible situation. I was asked to reboot, and I did: in a couple of minutes my parents were on the phone screaming about a BSOD. The computer wouldn't boot anymore, all we got was a STOP error with a very informative "c000021a" cause.

From there, we were stuck. Safe mode boot was unavailable, and there was no way on earth to obtain even the simplest command line to attempt a manual rescue. Browsing the web brought a whole wealth of panicking information, not to mention a couple of official Microsoft statements along the lines of "er... yeah, you know, we must have screwed something up with dependency management: would you mind reinstalling the whole thing? Sorry about that and, by the way, where do you want to go tomorrow?". Well, I don't know where I want to go, but I'm pretty certain on a number of places I would like to send the whole Redmond team responsible for such a gross mistake: isn't it time you just start behaving like a normal operating system that dumps on a console (no, COM2 doesn't qualify, sorry) what's going on with the boot process so that diagnosis and rescue can be available even to those poor guys who don't happen to have a lab on their desk? Or, even better, isn't it time you make sure that a mundane task such as removing software isn't allowed to screw the whole computer making it not only unusable but even unable to boot?

I'm actively looking for a country in the world where I could sue companies for wasting my time in such a stupid way. If anyone happens to know, I'd love to share thoughts, real estate estimates and immigration plans.

I'm doing some Swing stuff in my Copious Free Time, basically for fun but also to scratch an old itch. I'm committing myself to high percentages of test coverage (ideally 100%, but I'd sign up for everything above 80%), and this is a good exercise for my rusty Swing skills.

Tonight I spent more than a fair amount of time trying to test a JTextField on which I'm attaching a custom key listener (I want it to accept just digits): of course setText() doesn't work since it bypasses the key listener code, so I figured out I had to basically emulate the keyboard behaviour. From a first cursory look I thought it would be as easy as sending the key events to the widget via Component.dispatchEvent(), but I found out the hard way that this wasn't the case, since my widget wasn't receiving anything. A googling session showed me what my mistake was, and in the end I had to enter the treacherous hallways of AWT focus management, having learnt that a Component won't receive any key events unless focused (well, I assume that's just fair enough).

Unfortunately I have been unable to programmatically set the focus on the component I wanted to test: a Component won't receive any focus unless it's displayable, and setting displayability on a widget by hand is not an easy task. Ultimately I had to pack my widget into a frame in order to have AWT do the gruntwork for me: the good news is that my textfield works as expected and my bar is green again, but still I don't like having a Swing window popping up on every test run. Sure, I could probably use headless AWT to hide it, but if any Swing savy geek drops by this entry I could definitely use some assistance in solving this issue in a better way.

Update: thanks to Adrian Sutton I have a much better solution now. The only problem with Adrian's solution was the focusManagerIsDispatching field belonging to AWTEvent and being private, so the revised solution is:

    public void simulateKey(KeyEvent e, Component c) throws Exception {
        Field[] fields = AWTEvent.class.getDeclaredFields();
        for (int i = 0; i < fields.length; i++) {
           if ("focusManagerIsDispatching".equals(fields[i].getName())) {
              fields[i].setAccessible(true);
              fields[i].set(e, Boolean.TRUE);
              c.dispatchEvent(e);
           }
        }
     }

Thanks so much Adrian!

A few notes to self to learn from my own mistakes and avoid spending endless hours next time trying to clean things up when you're close to production. Some of these rules are of course already part of our internal Cocoon development process, but I thought I could share them online and see if someone has better approaches to suggest to a few simple but cumbersome issues when starting a Cocoon-based project:

• Don't even start any development before customizing the Cocoon environment for the project needs. This boils down to "cut the crap": be ruthless in excluding blocks, don't enable any of them "just in case". Unnecessary stuff will clutter at best and bite you at random times in most cases. Do version-control your local.build.properties and local.blocks.properties.
• Using Cocoon's xconf tool, have a set of files ready to further edit the Cocoon configurations, cutting even more crap. The block system still has some quirks, and you end up with unnecessary stuff such as JMS or XSP when you don't need it and really don't want it around.
• Always take relocability of your Cocoon application into account, from the very beginning of your project. Your application should work from the webapp root (mounted as /), under a context path (/whatever) or as a sub-sitemap (/whatever/the/user/wants). This means that you should always pass a "mount-point" attribute within your rendering pipelines and components, calculating where your application has been mounted, and building paths accordingly. Unfortunately the current Cocoon API will only tell you the full request path and the URI handled by the sitemap, so you need to mangle those data by substracting (string-wise) the sitemap URI from the request URI in order to obtain the path you're looking for. That is, if your sitemap is mounted on /context/foo and your request is for /context/foo/bar/baz, the sitemap URI will be bar/baz, while the data you need is actually /context/foo to build your links properly: yeah, that gives me headaches as well, and I have an overdue patch to provide this location in an easier way. But please tell me if I'm just missing an obvious solution.
• Don't ever rely on Cocoon samples for functionality. If you need any feature such as XSLTs, JS files or sitemaps, import it into your project right away. Do it now, or you will regret it in the future. A lot.
• The above note has a special meaning for form handling. The impressive and powerful Cocoon Forms resources are part of the samples. Since you probably want to reuse them, to avoid any temptation, just package everything up in a JAR file and use resource://whatever as your $resources-uri parameter in your forms stylesheets. the following Ant task might come handy:

   <target name="pack-cforms-resources" depends="jar"
      description="package all the CForms resources">
      <jar jarfile="${dist.dir}/cocoon-forms-block-resources.jar"
         basedir="${cocoon.home}/src/blocks/forms/samples">
          <include name="resources/**"/>
          <exclude name="**/.svn"/>
      </jar>
   </target>

and, later on:

      <map:transform type="forms"/>
      <map:transform
          src="resource://resources/forms-samples-styling.xsl">
        <map: parameter name="resources-uri"
          value="resource://resources"/>
      </map:transform>

• Keep a very strict separation between application files and resources that a user might want to customize. This is expecially true for stylesheets and client-side javascripts/images/icons. Consider using the xsl:import feature in your stylesheets, providing an empty user-oriented version of your stylesheets, where templates can be overridden. Might hurt performance a bit, but sure helps tremendously for real life scenarios, where your customer is supposed to customise files and you're supposed to provide updated versions of your applications. If you don't, every deployment after the first one becomes an incredibly painful process.
• Ideally, package the whole application as a jar file: remember that Cocoon can easily access jar-packaged resources with the resource: protocol, and this holds true even for that overrideable XSLT who can import from your jar files. You can even package your root sitemap inside a jar and reference it with the resource:// protocol.
• Don't forget error and logging management. There is nothing worse that the default Cocoon error page popping up in front of your customers, so plan for a sensible handle-errors section right from the beginning of your project. Also, don't forget to customise your logkit.xconf file. These resources can be easily part of a shared project codebase, so there is no excuse for preparing them in advance.