Aléatoire ou non ?

Est-ce que l'on devrait utiliser des données aléatoires lorsque l'on écrit des tests Selenium ?

Je vous invite à lire sur le sujet.

La suite...

Toronto, here I come.

Eh oui, je pars pour Toronto. Jeudi le 14 janvier ! Tout ça dans le cadre du cours Projet en Génie Logiciel. Je vais participer à un projet de l'UCOSP.

Le projet que j'ai choisi est Basie. Un projet qui cherche en gros à faire un Trac plus simple, pour et par les étudiants.

Basie est fait en Python, il sera d'ailleurs présenté lors du prochain Pycon, et utilise le framework web Django. J'ai choisi le projet parce qu'il va me permettre d'approfondir mes connaissances en Python et aussi parce que j'aime bien les applications webs.

Travailler avec des étudiants d'un peu partout au Canada risque d'être un défi intéressant. Je suis convaincu que je vais apprendre énormément en terme de gestion de travail et de communication ! J'ai bien hâte de rencontrer tout le monde en Ontario.. la fin de semaine s'annonce prometteuse.

En plus, bonus ! Je prends l'avion pour la première fois de ma vie. J'espère que tout va bien se passer :)

La suite...

ChromeGestures

Petite update pour vous dire que ChromeGestures est maintenant hosté sur Google Code (ChromeGestures)

Nous sommes maintenant rendu 3 développers et avons atteint plus de 2000 téléchargements en moins de 4 jours.

J'ai bon espoir que ChromeGestures va pouvoir devenir l'extension principale pour ajouter une fonctionalité de 'Mouse Gesture' à Chrome.

La suite...

Mac et moi

Je me suis acheté un Macbook Pro 13''. C'est ma gaterie de l'été. J'écris donc ce post, en direct de mon tout nouveau Macbook pour partager mon opinion sur mon achat.

C'est une belle machine. Petite, sexy et légère. J'adore la clarté de l'écran, les touches rétroéclairées et le trackpad qui agit comme un seul gros bouton. Les interfaces des applications sont claires et pures. Le clavier est vraiment smooth. Les touches sont plaisantes et s'utilisent bien.

Il y des petites choses auxquelles il faut s'habituer. Je viens d'un passé 100% PC. C'est la une des première fois de ma vie que j'utilise Mac OS X alors il faut me comprendre.

J'ai de la difficulté à penser que seulement la fenetre active a le controle de la barre en haut. Il faut que je penses à changer de fenetre avant d'aller jouer dans les options. C'est une question d'habitude et je n'ai pas peur que je vais y penser dans quelques semaines.

Mais malheureusement, ce n'est pas tous mes problèmes avec le système d'exploitation qui peuvent facilement se régler avec le temps. J'ai commandé mon ordinateur avec le clavier Français-Canada .. mais il semblerait qu'Apple n'a pas la meme définition que le reste du monde PC. En effet, il y a pas mal de touches qui ne sont pas aux meme places.. et d'autres qui ne sont tout simplement pas là. Dans ce post, si il n'y a aucun accent circonflexe, blamez Apple.

Un autre problème est que Mac OS X permet de faire les choses complexes de façon assez simple.. mais quand on veut faire quelquechose de trivial.. il semblerait que ce n'est pas toujours possible. Je m'explique. Je veux juste jouer une chanson sur iTunes. Je peux pas. iTunes permet juste de faire jouer des playlists. Il y a des workarounds, bien sur.. mais je veux juste jouer une toune !

Il y a des petites choses aussi que je voudrais pouvoir modifier. Il est possible de cacher 'The Dock' de façon automatique, quand tu mets ton curseur dessus ensuite, le Dock ouvre.. mais je trouve qu'il ouvre vraiment lentement. Et je ne peux pas changer la vitesse ! Dommage.

D'autres choses que j'aimerais faire mais que je comprends que ce ne soit pas possible :

• Chercher Google via Spotlight
• Envoyer une fenetre dans un autre 'Spaces' en la draggant sur le bord de l'écran
• Chercher Google par défaut en entrant quelquechose dans la barre d'adresse de Safari
• Voir la date dans la barre en haut (à coté de l'heure)

Aussi, j'aimerais ça pouvoir mettre les applications en plein écran. Probablement juste une mauvaise habitude de mon passé PC. Un autre petit hic, j'ai de la difficulté à saisir la différence entre CTRL, ALT et CMD.. Les deux premier ne semblent pas avoir la meme définition que sur PC et pour ce qui est du troisième, j'ai bien l'impression qu'il a été inventé seulement pour combler l'absence de right-click.

Somme toute, très content de mon achat. Je penses que la morale est qu'il va me falloir une certaine période d'adaptation, mais la transition sur Mac semble valoir la peine. Tout est plus simple et convivial... et accessible sans avoir à traverser 12 niveaux de 'Panneau de configuration'.

La suite...

Erratum

J'ai continué mon travail sur ChromeGestures et puis je me suis rendu compte de quelquechose.

J'ai fait une erreur dans mon post La puissance des langages de script ... :O

Le segment de code :

myGestures = [ [newTabGesture, newTabFunc],
[closeTabGesture, closeTabFunc] ];

Aurait du être :

myGestures = [];
myGestures[newTabGesture] = newTabFunc;

En effet, il faut absolument assigner les fonctions directement à l'index désiré, sinon ça ne marche pas.

Mais ça n'enlève rien à la puissance des langages interpretés ! ;)

Désolé...

La suite...

Perfect Developer

Dans le cadre de mon Bacc en Génie Logiciel je dois suivre le cours Spécification formelle et vérification de logiciels.. et c'est plate.

Pour créer nos spécifications formelles, on utilise Perfect Developer. Un (autre) logiciel qui est supposé faire disparaître les bugs logiciels de la surface de la planète.

Bullshit.

À force de me torturer avec ce merveilleux logiciel (et son tout aussi agréable langage de spécification), j'ai compilé une liste de 5 raisons qui expliquent pourquoi Perfect Developer ne sauvera pas l'humanité des BSOD.

1] La syntaxe

La syntaxe du langage utilisé par Perfect Developer ne ressemble à rien. Si j'avais à désigner un nouveau langage qui s'addresse principalement à des programmeurs, je ferais un effort pour créer un langage similaire à ce qu'ils connaissent déjà.

Ok, ok.. peut-être que les langages qui existent déjà n'offre pas les possibilités dont tu as besoin. Ça ne t'empêche pas de faire un effort d'utilisabilité et de t'arranger pour que tes mots clés soient lisibles. Qu'est-ce qui peut justifier que le not equals soit '~=' ...

En plus, Perfect Developer ne semble pas avoir de concept de variable locale. Ainsi, dans une spécification, il faut tout mettre sur une ligne. Impossbile de capturer une information et la réutiliser à plusieurs places. Il faut copier/coller le code pour obtenir cette information partout où l'on accèderait normalement à la variable locale.

La cerise sur le sunday est qu'il n'y a pas d'IDE. Il faut tout coder dans un editeur texte, pas d'autocomplete.

2] La documentation

Ou plutôt l'absence de documentation. Voici la documentation officielle de Perfect Developer. Je vous invite à porter une attention particulière à l'Annexe A2 qui documente l'API.

Il n'y a rien à comprendre. En fait, pour comprendre la syntaxe, il faut comprendre la syntaxe. Quelle brillante idée. Documentation du langage écrite avec son propre langage. Tu n'explique pas la syntaxe de la langue française à un Chinois avec un document en Français !

Mais tout ça serait acceptable si pour chaque méthode il y avait un exemple. Voici un extrait de la javadoc de la méthode split() de la classe String. On voit que tout est expliqué avec des mots simples. Plusieurs exemples illustrent des cas d'utilisation typiques. Très facile à comprendre, même pour quelqu'un qui n'a aucune idée comment utiliser cette classe ou cette méthode.

Aussi, il n'y a aucune documentation alternative. Pas de blog, pas de registre d'exemples.. rien. Mais c'est peut-être simplement parce que personne n'utilise Perfect Developer ? Je n'aurais pas de difficulté à comprendre ça.

3] L'architecture

La façon dont Perfect Developer gère les intéraction entre les différents objets est très mathématique. On peut faire des opérations telles que l'union de deux ensembles ou l'intersection. Malheureusement, cela implique que pour exprimer l'appartenance, il faut souvent recourir à une relation.

Par exemple, supposons que nous avons une classe Maison et que cette classe possède une liste de Personnes. Une personne possède un nom.

En Java :

class Maison{
    List habitants;
}

class Personne{
    String nom;
}

En Perfect Developer :

class Maison ^= 
    var
        habitants : map of (Personne -> String);

class Personne ^= tag;

Quel est le problème ?

On n'encapsule pas le nom à l'intérieur de notre classe Personne. Bien sur, il est possible de le faire. Cependant, le problème survient lorsque plus tard on veut spécifier des opérations complexes (Le déménagement d'une personne par exemple). Il devient très difficile et très lourd d'accéder aux données à travers de nombreux niveaux d'encapsulation.

Bref, pour se simplifier la vie, lorsque deux classes ont une relation 1-*, utiliser une map.

Vous ne voudriez pas maintenir un logiciel où tout est une HashMap n'est-ce pas ? Ce n'est pas très orienté objet !

Moi non plus.

4] La vitesse

Grâce à ce superbe langage, écrire une spécification est long et pénible. Mais ce n'est pas le seul problème. Vérifier la spécification est interminable !

J'écris ce post entre 2 vérifications. Et ce n'est pas parce que notre spécification couvre un gros logiciel ! À moins que 3 classes soit un signe que ton logiciel est trop gros ?

La spécification sur laquelle je travaille présentement nécessite plus de 15 minutes à prouver. Les Warnings et les Erreurs n'apparaissent qu'une fois les 15 minutes écoulées. Il n'est donc pas possible de faire progresser le projet durant cette période... et la spécification fait moins de 200 lignes (incluant les commentaires).

Afin de ne pas se donner de chance, Perfect Developer vérifie la spécification en entier, même si seulement une partie minime a changée.

5] La pertinence

Comme vous avez peut-être compris au fur et à mesure de la lecture de ce post.. L'écriture d'une spécification en Perfect Developer nécessite beaucoup de temps, d'effort et de patience. Mais si tout ces efforts servent à complètement éliminer les bugs de votre logiciel, ça vaut la peine, n'est-ce pas ?

Non.

Mais ce n'est pas un "Non ça ne vaut pas la peine d'éliminer tous les bugs". C'est un "Non, ça n'élimine pas tous les bugs". En effet, Perfect Developer ne peut pas garantir que votre code est parfait. Évidemment, la spécification n'est aussi bonne que celui qui l'écrit. Il peut y avoir des bugs dans votre spécification (belle ironie).

En ayant à tout coder 2 fois (Une fois pour écrire la spécification et une autre fois pour coder le logiciel), on double les chances de créer des bugs. On augmente également les coûts de production.

Ok, ok, supposons que nous avons quelqu'un qui maitrise vraiment bien le langage. On peut s'attendre à ce que la spécification crée par cette personne donnera une bonne garantie de l'absence de bug dans notre logiciel. On peut donc s'attendre à ce que ceux qui ont développé Perfect Developer aient les connaissances nécessaires afin de produire une spécification blindée.

On peut lire sur le FAQ de Perfect Developer :

There would be no point in selling a product to generate bug-free code if it contained bugs itself, therefore nearly all of Perfect Developer is implemented in its own technology.

Donc un des arguments de vente du produit est "Notre produit à pas de bug puisque nous l'avons certifié avec notre produit qui élimine les bugs". À part la faille flagrante de logique circulaire, il y a quelque chose de fondamentalement faux dans cet argument.

Internal error: rewrote using illegal branch combination! Please submit your example to Escher Technologies.

Perfect Developer a des bugs. En effet, ma spécification compile. Je sais que la logique est bonne. Cependant, elle fait planter le logiciel. À tous les coups !

Bravo Escher Technologies.

Je penses que ça démontre bien l'inutilité de tout ça. Leur logiciel est spécifié par Perfect Developer. Ils connaissent bien leurs outils. Il y a quand même des bugs. Les spécifications formelles n'en valent pas la peine.

Conclusion

Je trouve que les spécifications formelles sont un beau sujet de recherche. Il est facile de voir l'attrait ! Éliminer complètement les chances d'obtenir des bugs ?

Malheureusement, je crois que le temps investit sur la spécification formelle ne vaut pas la peine. Mieux vaut compter sur la compétence des développeurs et sur d'autres filets de sécurité comme les tests d'acceptation et les tests fonctionnels.

Le manque d'outil est également à blamer. Si seulement il était possible de vérifier une spécification en un temps raisonnable sans avoir un Super-Computer.

.. Dites moi ce que vous en pensez dans les Commentaires !

La suite...

La puissance des langages de script

Je travaille présentement sur un projet d'extension sur Google Chrome. Pas CustomNewTab, mais bien une nouvelle idée.

Petite mise en contexte afin de faciliter mon explication.

L'extension sur laquelle je travaille permet d'exécuter des scripts javascripts via un mouvement de la souris. Un début de FireGestures pour Chrome. Je veux cependant permettre aux utilisateurs de modifier le script afin de facilement ajouter des gestures et des actions associées à ces gestures.

Afin de garder la syntaxe la plus simple possible, j'ai décidé d'implémenter les gestures custom comme ceci :

newTabGesture = ["up"];
closeTabGesture = ["down"];

function  newTabFunc() {
    window.open();
}

function closeTabFunc() {
    window.close();
}

myGestures = [ [newTabGesture, newTabFunc],
[closeTabGesture, closeTabFunc] ];

On voit qu'on peut donc facilement définir une gesture comme un Array de string qui expriment clairement la séquence de mouvement à faire pour que la gesture soit reconnue. On définie ensuite une fonction qui va être associée au mouvement. On exprime cette association dans myGestures qui est un Array de paires (gesture, action).

Beaucoup d'explication, toujours pas de magie. Patience !

Plus loin dans le script, je capture les mouvements de la souris et je les sauvegarde comme un Array de mouvement également. Par exemple capturedGesture = ["up","down","up"]. Maintenant, je peux simplement faire :

myGestures[capturedGesture]();

Qu'est-ce que ça fait ? On obtient la donnée placée sous l'index capturedGesture, soit la fonction associée à cette gesture. Ensuite, grâce aux parenthèses, on exécute la fonction placée à cet index dans l'array.

Bref, on fait tout en une ligne de code.

Tout ça grâce au fait que tout est un objet. En effet, en javascript il est possible de faire :

var f1 = function() { alert("Function1") }
var f2 = f1;
f2(); // Affiche "Function1" à l'écran !

C'est une des raison pour laquelle je commence à apprécier de plus en plus les langages de script ( Python en particulier )... Essayez simplement d'imaginer le code nécessaire afin de pouvoir faire la même chose en Java.

La suite...