Dring a écrit 1182 commentaires

Et je me permets à ce titre d'insister lourdement !

Les machines d'il-y-a-pas-si-longtemps-que-ça ne proposaient pas le boot depuis un port USD, alors que c'est possible depuis le lecteur de CD. Donc, pour certains PC, ça reste la seule solution.

Pour tous les diagrammes "simples", l'outil de dessin de OpenOffice est carrément parfait.

Pour les diagrammes plus complexes, je me rabats sur un logiciel spécialisé, genre ArgoUML pour tout ce qui est UML.

Euh, l'édition de lien, ou la liaison peut-être. Le "liage", ça fait mal à l'oreille. En tout cas la mienne.

Euh, le monsieur parle des personnes conduisant des "monoplaces", pas des "monospaces", autrement dit des pilotes automobiles, dont c'est justement le métier.

Ou alors j'ai rien compris ?

D'ailleurs, ils ont même le droit de travailler pour moins cher.

Pour les recherches par tag avec "ET", c'est possible, en te créant des recherches personnalisées.

Par contre, je voudrais un truc qui permette de dire "je ne veux que ces tags là". Je n'ai pas trouvé, mais ça ne veut pas dire que ça n'y est pas.

En tout cas, Digikam est le logiciel KDE auquel je suis le plus fidèle. Autant il m'arrive de lancer Firefox au lieu de Konqui à cause de certains sites (Photoways et son applet java entre autres), autant je ne me sers que de Digikam pour la gestion de mes photos.

Dès que j'ai le choix, je prends des galettes à la pomme. La pomme ça roxorise des ours polaires.

Tu devrais essayer le module Draw de OpenOffice, il supporte les connecteurs et ça suffit pour bien des schémas.

Sache jeune padawan que je n'aurais jamais tord. Avoir tort me suffira largement ;-)

Effectivement, la page sur Wikipédia est très enrichissante, mais ça n'empêchera pas la syntaxe de me rebuter. Après, j'ai peu l'occasion de faire du traitement en parallèle, donc je survivrais.

Je viens de lire le comparatif, et je suis attéré par la syntaxe en Erlang. Je suis le seul à penser que taper :

<<"ma chaine">>

...plutôt que...

"machaine"

...ça dénote déjà un manque d'esprit pratique ? Comment peut-on imaginer une syntaxe ou taper une chaîne de caractères exige déjà 6 caractères de contrôle là où la plupart des langages, y compris les plus vieux, n'en demandent que 2 ?

Bon, je connais pas Erlang et ses avantages, mais après avoir lu ça j'ai pas trop envie de creuser. J'ai tort ?

Avec ce nom, et ce logo, je crains que si le site gagne en popularité, il se retrouve vite sous les feux de l'actu pour des raisons judiciaires...

...il n'y a même pas de screenshot !

Plus sérieusement, la synchro des scan séquentiels, c'est du tout bon. Le genre d'optim qui divise par deux le temps d'exécution de certaines requêtes.

On est déjà vendredi ?

Point Godwin atteint en une seule étape : bravo !

Ce que je ne comprend pas, c'est pourquoi utiliser le principe de la vente lié pour tenter d'imposer du Linux dans la concurrence.

Il n'est pas question d'imposer du Linux. Et encore moins dans la concurrence (de quoi, d'ailleurs ?).

Le but est d'offrir le choix : d'acheter un PC avec un autre système d'exploitation, voire pas de système d'exploitation du tout.

Ah bon, Steve Fossett est linuxien ?

Oups... --> []

Ah la la. Ca devait être en 1994 au taf. Le truc s'appelait Walnut Creek il me semble. C'était déjà sur CD, car j'avais un lecteur accessible au boulot. Je ne sais même pas si c'était déjà Linux 1.0.

J'ai réessayé l'année d'après sur mon PC perso, et suite à un find sur le répertoire racine, mon disque dur a rendu l'âme. Ca m'a refroidi, et je n'y suis revenu que 5 ans plus tard. L'année d'après, je basculais définitivement, "grâce" à une Mandrake qui avait bousillé mon boot Windows.

Au bout de 3 mois sans Windows, je me suis rendu compte que je m'en passais sans problème ; je n'y suis plus jamais revenu.

Je répète ce que j'ai écrit dans le journal ad-hoc :

A la lecture des commentaires sur le dot (dot.kde.org), il n'apparaît pas évident du tout que WebKit va remplacer KHTML.

Pour l'instant, il s'agit juste de créer un KPart qui puisse remplacer KHTML dans Konqueror, mais les développeurs de KHTML n'ont pas l'air unanime sur la décision (ou non) de faire de WebKit le moteur principal et/ou unique.

A suivre donc.

Je me réfère surtout au commentaire de SadEagle sur le dot, et à une lecture attentive de l'article.

A la lecture des commentaires sur le dot (dot.kde.org), il n'apparaît pas évident du tout que WebKit va remplacer KHTML.

Pour l'instant, il s'agit juste de créer un KPart qui puisse remplacer KHTML dans Konqueror, mais les développeurs de KHTML n'ont pas l'air unanime sur la décision (ou non) de faire de WebKit le moteur principal et/ou unique.

A suivre donc.

Ca me rappelle une des mes expériences. J'ai récupéré un projet d'interfaçage avec un soft d'un très gros éditeur de logiciels financiers.

La doc : un gros PDF qui ressemble à de la javadoc mais qui n'en n'est pas - et ça se voit, c'est pas à jour. Quand je demande la javadoc, on me dit "oui oui", mais ça ne vient jamais.

Je me dis que je vais la générer moi-même en décompilant la lib, mais pas de chance, elle est obfusquée. Du coup, lorsque je croise des bugs, la pile d'appel n'apporte aucune information utile que je puisse transmettre à leur support...

Et comme il n'ont pas respecté les conventions java (les méthodes commencent par une majuscule, les paramètres par des "p", etc.), la complétion ne marche plus dès que je tape le premier caractère d'une méthode (sauf si je pense à la taper en majuscule bien sûr).

Ils ont développé leur propre mini-framework de logging qui est compatible avec rien, et d'ailleurs ils ne l'utilisent pas toujours, ça va des fois directement dans SystemOut.

Que du bonheur...

Et il y en a encore : un système de licence contraignant et inutile, un "bugzilla" antédilluvien et bien sûr maison, une compatibilité avec uniquement certaines versions de JVM (java 1.4 maxi), etc.

Si je dois utiliser boxes un jour, ce sera pour enlever les cadres, certainement pas pour en rajouter. Rien de pire que les cadres, c'est "le mal" (c). Un commentaire multiligne, tu le fait comme ça :

/*
 * Wonderful function which prepares coffee and buys sugar
 * Don't forget to connect it to emacs
 */

Surtout pas comme ca :

/***********************************************************/
/* Wonderful function which prepares coffee and buys sugar */
/* Don't forget to connect it to emacs                     */
/***********************************************************/

A part faire des fichiers plus gros, rendre l'édition plus chiante pour aligner les fins de lignes, et alourdir la lecture, ça apporte quoi ?

Les commentaires, ça doit être un réflexe.

Et du coup, quelqu'un qui commente mal chez lui, commente également mal dans son boulot. En général.

Parce que le commentaire, ça doit venir avant le code, ou à la rigueur en même temps. Si tu te dis : ça je le ferais plus tard, tu es déjà sur une pente glissante. Et surtout, tu multiplies le temps nécessaire, car quand tu reviens sur ton code 1 semaine ou 1 mois plus tard, c'est bien plus dur de le commenter.

"Mais pourquoi j'ai écrit ça ?" "Bordel, ça correspond à quelle spec ?". Et j'en passe et des meilleures.

Et c'est pas valable qu'en informatique...

A mon sens, et je te rejoins, il ne faut jamais faire de commentaires pour explique ce que fait ton code. Si tu en arrives là, c'est que tu as pondu un monstre immaintenable. Par contre, je rajoute souvent des commentaires pour expliquer pourquoi mon code fait ceci ou cela, et cela prend généralement place dans l'entête de la fonction. Exemple "mauvais" :

fopen();
// début de la boucle
while (!eof()) {
  list.add(readln());
  // ligne suivante
  next();
} // while (!eof())
fclose();

Tous ces commentaires sont totalement inutiles, et le lecteur n'en sait pas plus grâce à eux. Le seul qui soit un petit peu défendable, c'est le "// while ..." qui, pour ceux qui n'ont pas un IDE moderne, permet de se retrouver ; et encore, il faut surtout éviter un trop grand nombre d'imbrications. Un truc comme ça :

/**
 * Chargement du fichier dans une liste de chaînes pour
 * pouvoir ensuite appeler une méthode standard de tri
 */
fopen();
while(!eof()) {
  list.add(readln());
  next();
}

Est bien plus utile. Le lecteur n'a pas besoin de parcourir tout le code pour savoir ce que ça fait, le commentaire apporte un vrai plus sur le code par une vision globale.

Après un calembour pareil, fais comme l'élan : cours !