Patatras !

Parfois la vie ressemble à ça...

Bon pour le service

La drogue était un bon milieu avant que le sport s'en mêle
- J.L. Aubert -

Good morning, nobody !

Si l'on excepte la reformation des Beatles (par spiritisme, hein, pour réussir à entendre John et George), voici l'évènement que vous attendiez le plus au monde, un nouveau post sur le divertimento's blog!

Hum. Bon, sérieusement, on va essayer de se remettre tranquillement à l'écriture de posts inutiles et lu par personne, pour changer ;-)

Il s'en est passé des choses depuis là dernière fois.

Comme je n'ai pas envie de commencer par un post "technique", mais plutôt par un point de repère de ma vie, voici un poème écrit au moment de mon récent déménagement (car comme le disait Holden Caulfied, il faut "bien s'imprégner de l'idée que l'on va partir. Sinon, c'est encore pire" ) :

A l'ombre de tes remparts,
Toi mon château d'adoption,
Tu m'avais pris sous ton aile,
D'affection.

5 ans d'escapades angevines,
Qui m'avait mené d'une ravine,
Aux prairies délicieuses,
D'une joie sereine & lucide.

C'était en Mai,
Il neigeait des poussières de coton.

Template PHP

Les templates sont un peu le graal, ou plus modestement la marotte de beaucoup de développeurs PHP.
Il faut dire que la séparation couche présentation/couche métier, est un idéal que d'aucuns voudraient
atteindre (je sais, c'est bien dit ;-))

La solution la plus connue est Smarty. Beaucoup de fonctionnalités, mais ce qui m'a toujours gêné, c'est qu'il
faille apprendre la syntaxe Smarty en plus de celle de PHP, ce qui fait un peu du travail en double.

J'ai ensuite regardé du côté de VTemplate, qui était un peu moins usine à gaz que Smarty, et qui pouvait gérer
les pages en cache.

J'ai utilisé quelques temps cette solution, mais j'ai été rapidement convaincu par l'arguemnt de certains, qui
trouvaient que ces solutions, complexifiaient le code, et qu'elles mettaient en avant un autre langage de script,
alors même que PHP est un langage de script puissant. Là encore, pourquoi faire les choses en double?

Et voici aujourd'hui ce que j'ai trouvé: Savant.

Un exemple vaut mieux qu'un long discours :

example.tpl.php

< ? loadTemplate('header.tpl.php') ?>
<>This is the main body of my template. Hello, name ?>!
< ? loadTemplate('footer.tpl.php') ?>

Et voici le script de logique métier associé :

< ?php require_once 'Savant2.php'; $tpl =& new Savant2(); $tpl->assign('name', 'Fester Addams');
$tpl->display('example.tpl.php');
? >

C'est d'une simplicité désarmante non?

Ici, nous avons une solution de template, 100% PHP (il existe des "plugins", permettant de ne pas coder des balises HTML tel que form mais elles sont tout à fait optionnelles), et qui sépare bel et bien la présentation de la partie métier.

De plus, on peut très bien passer par des subtemplates, pour créer les briques header, footer de son site.

White paper contre les brevets logiciels

ObjetctWeb propose un mémo sur les brevets logiciels : les problèmes que ça pose, pourquoi il faut l'éviter.

http://wiki.objectweb.org/Wiki.jsp?page=CWP_SoftwarePatents_French

D'abord, ils expliquent que le brevet n'est pas forcément une chose mauvaise, intrinsèquement. Si cela apporte des bénéfices à la communauté, pourquoi pas. (c'est donc bon pour des domaines techniques, concrets).

Mais ils mettent en cause les brevets pour les idées, les algorithmes, les structures de données en programmation. D'une part ce n'est pas concret, ça bloque l'innovation, et le temps pour passer au domaine publique ne devrait pas être le même que pour les autres domaines, puisque tout bouge plus vite en informatique.

Je quote 2 paragraphes importants.

Le 1er qui décrit comment ça se passe aux EU *avec* les logiciels brevetables :

Le Parlement Européen a récemment confirmé que le logiciel en tant que tel doit demeurer hors du champ du brevetable. Force est de constater qu'outre-Atlantique, la possibilité d'obtenir des brevets de logiciels a surtout des effets négatifs, de plus en plus décriés.

L'analyse économique montre que 10% des budgets de la R&D sont maintenant capturés par les problèmes juridiques. Par ailleurs, on voit apparaître de plus en plus de « racket au brevet », typiquement contre des PME qui préfèreront payer de petites sommes plutôt que d'aller à un contentieux plus coûteux.

La récente affaire Eolas contre Microsoft, où Eolas prétend détenir des droits sur des mécanismes fondamentaux du web, est aussi caractéristique que scandaleuse. C'est une excellente illustration d'un abus courant qui consiste à déposer les brevets discrètement, laisser les tiers utiliser indépendamment les même techniques, et clamer ses droits une fois le travail de popularisation achevé par d'autres.

Cette pratique, manifestement de mauvaise foi, est possible car le degré d'innovation réelle dans les brevets obtenus ne cesse de décroître. Il faut donc craindre l'apparition de systèmes quasi mafieux où la tranquillité judiciaire des petites entreprises serait achetée à des gros bonnets de la propriété intellectuelle.

Le 2ème qui montre le problème institutionnel Européen, car il y a un réel combat de 2 organisations, le Parlement Européen, résolument anti-brevet, et l'Office Européen des Brevets, qui lui suit les désirs des grosses boites, cad des brevets à gogo.

Face à ces constats, il faut s'étonner et s'inquiéter de l'activité de l'Office Européen des Brevets. Au mépris des lois existantes, l'OEB cède au mercantilisme et prône la brevetabilité sans limite. Dans une approche marchande, l'OEB ne rencontre que des industriels soucieux d'obtenir des brevets. L'opinion d'autres acteurs d'avis contrastés semble purement ignorée par l'Office.

Mais l'OEB ne devrait pas être au service de ses « clients », acheteurs de brevets, mais au service de l'économie européenne. A ce titre, il est très surprenant que l'OEB ait fait évoluer sa jurisprudence sans procéder à aucune étude économique (du moins qui ait été rendue publique) sur l'opportunité d'une telle évolution.

Voila, je suis resté assez longtemps loin de ce pb, me disant ça ne me concerne pas, mais je crois que toute personne qui touchent de près ou de loin à l'informatique doit se sentir concerné...

Retour vers le futur

Je crois que j'ai trouvé mon langage idéal : en gros, imaginez Java avec une syntaxe améliorée, plus souple et plus pratique, et vous aurez une idée de ce qu'est Groovy (http://groovy.codehaus.org).

Ses caractéristiques marquantes :

• Groovy est un langage interprété, donc il est rapide à écrire et à tester
• il peut être compilé et donc gagner en performance.
  
• il s'interface facilement avec du code Java, et réciproquement.
• il peut utiliser n'importe quelle classe Java (même du Swing!).
  
Bref, on peut imaginer que ce code serve de prototypage, masi jamais si votre code vous satisfait, que les performances sont correctes, vous pouvez purement et simplement l'utilisez dans le reste de votre application Java.

Sa principale caractéristique est la closure : ça ressemble à une inner classe java anonyme, mais cela peut se définir au moment même de son application.

ex :

value = [1, 2, 3].collect { it * 2 }
assert value == [2, 4, 6]

(à noter que si la notion est aussi pratique qu'on peut le croire ce principe des closures et aussi possible avec Java, grâche aux API de Jakarta Commons Functor)
• un plugin Eclipse est disponible (pour Eclipse 3 malheureusement pour moi, qui doit rester avec Eclipse 2 pour des questions de compatibilités avec d'autres plugins...)
• Une JSR envoyé au JCP demande à ce que Groovy fasse partie de Java standard :-)
  
  

Le principal point négatif, c'est que le produit n'est pas encore finalisée...
Je n'ai pas réussi à le faire fonctionner avec l'utilitaire groovyconsole (qui est le même genre que l'éditeur IDLE de Python), mais seulement en configurant Ultraedit. (mais bon, si ça marche bien avec Eclipse 3, ça n'est pas rédhibitoire).

L'auteur donne d'ailleurs une bonne idée pour commencer à utiliser Groovy : l'établissement des tests JUnit pour votre dernière appli Java!

Liens :

• présentation préparée pour le dernier Javapolis est disponible, il est synthétique et bien fait.
• Commons Functore : le principe de closure pour Java http://jakarta.apache.org/commons/sandbox/functor/
  http://www-106.ibm.com/developerworks/java/library/j-fp.html
  

Eclipse est une jungle...

Je viens de passer quelques heures à me battre sur internet, pour répondre à la question : comment changer de JDK dans Eclipse?

J'ai 2 versions d'Eclipse, la 2.1.2 qui me sert pour mes projets professionnels, et la version 3.0.1, qui me sert pour mes tests.

Pour changer de JRE, ce n'est pas trop dur : Windows > Preferences / Installed JRE

Mais pour changer de JDK (le javac), quid?
Il y a bien une partie Compiler dans les préférences, avec un onglet Compliance and Classfiles, mais le niveau de compatibilité me donne seulement le choix qu'entre 1.3 et 1.4...

Bref, je me dis qu'il y a sûrement quelquechose à configurer quelquepart, mais en fait non!

Il est impossible de bosser avec le JDK 1.5 avant la version 3.1 d'Eclipse => Juin 2005
C'est ce qu'on apprend ici : http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html

Je sais bien qu'Eclipse est plus qu'un éditeur, mais sachant qu'on a attendu plus d'1 an pour avoir le JDK 1.5 de la part de Sun, il va falloir attendre encore 8 mois pour avoir un eclipse compatible??

On ne marcherait pas un peu sur la tête là?

C'est que je l'attends depuis longtemps moi mon ArrayList avec autoboxing....

http://eclipse-wiki.info/JavaGeneralFaq

http://www.eclipsetotale.com/index.html

PS : Et quand aura-t-on une FAQ, un forum eclipse digne de ce nom?
Pour l'instant à part des newsgroup demandant x logins tordus, c'est le désert, ou la jungle pour celui qui veut en retirer quelque chose...