Do you mean I have already used IoC ?

  Selon Sam, le plus petit conteneur IoC est en fait celui fourni avec le JDK et utilisant XMLEncoder et XMLDecoder. J’ai déja eu l’occasion de l’utiliser, quand XML commencait à être un buzzword, et que ma société désirait un mécanisme de serialization XML. Ce que je me demande est tout simple : l’IoC n’est que ça ? Plus j’en entends parler, plus j’ai tendance à être d’accord avec mon ami Marc :

IoC, ça n’est rien qu’une super-factory de la mort qui tue.

Est-ce vrai ? Si oui, alors je ne peux dire qu’une chose : pourquoi utiliser le XML quand Java5 fournit les annotations (et que CodeHaus les donne aux versions précédentes) ?

Publicités

De 36trucs à 43things

Comme je le dis dans ce message, une adaptation française de {43things} a été créée il y a peu. Après ma découverte, c’est au tour de .conforme de se pencher sur le sujet. Il nous en dit notamment :

  Perso j’avoue que j’avais moyennement accroché à ce truc il y a quelques semaines et que je suis beaucoup plus tenté par cette adaptation francophone découverte dans mon mail grâce à un ouvre-boîte.

Pour l’avoir testé (certes assez rapidement), je préfère largement pour ma part la version américaine, qui est beaucoup plus « communicante », et surtout beaucoup plus facile à utiliser avec Opera. En effet, l’inconvénient de Viabloga est l’utilisation d’une zone de texte spécifique, sans aucun doute javascriptée, qui ne marche pas avec Opera. Du coup, il m’est impossible de saisir mes trucs dans Opera. Frustrant ! Et puis, contrairement à 43things, il n’est pas possible dans 36trucs de s’ajouter simplement un nouveau truc, simplement en cliquant sur son lien dans une page. il faut voir la liste des trucs préférés des utilisateurs, puis aller dans la zone de texte et taper le même texte pour s’associer à eux. La méthode de 43things me paraît personnellement nettement plus pertinente.

C’est parti !

This has already been blogged there. This entry is mainly a french translation of the previous link. Comme je le dis en anglais , j’ai commencé à apprendre Ruby avec le RDT (même si il existe un très bon package pour Windows) et un tutorial en français, très progressif (chapeau aux auteurs). Parmi les choses qui surprennent déja :

  • La syntaxe des boucles avec le 5.times do.
  • Les méthodes sans paramètres qui s’écrivent sans aucune parenthèse.
  • L’absence complète d’accolades.

TODO liste dans le futur

Grâce à une brève de .conforme, encore une découverte intéressante : FutureMail permet de s’envoyer des mails qui arriveront à une date donnée (ça, c’est relativement courant), mais aussi de générer un RSS à partir de ces mails qui arriveront dans le futur. Je crois que je vais essayer de marier ça à une idée qui m’a été présentée pour gérer ma TODO-List en utilisant GMail pour créer quelque chose de vraiment bien.

J’espère juste qu’on peut envoyer des mails à futuremail pour qu’il nous les reforwarde, auquel cas ce serait le pied. A première vue, ça n’est pas le cas : FutureMail garantit seulement que le mail sera envoyé à une date donnée (donc pas possible de s’envoyer des rappels pour aller chez le dentiste, juste des tâches à long terme), et seulement à partir d’une interface web. Je pense que je vais commencer à tanner l’auteur. En plus, comme c’est codé avec Rails, (LE framework web pour {Ruby}), ce sera peut-être pour moi une bonne façon de m’investir dans ce langage de script que je vais essayer d’approfondir.

[EDIT] Après avoir jeté un oeil à mon compte FutureMail (je n’aurais pas dû le publier, maintenant, je ne pourrais plus m’envoyer de trucs à faire vraiment importants. Ah, ben non, tiens. C’est vachement bien fait, en fait, la saisie du message comporte une case à cocher « add to my public RSS feed »), j’ai découvert une liste de features à venir assez alléchante :

  1. Repeat scheduling
  2. Timezone and delivery time options
  3. A better date selection control
  4. And more!

Le point 2 me fait un peu peur, car il signifie qu’à l’heure actuelle mes mails vont me revenir à l’heure dépendant du fuseau horaire de FutureMail.

And so spoke Craig

  En continuant mes explorations des problèmes de multithreading dans Struts, j’ai trouvé cette page de wiki discutant un point proche du multithreading (et une solution possible de ce problème) : remplacer le modèle à instance unique par un modèle à une instance par requête. Et ainsi parle Craig :

Changing this now would be a major backwards incompatibility issue, so it will not be done in any Struts 1.x release. We can look at other approaches in a 2.x time frame.

Il y a quelque chose dans cette phrase que je ne comprend pas clairement. Supposons que dans le RequestProcessor on change le code de

// Return any existing Action instance of this class              instance = (Action) actions.get(className);              if (instance != null) {                  if (log.isTraceEnabled()) {                      log.trace("  Returning existing Action instance");                  }                  return (instance);              }              // Create and return a new Action instance              if (log.isTraceEnabled()) {                  log.trace("  Creating new Action instance");              }              try {                  instance = (Action) RequestUtils.applicationInstance(className);

pour le plus simple

try {                  instance = (Action) RequestUtils.applicationInstance(className);                  // TODO Maybe we should propagate this exception instead of returning                  // null.              } catch (Exception e) {

Quelle serait la perte ? Comme dit sur le Wiki « quel est le coût d’une création d’objet ? », déclaration à laquelle je pourrais ajouter « quand on ne sait même pas à quel point la logique peut être lourde ? ».

 

Struts seems mediocre

  Je me pose actuellement des question sur la gestion multithread de Struts (qui en fait n’existe pas). Donc, comme tout développeur, j’ai googlé « multithreading in Struts » et d’autres requêtes. Malheureusement, les résultats commencent presque avecdes pages comme Struts semble médiocre. je trouve cette critique de Struts très intéressante, et pas seulement parce que je n’aime personnellement pas ce non-framework. En effet, les arguments correspondent fortement aux miens :

No policies for translating request parameters into common java objects.

Est-ce pourquoi mes beans métier contiennent des setters utilisant des String ?

ActionForms are a massive parallel structure to the « real » model.

Encore une fois, puisque je n’utilise personnellement rien d’autre que les DynaActionForm, je peux considérer que j’ai trouvé un contournement utile, qui déplace toute la validation dans le Javascript ou dans les classes métier.

Standard HTML forms are not used.

Dans mon cas, le tag Struts form n’est pas utilisé. Il n’y a que des formulaires HTML standards. Bien sûr, on doit coder notre validation Javascript spécifique. Mais c’est nettement plus simple, et plus facile à « introspecter » en utilisant du Javascript spécifique. En fait la seule partie délicate a été le Javascript modifiant la taille d’une propriété mappée.

Actions must be thread-safe.

Je lutte encore là-dessus, et j’apprécierais toute aide 😉

Struts is an unimpressive implementation of the Command pattern.

Et personne ne parle de la DispatchAction et de ses mystères.

De 43things à 36Trucs

Souvenez-vous (si vous étiez là). Il y a une semaine à peine, je parlais du bouillonement intellectuel (si je voulais faire savant, je parlerais d’un exemple tout à fait fascinant de mème à l’oeuvre) agitant le web à propos des folksonomies et en particulier de son application aux listes de choses à faire (les idées du type GTD – ou getting things done, ou comment être efficace – étant également assez bien représentées dans les sphères des décideurs).

Bon, eh bien, en France, on a aussi des idées (ou tout au moins, on sait les exploiter). Voici donc une adaptation française de 43things : 36trucs qui est soutenue par un réseau assez bien fichu auquel je vais m’intéresser de plus près, notamment L’ouvre-boîte qui dispose d’un post beaucoup plus complet que le mien sur les folksonomies, mais apparement pas d’un trackback qui m’aurait permis d’agrandir la discussion. On y trouve aussi un lien, à explorer à mon avis, vers 6nergies, un outil de social networking que {Charles Lehalle} pourrait investir comme il a su pénétrer linkedin.