Pomodoro desktop reached 0.30 release

Everaldo nicely contributed with new gorgeous icons, plus some small fixes here and there.


Check out the best pomodoro application in the whole world
Comments (14) Show Comments

Pomodoro desktop for Mac


Just announced my Pomodoro desktop client for mac. It is a simple but effective way to manage your (coding) time. I am planning to add a lot of interesting features to it, so stay tuned!
Comments (1) Show Comments

Da Java a Logo...

scherzo, ovviamente.

Però qui potete trovare il materiale del corso di programmazione che ho organizzato per i bambini della scuola elementare Maurizio Poggiali, in via Benedetto Croce. Per rendere il post minimamente più interessante, con antlr sto anche cercando di implementare un interprete migliore di quello scritto "a mano" in kde. Ovviamente tanto non lo finirò mai, ma questa è un'altra storia :)
Comments (2) Show Comments

iPhone applications up and running...

And finally, they are.

Almost 20 days to approve the contract, phew.

And now, let's find the bug: in the iFiscal app, some users reported crashes and hangs. Unfortunately, the app works pretty well in the simulator and on all physical devices I tested. Right now, I don't know how to fix it: I found a little leak with Instruments which I'll fix as soon as possible, but it appears to be not related to the crashes reported (apparently all on "cambio comune").

If you own an iphone/ipod touch and the application didn't work for you, let me know exactly the firmware and the exact model of your device (f.e. iPhone 16Gb, 2nd generation, fw 2.2), and what you were doing.

Update: ah, let me also know if it's jailbreaked (no, I'm not an apple employee :) ). Perhaps it doesn't mean anything, but I didn't test the app on a jailbreaked iphone, and the users who reported me the crash have all a jailbreaked iphone.

The most compatible partitioning OSX scheme?

As I wrote in my previous entry, various apple software has issues with HFSX, which is a Leopard interesting option for unix oldies.
I think there is probably no value to have filenames differing only in case (e.g., Readme an README), but, as a matter of fact these things can happen. And checking out project files with same name from subversion can be really annoying.

So, apparently OSX users have to face this decision:

  • HFS+, case insensitive, compatible with photoshop and other (poorly designed) software, but not unix compliant (potential problems with mysql, cvs, svn, etc.)

  • HFSX, case sensitive, unix compliant (mysql, cvs, svn, etc.) but facing potential problems with a lot of apple and third party software (filevault, photoshop CS3, photoshop elements, and probably lot of others)

Not an easy one, though I'd probably have gone for the HFS+. But luckily with Leopard is easy to partition your disk (ie you don't need anymore iPartition or similar), and you can mix and match HFS+ and HFSX partitions. So, to minimize the impact of case sensitivity/insensitivity problem, you can just slice up your disk in - let's say - 3 partitions:

  • The System one, case insensitive. Photoshop CS3 writes things in the /System and /Library folders, and its installer simply quits if you boot your mac from a case sensitive FS.

  • Another one with /Application and /Users, case insensitive. Here you will install all the adobe and other not-unix-compliant software. This will be the default for all your applications. Case insensitive /Users is needed for FileVault.
  • Another one for other unix software, case sensitive. Here you can checkout from cvs/svn, install mysql and so on. You can also mount /Users here if FileVault is not an option for you

To do that, just start DiskUtility (usually in /Applications/Utilities), select your OSX disk and choose the Partition tab. Then add as many partitions you like, and format them as planned. Easily done that said.

Ah, and don't forget to edit your .profile:

bind "set show-all-if-ambiguous On"
bind "set completion-ignore-case On"

so that bash don't get in your way when dealing with filenames differing only in case.
Comments (1) Show Comments

The case for case insensitivity

when I first discovered that the default file system on OSX was case insensitive, I said it was impossible. I was sure it's case sensitive, it's unix, and unix IS case insensitive, isn't it? The truth was that I had been working on it for more than a year, but my mbp was indeed case insensitive, and I never noticed only it because the bash was shielding me from this detail. I configured bash to be more case-aware (bind "completion-ignore-case On"), but after having some issues with subversion, I decided that my next installation would have been a standard unix case sensitive one.

So, fast forward to present. I decided to install the HFS+ case sensitive file system (aka HFSX), although I had a little voice in my head screaming... I also read some warnings but decided to proceed anyway. After a few months of working on a case sensitive mac, it's time to wrap up:

- Backups. It's reported that backup tools on mac can be confused by case sensitive fs. Indeed, Time Machine didn't recognize its own backup, and suggested me to format again the external firewire (sic!). Ok, I copied the files manually and then started again with time machine. Scaring, isn't it? mmm... perhaps I had to listen to the little voice.
- FileVault. Then I discovered that Filevault simply DOESN'T work on a case sensitive file system. So, if you are planning to use it, beware: you'll have to choose between filevault and case sensitivity. I don't know if FileWault is worth its weight, but this is really annoying. Well, let's go on with our case sensitive FS for a while.
- Adobe. Can you believe it? Photoshop CS3, Photoshop Elements and other well known mainstream apps DON'T work on a case sensitive file system. This was really hard to believe for me, but apparently they can't spend 1 week of their precious engineering time to fix this. Someone managed to workaround the issue (I'd say it's a bug, but the Adobe guys don't think so) but it looks to me very dangerous. The truth is that photoshop is untested on HFSX, and any serious user should not rely on the "hacked" version.
- iPhoto. I have also read some people having issues with iPhoto on HFSX

So, blame on Apple, because they can't manage to make their own apps working well on HFSX, and because they make the case insensitive fs the default. And blame on Adobe, because they are supposed to be a serious software house: in 2008 saying that this is not an issue and/or it's not worth fixing it's kinda lame. C'mon guys, just renaming some files in your VCS and do some regression testing can't be that hard!

Ah, I'll go back with a case insensitive FS as soon as possible. Thanks, Adobe.


Arriva per la prima volta in Italia l'evento internazionale che mette a confronto gli IDE Java più utilizzati e le loro community. JDeveloper (Oracle), NetBeans (Sun Microsystems), IntelliJ IDEA (JetBrains), invieranno un evangelist del loro core di sviluppo internazionale per confrontarsi a vicenda.

Speaker presenti:

Roman Strobl (Sun Microsystems)
Paolo Ramasso (Oracle)
Vaclav Pech (JetBrains)
Purtroppo nonostante l’impegno da entrambe le parti, non è stato possibile avere la presenza di Eclipse.

Uno slot di tempo a disposizione per ogni IDE per mostrare le potenzialità del proprio ambiente rispetto agli altri. Ruolo fondamentale sarà giocato dal pubblico in quanto sono previsti appostiti spazi per porre domande direttamente agli evangelist internazionali. La parte finale dell’ evento sarà dedicata ad un dibattito ragionato sul futuro degli ambienti di sviluppo. L’evento sarà in lingua inglese.

L’evento è gratuito, ma è gradita la registrazione.

L’IDE Day è organizzato dal Jug Genova e Jug Roma

Quando e dove:
Sono previste due date: Genova, 10 marzo e Roma, 12 marzo. L’evento si svolgerà nel pomeriggio, all'interno delle Università. Per gli orari, agenda e informazioni logistiche si rimanda al sito dell’ evento.

Sito di riferimento: http://www.ideday.org/
Comments (3) Show Comments

File a bug to Apple: add Java 6 to Mac OS X

Henry Story had a great idea. 

Let's file a bug to Apple asking for Java 6 on Mac OS X, and remember to add this string 13949712720901ForOSX to your blog tags, so Apple will easily track how many people needs an official Java6 for OSX.

In the meantime, thanks to Landon Fuller, we have this.
Comments (9) Show Comments

Dtrace on Leopard

Leopard got what's considered to be the best debugging tool in the world, dtrace, coming directly from the Open Solaris kernel. Dtrace lets you probe your kernel in an unprecedented and dynamic way (ie, without recompiling.)

Here you can find the dtrace solaris guide if you want to delve deep in its syntax and probes.

Almost everyone (myself included) blogged or wrote about the Ruby dtrace probes being in Leopard, so I immediately tried a bunch of scripts to give them a run. Interestingly, you can find dtrace ruby examples right in the /Developer directory.

<rant>That probably means a shift in Apple developer support from Java to Ruby, which sounds a bit strange if you really think about that: how cool and useful could be a java 6 JVM with a lot of dtrace probes? Yep, I like Ruby. I like it a lot for fast object oriented scripting, I like the dynamic part, I like the Smalltalkness and whatever. But, seriously, java is THE platform to support. Come on. We are all waiting for exciting java news from you, Apple. </rant>

Well, let's go back in topic now.

sudo dtrace -s /Developer/Examples/Ruby/DTrace/print_calls.d

says that

dtrace: failed to compile script /Developer/Examples/Ruby/DTrace/print_calls.d: line 4: probe description ruby*:::function-entry does not match any probes

and infact with a simple grep

sudo dtrace -l | grep -i object-free

you can see that it doesn't show one the expected ruby probes.

So, are the Ruby dtraces probe really there or the Gold Master lost something?

<update> Ok, just found this a few minutes after publishing :).

Being dynamic, you should attach it to a running ruby interpreter. Can't still explain why the dtrace -l doesn't show the ruby probes...

sudo dtrace -s /Developer/Examples/Ruby/DTrace/print_memory_usage.d -p <pid> PID number</pid>


Leopard: things I like and things I dislike, a developer perspective

It's more than a full day working on Leopard right now. So, here are my first impressions on what I like and what I don't like from a developer perspective.What I like:
  1. Time Machine. Easy, almost everyone paid lip service to TM. But it's still impressive when you look at it
  2. Dtrace and Instruments. This is a joy for developers. More on this in next posts, in the meanwhile have a look at Bryan Cantrill blog,  dtrace creator 
  3. Spaces. Another easy one. Bye bye buggy Virtue Desktop, welcome pre-organized spaces (yes, you can assign applications to predefined spaces)
  4. Terminal. You won't need anymore iTerm to tail logs in tabbed windows.
  5. Calendar icon now shows the real date and not 17 of July!
  6. Ruby/Rails out of the box. Very nice to have ruby/rails integrated. Well, I would have preferred a java 6 virtual machine, but it's nonetheless a nice feature. Not as much as the Calendar icon, but a good one :). Jokes aside, is nice that ruby apps on apple are also Dtraceable
What I don't like:
  1. No Java 6. No workarounds: but java 5 looks very fast, and rumors are that we will see java 6 very soon. (hopefully with fast opengl rendered Swing, working Java Sound and a lot of dtrace probes)
  2. PostgreSql from MacPorts failed to compile, and I still hadn't had time to see why
  3. The 3D Dock looks ugly. Easy workaround:  simply type "defaults write com.apple.dock no-glass -boolean YES" and then a "killall Dock" in the command line
  4. The tranlucent menu looks ugly too. This isn't easily and completely solved right now
  5. Skype works only the first time! This happens because Skype self-modifies itself after the first launch, and the app signing mechanism break. Either wait for Skype folks to solve it or reinstall with the firewall disabled. More info here
  6. Intellij Idea 7.0.1 can't be assigned to a space :(
Comments (1) Show Comments

Idiomatica #1: il polimorfismo dei poveri

Comincerò a postare regolarmente il materiale pubblicato sulla versione cartacea di JavaJournal . Questo è il primo numero della rubrica.

Voglio cominciare questa rubrica con una “worst practice” fra le più orribili, il polimorfismo dei poveri. Non che non abbia materiale a disposizione per decine e decine di rubriche, e centinaia di esempi di come non si dovrebbe scrivere del codice in Java... ma questa particolare pratica, oltre a essere veramente brutta, ha delle caratteristiche che secondo me la rendono unica. E per questo deve avere l'onore del primo numero di questa rubrica dedicata alle brutture nel design.

  • E' assolutamente non necessaria, e l'alternativa è nell'abc della programmazione ad oggetti

  • Non offre nessun vantaggio particolare rispetto all'alternativa corretta, ma solo svantaggi. Altre brutture perlomeno hanno una qualche giustificazione più o meno fondata, questa no.

  • E' incredibilmente diffusa

Il polimorfismo dei poveri è caratterizzato da codice simile a questo:

if (a instanceof b) {

// fai qualcosa

} else if (a instanceof c) {

// faiqualche altra cosa


Ora, gia' l'uso di instanceof di per se' è criticabile: instanceof in un linguaggio ad oggetti non dovrebbe mai essere usato, se non in un caso particolare che lascio come simpatico esercizio agli amici lettori.

Ma usare instanceof per fare eseguire logiche diverse ad un oggetto a seconda del suo tipo, è veramente abominevole: a cosa serve il polimorfismo – che fa esattamente la stessa cosa - se poi devo ricostruirmelo malamente da solo? Notare che il fatto che l'operazione sia eseguita sullo lo stesso oggetto su cui si è operata la condizione o su un altro è irrilevante: in quest'ultimo caso è solo segno di un cattivo assegnamento di responsabilità e della necessità di spostare l'eventuale metodo al posto giusto.


E' evidente come il vero polimorfismo sia infinitamente superiore alla sua brutta copia: l'”if” viene fatto dal runtime automaticamente, e voi non dovete fare nulla di particolare se non usare degli oggetti in maniera polimorfa. Il polimorfismo dei poveri invece va invece mantenuto, ogni volta che si introducono nuovi tipi e nuove logiche: di solito fra l'altro questo tipo di strutture condizionali si trovano ripetute in diversi punti del codice, poichè è molto comune che esistano diverse logiche da eseguire, rendendo l'introduzione di bug così probabile da essere quasi scontata. Il vero polimorfismo invece vi permette semplicemente di aggiungere nuovi metodi per ogni nuova logica, concentrando così in unico punto tutto ciò che ha gli stessi motivi per cambiare.

Eseguite per curiosità un bel

grep -R instanceof .

nella directory demo del vostro JDK, e troverete molti esempi di poliformismo dei poveri. Sembra che Swing sia un portatore (sano?) di polimorfismo dei poveri!

Permettetemi di riformulare il concetto in maniera più immediata: se trovate del codice che usa “il polimorfismo dei poveri”, è codice strutturato e non codice ad oggetti. Che sia nelle librerie di java, che l'autore sia considerato un guru, che sia uno dei software open più blasonati, che l'abbiate trovato su un libro (di solito di API, non certo di design), o che l'abbiate scritto voi stessi in quello che considerate il vostro capolavoro di programmazione ad oggetti, non cambia la sostanza: non sarà che in 20 anni questa benedetta programmazione ad oggetti a molti non è ancora entrata in testa?

Eliminare il polimorfismo dei poveri da uno qualsiasi degli esempi Swing del jdk. Come dite? Eh no, così bisogna rivedere le gerarchie... e poi inserire nuove interfacce. E poi bisogna eliminare quelle istanziazioni di oggetti concreti... bene, quella si chiama programmazione ad oggetti.
Ora salutate con la manina quella brutta e vecchia programmazione strutturata, e cercate di lasciarvela per sempre alle spalle!

Il polimorfismo dei poveri è una delle peggiori pratiche che si possa adottare per avere codice difficilmente manutenibile, inutilmente complicato e soggetto a bug. Il polimorfismo dei poveri indica inoltre che non state sfruttando la potenza degli oggetti. Se siete pagati per linee di codice, o per bug risolti, usatelo pure liberamente! Ma se poi vi trovate nei guai, non dite che nessuno vi aveva avvertito...