Find file
Fetching contributors…
Cannot retrieve contributors at this time
1113 lines (812 sloc) 74.6 KB
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="">
<title type="text" xml:lang="en">SKURO! -- Shading lights</title>
<link type="application/atom+xml" href="" rel="self"/>
<link type="text" href="" rel="alternate"/>
<name>Carlo Sciolla</name>
<rights>Copyright (c) 2010-2011 Carlo Sciolla</rights>
<title>The best keyboard layout for Clojurists</title>
<link href=""/>
<summary type="html">&lt;h1&gt;Keyboards, oh my!&lt;/h1&gt;
&lt;p&gt;If you&#39;re a programmer, you spend most of your working life on your keyboard, and a good keyboard layout can make the difference between touch typing and carpal syndrome.&lt;/p&gt;
&lt;p&gt;That, and an irresistible drive for being the alpha nerd around, pushed me to teach myself &lt;a href=&quot;;&gt;Colemak&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;It was painful and frustrating at the beginning, when I saw my typing speed precipitating from a respectable 80 words per minute to a horrific 20wpm. But now, now that touch typing has no mysteries for me on this mystical keyboard, now I got beyond my past self, recently crushing the 90wpm milestone. Hooray!&lt;/p&gt;
&lt;h1&gt;&lt;code&gt;(def best)&lt;/code&gt;&lt;/h1&gt;
&lt;p&gt;In this data driven world, we constantly need to verify whether the decisions we make are still valid, and therefore the question: would Colemak be the best keyboard for me? Am I losing by sticking with the wrong choice? And would I be even willing to switch again keyboard layout in the foreseeable future?&lt;/p&gt;
&lt;p&gt;While the answer to the last question is a roaring &lt;a href=&quot;;&gt;&quot;NO!&quot;&lt;/a&gt;, I needed to know. I needed data. But how?&lt;/p&gt;
&lt;p&gt;Well, first things first, I type lots of &lt;a href=&quot;;&gt;Groovy&lt;/a&gt; and &lt;a href=&quot;;&gt;Clojure&lt;/a&gt; these days. But I don&#39;t care for the former language, my heart is really about my dear lispy friend. I just had to find a way to produce an automatic comparison, surely enough, here it is: the &lt;a href=&quot;;&gt;Keyboard Layout Analyzer&lt;/a&gt;, courtesy of &lt;a href=&quot;;&gt;Patrick Gillespie&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;I love the Internet.&lt;/p&gt;
&lt;h1&gt;The winner is..&lt;/h1&gt;
&lt;p&gt;Aaaaand here it is: a comparative analysis of what keyboard is the best for Clojure Developers&amp;#8482;, after feeding the analyzer with &lt;a href=&quot;;&gt;&lt;code&gt;clojure/core.clj&lt;/code&gt;&lt;/a&gt;, with its impressive 7447 lines of code:&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;/img/post/colemak_clj.png&quot; alt=&quot;Test results&quot; /&gt;&lt;/p&gt;
&lt;p&gt;Now you know. Now it&#39;s official.&lt;/p&gt;
&lt;p&gt;Happy touch typing, everyone!&lt;/p&gt;
&lt;p&gt;p.s.: you can read the details of the comparison &lt;a href=&quot;;&gt;here&lt;/a&gt;&lt;/p&gt;
<title>Spring Environment is for initialization code only</title>
<link href=""/>
<summary type="html">&lt;p&gt;Since version 3.1, the &lt;a href=&quot;;&gt;Spring framework&lt;/a&gt; offers an abstraction towards several different
sources through which you can easily configure your application: the &lt;a href=&quot;;&gt;&lt;code&gt;Environment&lt;/code&gt;&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;In this post I describe a micro benchmark that I ran to prove that, while it&#39;s a convenient API if you&#39;re
using Spring in your application, it might introduce a performance penalty for which you should not use it
outside of your initialization code.&lt;/p&gt;
&lt;h1&gt;How it works&lt;/h1&gt;
&lt;p&gt;Before getting into the numbers, a quick digression on the internals of the &lt;code&gt;Environment&lt;/code&gt; that are important
to this post.&lt;/p&gt;
&lt;p&gt;From the documentation:&lt;/p&gt;
&lt;blockquote&gt;&lt;blockquote&gt;&lt;p&gt;&lt;em&gt;Properties play an important role in almost all applications, and may originate from a variety of sources: properties files, JVM system properties, system environment variables, JNDI, servlet context parameters, ad-hoc Properties objects, Maps, and so on. The role of the environment object with relation to properties is to provide the user with a convenient service interface for configuring property sources and resolving properties from them.&lt;/em&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/blockquote&gt;
&lt;p&gt;So, you can use the &lt;code&gt;Environment&lt;/code&gt; to have a common interface to properties provided with different strategies, using
a simple &lt;code&gt;getProperty&lt;/code&gt; call to access the required value. Look at the following Groovy code:&lt;/p&gt;
&lt;pre&gt;&lt;code class=&quot;java&quot;&gt; @Component
public class Greeter {
private Environment environment
public Greeter greeter(Environment environment){
this.environment = environment
def nickName(user) {
environment.getProperty(&quot;user&quot;) // here be magic
def greet(user) {
def nick = nickName(user)
if (name == null) println &quot;Hi, ${user}!&quot;
else println &quot;Hi, ${nick}!&quot;
&lt;p&gt;Now, I can specify nicknames in a properties file so that I can greet know users with a more familiar nick name,
still being able to salute also users which are not given a nickname. Neat, but how about performance?&lt;/p&gt;
&lt;h1&gt;The hidden Exception&lt;/h1&gt;
&lt;p&gt;I got into this exercise while debugging a couple of slow pages in the website I&#39;m working on: the
&lt;a href=&quot;;&gt;destinations pages&lt;/a&gt; of the KLM main site. While performance is generally
satisfactory, two pages were constantly giving above second response times. Definitely &lt;a href=&quot;;&gt;too much&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;In our code, we were translating some country names into queriable keys for an external services. We also needed to override
an otherwise straightforward translation algorithm with very specific exceptions to the rule. The actual code was pretty much
like the above &lt;code&gt;Greeter.greet(user)&lt;/code&gt;, and a &lt;a href=&quot;;&gt;Flight Recorder&lt;/a&gt; session
eventually provided us with the performance bottleneck (click to open):&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;/img/post/exceptions.png&quot;&gt;&lt;img style=&quot;width: 500px&quot; src=&quot;/img/post/exceptions.png&quot; /&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;For 12 page refreshes we were silently throwing 140k+ exceptions. And exceptions are
&lt;a href=&quot;;&gt;sloooooow&lt;/a&gt;, even if you just create them.&lt;/p&gt;
&lt;p&gt;Looking at the top thrown exception, it was actually pretty
easy to understand what&#39;s going on: the &lt;code&gt;Environment&lt;/code&gt; checks whether the requested property is defined in the current JNDI context. But, if the
name is not found, a &lt;a href=&quot;;&gt;&lt;code&gt;NameNotFoundException&lt;/code&gt;&lt;/a&gt; is thrown. In our specific case we were using property lookup for &lt;em&gt;exceptional&lt;/em&gt; cases,
which means the vast majority of cases resulted in an exception being thrown.&lt;/p&gt;
&lt;h1&gt;Micro benchmark&lt;/h1&gt;
&lt;p&gt;I put together a &lt;a href=&quot;;&gt;micro benchmark&lt;/a&gt; to evaluate the potential performance gain
of the original property lookup strategy versus a simpler one where relevant properties are loaded up at class construction time. I used the
&lt;a href=&quot;;&gt;Java Microbenchmark Harness&lt;/a&gt;, which does an incredible job at making micro benchmarks
easy on the JVM: JIT, warm up, class loading, all is taken care of for you and you can just go ahead and put your code under test. Here the results
(higher numbers better):&lt;/p&gt;
&lt;blockquote&gt;&lt;blockquote&gt;&lt;p&gt;[Property lookup per invocation]&lt;/p&gt;
&lt;p&gt;Result: 28917.876 ?(99.9%) 183.630 ops/s [Average] &lt;br /&gt;
Statistics: (min, avg, max) = (25688.067, 28917.876, 30976.876), stdev = 777.500 &lt;br /&gt;
&lt;strong&gt;Confidence interval (99.9%): [28734.246, 29101.505]&lt;/strong&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/blockquote&gt;
&lt;hr /&gt;
&lt;blockquote&gt;&lt;blockquote&gt;&lt;p&gt;[Property loading at class construction]&lt;/p&gt;
&lt;p&gt;Result: 159062.900 ?(99.9%) 1013.309 ops/s [Average] &lt;br /&gt;
Statistics: (min, avg, max) = (138707.926, 159062.900, 177183.549), stdev = 4290.413 &lt;br /&gt;
&lt;strong&gt;Confidence interval (99.9%): [158049.591, 160076.209]&lt;/strong&gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;/blockquote&gt;
&lt;p&gt;As expected, five times as fast.&lt;/p&gt;
&lt;p&gt;I&#39;m not a big fan of Spring, but if you&#39;re using it the &lt;code&gt;Environment&lt;/code&gt; class is a dead easy interface to your application configuration. But,
unless you&#39;re using JNDI as your main store of configuration properties,
its performance characteristics make it a great tool only if you&#39;re using it in your initialization code, and not during on-line processing of
<title>Alfresco H2 support releases and versioning scheme</title>
<link href=""/>
<summary type="html">&lt;p&gt;Some time has passed since the &lt;a href=&quot;/2013/03/27/h2-support-for-alfresco-3-4-12-and-maven/&quot;&gt;last releases&lt;/a&gt;, and all the merits go once again to our dear &lt;a href=&quot;;&gt;John Evans&lt;/a&gt; from &lt;a href=&quot;;&gt;Ixxus&lt;/a&gt;. Let&#39;s see what&#39;s new in the project.&lt;/p&gt;
&lt;h1&gt;Lots of releases, now with a new version scheme!&lt;/h1&gt;
&lt;p&gt;We were lagging behind Alfresco releases quite a bit, so you now have quite some &lt;a href=&quot;;&gt;new releases&lt;/a&gt; to look at. Most importantly, starting with Alfresco 4.2.0 we decided to align H2 Support with the official Alfresco versioning. So, while H2 Support v1.7 and v1.8 are the ones to be used respectively with Alfresco Enterprise 4.1.5 and 4.1.6, you will easily guess what versions of Alfresco Enterprise will have to use H2 Support v4.2.0 and v4.2.1.&lt;/p&gt;
&lt;p&gt;Say your Alfresco v4.2.0 project is based on the &lt;a href=&quot;;&gt;maven archetypes&lt;/a&gt; (and shame on you if it&#39;s not), then you could simply override the following &lt;code&gt;&amp;lt;property&amp;gt;&lt;/code&gt; in your pom:&lt;/p&gt;
&lt;div class=&quot;highlight&quot;&gt;&lt;pre&gt;&lt;code class=&quot;language-xml&quot; data-lang=&quot;xml&quot;&gt;&lt;span class=&quot;nt&quot;&gt;&amp;lt;h2-support.version&amp;gt;&lt;/span&gt;${alfresco.version}&lt;span class=&quot;nt&quot;&gt;&amp;lt;/h2-support.version&amp;gt;&lt;/span&gt; &lt;span class=&quot;c&quot;&gt;&amp;lt;!-- WARN WARN WARN!! --&amp;gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Neah huh? But there&#39;s a big &lt;code&gt;WARN&lt;/code&gt; sign in there, why&#39;s that?&lt;/p&gt;
&lt;p&gt;Say the release of H2 Support is broken in any way (in theory it should never happen, but in practice it might happen). Then it might be a bit unfortunate if your poms rely on H2 Support and Alfresco to have exactly the same version. So, while the above should work in most cases, the preferred way to include H2 Support in your project is still as follows:&lt;/p&gt;
&lt;div class=&quot;highlight&quot;&gt;&lt;pre&gt;&lt;code class=&quot;language-xml&quot; data-lang=&quot;xml&quot;&gt;&lt;span class=&quot;nt&quot;&gt;&amp;lt;h2-support.version&amp;gt;&lt;/span&gt;4.2.0&lt;span class=&quot;nt&quot;&gt;&amp;lt;/h2-support.version&amp;gt;&lt;/span&gt; &lt;span class=&quot;c&quot;&gt;&amp;lt;!-- much better! --&amp;gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;h1&gt;Plans for the future&lt;/h1&gt;
&lt;p&gt;In the future we plan to have a different strategy to bring H2 Support for Alfresco. Currently, we simply copy all the PostgreSQL in an H2 friendly package, so that the internal Alfresco machinery will automatically find them. Then, H2 compatibility mode is used to make the PostgreSQL dialect understood by the H2 driver. That&#39;s obviously suboptimal, and we will research methods to skip shuffling files around, but rather override the Alfresco SQL files locator strategy. The new strategy should provide a better integration with any Alfresco release, and we might very well need not new H2 Support releases per Alfresco version.&lt;/p&gt;
&lt;p&gt;If you&#39;d like to help us realizing this integration sweet spot, you&#39;re so much welcome to joink the H2 Support crew!&lt;/p&gt;
<title>SeedUML, an online PlantUML editor</title>
<link href=""/>
<summary type="html">&lt;h1&gt;Finally online&lt;/h1&gt;
&lt;p&gt;It&#39;s my pleasure to announce the availability of &lt;a href=&quot;;&gt;SeedUML&lt;/a&gt;, the online editor for UML diagrams based on the great &lt;a href=&quot;;&gt;PlantUML language&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;As it&#39;s in its early beta stages, I&#39;m sure you&#39;ll find some rough edges here and there, but there&#39;s some great and useful features I&#39;m sure you&#39;ll love. Especially if you&#39;re new to PlantUML, you&#39;ll find a damn easy way to create all sorts of UML diagrams, like &lt;a href=&quot;;&gt;state&lt;/a&gt;, &lt;a href=&quot;;&gt;sequence&lt;/a&gt;, &lt;a href=&quot;;&gt;class&lt;/a&gt;, etc, all with a crystal clear plain text description. The diagram updates as you type, and you can save the image for later use, or simply link it wherever you need it to show up.&lt;/p&gt;
&lt;h1&gt;Quick user guide&lt;/h1&gt;
&lt;p&gt;If you need an user guide, the site is itself not easy enough to use. But let&#39;s give a couple of pointers to start with:&lt;/p&gt;
&lt;li&gt;you need to start a new diagram, you go to &lt;a href=&quot;;&gt;;/a&gt;&lt;/li&gt;
&lt;li&gt;a random diagram ID is generated, and you&#39;ll be redirected to such diagram page (eg: &lt;a href=&quot;;&gt;;/a&gt;)&lt;/li&gt;
&lt;li&gt;remember to bookmark the URL if the diagram is important, as there&#39;s no user save&lt;/li&gt;
&lt;li&gt;you follow PlantUML docs and create beautiful diagram&lt;/li&gt;
&lt;li&gt;whenever you need to edit the doc again, you go back to the same URL (you bookmarked it, right?)&lt;/li&gt;
&lt;p&gt;Done. Easy, huh?&lt;/p&gt;
&lt;p&gt;This is an &lt;strong&gt;early beta&lt;/strong&gt;, use at your own risk (and pleasure, hopefully). Especially, don&#39;t expect to&lt;/p&gt;
&lt;li&gt;be guaranteed that your diagrams will stay there forever&lt;/li&gt;
&lt;li&gt;the service will be up and running at all times&lt;/li&gt;
&lt;li&gt;be able to save hidden diagrams&lt;/li&gt;
&lt;li&gt;have a rock solid syntax highlight&lt;/li&gt;
&lt;li&gt;etc etc etc&lt;/li&gt;
&lt;p&gt;I will share some of the juicy technical details of that site later on on these pages, but for now, have fun and happy diagram authoring!&lt;/p&gt;
<title>H2 support 1.1.1 for Alfresco 3.4.12 Enterprise with Maven</title>
<link href=""/>
<summary type="html">&lt;p&gt;Just a quick update on the &lt;a href=&quot;;&gt;H2 support&lt;/a&gt;
project, today I released the &lt;code&gt;1.1.1&lt;/code&gt; maintenance version which targets
Alfresco v3.4.12 Enterprise.&lt;/p&gt;
&lt;p&gt;Please make sure you always double check the &lt;a href=&quot;;&gt;official documentation&lt;/a&gt;
to pick and choose the right version to use in your Alfresco project.&lt;/p&gt;
&lt;h1&gt;H2 and Maven&lt;/h1&gt;
&lt;p&gt;For &lt;del&gt;the sane&lt;/del&gt; those among you that use the &lt;a href=&quot;;&gt;Maven SDK&lt;/a&gt;,
you should know that &lt;code&gt;H2 support&lt;/code&gt; is used to quickly boot the Alfresco repository
webapp during your development cycles.&lt;/p&gt;
&lt;p&gt;If you&#39;re using a version of Alfresco other than the default 4.x that&#39;s assumed
by the SDK, you must also adapt your H2 support version to be able to start up
Alfresco. It&#39;s as easy as overriding the following maven property:&lt;/p&gt;
&lt;p&gt;Happy development!&lt;/p&gt;
<title>Java StringBuilder myth debunked -- now with content!</title>
<link href=""/>
<summary type="html">&lt;h1&gt;The myth&lt;/h1&gt;
&lt;blockquote&gt;&lt;p&gt;Concatenating two Strings with the plus operator is the source of all evil&lt;/p&gt;
&lt;p&gt;-- Anonymous Java dev&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;NOTE&lt;/strong&gt;: The source code for the tests discussed here can be found on &lt;a href=&quot;;&gt;Github&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;It&#39;s from university time that I learned to regard &lt;code&gt;String&lt;/code&gt; concatenation in Java
using the &#39;+&#39; plus operator as a deadly performance sin. Recently there has been
an internal review at &lt;a href=&quot;;&gt;Backbase R&amp;amp;D&lt;/a&gt; where such recurring
mantra was dismissed as a myth due to &lt;code&gt;javac&lt;/code&gt; using &lt;code&gt;StringBuilder&lt;/code&gt; under the hood
any time you use the plus operator to join Strings. I set myself up to prove
such a point and verify the reality under different environments.&lt;/p&gt;
&lt;h1&gt;The test&lt;/h1&gt;
&lt;p&gt;Relying on your compiler to optimize your &lt;code&gt;String&lt;/code&gt; concatenation means that things
might change heavily depending on the JDK vendor you adopt. As far as platform
support goes for my daily job, three main vendors should be considered:&lt;/p&gt;
&lt;li&gt;Oracle JDK&lt;/li&gt;
&lt;li&gt;IBM JDK&lt;/li&gt;
&lt;li&gt;ECJ -- for developers only&lt;/li&gt;
&lt;p&gt;Moreover, while we officially support Java 5 through 6, we are also looking into
supporting Java 7 for our products, adding another three-folded level of indirection on top of
the three vendors. For the sake of &lt;del&gt;lazyness&lt;/del&gt; simplicity, the &lt;code&gt;ecj&lt;/code&gt; compiled
bytecode will be run with a single JDK, namely Oracle JDK7.&lt;/p&gt;
&lt;p&gt;I prepared a &lt;a href=&quot;;&gt;Virtualbox&lt;/a&gt; VM with all the above JDK
installed, then I developed some classes to express three different concatenation
methods, amounting to three to four concatenations per method invocaiton,
depending on the specific test case.&lt;/p&gt;
&lt;p&gt;The test classes are run a thousands times for each test round, with a total of
100 rounds each test case. The same VM is used to run all the rounds for the same
test case, and it&#39;s restarted across different test cases, all to let the Java
runtime perform all the optimizations it can, without affecting the other test
cases in any way. The default options were used to start all JVMs.&lt;/p&gt;
&lt;p&gt;More details can be found in the benchmark runner &lt;a href=&quot;;&gt;script&lt;/a&gt;.&lt;/p&gt;
&lt;h1&gt;The code&lt;/h1&gt;
&lt;p&gt;Full code for both test cases and the test suite is available on &lt;a href=&quot;;&gt;Github&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The following different test cases were produced to measure performance
differences of the String concatenation with plus against the direct use of a
&lt;pre&gt;&lt;code&gt;// String concat with plus
String result = &quot;const1&quot; + base;
result = result + &quot;const2&quot;;
&lt;hr /&gt;
&lt;pre&gt;&lt;code&gt;// String concat with a StringBuilder
new StringBuilder()
&lt;hr /&gt;
&lt;pre&gt;&lt;code&gt;//String concat with an initialized StringBuilder
new StringBuilder(&quot;const1&quot;)
&lt;p&gt;The general idea is to provide a concatenation both at the head and at the tail
of constant &lt;code&gt;String&lt;/code&gt;s over a variable. The difference between the last two cases,
both making explicit use of &lt;code&gt;StringBuilder&lt;/code&gt;, is in the latter using the 1-arg
constructor which initializes the builder with the initial part of the result.&lt;/p&gt;
&lt;h1&gt;The results&lt;/h1&gt;
&lt;p&gt;Enough talking, down below here you can have a look at the generated graphs, where
each data point corresponds to a single test round (e.g. 1000 executions of the same
test class).&lt;/p&gt;
&lt;p&gt;The discussion of the results and some more juicy details will follow.&lt;/p&gt;
&lt;h2&gt;&lt;img src=&quot;/img/post/catplus.png&quot; title=&quot;Concatenation with plus&quot; alt=&quot;Concatenation with plus&quot; /&gt;&lt;/h2&gt;
&lt;h2&gt;&lt;img src=&quot;/img/post/catsb.png&quot; title=&quot;Concatenation with StringBuilder&quot; alt=&quot;Concatenation with StringBuilder&quot; /&gt;&lt;/h2&gt;
&lt;p&gt;&lt;img src=&quot;/img/post/catsb2.png&quot; title=&quot;Concatenation with initalized StringBuilder&quot; alt=&quot;Concatenation with initialized StringBuilder&quot; /&gt;&lt;/p&gt;
&lt;h1&gt;The discussion&lt;/h1&gt;
&lt;p&gt;Oracle JKD5 is the clear loser here, appearing to be in a B league when compared
to the others. But that&#39;s not really the scope of this exercise, and thus we&#39;ll
gloss over it for the time being.&lt;/p&gt;
&lt;p&gt;That said, there are two other interesting bits I observe in the above graph. The first is that indeed
there is generally quite a difference between the use of the plus operator vs an explicit
&lt;code&gt;StringBuilder&lt;/code&gt;, &lt;em&gt;especially&lt;/em&gt; if you&#39;re using Oracle Java5 which performs tree
times worse the the rest of the crew.&lt;/p&gt;
&lt;p&gt;The second observation is that while it generally holds for most of the JDKs that
an explicit &lt;code&gt;StringBuilder&lt;/code&gt; will offer up to twice the speed as the regular plus
operator, &lt;strong&gt;IBM JDK6 seems not to suffer&lt;/strong&gt; from any performance loss, always averaging
25ms to complete the task in all test cases.&lt;/p&gt;
&lt;p&gt;A closer look at the generated bytecode reveals some interesting details&lt;/p&gt;
&lt;h1&gt;The bytecode&lt;/h1&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;NOTE:&lt;/strong&gt; the decompiled classes are also available on &lt;a href=&quot;;&gt;Github&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Across all possible JDKs &lt;code&gt;StringBuilders&lt;/code&gt; are &lt;strong&gt;always&lt;/strong&gt; used to implement &lt;code&gt;String&lt;/code&gt;
concatenation even in presence of a plus sign.
Moreover, across all vendors and versions, &lt;strong&gt;there is almost no difference at all&lt;/strong&gt;
for the same test case. The only one that stands a bit apart is &lt;a href=&quot;;&gt;&lt;code&gt;ecj&lt;/code&gt;&lt;/a&gt;,
which is the only one to cleverly optimize the &lt;code&gt;CatPlus&lt;/code&gt; test case to invoke
the 1-arg constructor of the &lt;code&gt;StringBuilder&lt;/code&gt; instead of the 0-arg version.&lt;/p&gt;
&lt;p&gt;Comparing the resulting bytecode exposes what could affect performance in the
different scnarios:&lt;/p&gt;
&lt;li&gt;&lt;p&gt;when concatenating with plus, &lt;em&gt;new instances of &lt;code&gt;StringBuilder&lt;/code&gt;&lt;/em&gt; are created
any time a concatenation happens. This can easily result in a performance
degradation due to useless invocation of the constructor plus more stress on
the garbage collector due to throw away instances&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;compilers will take you literally and only initalize &lt;code&gt;StringBuilder&lt;/code&gt; with its
1-arg constructor if and only if you write it that way in the original code. This
results in respectively four and three invocations of &lt;code&gt;StringBuilder.append&lt;/code&gt; for
&lt;a href=&quot;;&gt;CatSB&lt;/a&gt; and &lt;a href=&quot;;&gt;CatSB2&lt;/a&gt;.&lt;/p&gt;&lt;/li&gt;
&lt;h1&gt;The conclusion&lt;/h1&gt;
&lt;p&gt;Bytecode analysis offers the final answer to the original question.&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;Do you need to explicitly use a &lt;code&gt;StringBuilder&lt;/code&gt; to improve performance? &lt;strong&gt;Yes&lt;/strong&gt;&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;The above graphs clearly show that, unless you&#39;re using IBM JDK6 runtime, you will
loss 50% performance when using the plus operator, although it&#39;s the one to perform
slightly worse across the candidates when expliciting &lt;code&gt;StringBuilder&lt;/code&gt;s.&lt;/p&gt;
&lt;p&gt;Also, it&#39;s quite interesting to see how &lt;em&gt;JIT optimizations&lt;/em&gt; impact the overall
performance: for instance, even in presence of different bytecode between the two
explicit &lt;code&gt;StringBuilder&lt;/code&gt; test cases, the end result is absolutely the same in the
long run.&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;/img/post/myth-confirmed.jpg&quot; alt=&quot;Myth confirmed&quot; /&gt;&lt;/p&gt;
<title>The Observer Pattern in Spring</title>
<link href=""/>
<summary type="html">&lt;h1&gt;Observers in Spring&lt;/h1&gt;
&lt;blockquote&gt;&lt;p&gt;To the man-in-the-street, who, I&#39;m sorry to say,&lt;br/&gt;
Is a keen observer of life,&lt;br/&gt;
The word &quot;Intellectual&quot; suggests straight away&lt;br/&gt;
A man who&#39;s untrue to his wife.&lt;/p&gt;
&lt;p&gt;-- W.H. Auden&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;The Observer pattern is a very basic one out of the GoF bible which is unbelivably easy to implement and still quote
powerful so use. Here I present my take on it using the Spring observer pattern which I found quite helpful in designing
extension points for my software.&lt;/p&gt;
&lt;h1&gt;Core classes&lt;/h1&gt;
&lt;p&gt;Pushing back the little NIH devil whispering in my ears, I started by reusing the standard building blocks for the
Observer pattern: &lt;code&gt;java.util.Observable&lt;/code&gt; and &lt;code&gt;java.util.Observer&lt;/code&gt;. The Observable class provides the logic to handle a
registry of Observers, and to propagate updates (I prefer to think more of in terms of events) to all of the registered
&lt;p&gt;In the context of a Spring container, there will be beans to configure and hook together, and it&#39;s key to this exercise
to find a flexible and handy way to connect things together.&lt;/p&gt;
&lt;h1&gt;Automatic registration&lt;/h1&gt;
&lt;p&gt;Supporting code for this blog post can be found on &lt;a href=&quot;;&gt;GitHub&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;When developing a Spring application you&#39;re always instantiating your classes as singletons within the Spring container.
Annotations or XML configurations will take care of initialize instances of your classes, wiring them together in a
connected graph of objects with loose dependencies on the specific concrete classes you adopt in your code.&lt;/p&gt;
&lt;p&gt;As you will always have to declare beans, it would be nice to let Spring wire obects for you in an Observer fashion,
with a minimal coding effort required. The most minimalistic approach I could think of is to just require developers to
declare their observer beans, and put in place enough machinery to automatically hook them to an Observable provided by
the application. In this example I create a &lt;code&gt;ObserverBeanPostProcessor&lt;/code&gt; and a &lt;code&gt;SpringObserver&lt;/code&gt;
tagging interface to identify which beans are actually declaring valid Observers, and register them automatically.&lt;/p&gt;
&lt;p&gt;To complete the picture, the &lt;code&gt;SpringObservable&lt;/code&gt; interface declares which &lt;code&gt;Observer&lt;/code&gt; class it&#39;s able to notify, thus
leveraging the tagging interface and letting the &lt;code&gt;ObserverBeanPostProcessor&lt;/code&gt; know which beans to filter and registser.&lt;/p&gt;
&lt;p&gt;This enables a software component to provide the desired &lt;code&gt;SpringObservable&lt;/code&gt; and the &lt;code&gt;ObserverBeanPostProcessor&lt;/code&gt; beans, where
consumers of such API will be only required to instantiate their &lt;code&gt;Observer&lt;/code&gt; beans.&lt;/p&gt;
&lt;p&gt;Note that &lt;code&gt;Observers&lt;/code&gt; can be themselves &lt;code&gt;Observables&lt;/code&gt;, so that you can easily construct chains of beans in which events
will be propagated. As long as you ensure not to form any cyclic graph, of course.&lt;/p&gt;
&lt;p&gt;In object oriented languages such as Java, patterns are a powerful tool to apply. The Observer is a neat strategy for
cascading changes on objects, or just to propagate events through a series of processors. All in a clean, loosly coupled
&lt;p&gt;The code here is just a proof of concept, not a library which is intended for production use. The concepts and the
implementation are easy enough to be applied in your Spring application without any need for depending on this code.&lt;/p&gt;
<title>Java StringBuilder myth debunked</title>
<link href=""/>
<summary type="html">&lt;p&gt;&lt;em&gt;NOTE: this post was published before it was ready, the real content can now be found &lt;a href=&quot;2013/03/11/java-stringbuilder-myth-now-with-content/&quot;&gt;here&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;
<title>A svn post commit hook to comment on Jira</title>
<link href=""/>
<summary type="html">&lt;p&gt;If I had to pick a single thing that really bothers me of &lt;a href=&quot;;&gt;Jira OnDemand&lt;/a&gt;
is that it &lt;a href=&quot;;&gt;doesn&#39;t support our hosted svn&lt;/a&gt; in any
possible way.&lt;/p&gt;
&lt;p&gt;The biggest pain developers like me have without any basic integration between the VCS and the ticketing system is that any time you have to
test an issue, perform some code reviews, sort out some merging or simply digging the history of a given piece of code, it wastes your time to
switch between all of your unconnected tools to accomplish your task. As an example, at &lt;a href=&quot;;&gt;Backbase&lt;/a&gt; we use
&lt;a href=&quot;;&gt;Trac&lt;/a&gt; to look at our code on a browser, and we end up having to type URLs by hand to switch on and off Jira.&lt;/p&gt;
&lt;p&gt;How hard could it be to simply &lt;em&gt;link&lt;/em&gt; Jira to our commits?&lt;/p&gt;
&lt;h2&gt;A hint to the solution&lt;/h2&gt;
&lt;p&gt;Looking at a way to fix this issue, I first had an intuition: what our Jira &lt;em&gt;does&lt;/em&gt; support are web links to an issue. Trac is
just another web site, why can&#39;t we use application links instead of listing the commit messages as Jira comments? After all,
there&#39;s a &lt;a href=&quot;;&gt;rich API&lt;/a&gt; that I can use to
script the hell out of our commits! It literally took me 40 minutes to come up with the following:&lt;/p&gt;
&lt;script src=&quot;;&gt;&lt;/script&gt;
&lt;p&gt;It currently features:&lt;/p&gt;
&lt;li&gt;creates a &lt;em&gt;Related commits&lt;/em&gt; link on each Jira issue mentioned in your commit comment&lt;/li&gt;
&lt;li&gt;multiple Jira keys in the same commit message supported&lt;/li&gt;
&lt;p&gt;That&#39;s it. Not an impressive list of features, but enough for 40m hacking on bash scripts. When we&#39;ll have this hook installed
in our svn server, we can easily go from the Jira issue to all the diffs associated with it.&lt;/p&gt;
&lt;p&gt;This facilitates code reviews and
issue verification or analysis at a later stage, enormously simplifying the life of every developer by providing that dead-simple
integration that Atlassian doesn&#39;t want to provide out of the box.&lt;/p&gt;
&lt;p&gt;I understand the performance reasons behind avoid fully integrating
on-premise svn with OnDemand instances. Still, they could do much, much better than say they&#39;re sorry and live their customers
lives being miserable because of it.&lt;/p&gt;
<title>H2 support 1.5 for Alfresco 4.1.1 Enterprise</title>
<link href=""/>
<summary type="html">&lt;p&gt;After Alfresco version 4.1.1 Enterprise came out earlier this month,
&lt;a href=&quot;;&gt;H2 support&lt;/a&gt; needed to
stay up to date and release a new version which incorporates the
few schema changes in the Alfresco database. Thanks to
&lt;a href=&quot;;&gt;Jon Evans&lt;/a&gt; and &lt;a href=&quot;;&gt;Ixxus&lt;/a&gt;,
H2 Support v1.5 it&#39;s already out there!&lt;/p&gt;
&lt;h1&gt;Version management&lt;/h1&gt;
&lt;a href=&quot;;&gt;usual&lt;/a&gt;,
H2 support follows its own version numbering scheme, and you need to
double check which one to use depending on the Alfresco version you&#39;re
running: version 1.5 only supports Alfresco 4.1.1 Enterprise, so if
you&#39;re targeting other versions go and update your POM.&lt;/p&gt;
&lt;h1&gt;Availability on Maven Central&lt;/h1&gt;
&lt;p&gt;By the time of this writing, H2 support was just pushed to
&lt;a href=&quot;;&gt;Sonatype OSS&lt;/a&gt;, and while it
should happen shortly, it still has to be synchronized with Maven
Central. If the following Maven dependency fails to resolve, try to
download and install it from
&lt;a href=&quot;;&gt;here&lt;/a&gt;:&lt;/p&gt;
&lt;p&gt;On a side note, the stats feature of Sonatype Nexus are plain awesome.
I can have direct insights of the amount of downloads of H2 support
over time, split by version number. Check it out:&lt;/p&gt;
&lt;p&gt;&lt;img src=&quot;/img/post/h2stats.png&quot; title=&quot;H2 download stats&quot; alt=&quot;H2 download stats&quot; /&gt;&lt;/p&gt;
&lt;h1&gt;Your chance to be awesome&lt;/h1&gt;
&lt;p&gt;Jon was just great to help H2 support and provide the patch that made
1.5 happen. It&#39;s always inspiring to see how OpenSource drives people
to build something together, spending time to shape technology to be
the way we need, asking for nothing else in return than just be part
of the community.&lt;/p&gt;
&lt;p&gt;H2 support is a tiny project, and requires little
development and maintenance. Still, you can always help by either
testing it against &lt;a href=&quot;;&gt;undocumented Alfresco versions&lt;/a&gt;, or &lt;a href=&quot;;&gt;reporting bugs&lt;/a&gt;
or your wish list as soon as you figure them out.&lt;/p&gt;
&lt;p&gt;Thanks for reading this and happy Alfresco hacking!&lt;/p&gt;
<title>October Amsterdam Clojure 2012 is coming up!</title>
<link href=""/>
<summary type="html">&lt;p&gt;Saturday, October 27th. Less than two weeks. That&#39;s the time when
October Amsterdam Clojure, the biggest Clojure free event in the
Netherlands, will be up on stage. I&#39;m so incredibly excited about it,
I can&#39;t wait to see all the seasoned clojurians, passionate
technologists and curious newbies meet together to discuss one of the
most intriguing technologies of our present day. Here&#39;s a couple of
things to remind you of what&#39;s ahead of us.&lt;/p&gt;
&lt;h1&gt;Don&#39;t forget to bring a ticket&lt;/h1&gt;
&lt;p&gt;As much as the event is totally free to attend, our limited logistics
imposes us a limit on the attendance. In order to reserve your seat at
the event, just go on the event
&lt;a href=&quot;;&gt;Meetup page&lt;/a&gt; and RSVP. This much,
and you&#39;ll be joining us and have full access to the conference.&lt;/p&gt;
&lt;h1&gt;How to reach us&lt;/h1&gt;
&lt;p&gt;As it goes with all Amsterdam Clojurians regular meetup, the big
October event will be also hosted by
&lt;a href=&quot;;&gt;Backbase&lt;/a&gt;. You can find the &lt;a href=&quot;;&gt;directions to
the venue&lt;/a&gt; on the official &lt;a href=&quot;;&gt;event page&lt;/a&gt;.
While it&#39;s not far from Central Station, make sure to take note of the
correct address. Once you&#39;re in the neighborhood, it&#39;s easy to find
us: just go to the main entrance of the big, glass building with the
huge newspapers logos on top. Yes,
&lt;a href=&quot;;&gt;that one&lt;/a&gt;.
You&#39;ll find some of our awesome Clojurian volunteer to wait for you
&lt;h1&gt;Afterparty drinkup&lt;/h1&gt;
&lt;p&gt;We&#39;re still in the process of organizing a drinkup right after the
event, make sure your agenda is free in order to join the swarm of
Clojure coders and discuss functional programming philosophies over a
couple of beers!&lt;/p&gt;
&lt;h1&gt;Stay up to date&lt;/h1&gt;
&lt;p&gt;Events are complex beasts, and we&#39;ll try hard to let you always be up
to date with any sudden change of the plan. If you want to double
check the official plan, here&#39;s where you can find all the info you
&lt;li&gt;&lt;p&gt;the official &lt;a href=&quot;;&gt;event page&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;#OctAmsClj at
&lt;a href=&quot;;&gt;;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;our official social channels (&lt;a href=&quot;;&gt;Twitter&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;our official social channels (&lt;a href=&quot;;&gt;Twitter&lt;/a&gt;,
(Facebook)[] and
&lt;a href=&quot;;&gt;Google+&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;p&gt;Looking forward to meet you there!&lt;/p&gt;
<title>org4idea adds org-mode support to Intellij IDEA</title>
<link href=""/>
<summary type="html">&lt;p&gt;&lt;em&gt;tl;dr:&lt;/em&gt; &lt;a href=&quot;;&gt;org4idea&lt;/a&gt; is a brand new
project to add &lt;a href=&quot;;&gt;org-mode&lt;/a&gt; support to &lt;a href=&quot;;&gt;IntelliJ IDEA&lt;/a&gt;&lt;/p&gt;
&lt;h2&gt;A coin with two sides&lt;/h2&gt;
&lt;p&gt;Given the gargantuan size of the feature list of
&lt;a href=&quot;;&gt;org-mode&lt;/a&gt;, there&#39;s hardly any competition of
note taking systems for hackers. I&#39;m completely sold on it since long
time already, so much that
&lt;a href=&quot;;&gt;uptime(1)&lt;/a&gt; returns
always a quite precise approximation of the Emacs process lifetime.&lt;/p&gt;
&lt;p&gt;While such setup makes for a merry and seamless experience while
hacking on my &lt;a href=&quot;;&gt;Clojure&lt;/a&gt; projects, the dream
breakes when I move to work on Java code, where I shall have no other
IDE besides &lt;a href=&quot;;&gt;IntelliJ IDEA&lt;/a&gt;.&lt;/p&gt;
&lt;h2&gt;Baby steps&lt;/h2&gt;
&lt;p&gt;As there&#39;s no better way than a quick hacking session to start the
weekend, I eventually decided to take some time to put together a
minimal plugin to support editing org files within IntelliJ: a few
hours later &lt;a href=&quot;;&gt;org4idea&lt;/a&gt; landed on my
GitHub account. It&#39;s a ridiculously tiny plugin at the moment, only
providing syntax highlight for comments and outlines.&lt;/p&gt;
&lt;p&gt;While I&#39;m
not planning to support all the features and plugins of org in
IntelliJ you can safely bet I&#39;ll be adding new features with time. You
can always open an &lt;a href=&quot;;&gt;issue&lt;/a&gt;
to try to buy some karma points to that specific feature you desperately
need to be implemented (well, in such cases you could also realize you&#39;re just
one fork away).&lt;/p&gt;
&lt;p&gt;While the plugin still awaits approval in the official
&lt;a href=&quot;;amp;pluginId=7095&quot;&gt;repository&lt;/a&gt; you
can manually install the plugin by downloading &lt;a href=&quot;;&gt;org4idea.jar&lt;/a&gt;
and feed it to the &lt;em&gt;Settings -&gt; Plugins -&gt; Install plugin from disk&lt;/em&gt;
&lt;p&gt;Happy GTD!&lt;/p&gt;
<title>Slides from Dispatch in Clojure</title>
<link href=""/>
<summary type="html">&lt;h2&gt;Presentation slides&lt;/h2&gt;
&lt;p&gt;A bit late, and already announced
&lt;a href=&quot;;&gt;elsewhere&lt;/a&gt;, but
here you can find the slides from the &lt;em&gt;Dispatch in Clojure&lt;/em&gt;
presentation I gave at the
&lt;a href=&quot;;&gt;August 2012 meetup&lt;/a&gt;
of the
&lt;a href=&quot;;&gt;Amsterdam Clojurians&lt;/a&gt;
group. Hopefully it will ease you bearing to wait for the &lt;a href=&quot;;&gt;October
Amsterdam Clojure&lt;/a&gt; event later in October :-)&lt;/p&gt;
&lt;p&gt;The code samples I used in the presentation are available on &lt;a href=&quot;;&gt;GitHub&lt;/a&gt;.&lt;/p&gt;
&lt;iframe src=&quot;; width=&quot;427&quot; height=&quot;356&quot; frameborder=&quot;0&quot; marginwidth=&quot;0&quot; marginheight=&quot;0&quot; scrolling=&quot;no&quot; style=&quot;border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px&quot; allowfullscreen&gt; &lt;/iframe&gt;
&lt;h2&gt;The story behind&lt;/h2&gt;
&lt;p&gt;In a previous meetup a discussion arose about
&lt;a href=&quot;;&gt;protocols&lt;/a&gt; and how they relate to
&lt;a href=&quot;;&gt;mixins&lt;/a&gt; in other languages such
as &lt;a href=&quot;;&gt;Ruby&lt;/a&gt;. A quick mention to virtual
methods dispatch table was enough to let my head spin around all the
details I was missing on low level Clojure mechanics. A presentation
was due.&lt;/p&gt;
&lt;h2&gt;What&#39;s in&lt;/h2&gt;
&lt;p&gt;What I was curious about, and eventually ended in the presentation, is
how Clojure implements function calls and method dispatch from both a
low level JVM and high level language syntax perspectives, and how
they relate to each other. What&#39;s (briefly) covered in the
&lt;li&gt;JVM bytecodes used for method call&lt;/li&gt;
&lt;li&gt;plain &lt;a href=&quot;;&gt;function call&lt;/a&gt; in Clojure&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;;&gt;multimethods&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&quot;;&gt;protocols&lt;/a&gt;&lt;/li&gt;
&lt;p&gt;What couldn&#39;t be entered in the presentation is the interesting
digressions we had during the meetup using an open REPL, some sample
projects and a Java decompiler.&lt;/p&gt;
&lt;p&gt;Video recordings are still a pending TODO in the meetup list, so if
you&#39;re around Amsterdam make sure you come and &lt;a href=&quot;;&gt;join us&lt;/a&gt; for some other
awesome Dutch Clojure nights!&lt;/p&gt;
<title>H2 support updated to the latest Alfresco versions</title>
<link href=""/>
<summary type="html">&lt;p&gt;&lt;strong&gt;tl;dr:&lt;/strong&gt; two new releases of &lt;a href=&quot;;&gt;H2 Support&lt;/a&gt; are available, to support both Alfresco v4.0.1 and v4.0.2 Enterprise edition&lt;/p&gt;
&lt;p&gt;Time flies, and (good) software always keeps a fast development pace. This applies to &lt;a href=&quot;;&gt;Alfresco&lt;/a&gt;, which released a couple of Enterprise versions since I last updated the &lt;a href=&quot;;&gt;H2 Support&lt;/a&gt; module. Promptly, &lt;a href=&quot;!/pjlucidi&quot;&gt;Piergiorgio Lucidi&lt;/a&gt; &lt;a href=&quot;;&gt;found out&lt;/a&gt; that the latest H2 Support version was incompatible with Alfresco v4.0.2. Time for a new release.&lt;/p&gt;
&lt;h2&gt;Double rainbows&lt;/h2&gt;
&lt;p&gt;Last time I released H2 Support Alfresco was still on v4.0.0, with v4.0.1 and v4.0.2 already released in the meanwhile. The effort to upgrade H2 Support is fairly trivial, as it only requires some diff&amp;amp;merge of DB related configuration from the original Alfresco codebase to H2 Support sources. Hence, not one but &lt;strong&gt;two&lt;/strong&gt; releases of H2 Support were issued today, namely&lt;/p&gt;
&lt;li&gt;&lt;p&gt;&lt;a href=&quot;;&gt;v1.4&lt;/a&gt; -- H2 Support for Alfresco v4.0.2&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a href=&quot;;&gt;v1.3&lt;/a&gt; -- H2 Support for Alfresco v4.0.1&lt;/p&gt;&lt;/li&gt;
&lt;p&gt;As usual, please refer to the &lt;a href=&quot;;&gt;official documentation&lt;/a&gt; for matching H2 Support and Alfresco versions.&lt;/p&gt;
&lt;h2&gt;Availability on Central&lt;/h2&gt;
&lt;p&gt;The new releases are already available on OSS Sonatype &lt;a href=&quot;;&gt;maven repository&lt;/a&gt;. Give it enough time and they&#39;ll end up in Maven Central.&lt;/p&gt;
<title>Legacy artifacts repository update: going remote</title>
<link href=""/>
<summary type="html">&lt;h1&gt;The case against&lt;/h1&gt;
&lt;p&gt;After &lt;a href=&quot;;&gt;showing&lt;/a&gt; how to use your version control repository to host legacy libraries, &lt;a href=&quot;;&gt;Tim O&#39;Brien&lt;/a&gt; made a case against its use mentioning how a maintenance hell it would be to use such a strategy, and that a repository manager like &lt;a href=&quot;;&gt;Nexus&lt;/a&gt; or &lt;a href=&quot;;&gt;Artifactory&lt;/a&gt; is the preferred solution. After all, with a local repository in your sources you&#39;re indeed unable to &lt;strong&gt;download&lt;/strong&gt; the JAR, so that any dependent project wouldn&#39;t be able to compile against your transitive dependencies. Isn&#39;t it part of the maven revolution to never, ever check in your libraries in your VCS?&lt;/p&gt;
&lt;h1&gt;The case for&lt;/h1&gt;
&lt;p&gt;When your project has a mid-big scale, and you depend on a tens of legacy/funny libraries that the whole Internet can&#39;t provide, which are maybe still likely to get updates, you should &lt;del&gt;question your project&lt;/del&gt; take the chance to leverage a repository manager. But, if your project is relatively small, with just a bunch of stray dependencies and no access to a repository manager for any reason, there&#39;s little value to gain from building an infrastructure around your JARs, and you can easily leverage a piece of infrastructure you&#39;re most likely to have already: your remote or centralized VCS repository.&lt;/p&gt;
&lt;h1&gt;[Not only] Github&lt;/h1&gt;
&lt;p&gt;While &lt;a href=&quot;;&gt;Github&lt;/a&gt; is my source hosting service of choice, and I&#39;m sticking to it for the sake of my example, the strategy is not limited to it, and as long as you have plain HTTP access to your source files you can create such an integration. &lt;a href=&quot;;&gt;SVN on Google Code&lt;/a&gt; is just another option.&lt;/p&gt;
&lt;p&gt;That said, let&#39;s get to the juicy part. The main problem with a &lt;code&gt;file://&lt;/code&gt; based repository is that absolute URLs and locality of artifacts get in the way of other people leveraging your project, eventually breaking transitive dependencies access. The trick is then to just point to the remote location where your sources are already hosted and available, still exploiting the Maven repository layout. As already explained &lt;a href=&quot;;&gt;elsewhere&lt;/a&gt;, here&#39;s the &lt;code&gt;&amp;lt;repository&amp;gt;&lt;/code&gt; definition to put in your POM in case you&#39;re on Github:&lt;/p&gt;
&lt;p&gt;Where you have to replace &lt;code&gt;$USER&lt;/code&gt;, &lt;code&gt;$PROJECT&lt;/code&gt; and &lt;code&gt;$PATH&lt;/code&gt; with your Github username, your project name and the path to your maven repository root within your sources (e.g. &lt;code&gt;src/main/lib&lt;/code&gt; in the previous article).&lt;/p&gt;
<title>Legacy libraries for your maven build</title>
<link href=""/>
<summary type="html">&lt;h1&gt;Legacy libraries&lt;/h1&gt;
&lt;p&gt;Dealing with legacy code is always tricky, and adapting your tooling to leverage them is sometimes plain hard. Especially when you&#39;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&#39;t ship with a POM, therefore they don&#39;t mavenly exist.&lt;/p&gt;
&lt;h1&gt;Local repositories FTW&lt;/h1&gt;
&lt;p&gt;&lt;strong&gt;UPDATE:&lt;/strong&gt; following the argument from &lt;a href=&quot;;&gt;Tim O&#39;Brien&lt;/a&gt;, I wrote a &lt;a href=&quot;;&gt;follow up&lt;/a&gt; to also exploit Github as a remote repository using the same storage strategy&lt;/p&gt;
&lt;p&gt;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 &lt;a href=&quot;;&gt;Alfresco&lt;/a&gt;, to enable &lt;a href=&quot;;&gt;Lambdalf&lt;/a&gt; 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:&lt;/p&gt;
&lt;p&gt;One solution I found that doesn&#39;t require setting up your publicly available &lt;a href=&quot;;&gt;Nexus&lt;/a&gt; repository, nor using someone else&#39;s &lt;a href=&quot;;&gt;Artifactory&lt;/a&gt;, is to provide the problematic JARs in a maven repository as part of your sources. Suppose you have a mysterious &lt;code&gt;fluff.jar&lt;/code&gt; library you need to include in your classpath, here&#39;s how it works:&lt;/p&gt;
&lt;li&gt;&lt;p&gt;place the JAR file in &lt;code&gt;src/main/lib/fluff/fluff/unknown/fluff-unknown.jar&lt;/code&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;setup the dependency in your POM:&lt;/p&gt;
&lt;p&gt; &lt;dependencies&gt;
&lt;li&gt;&lt;p&gt;still in your POM, enable the local repository:&lt;/p&gt;
&lt;p&gt; &lt;repositories&gt;
&lt;p&gt;Voil&amp;aacute;. You just created a local, portable repository in your sources and instructed Maven to look there for artifacts.&lt;/p&gt;
&lt;p&gt;A couple of golden rules for all the cowboy programmers out there:&lt;/p&gt;
&lt;li&gt;always, always, &lt;strong&gt;always check if the license allows you to redistribute the libraries&lt;/strong&gt; you&#39;re going to include in your project&lt;/li&gt;
&lt;li&gt;never, never, &lt;strong&gt;never distribute a piece of software you&#39;re not entitled to give away&lt;/strong&gt; and &lt;strong&gt;attach the license of all third party libraries&lt;/strong&gt; along with your project&lt;/li&gt;
&lt;p&gt;That said, I&#39;ll leave you to your local Maven repositories. Happy building!&lt;/p&gt;
<title>Debug your build with the plan maven plugin</title>
<link href=""/>
<summary type="html">&lt;h1&gt;Contention over configuration&lt;/h1&gt;
&lt;p&gt;While &lt;a href=&quot;;&gt;ThoughtWorks&lt;/a&gt; put it &lt;a href=&quot;;&gt;on hold&lt;/a&gt;, 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&#39;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.&lt;/p&gt;
&lt;h1&gt;Plan plugin FTW&lt;/h1&gt;
&lt;p&gt;I ended up writing a small plugin to help me debugging the build by dumping the execution plan. I originally named it &lt;a href=&quot;;&gt;&lt;code&gt;plan-maven-plugin&lt;/code&gt;&lt;/a&gt;, and put all the sources on &lt;a href=&quot;;&gt;github&lt;/a&gt;. As the plugin is already on &lt;a href=&quot;;&gt;Maven Central&lt;/a&gt;, you only need to place the following in your &lt;code&gt;settings.xml&lt;/code&gt;:&lt;/p&gt;
&lt;p&gt;Thanks to &lt;a href=&quot;;&gt;David Thume&lt;/a&gt;, this is what it looks like now:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;$ 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] 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] 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)
&lt;p&gt;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&#39;s possibly going wrong. Enjoy!&lt;/p&gt;
<title>Spring surf Clojure and Alfresco H2 support now in Maven Central</title>
<link href=""/>
<summary type="html">&lt;p&gt;&lt;strong&gt;tl;dr:&lt;/strong&gt; I had to change the groupId of both
&lt;a href=&quot;;&gt;h2-support&lt;/a&gt; and
&lt;a href=&quot;;&gt;spring-webscripts-addon-clojure&lt;/a&gt;. Good
news is, they&#39;re now available on Maven Central!&lt;/p&gt;
&lt;h2&gt;Build management dilemma&lt;/h2&gt;
&lt;p&gt;Part of &lt;a href=&quot;;&gt;my company&lt;/a&gt; offering is an Alfresco
based CMS, which we build the
&lt;a href=&quot;;&gt;maven way&lt;/a&gt;. 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&#39;m maintaining an
H2 &lt;a href=&quot;;&gt;compatibility module&lt;/a&gt;
for Alfresco it&#39;s natural for me to integrate and use it.&lt;/p&gt;
&lt;p&gt;There was only one thing blocking this process, and that&#39;s the maven
repository where such artifact were deployed.&lt;/p&gt;
&lt;h2&gt;Deploy on Central&lt;/h2&gt;
&lt;p&gt;As much as I love &lt;a href=&quot;;&gt;Clojars&lt;/a&gt;, it still requires to be manually configured
when dealing with a pure Maven build. Since it&#39;s not quite an option to add
an artifacts repository for something as small as &lt;code&gt;h2-support&lt;/code&gt;, I
decided to just follow the guidelines for Maven Central sync on
&lt;a href=&quot;;&gt;OSS Sonatype&lt;/a&gt; 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
&lt;a href=&quot;;&gt;v1.1&lt;/a&gt; and
&lt;a href=&quot;;&gt;v1.2&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;But, as the only change in the POM is &quot;non functional&quot; such as
description, developers and such, it&#39;s not going to hurt much I
&lt;p&gt;This move is reflected also in the currently unreleased
&lt;code&gt;spring-webscripts-addon-clojure&lt;/code&gt;, so if you&#39;ll be using it or
you need &lt;code&gt;h2-support&lt;/code&gt; remember to use the &lt;code&gt;tk.skuro.*&lt;/code&gt; group IDs, and
you won&#39;t need to add a &lt;code&gt;&amp;lt;repository&amp;gt;&lt;/code&gt; to your POM ever again.&lt;/p&gt;
&lt;p&gt;Thanks &lt;a href=&quot;;&gt;Sonatype&lt;/a&gt; for the awesome service!&lt;/p&gt;
<title>H2 support updated for Alfresco 4.x</title>
<link href=""/>
<summary type="html">&lt;h2&gt;H2 Support reloaded&lt;/h2&gt;
&lt;p&gt;Some time ago I &lt;a href=&quot;/2011/08/03/h2-embedded-db-and-alfresco-3-4/&quot;&gt;announced&lt;/a&gt; a &lt;a href=&quot;;&gt;module&lt;/a&gt; to enhance &lt;a href=&quot;;&gt;Alfresco&lt;/a&gt; in order to support H2 as its persistent data storage. While it was successfully tested against Alfresco v3.4 and v3.5, &lt;a href=&quot;;&gt;@mindthegab&lt;/a&gt; pointed me out that Alfresco v4.x wasn&#39;t even starting when using the H2 module.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h2&gt;Matching versions&lt;/h2&gt;
&lt;p&gt;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&#39;re running, namely:&lt;/p&gt;
&lt;th&gt;H2 module&lt;/th&gt;&lt;th&gt;Alfresco versions supported&lt;/th&gt;
&lt;p&gt;The artifacts for both versions are available on &lt;a href=&quot;;&gt;clojars&lt;/a&gt;, please refer to the official documentation for the usage guide.&lt;/p&gt;
<title>Jekyll, Github and Emacs</title>
<link href=""/>
<summary type="html">&lt;blockquote&gt;&lt;p&gt;&lt;strong&gt;tl;dr:&lt;/strong&gt; I moved from Wordpress to &lt;a href=&quot;;&gt;Jekyll&lt;/a&gt;, you can now find the sources for this blog on &lt;a href=&quot;;&gt;Github&lt;/a&gt;&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;It has been a great adventure to host my blog on a private machine for &lt;a href=&quot;;&gt;more than two years&lt;/a&gt;. 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 &lt;a href=&quot;;&gt;Wordpress&lt;/a&gt; instance was not optimal anymore.&lt;/p&gt;
&lt;p&gt;I also gave the whole blog a new look, shamelessly copying much of &lt;a href=&quot;;&gt;Zach Holman&lt;/a&gt; design, I think it greatly improves readibility. Feedback welcome!&lt;/p&gt;
&lt;h2&gt;Going down&lt;/h2&gt;
&lt;p&gt;It first happened at the beginning of this year that &lt;a href=&quot;;&gt;one of my posts&lt;/a&gt; attracted a good deal of attention. While it wasn&#39;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 &lt;a href=&quot;;&gt;LAMP&lt;/a&gt;) system down. It has to be noted that I&#39;m no PHP nor Wordpress expert, and I was also so sloppy to let every single &lt;a href=&quot;;&gt;apache&lt;/a&gt; process (-&gt; 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 &lt;a href=&quot;;&gt;several&lt;/a&gt; &lt;a href=&quot;;&gt;times&lt;/a&gt; &lt;a href=&quot;;&gt;later&lt;/a&gt; on, it was everytime on the edge of the catastrophe. It was clear to me that my Wordpress blog was to be replaced.&lt;/p&gt;
&lt;p&gt;Note: I&#39;m not saying LAMP + Wordpress is not a good option for a personal blog, it just wasn&#39;t an attractive option for me to get into the details of how to make it robust enough in my case.&lt;/p&gt;
&lt;h2&gt;Static content&lt;/h2&gt;
&lt;p&gt;PHP allows for highly dynamic content via server side rendering. Cool, but does a blog &lt;em&gt;really&lt;/em&gt; 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&#39;s hardly any difference in a page in its whole lifetime. All the &lt;a href=&quot;;&gt;features&lt;/a&gt; you might get out of a blog engine such as Wordpress are in my case of no real use.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h2&gt;Github Pages and Jekyll&lt;/h2&gt;
&lt;p&gt;I did some initial experiments with a fully custom &lt;a href=&quot;;&gt;Clojure&lt;/a&gt; blog engine, where I explored various combinations of &lt;a href=&quot;;&gt;Compojure&lt;/a&gt;, &lt;a href=&quot;;&gt;Noir&lt;/a&gt;, &lt;a href=&quot;;&gt;Hiccup&lt;/a&gt;, &lt;a href=&quot;;&gt;Enlive&lt;/a&gt;, etc. While it was a nice exercise, it was really more of a technical exercise which wasn&#39;t getting me nowhere, as I kept running in circles while picking up new technologies every other day. &lt;a href=&quot;;&gt;Github Pages&lt;/a&gt; was there, tempting me all along the way: I already loved &lt;a href=&quot;;&gt;Git&lt;/a&gt; and &lt;a href=&quot;;&gt;Markdown&lt;/a&gt;, 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 &lt;a href=&quot;;&gt;migration guide&lt;/a&gt; that I couldn&#39;t deny anymore Github hosted &lt;a href=&quot;;&gt;Jekyll&lt;/a&gt; was the best option I had.&lt;/p&gt;
&lt;h2&gt;Emacs, of course&lt;/h2&gt;
&lt;p&gt;Migrating to Jekyll took just a couple of days, I even wrote my first Ruby &lt;a href=&quot;;&gt;code&lt;/a&gt; ever. Everything looked pretty promising, but I needed an extra step: there was no point in having a plain text interface if I couldn&#39;t use the &lt;a href=&quot;;&gt;Almighty Emacs&amp;trade;&lt;/a&gt; editor as the main interface to my blog. Sure thing, I wasn&#39;t the first to think so, and I promptly found an &lt;a href=&quot;;&gt;initial implementation&lt;/a&gt; I could use to start walking the Emacs way.&lt;/p&gt;
&lt;p&gt;Needless to say, I&#39;m writing this very post from Emacs. And it feels good.&lt;/p&gt;
&lt;p&gt;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&#39;t be more happy!&lt;/p&gt;