PhiLho tech web log

A function that is useful is a comparator of strings (for sorting purpose, in general) that respect the natural order of numbers.

So when we have a list of strings, like file names, for examples, with numbers in them, it is better to respect the numerical order when strings are equal.

A common case is numbered names: a trivial, lexicographical order would be:
foo-1
foo-10
foo-11
foo-2
...
foo-9

where one expects:
foo-1
foo-2
...
foo-9
foo-10
foo-11

I show here how to do such comparator.

I had to make a rollover image: a copy of an image with slightly different colors.
Editing with Gimp 2.6, I just copied the image and altered the colors, but then I adjusted the transparency of the original image (smoother transition from opaque to transparent) and I wanted to copy the transparency information to the rollover image. For some reason, I didn't want to redo the color change again.

A blog post (Double Parsing Regexp) caught my attention. The base problem is to check if a string is a valid number, without necessarily needing the real value. Or, perhaps, to skip the conversion if we are sure it will fail, as Double.valueOf throws an exception in this case, and the try/catch mechanism is known to be slow.

The numbers given were intriguing, and I wondered if the given regular expression could be optimized. Somehow, it was a great opportunity to use Caliper a library to do correctly micro-benchmarks.

I recently started to learn Scala, an interesting language in the (very strongly) statically typed category. So far, I only compiled single files with little or no dependency, so the command line was good enough. Now, I start to try small sample files with a rather complex classpath (using Piccolo2D and Pivot), so I searched something more sophisticated.

The main constraint was to be able to compile and run Scala programs, using my local copy of Scala compiler, and the local libraries where I gather them. I soon discovered it is now a quite unusual setup...

Je me suis enfin mis à Scala ! (depuis deux semaines à peu près)

Ça faisait un moment que je voulais m'y mettre. J'ai atteint un niveau décent en Java, et je voulais explorer un langage un peu plus souple, n'ayant jamais apprécié les classes anonymes, surcharges de méthodes pour gérer les paramètres optionnels et autres lourdeurs de Java. Sans parler des incohérences hérités du C.

J'ai balancé un moment entre Groovy et Scala (Clojure : pas fana de Lisp, même si j'ai appris Scheme pour faire des scripts dans Gimp ; JRuby : ressemble trop à Perl ! Jython : pourquoi pas, mais plus tard). J'ai fini par basculer vers Scala !

Test de Google Chrome 3.0.195.38 le 12 janvier 2010.

Ça faisait un moment que je voulais l'essayer, au moins en tant que webmaster, vu qu'il faut tester les pages sur un maximum de navigateurs. J'ai attendu qu'il se stabilise, puis j'ai un peu oublié.
Leur publicité (pour un produit gratuit !) sur les murs du RER parisien et en couverture d'un journal gratuit (entre autres) a servi de rappel (donc... c'est efficace). Je soupçonne Google d'avoir demandé aux sites qu'il mentionne dans ses publicités d'aider à financer la campagne...

Premier contact : désagréable !
J'ai détesté la procédure d'installation... Je peux comprendre la volonté de simplifier la vie de la plupart des utilisateurs, mais cela ne devrait pas exclure un paramétrage fin par ceux qui savent ce qu'ils font...

Recently (beginning of this month), Josh Marinacci proposed on the JFXStudio site a Challenge: Small is the New Big. The goal is to write a short but spectacular JavaFX program on a given theme. The theme was revealed shortly after: Time.

Dans le forum JavaFX de Sun, quelqu'un a demandé How to implement magnify glass effect? (Comment implémenter un effet de loupe ?). J'ai trouvé le challenge intéressant, et après quelques fausses pistes et périodes où j'ai fait autre chose, j'ai fini par atteindre un stade utilisable.

In the Sun JavaFX forum, somebody asked How to implement magnify glass effect? I was interested by the challenge, and after some dead end trials and on/off periods of coding, I reached a usable state.

Suite à une question dans le forum de Processing (Localization [ i18n ] - go there if you can't read French, most of the info here is there), je me suis penché de plus près sur le système d'internationalisation de Java.

L'internationalisation (i18n en abrégé : 18 lettres entre i et n...) de logiciels est un point important pour une utilisation aisée dans tous les pays. Cela comprend non seulement la traduction des textes, mais aussi la prise en compte des particularités de chaque pays (localisation, ou l10n), comme les séparateurs de décimales et de milliers, l'écriture des dates, la gestion des pluriels, etc.

Je me suis aperçu que pour Processing, il fallait contourner certains obstacles pour parvenir au résultat. Je livre ici mon expérience, dont une partie est utilisable directement dans Java.

Certains raccourcis de codage offerts par JavaFX, qui sont sympas quand ils sont pris séparément, peuvent constituer une combinaison mortelle quand ils sont utilisés ensemble...