If you never heard of tig, well, probably you are not a fan of git, or the
command line, or just both. There are already a few blog posts about it, like this one, or this one. So if you don’t know what tig is, go read them.

The only think I didn’t like about tig, is that it comes by default with a not very
pleasant color scheme. Luckily colours are configurable, so I decided to
define a custom color scheme, that aims to recall the 256 colours vim theme desert. Here are a couple of screenshot, that shows how tig is going to look with it.

Screen Shot 2013-05-27 at 09.41.19

Screen Shot 2013-05-27 at 09.41.46

So, if you like it, you can download it from my GitHub page. If you would like to improve it, please write, or open a pull request, or wathever.

JBoss 7.1.1 comes with JBossWS-cxf-4.0.2.GA bundled. But if you plan to deploy a Spring based application, containing some web services, be sure to update to JBoss-cxf-4.1.1.Final, otherwise you will incur in the following error:

Caused by: java.lang.NoClassDefFoundError: org/springframework/beans/BeansException
 at org.jboss.wsf.stack.cxf.client.configuration.JBossWSBusFactory.getSpringBusFactory(JBossWSBus

That’s very simple: follow the official instructions ;) The problem is caused by a known bug.

For my last couple of Java projects, I decided to use Maven. It was a long due  experiment. I’m not gonna talk about my experience with it, maybe in a future post, suffice to say that I’m quite satisfied. The first project went to production a couple of weeks ago, and all went fine, except for one thing. Reading the specs of the project, I overlooked the tiny little print that stated: “The final product must be built with Ant“.
, was the first thing I thought. Obviously, the client refused the proposal to install Maven. As a programmer, I usually try to solve my problem the lazy way. I really don’t want to commit all the project dependencies to the Subversion repository. That sort of freaks me out. Here enters the Ant mvn task. For the sake of simplicity, the mvn task can be seen as, more or less, a wrapper that allows to invoke a Maven build from ant. I felt I was on the right track, but I thought I had one more problem to solve: how to install Maven on any possible build machine ? Luckily, the answer lied in the documentation.

<target name="build">
    <artifact:mvn mavenVersion="3.0.3" pom="./pom.xml">
        <arg value="package"/>

This snippet shows how to invoke a Maven goal, specifying the pom location and the Maven version we would like to use. The first time you run the build, the mvn task will take care of downloading mvn with all the necessary dependencies. That was easy.
There is one last thing to take care of though, dependencies. My project depends on a few libraries, and in particular on the JMS jar, which, due to license restrictions, cannot be distributed through a Maven repository. So I have to install it in my local repo, and the following snippet shows how:

<artifact:pom id="jms-dep" file="deps/jms-1.1.pom"/>
<artifact:install file="deps/jms-1.1.jar">
    <pom refid="jms-dep"/>

This snippet should go in a target executed before the build one. So, let’s have a look at the complete build.xml:

<project name="gestoreAlert" default="build" basedir="." xmlns:artifact="antlib:org.apache.maven.artifact.ant">
        Invoke mvn package goal.

    <path id="maven-ant-tasks.classpath" path="maven-ant-tasks-2.1.3.jar" />
    <typedef resource="org/apache/maven/artifact/ant/antlib.xml"
        classpathref="maven-ant-tasks.classpath" />

   <artifact:localRepository id="local.repository" path="~/.m2/repository" layout="default" />

   <target name="deps">
       <artifact:pom id="jms-dep" file="deps/jms-1.1.pom"/>
       <artifact:install file="deps/jms-1.1.jar">
           <pom refid="jms-dep"/>

       <artifact:pom id="jboss-javaee-dep" file="deps/jboss-javaee-5.1.0.GA.pom"/>
       <artifact:install file="deps/jboss-javaee-5.1.0.GA.jar">
          <pom refid="jboss-javaee-dep"/>

       <artifact:pom id="kryo-dep" file="deps/kryo-2.0.5.pom"/>
       <artifact:install file="deps/kryo2-2.05-all.jar">
          <pom refid="kryo-dep"/>

   <target name="build" depends="deps">
       <artifact:mvn mavenVersion="3.0.3" pom="./pom.xml">
           <arg value="package"/>

Any key on the keyboardA few weeks ago I was waiting for my flight at the Zurich Airport. While watching an episode of the last season of House, a guy tapped on my shoulder asking for help with the wifi connection. He wanted to know if he could surf the web. Obviously there were a few different available network. So I answered him «Sure, just connect to any open network, and surf on some website [...]». So he said: «Ok, thanks, I’ll connect to any network.» At first I didn’t pay much attention to his answer, but just a second before leaving the wating lounge, I checked the available networks with my phone. And there was the any network. Those Swiss have some humor :-)

A few months ago, a MacBookPro became my working machine. As a long time Linux user, I’m pretty much used to case sensitivity in everything I do. Like searching in a man page, for instance. If I don’t remember the meaning of ‘-l’, why should I care about ‘-L’? So, if you’re like me, you might wanna have a look at /private/etc/man.conf at the lines

PAGER        /usr/bin/less -is
BROWSER      /usr/bin/less -is

and remove the -i options.

You’re probably thinking “Wait a moment, you really wrote a post about this ancient technology in 2012?” Yeah, I know, I use WhatsApp too, and not only because it is based on an Erlang backend. So, if you’re already an expert on the matter, you can stop reading now, I won’t take it personally ;)

A few weeks ago, I read some articles regarding the problem of SMS’ cost, when sending texts with accented caps. One of the article’s heading was something like “Beware the accents, they are worth 70 characters”.  Come again please, a single letter that takes 70s? That must be quite some hype, right? When I owned my old faithful Nokia, I simply used to ignore orthography writing, for example, è or E’ instead of È and so forth. Now that my Android handset has an almost QWERTY keyboard, I try to write correctly, so I knew it was time to understand what was really going on. Follow me, it will only takes some very basic maths.

Texts are encoded using a character set called 03.38. With this encoding, your mobile may choose between 3 different encodings: 7 bit, 8 bit or 16 bit. The 7 bit one is the default GSM encoding, we’re not interested in the 8 bit one, while the 16 bit corresponds to UTF-16 alphabet. In some older documents you may read UCS2 instead of UTF-16, this is simply due to the fact that UTF-16 is the successor of UCS2. One more fact, and then you’ll be needing your trusted calculator. An SMS is long at most 140 octets. Hey you nerd, I only want my 160 characters! Don’t worry, here they are:

  • 7 bit encoding: 140 * 8 / 7 = 160 characters
  • 16 bit encoding: 140 * 8 / 16 = 70 characters

So, if you write a character not included in the 7 bit alphabet, like the infamous È, your phone will (probably) silently switch to the UTF encoding, which explains the reduced available text.

Long story short: will an accented character eat up 70 precious characters? No way :)

Reference: 3GPP Alphabets and language-specific information

Today I’ve encountered one of those strange problems that makes you learn a few interesting things about the internals of the tool we daily use.
I’m working on a Java project with Maven and Eclipse. Since I’m not a masochist, every now and then I write a few unit tests. And so I did this time. Well, maybe I’m a bit of a masochist, because in a test, I’ve inserted a non Latin string (“งานเลี้ยงอำลา”, which should mean “Farewell party” in Thai). So far so good. The JUnit was fine, and so the test ran by the maven surefire plugin.
Today I did some refactoring, and I moved the tested class, along with the test, in another Maven module. I ran mvn package, and the test failed unexpectedly. Hey, wait a minute, I didn’t change a single line of code, well, apart from the package name. I ran the JUnit directly from Eclipse, and guess what, no error at all. So I ran again mvn package, and looked at the failure message:

expected:<...><footer><message>[?????????????]</message></footer...> but was:<...><footer><message>[?????????????]</message></footer...>

What are all those question marks? Where did my farewell go? Changing the Thai string with one with only Latin characters, made the error disappear. A little cell in my brain  was screaming “Character encoding, character encoding!”. After a bit of research, I’ve added this to my pom.xml:

			<argLine>-Xms256m -Xmx512m -XX:MaxPermSize=128m -ea

The most important parameter is "-Dfile.encoding=UTF-8", which tells to the underlining JVM the default character encoding to use. With this parameter the failing test finally succeeded again.

I would like to understand why I did not have to use that parameter before, but only after I created the new project. I quickly compared the pom files, but I couldn't find any relevant difference. Maybe I'll investigate it further, and describe my findings in another post.

In the last week I’ve had to deal with configuration management for the J2EE application I’m working at the moment. As you may have guessed, I chose the JNDI path. Since I’ve spent an insane amount of time, i.e. more than 5 minutes ;), googling for a solution, I’m gonna share what I discovered. Actually, it’s quite simple, we just need to instantiate a managed bean. Let’s create a file to define two java.net.URL. Create a file named pizza-service.xml in your server deploy directory. For the default configuration it should be $JBOSS_HOME/default/deploy. Filename must end with the suffix “-service”, otherwise JBoss will ignore it.
Insert the following content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server PUBLIC "-//JBoss//DTD MBean    Service    4.0//EN"
    <mbean code="org.jboss.naming.JNDIBindingServiceMgr" name="jboss.apps:name=pizzeria">
        <attribute name="BindingsConfig" serialDataType="jbxb">
            <jndi:bindings xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
                xs:schemaLocation="urn:jboss:jndi-binding-service resource:jndi-binding-service_1_0.xsd">
                <jndi:binding name="java:pizzeria/capricciosa">
                    <jndi:value trim="true" type="java.net.URL">


                <jndi:binding name="java:pizzeria/margherita">
                    <jndi:value trim="true" type="java.net.URL">



Once you saved the file, JBoss should reload it automatically.
This is all it takes. If you want to separate the JNDI definitions in multiple files, just change the name attribute of the mbean definition. With this solution you can easily handle multiple configurations for your environments (test, staging etc.)

Hi, after a lot of tinkering, I eventually decided to open my programming blog. I’m doing this because, so many times, during my work, I googled for solutions to my, apparently unsolvable, problems. And most of the times I succeeded. Some others I wouldn’t, and I kept banging the keyboard like my avatar, until I came to a solution. So now it’s time to give something back the community, sharing solutions to awkward problems, because, as Donne wrote, no programmer is an island. Well, maybe those were not his exact words.


Get every new post delivered to your Inbox.