Design pattern, quand on fait mine de savoir

L’open source est magique. Comment croire qu’on utilise quelque chose, être persuadé de l’utiliser, et le clamer haut et fort, alors qu’en fait c’est totalement faux.

CodeIgniter l’a fait. Le design pattern Active Record, qui consiste en gros à encapsuler les données d’une base de données dans des classes, est largement mis en avant dans CodeIgniter alors que c’est faux.

Tout d’abord, ils ont appelé leur librairie Active Record, rien que ça, comme le design pattern, et on lit:

CodeIgniter uses a modified version of the Active Record Database Pattern.

Le design pattern semble être connu, mais il est modifié comment ? Au point de ne plus rien avoir avec. J’étais curieux de voir leur méthode, puis au fur est à mesure c’était de la déception.

Les méthodes s’appliquent directement sur l’objet base de données, toutes les métodes, y compris l’insertion. Rien n’est digne du design pattern Active Record. Comment ont-ils pu avoir le culot d’appeler leur librairie comme ça ?

Wikipedia me rassure dans la définition, on peut lire:

CodeIgniter has a query builder it calls « ActiveRecord », but which doesn’t implement the Active Record pattern. Instead it implements what the user guide refers to as a modified version of the pattern. The Active Record functionality in CodeIgniter can be achieved by using either CodeIgniter DataMapper library or CodeIgniter Gas ORM library.

Merci, CodeIgniter possède juste un Query Builder (et ils auraient du appeler leur librairie comme ça). Voici comment on apprend des choses fausses aux personnes. Il faut toujours garder un regard critique.

Publicités

Messages d’erreur ?

Je me suis longtemps intéressé à Dart, qui est sortie récemment en version 1, mais faire apprendre un nouveau langage à une équipe de développement ce n’est pas évident.

J’ai donc pensé à TypeScript, un sur-ensemble de javascript, un peu comme SASS pour le CSS, le code CSS est du code SASS valide, le code javascript est du code TypeScript valide. Cela a été un avantage clé pour SASS/Compass dans son adoption autour de moi, et si cela pouvait faire la même chose avec TypeScript ça serait nickel.

En effet, quand on utilise un sur-ensemble, on conserve l’existant en utilisant progressivement les fonctionnalités offertes au fur et à mesure de l’apprentissage. Pour sass/compass, cela a commencé clairement avec l’imbrication des sélecteurs css (nesting selector), puis au fur et à mesure par l’utilisation de variables, l’utilisation des mixins, la génération de sprites, etc. Au final, un gain de temps et de maintenance énorme du code CSS, et si c’était aussi possible avec le javascript ?

Mais avant, testons TypeScript. C’est du Microsoft et c’est pour cette raison que je ne me suis jamais trop intéressé à ce langage. Cela commence très mal sur la page d’accueil, cela parle d’un plug-in Visual Studio (sans lien) mais que d’autres éditeurs sont supportés (vim, emacs, sublime text).

Après tout, c’est normal qu’ils mettent en avant Visual Studio, sauf que connaissant strictement rien à Visual Studio je ne sais pas si c’est gratuit, je ne sais pas où chercher le plug-in et ni où le télécharger. Grâce à Google je trouve le lien vers la page de téléchargement, mais il me faut un compte Microsoft pour télécharger le truc. Pas grave, dans l’immédiat testons avec un éditeur basique.

J’ai suivi le tutorial, For NPM users:

$ npm install -g typescript
npm http GET https://registry.npmjs.org/typescript
npm http 200 https://registry.npmjs.org/typescript
npm http GET https://registry.npmjs.org/typescript/-/typescript-0.9.5.tgz
npm http 200 https://registry.npmjs.org/typescript/-/typescript-0.9.5.tgz
/usr/bin/tsc -> /usr/lib/node_modules/typescript/bin/tsc
typescript@0.9.5 /usr/lib/node_modules/typescript

Je commence par simplement créer un fichier vide pour tester l’installation, et je lance la commande indiquée:

$ touch test.tsc
$ tsc test.tsc
error TS5007: Cannot resolve referenced file: ‘test.tsc’.

Ok baby. Testons avec le chemin complet alors, c’est du microsoft après tout, et on est sur linux:

$ tsc /home/test/www/test/typescript/test.tsc
error TS5007: Cannot resolve referenced file: ‘test.tsc’.

OKAY, je me dis que le compilateur doit être trop con et qu’il met l’erreur parce que le fichier est vide, je teste en mettant deux conneries, même erreur, je mets ensuite exactement la même chose que le tutorial, même erreur.

Sur internet, je ne suis pas le seul. Le problème se produit depuis la version 0.9. La meilleure réponse indique que c’est à cause du charset, qu’il faut utiliser l’encodage unicode (UTF-8 en suivant le lien). Sauf que:

$ file test.tsc
test.tsc: ASCII text

ASCII est un sous ensemble d’UTF-8, donc ASCII c’est de l’UTF-8. Et pour la peine, j’ai même ajouté un accent en commentant une ligne:

$ file test.tsc
test.tsc: UTF-8 Unicode text

Et là franchement, je me suis dis que ce n’est même pas la peine que je tente d’intégrer cet outil dans une équipe de développement. Je sais que c’est une technologie en preview, mais d’après la roadmap, la version 0.9.5 est la dernière avec la release candidate. Et cela apporte beaucoup de déception si TypeScript ne fonctionne pas du premier coup sur linux.

Finalement, après quelques tests, je décide de renommer mon fichier test.tsc en test.ts puis suivre précisément le tutorial. Et là, magie, le fichier se compile.

Dans le compileur, l’extension est donc vérifiée. Putain de merde, et c’est écrit nul part bien sûr et le message d’erreur est totalement à la ramasse. Heureusement, c’es un projet open source, même si c’est du MS, et en effet, en éditant tsc.js, on peut voir:

function isTSFile(fname) {
return isFileOfExtension(fname, « .ts »);
}

Mais la véritable question, est pourquoi ne pas indiquer que le fichier ne possède pas la bonne extension, au lieu d’indiquer qu’il n’est pas trouvé… Messages d’erreur incompréhensible, bonjour.

Puis-je blamer TypeScript pour ça ? Cela ne m’a pas donner une bonne image de Microsoft..

On peut par contre noter l’avantage d’utiliser des codes d’erreur (TS5007) qui permet de trouver une solution peu importe la langue du message d’erreur. Par opposition à Git par exemple, où recemment (début décembre 2013) la traduction française a été disponible dans plusieurs distributions. Ce qui cause un problème majeur, car en cas de problème on recherche le message d’erreur retourné par git pour trouver une solution. En recherchant le message d’erreur français on trouvera donc moins de résultat (voir aucun). On peut donc noter l’expérience de Microsoft dans l’internationalisation (et les erreurs à la con).

Quoi qu’il en soit, le code d’erreur TS5007 est trop générique, il correspond à un fichier non trouvé alors que mon problème était à cause d’un fichier dans la mauvaise extension.

Mon intérêt pour TypeScript est aussi lié à Anders Hejlsberg, architecte du langage et connu pour Turbo Pascal et Delphi. En tant qu’ancien développeur Delphi, je me demande ce qu’il va faire avec TypeScript.