SKURO! -- Shading lights

Legacy libraries for your maven build

2012-05-14T00:00:00+02:00

Legacy libraries

Dealing with legacy code is always tricky, and adapting your tooling to leverage them is sometimes plain hard. Especially when you're building your projects with Maven and your code happens to depend on some ancient library which appear to be unknown to the Internet™, you probably have to figure out how to tell Maven where to find that damn library. This is also the problem when dealing with e.g. proprietary third party libraries which don't ship with a POM, therefore they don't mavenly exist.

Local repositories FTW

There are a number of possible solutions to the above mentioned problem, which ideally involve a shared, remote artifact repository where to deploy the JAR file that causes you headaches. Recently, I found myself in the need of creating (yet another) Maven build around some Alfresco, to enable Lambdalf to build its Clojure sources. The rocky road to Maven for Alfresco is still long, and as a result you find yourself dealing with some iffy libraries when coding against Alfresco. Some examples, just opening up the WAR files:

truezip.jar
mybaties-3.0.4-patched.jar
acegi-security-0.8.2_patched.jar

One solution I found that doesn't require setting up your publicly available Nexus repository, nor using someone else's Artifactory, is to provide the problematic JARs in a maven repository as part of your sources. Suppose you have a mysterious fluff.jar library you need to include in your classpath, here's how it works:

place the JAR file in src/main/lib/fluff/fluff/unknown/fluff-unknown.jar

setup the dependency in your POM:

<dependency>
  <groupId>fluff</groupId>
  <artifactId>fluff</artifactId>
  <version>unknown</version>
</dependency>

still in your POM, enable the local repository:

<repository>
  <id>legacy-artifacts</id>
  <url>file://${project.basedir}/src/main/lib</url>
</repository>

Voilá. You just created a local, portable repository in your sources and instructed Maven to look there for artifacts.

License

A couple of golden rules for all the cowboy programmers out there:

always, always, always check if the license allows you to redistribute the libraries you're going to include in your project
never, never, never distribute a piece of software you're not entitled to give away and attach the license of all third party libraries along with your project

That said, I'll leave you to your local Maven repositories. Happy building!

Debug your build with the plan maven plugin

2012-05-08T00:00:00+02:00

Contention over configuration

While ThoughtWorks put it on hold, there are still a number of occasions where a normal Java guy such as the truly yours have to face refactorings of ginormus Maven builds. In my company, for instance, I'm now in the situation where I need to speed up the build of one component whose project structure involves 27 POM files, with up to 4 levels of nesting. Needless to say, there are tens of plugin executions, plugins and all the possible Maven black magic you can think of. The default options for build introspection (help plugin, enable debug, etc.) left me helpless in the middle of a gargantuan build execution log file.

Plan plugin FTW

I ended up writing a small plugin to help me debugging the build by dumping the execution plan. I originally named it plan-maven-plugin, and put all the sources on github. As the plugin is already on Maven Central, you only need to place the following in your settings.xml:

<pluginGroups>
  <pluginGroup>tk.skuro</pluginGroup>
</pluginGroups>

Thanks to David Thume, this is what it looks like now:

$ mvn plan:plan -Dgoals=clean,javadoc:jar,sources:jar,package,gpg:sign
...
[INFO] --- plan-maven-plugin:1.1:plan (default-cli) @ plan-maven-plugin ---
[INFO] 
[INFO] Current lifecycle:
[INFO]     pre-clean
[INFO]     clean
[INFO]     post-clean
[INFO]     validate
[INFO]     initialize
[INFO]     generate-sources
[INFO]     process-sources
[INFO]     generate-resources
[INFO]     process-resources
[INFO]     compile
[INFO]     process-classes
[INFO]     generate-test-sources
[INFO]     process-test-sources
[INFO]     generate-test-resources
[INFO]     process-test-resources
[INFO]     test-compile
[INFO]     process-test-classes
[INFO]     test
[INFO]     prepare-package
[INFO]     package
[INFO]     pre-integration-test
[INFO]     integration-test
[INFO]     post-integration-test
[INFO]     verify
[INFO]     install
[INFO]     deploy
[INFO]     
[INFO] Execution plan:
[INFO]     [clean] org.apache.maven.plugins:maven-clean-plugin:clean (default-clean)
[INFO]     [-] org.apache.maven.plugins:maven-javadoc-plugin:jar (default-cli)
[INFO]     [-] org.apache.maven.plugins:maven-source-plugin:jar (default-cli)
[INFO]     [validate] org.apache.maven.plugins:maven-enforcer-plugin:enforce (enforce-maven)
[INFO]     [generate-resources] org.apache.maven.plugins:maven-plugin-plugin:descriptor (default-descriptor)
[INFO]     [process-resources] org.apache.maven.plugins:maven-resources-plugin:resources (default-resources)
[INFO]     [compile] org.apache.maven.plugins:maven-compiler-plugin:compile (default-compile)
[INFO]     [process-test-resources] org.apache.maven.plugins:maven-resources-plugin:testResources (default-testResources)
[INFO]     [test-compile] org.apache.maven.plugins:maven-compiler-plugin:testCompile (default-testCompile)
[INFO]     [test] org.apache.maven.plugins:maven-surefire-plugin:test (default-test)
[INFO]     [package] org.apache.maven.plugins:maven-jar-plugin:jar (default-jar)
[INFO]     [package] org.apache.maven.plugins:maven-plugin-plugin:addPluginArtifactMetadata (default-addPluginArtifactMetadata)
[INFO]     [-] org.apache.maven.plugins:maven-gpg-plugin:sign (default-cli)
...

I still have a long way to go before I can bring my build to acceptable performance levels, but surely enough this will give me much more insights on what's possibly going wrong. Enjoy!

Spring surf Clojure and Alfresco H2 support now in Maven Central

2012-03-06T00:00:00+01:00

tl;dr: I had to change the groupId of both h2-support and spring-webscripts-addon-clojure. Good news is, they're now available on Maven Central!

Build management dilemma

Part of my company offering is an Alfresco based CMS, which we build the maven way. While this is already a nicely integrated build with the rest of the other products, I currently find it annoying to require a database to be installed wherever the project is built (ubiquitous MySQL installed locally on my laptop, on the CI server, etc.). As I'm maintaining an H2 compatibility module for Alfresco it's natural for me to integrate and use it.

There was only one thing blocking this process, and that's the maven repository where such artifact were deployed.

Deploy on Central

As much as I love Clojars, it still requires to be manually configured when dealing with a pure Maven build. Since it's not quite an option to add an artifacts repository for something as small as h2-support, I decided to just follow the guidelines for Maven Central sync on OSS Sonatype and rename the group ID to resabmle my personal web domain. This means I did dirty, dirty things that bought me an entire eternity in hell, such as retagging both v1.1 and v1.2.

But, as the only change in the POM is "non functional" such as description, developers and such, it's not going to hurt much I believe.

This move is reflected also in the currently unreleased spring-webscripts-addon-clojure, so if you'll be using it or you need h2-support remember to use the tk.skuro.* group IDs, and you won't need to add a <repository> to your POM ever again.

Thanks Sonatype for the awesome service!

H2 support updated for Alfresco 4.x

2011-12-14T00:00:00+01:00

H2 Support reloaded

Some time ago I announced a module to enhance Alfresco in order to support H2 as its persistent data storage. While it was successfully tested against Alfresco v3.4 and v3.5, @mindthegab pointed me out that Alfresco v4.x wasn't even starting when using the H2 module.

A quick look at the PostgreSQL scripts and configuration of Alfresco 4 revealed that they were indeed radically changed in the new release, so that an update was necessary.

Matching versions

Since 3.4+ and 4.x version series have quite different configuration, you need to use a different version of the h2 module depending on the Alfresco version you're running, namely:

H2 module	Alfresco versions supported
1.1	3.4+
1.2	4.x

The artifacts for both versions are available on clojars, please refer to the official documentation for the usage guide.

Jekyll, Github and Emacs

2011-11-27T00:00:00+01:00

tl;dr: I moved from Wordpress to Jekyll, you can now find the sources for this blog on Github

It has been a great adventure to host my blog on a private machine for more than two years. Setting up everything, in a pure DIY fashion, has been instructive and a funny journey. Unfortunately, there were a number of reasons why a privately hosted Wordpress instance was not optimal anymore.

I also gave the whole blog a new look, shamelessly copying much of Zach Holman design, I think it greatly improves readibility. Feedback welcome!

Going down

It first happened at the beginning of this year that one of my posts attracted a good deal of attention. While it wasn't really that big thing, 2k requests/hour were enough to drain every bit of available memory my VPS had to offer, thus repeatedly killing my whole LAMP) system down. It has to be noted that I'm no PHP nor Wordpress expert, and I was also so sloppy to let every single apache process (-> request) suck up to a round 20MB. No wander my machine went down, and while I was able to finally handle 1k request/hour order of magnitude several times later on, it was everytime on the edge of the catastrophe. It was clear to me that my Wordpress blog was to be replaced.

Note: I'm not saying LAMP + Wordpress is not a good option for a personal blog, it just wasn't an attractive option for me to get into the details of how to make it robust enough in my case.

Static content

PHP allows for highly dynamic content via server side rendering. Cool, but does a blog really need such power? The reality is that most of the pages served by a blog are the same almost all the time.Apart from when you create a new post, there's hardly any difference in a page in its whole lifetime. All the features you might get out of a blog engine such as Wordpress are in my case of no real use.

Static content was appealing from a number of reasons: lightweight, plain HTML and resources (JS, CSS). The whole site fits in my mental picture quite easily. I needed only a thin layer that would allow me to use a more convenient interface to the presentation layer than HTML.

Github Pages and Jekyll

I did some initial experiments with a fully custom Clojure blog engine, where I explored various combinations of Compojure, Noir, Hiccup, Enlive, etc. While it was a nice exercise, it was really more of a technical exercise which wasn't getting me nowhere, as I kept running in circles while picking up new technologies every other day. Github Pages was there, tempting me all along the way: I already loved Git and Markdown, and delegating the whole infrastructure to Github was eventually tackling the very core of my original issues with hosting my own blog. It was when I found a great migration guide that I couldn't deny anymore Github hosted Jekyll was the best option I had.

Emacs, of course

Migrating to Jekyll took just a couple of days, I even wrote my first Ruby code ever. Everything looked pretty promising, but I needed an extra step: there was no point in having a plain text interface if I couldn't use the Almighty Emacs™ editor as the main interface to my blog. Sure thing, I wasn't the first to think so, and I promptly found an initial implementation I could use to start walking the Emacs way.

Needless to say, I'm writing this very post from Emacs. And it feels good.

Conclusions

With this first post I just started feeling the good parts of my new setup. There are huge areas of improvements here and there, but hey, for just a 4 days job I can't be more happy!

Maven 3 Cookbook reviewed

2011-11-15T00:00:00+01:00

Better late than ever, here you can find my review on the Packt Publishing Apache Maven 3 Cookbook written by Srirangan. Let's see what it has to offer.

The basics

The author aims to talk to Maven, and possibly ALM, illiterates. This means the first step is to allow the reader to bootstrap his build infrastructure. This is one of the main Maven features, and the first chapters are easily leaping from nothing to a QA and TDD enabled build system. The book exploits Maven magic all the way there, and goes really fast to the target, no time for digressions on how, why or how does it compare with other build systems.

The ALM

Chapter 3 it's a bit off topic, even though it's probably for the greater good: it broadens the attention to ALM as a whole, all on open source products such as Hudson/Jenkins, SCM and a bit of agile. The topic is so huge that one single chapter cannot afford to cover it extensively, nor effectively: take it as an introduction to software lifecycle management, and dig somewhere else if you want more (and you definitely want). Chapter 4 indulges a bit more in QA and non functional build features, such as documentation and reporting. After all, the real mission of Maven is ALM.

The Meat

Chapters 5 to 9 form the really juicy part of the book. I'm not going to rewrite the TOC here, but it's definitely a rich set of handy recipes that can either directly target common needs or provide inspirational snippets that will effectively help you writing your POM. Good marks for the attention to languages other than Java (but bad marks for forgetting Clojure!).

These chapters offer much more value than the previous, as they're better aiming at developer needs. Still, focus could have been more towards existing Maven users, leaving the newbies to better learning paths.

Overall impression

tl;dr: If you are already a Maven literate, it's a book you probably want to have close to your keyboard. Just forget about the first three or four chapters.

The book is an authentic source of good base recipes, that you would keep on your desk for quick reference of specific build tasks you need to implement (and your Google foo is weak). All the recipes are provided with a little description of what happens under the hood, so that you may use such knowledge to build upon them your more complex procedures. The whole focus on the book is on getting things done, with lesser attention to fully understanding Maven: after all, a recipes book cannot replace a cooking course. As a result, its tutorial style of presenting recipes completely overlooks fundamental concepts such as plugins, executions and goals, with seldom sloppy terminology ("archetype:generate" is a goal, not a command). While it can be good to always have this book on your desk, if you're a Maven newbie it's highly recommended to look somewhere else to build up your knowledge.

Full disclosure

I was asked by Packt to provide this online review, for which I've been handed over a digital preview of the book.

Slides from Alfresco the Clojure way

2011-11-10T00:00:00+01:00

I just gave a talk at the Alfresco DevCon 2011 in London, and I published the slides at slideshare:

There's also an extended version of the presentation that I originally wrote, which ended up being too big for the time slot I had.

Hope you either enjoyed the talk or the slides, next steps are getting to GitHub and fork lambdalf and clojure webscripts away!

October Amsterdam Clojure with Uncle Bob

2011-09-27T00:00:00+02:00

I'm very excited to announce that we have finalized the details, and Wednesday, October 12th we're going to have a great Amsterdam Clojure meetup", with great talks and an awesome guest speaker: "Uncle" Bob Martin from Object Mentor and of Clean Coders fame.

Thanks to Sourcesense, which is once again backing up and ultimately allowing this event to happen in an awesome location such as the Pakhuis de Zwijger, I look forward to meet a number of Clojure enthusiast, newcomers or tired Java developers looking for something new.

We have limited seating possibilities, so make sure to register at the meetup official page to ensure there will be a spot for you!

Reviewing Maven 3 Cookbook from Packt Publishing

2011-09-06T00:00:00+02:00

Packt Publishing recently proposed me to review their new book Maven 3 Cookbook written by Srirangan. I just received a copy of the book, I'll start reading it immediately and provide my review in a future blog post here.

In the meanwhile, here's the book home page where to find the detailed table of contents and a sample chapter.

Clojure makes it to the Alfresco DevCon2011

2011-09-04T00:00:00+02:00

If you're a bit into Alfresco, you surerly know what the DevCon is.

To use the same words from Jeff Potts:

the premier event for digging into the details of the Alfresco platform and collaborating with others who are doing the same

Now, as soon as I received the CallForPapers I immediately (and impulsively!) submitted a talk named Alfresco, the Clojure way in the Customizing Alfresco track, where I wanted to introduce to enthusiastic Alfresco developers how to do their job using a fantastic programming language. It was just last week that I was notified that yes, my talk made it to the conference schedule! Clojure goes to London!

It will be great chance for Clojure to prove itself a great tool, and to get some more exposure to software professionals around Europe and beyond. Now that things got serious, I really need to put my presentation together, and that's where you can provide some help.

I still don't know the time slot the presentation will be given, but surely enough I'll publish online the full version of it as soon as I'll be back from London. The following is the initial list of topics I'd like to cover, but I'm eager to know from you what you would like to add to it.

High level topics

crash-course on Clojure syntax
extremely fast digression on some core language features and functional programming topics
introduction to lambdalf, a Clojure adapter to the Alfresco Foundation API
introduction to the Clojure addon for the Spring Web Script framework
show and tell: start Alfresco, start a swank server and do live coding against the repository
OPTIONAL: showcase a Clojure-based sample Alfresco application

Again, I don't know how much time I'll be given, so I can't even guarantee I'll have time for all the above topics to get a proper introduction, but since I also might have still enough time to cover other topics, what would you like to see in there?

H2 embedded DB and Alfresco 3.4

2011-08-03T00:00:00+02:00

One of the most useful thing an embedded DB can do for you is to provide a clean environment in your automated tests to use as a clean slate where to repeatedly and reliably test your code. It's been a while since Alfresco broke compatibility with some embedded DB we used to run our tests (HSQLDB above all others).

I recently regained interest into cutting out any useless dependency on MySQL or PostgreSQL on the test server to run my Alfresco tests, and H2 looked sexy. I found here and there some promising work by other people, but none worked for me out of the box. I then started from scratch using PostgreSQL DB scripts and voila! Now I have back my Alfresco running against an embeddable DB! You can see & fork the results of my job if you like. It's supposed to help you with a Maven Alfresco project, but you can probably benefit from it even if you're using some other build tools.

As soon as you have all those files in your classpath, be sure you edit your alfresco-global.properties like the following:

db.driver=org.h2.Driver
db.url=jdbc:h2:alf_data/h2_data/alfresco
db.username=alfresco
db.password=alfresco
hibernate.dialect=org.hibernate.dialect.H2Dialect

Make sure you're using an hibernate version >= 3.1 as per H2 documentation.

Verifying my Technorati claim

2011-05-11T00:00:00+02:00

You can safely ignore this entry, as it's only to comply to technorati request to add a random code in a blog post to validate it.

I placed the code in this page, can you spot it?

UVBRKNJTRFH7

More Clojure for Spring Surf

2011-05-10T00:00:00+02:00

After some time from my initial announcement, I've started again working on my Clojure addon for Spring Surf. While it's still a rudimentary piece of glue code, it's now getting better and better, so much that I decided it's good enough now to release an alpha version on clojars. Here's what this library currently provides:

a ScriptProcessor that allows webscript controllers to be written in Clojure
a WebScript protocol and some utility functions to ease development of your own web scripts
enough spring configuration to enable this addon just by importing the provided contextes

The approach is indeed easy and hopefully straightforward: the idea is to have your WebScript clojure controllers return an instance of a concrete implementation of the WebScript protocol, which will implement the run method the way you like.

Here's the sample code from a gist you might want to have a look at to better understand how to use this library:

You can also find other samples in the project tests.

The next episode will be about lambdalf, an Alfresco AMP I've been initially developing to prove the Clojure surf addon works fine, but that is now growing to be a full blown project by itself: a Clojure API for Alfresco!

Stay tuned. UVBRKNJTRFH7

Performance boost in Clojure 1.3 (alpha4)

2011-01-24T00:00:00+01:00

As release 1.3 of Clojure is on its way, I decided to give the currently available alpha4 a try and see some of the good stuff it brings. First thing first, I wanted to experiment myself with the performance gain that the extended support for native types would bring. I ran into an old post from which I got the inspiration for the specific test to run: the Takeuchi function.

The Java implementation for Tak provided me with a bottom line for performance comparison:

Then I used the Clojure version provided in the original blog post run to test against Clojure 1.2:

Finally, I leveraged the new syntax for the enhanced primitives support to test against Clojure 1.3 (thanks to neotyk to point that out to me):

As you can see, timing is tracked from the application code, as various accessory overhead like JVM and Clojure runtime bootstrap are not in the scope of this post.

As this benchmark is "just for fun", I won't pretent I did an extensive benchmark, or that I engineered a bullet proof benchmark strategy and the like. I just ran the above code some tens of times and here follows the average running time for the three versions:

NOTE: an updated benchmark is provided down below NOTE2: to have a more fair performance comparison, keep reading

The results tells of a ~4.5x speed gain, ~~getting close to match plain Java code performance~~.

Now, even if such a benchmark won't be any news to the Clojure community, it's still absolutely awesome to see such a performance gain in the next release of this beautiful Lispy language :-)

Update: following the advice by Jürgen Hötzel in his comment, I slightly modified my Clojure sources to change clojure.core/- with clojure.core/unchecked-subtract and re-run the test. Here's the final results, which are way better for Clojure, especially for version 1.2:

Update 2: the following graph shows the impact of the direct use of the recur special form tested against plain recursive invocation of Tak, as per requested in some comments

Update 3: even if this all started as a quick&dirty, amatorial benchmark, it attracted quite some attentions, demanding more fair and precise benchmarks, especially on the Java vs Clojure comparison. As in the Java version of Tak I used Integers and not primitive types, there is an unfair burden Java had to carry along the computation. The following is the result of a re-run of the test for Java (using primitive long) and Clojure 1.3:

SproutCore encoding gotchas

2010-09-30T00:00:00+02:00

These days I'm trying out SproutCore, an MVC framework written in Javascript that aims to help developing rich client web applications. I'm not going to entertain you with any juicy technical spotlight, as they'll hopefully find their way in these pages later on with plenty of details. At the moment I'd like to share a little problem I got stuck with that had a non trivial solution~~, at least for the noob I am~~.

First thing you have to know is that SproutCore ships with both a rich Javascript library and a set of building tools written in ruby, which go under the code name of abbot. New projects kickstart, scaffolding, automatic documentation are among the features that abbot provides you with, along with the ability to run you application on a local web server during development. Sounds cool, isn't it? And I didn't even mention it's integrated unit testing facility!

I immediately tried to give it a shot, and ran through one of the tutorials to write down my first HelloWorld. The first pieces got into place, and after the first quick round I left my hello world project in such a state that I already decided to build a simple but complete application right away. How arrogant.

The second day something Bad™ happened, I cannot really tell what, but everything started to fall apart: no one tool in the abbot suite worked properly, I was no more able to get any further and I started a painful journey of which I only remember installing and changing between zillions of ruby versions, crying and considering to give up with IT and to start my own religion to make a living.

But then I simply resorted to the #sproutcore IRC channel and I got the tip that saved the day (thanks pjmorse!):

export LC_CTYPE=UTF-8

"Boom baby!" I said, everything got back to normality. I can save my holy plans for a rainy day. It seems that encoding is an endless source of issues in the ruby world, so that probably if you have any ruby knowledge whatsoever this all rant might just seem pointless and the solution trivial.

Next episode on SproutCore (if everything goes well): a sample SproutCore + Clojure application. See you there!

Crampi alla lingua

2010-09-29T00:00:00+02:00

Per la prima volta mi trovo a scrivere in Italiano in questo blog. Contando che vorrei affrontare l'argomento della guerra, se così la si può chiamare, tra l'Italiano e l'Inglese, mi sembra anche appropriato.

Tutto parte da un interessante blog post che cerca di mettere in luce le insidie di una politica aggressiva di apprendimento dell'Inglese, a scapito di un sempre più bistrattato Italiano: l'eliminazione del doppiaggio dalle TV di stato e balzi in avanti maoisti nell'inglese a scuola. Vengono affrontati argomenti che mi stanno a cuore tanto da giustificare un intero post e non un semplice commento a margine.

Vediamo un po'.

Il motto "vietato doppiare!" in uso in paesi come l'Olanda [...] ha procurato un arretramento dell'olandese e dello svedese in tutti gli ambiti, non solo quelli formali, al punto che uno straniero può vivere lì senza mai imparare una parola di olandese

Da emigrato proprio in Olanda, confermo l'avanzamento dell'inglese in questa nazione, tanto da spingere a dichiarazioni pubbliche alcune cariche dello stato (ahimé, ho perso il link, vi dovrete fidare) per limitare allo stretto necessario campagne pubblicitarie in inglese, in nome della conservazione della lingua. Badate bene, è un Paese dove un anziano di estrema periferia può essere in grado di comunicare nella lingua d'Albione. Una situazione che, nella più rosea delle previsioni, l'Italia riuscirà a raggiungere tra mezzo secolo.

Epperò devo anche dire che al momento il Nederlandese non vive nessun tipo di relegazione, anche e soprattutto sul posto di lavoro, dove chi non vive di IT come il sottoscritto può avere discrete difficoltà a trovare un impiego.

Ma andiamo avanti.

se [si] prova a parlare nella loro lingua, loro gli rispondono in inglese. Se a un turista occasionale questa situazione può indubbiamente essere utile, per un residente può creare un apartheid linguistico, al punto tale che uno straniero non riuscirà mai ad integrarsi veramente nel tessuto sociale del luogo

Di nuovo, concordo pienamente. La quasi totalità della mia rete di amicizie in Olanda é fatta di italiani ed immigrati di varie nazioni. "Apartheid" é di origine Olandese, e ben si presta ad esprimere il concetto di come l'uomo sia tendenzialmente impermeabile ad avvicinamenti alla sfera privata da parte di chi non parla la sua lingua. é un dato di fatto a cui mi sono ormai rassegnato.

La soluzione è una ed una soltanto: emigrare in un altro paese comporta anche la necessità di impararne la lingua. E l'Olanda è anche molto ben disposta ad insegnare la propria lingua e cultura agli immigrati, con corsi offerti a costi ridicoli. Di fatto, la maggior parte degli immigrati in Olanda ricade in fasce di reddito medio basse, con altrettanto bassi livelli di scolarizzazione, e con una penetrazione del Nederlandese molto forte.

Siamo ormai in chiusura.

Andrà a finire che faremo una cosa all'italiana, [...] parleremo un orrido spaghetti English pensando di essere molto bravi finché non ci scontreremo contro la dura realtà [...]. Ma in quel momento, sarà troppo tardi per svegliarsi.

Essendo il discorso imperniato in particolare sul doppiaggio dei film, non mi trovo assolutamente d'accordo con le conclusioni. Ho sempre sostenuto che il doppiaggio dei prodotti televisivi o cinematografici in italiano sia un'enorme deficit nel nostro apprendimento dell'inglese, basti guardare Portogallo e Spagna: in Portogallo, dove il doppiaggio non avviene, si parla mediamente un buon inglese, e basta passare il confine di pochi centimetri per approdare in una Spagna completamente estranea al concetto stesso di inglese.

Sono assolutamente d'accordo nel sostenere che la cultura e la lingua italiane debbano avere il primato, debbano essere sostenute e che navighino attualmente in cattive acque, ma questa situazione é già davanti ai nostri occhi anche senza la presenza dell'inglese in TV. Ai giorni nostri l'inglese é uno strumento fondamentale, che l'italiano medio non riesce ad acquisire in maniera tale da poterlo sfruttare a proprio vantaggio. Tutt'al più può sperare di dare le indicazioni ad un turista approdato in terra italica.

Io mi sento di ribaltare il punto di vista: non si può far si che un colpevole disinteresse per la lingua italiana vada a scapito degli interventi che possono migliorare l'apprendimento dell'inglese.

Spring Surf meets Clojure

2010-05-23T00:00:00+02:00

For those who missed it, some time ago the Alfresco guys donated their Surf Platform to SpringSource, giving birth to the now-called SpringSurf, which is thereby described as:

a view composition framework for Spring MVC that plugs into your existing Spring applications. It provides a scriptable and content-centric approach to building web applications.

I'm not going to introduce you how to use this yet-another MVC framework, but Michael Uzquiano provided an awesome blogpost, in case you were interested into learning more about it.

Part of the job of this Spring Surf framework is to provide an easy to use web scripting framework, REST like, that enables you to easily put together a View and, optionally, a Controller to implement a web API, provide them in the classpath together with a small XML descriptor, and your REST API is deployed right away. In the SpringSurf parlance, this is called called WebScript. Again, technical insights about the framework are better explained elsewhere, so no repetitions here. What I think is cool about Spring Surf, and I'm here with you to discuss, is it's multi-language focus: web script Controllers can be written in Javascript, PHP or Groovy right out of the box, allowing you to choose whichever language you prefer. Moreover, if you just peek at Spring Surf source code, plugging in support for new languages doesn't look so hard, so I decided to challenge myself and write support for Clojure backed webscripts. You can find the result of my efforts on github, with a sample webscript that proves the concept.

Following the webscript framework praxis, a model map object is passed around that acts as a container for whichever result your computation will produce, that will at the end handed over to a view rendition engine, Freemarker in our case, to build the resulting document. Webscripts are intended to support a number of different output formats, from JSON to XML to plain text, so being generic here is not an option.

Anyway, the first thing you usually do is to populate the model map with a number of objects that will be needed by the rendering engine to build the response. To support this use case, this first implementation of the Clojure backend for Spring Surf webscripts expects your Clojure "script" to yield a map, in Clojure sense. This map will be then forwarded to a Freemarker template and used to build a webpage or whatever the user asked for, i.e. this controller:

(ns web.script.test)

{:foo "bar"}

and this freemarker template:

foo: ${foo}

will provide "foo: bar" back to the client.

This is just an experiment at the moment, and far from being production-quality stuff. Still, it has been instructing to build a Java-to-Clojure integration, and nonetheless it might come in handy when I'll be trying to put more Clojure in my working life.

(bye)

Handling Microsoft Windows NTP sync

2010-04-23T00:00:00+02:00

This post should raise some eyebrows around, as I'm advocating Linux since ages and I'm not at all into Microsoft stuff for the 99.99% of my time. This story comes out of that (usually negligible) 0.01%.

Why bother with NTP on MS Windows?

The Alfresco implementation I'm working on has to integrate with a fully MS-powered environment, with a Domain Controller pulling the strings of network entities such as users and hosts. As the customer has strict security requirements, no remote access can be granted to their intranet, and since their offices are a bit far away from mine, we decided to replicate their environment locally, providing the minimum set of components such as

a domain controller (WinServer 2k8)
a domain host (WinXP Pro SP2)
the Alfresco server (RHELv5.4)

I was able to build up the whole replicated environment, with a relative limited effort, using virtual machines to host all the different operating system on my laptop. I was so happy that everything worked almost at the first shot that I almost died when it all went wrong after the first reboot of the VMs: I couldn't log anymore on the WinXP box!

It turned out that all clocks drifted away, making Kerberos auth checks fail because of replication attacks protection. Looked like it was time to strengthen my Win-fu and configure NTP in a proper way. This is what I learned.

WinServer2k8 and clock management

If there's one thing I enjoyed out of all the time spent on these tasks, the prize goes definitely to w32tm: I had to deal with Windows, and there were no windows involved! As usual, whenever I'm typing into a command line, I feel at home. I'm actually writing this whole blog post to take note of the tricks I learned around w32tm and NTP clock sync. Here we go:

Configure NTP servers

w32tm /config /manualpeerlist:europe.pool.ntp.org \
     /syncfromflags:manual /reliable:no /update

Query NTP servers

w32tm /stripchart /computer:europe.pool.ntp.org \
     /samples:5 /dataonly

Resync clock
```
w32tm /resync /rediscover
```
Allow resync in case of huge drifts If your clock drifted too far away Windows will refuse to sync. In order to disable such check you have to import the following changes (write them in a reg-keys.reg file and double click it):
```
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"MaxNegPhaseCorrection"=dword:ffffffff
"MaxPosPhaseCorrection"=dword:ffffffff
```

That's it for now. I hope this will come in handy to somebody else, since I'll try to avoid any more contact with the Microsoft stacks as long as possible, since without grep, find, awk, sed, vim I feel as uncomfortable as this.

Tales from an Icelandic volcano victim

2010-04-21T00:00:00+02:00

Last weekend Eyjafjallajökull decided my long-planned trip to visit my dear family in Italy had to be exhausting. On Friday, April 16th at 2pm my flight to Milan, scheduled to leave Amsterdam Schiphol at 8pm, was eventually cancelled. It had to be the first step of a longer journey, which was planned to be as follows:

Amsterdam -> Milan - Friday, 16th April @8pm
Milan -> Cagliari - Saturday, 17th April @10am
Cagliari -> Milan - Monday, 19th April @12.30pm
Milan -> Asterdam - Monday, 19th April @6pm

When it was clear that I was not going to leave Amsterdam by plane, I did the only thing you wouldn't take seriously, if you were me: I rented a car to try and catch the flight leaving Milan the next day. This is the story of this long, long journey.

Amsterdam -> Milan: CANCELLED

I didn't take note of the steps along the way down to Milan, so I will just write down a short story here.

We left Amsterdam by car at around 6pm. "We" means just me and my girlfriend, who wasn't 100% sure I had a great idea renting the car. But she supported me all the way long, she even drove for ~300km between Frankfurt and Stuttgart, while I was sleeping next to her. She had to stop around midnight, when we both fell asleep for 2h.

Coffee, sugar, then I got back at the driver seat and drove with no intermediate stops, if not for fueling, down to Milan.

We were stopped at the customs between Switzerland and Italy (6am), where three cops checked our pockets, our luggages and even our car trying to find some criminal stuff. Needless to say, they didn't find anything, but we lost 30 precious minutes.

Fortunately, the traffic jam that usually takes you ages to get through when you're near Milan at rush hours was yet to ramp up, so that we made it on time at Milan airport (7.45am). We left the car at the parking area, grabbed a coffee and waited to take off.

Milan -> Cagliari: AIRBORNE

This is the most boring part of this diary: everything went really good, no delays, no nothing. We arrived, we enjoyed our time and my beloved Sardinia (and a Misfits concert, by the way). As time went by, it was clear that some more troubles were about to come.

We didn't care until Sunday night, when they announced that Milan airport was definitely closed.

Cagliari -> Milan: CANCELLED

This hit us badly: we didn't even considered the idea that that ash could get past the Alps, and now we were stuck in an island, even though a beautiful one. We decided to go the traditional way: we bought tickets to get back to Italy by boat.

This time we teamed up with my brother, his girlfriend and their awesome, 4 months old son. They had to come back to Pisa, so that we could share the first part of our trip together.

We left Iglesias, my birth place, at 11am, and after some hours and two stops (feeding, then fueling) we arrived at Olbia at 2.30pm. Having studied in Pisa for 7 years, the whole boat experience became quite familiar and boring long time ago. But those 9 hours passed by quite fast, as we enjoyed our time together with the little newborn totally starring the show.

We eventually arrived at Livorno at 11pm, where my girlfriend's father was awaiting us to give us a lift to Milan. Take note: 60 years old man, driving all night long for a total of 700km just to start working the next day without any rest in between. I hope I'll have the same energy when I'll be aged the same.

Milan -> Amsterdam: CANCELLED

We got at Milan airport at 2.30am, where we found a surreal, totally empty place that was nonetheless bright, colorful and with all the monitors repeating the same word "cancelled" to death with nobody except us staring at them, as if their only purpose was to remind us why we were actually there.

Bathroom, coffee, take back the car from the parking lot and back on track: our former driver headed back to the south, we followed the Pole Star (3am).

They didn't care to stop us again at customs, so we went straight to Basel, around where we took our now traditional 2h nap at around 6am.

Coffee, sugar, my girlfriend took the driver seat. I slept for the usual 300km and then drove all the way to Amsterdam.

The end

We arrived at home around 4.30pm. We were both completely exhausted, done, finished. Yet something more was left to do: empty the car, fuel it, take it back to the airport where the rental agency is, and then, finally, back at home, with enough energies left to get on and crush on the bed. 12h of sleep later, the whole story started to look like a long, distant, strange dream.

It has been devastating, and I don't think I'm going to did it again. Still, the only regret I have is that I didn't take pictures, as my camera was packed within my luggage. I now look at the map above, which pin points all the steps along our way back here, and think "did it". And I cannot hide a smile.

Amsterdam Clojurians meeting #4 - Dojo style

2010-04-14T00:00:00+02:00

Today the fourth meeting of the Amsterdam Clojure user group was held at the now usual Sourcesense offices venue in Amsterdam.

It has been probably the most successful one until now: thanks to some newcomers we had the most participated event ever with 10 nerdy, awesome geeks sitting together to discuss about nerdy, awesome stuff with lots of parenthesis.

As previously proposed by Jeff Rose, we started thinking about improvements we could provide to the standard Clojure REPL, deciding for colorful messages for the doc function. Sam Aaron proposed then to follow a dojo-like approach, with a single laptop connected to a projector where everybody has the chance to step in and do some coding while everybody else discuss possible approaches and alternatives.

The resulting code from this session is available on github. It does just a simple thing, it provides a way to override the default doc behavior in order to make use of our custom, colorful implementation of print-doc. And even if it doesn't look like rocket science, I can guarantee that being there and looking at how we came up with that, from some impressive vim-fu showed by Michiel de Mare to the clever and clean code provided by Remco van 't Veer, was indeed a lot of fun!

If all this sounds interesting to you, go and checkout the group mailing list or just show up at the next meeting, second Wednesday of each month at the Sourcesense office.