Incapable de supporter des noms de fichiers ou de répertoires un peu long, obligé de faire des bidouilles infâmes pour contourner le problème (passer en DOS, zipper puis décompresser le répertoire gênant), pfff. Quel temps je peux perdre… Pittoyable.
.
Promouvoir les standards du web… À quoi ressemble votre site sans CSS ?
Il y a quelques temps, j’ai eu l’occasion de rencontrer un cas qui m’a
donné à réfléchir sur la signification des suffixes anglais able et
ed. En l’occurrence, le cas portait sur une classe qui dérivait en
Java de ArrayList qui s’appelait SortedArrayList.
Cette classe ajoutait la possibilité de tri à sa super-classe ArrayList.
Elle possédait pour ce faire la méthode sort(), et c’est justement ça
que je le lui reprochais.
Le suffixe able signifie qu’un objet peut atteindre un état, sans y être nécessairement constamment, par l’appel par exemple d’une méthode qui lui fera atteindre cet état à un instant t. Pour une propriété X, le sufixe ed signifie quant à lui qu’un objet est constamment Xed.
C’est peut-être un peu abstrait comme ça, je vais donc illustrer avec la classe SortedArrayList dont j’ai parlé ci-dessus.
Une classe en ed, comme sorted, est triée. Cela signifie qu’elle l’est constamment, en considérant un point de vue extérieur à l’objet : en interne, l’objet peut ne plus respecter l’état, mais au retour de la méthode, il doit y être revenu. Exemple : dans le corps d’une méthode add d’un conteneur trié, il peut se faire que l’objet soit non trié à un instant t, mais jamais au retour de la méthode add en question.
Toute action occasionnant une modification de son contenu doit laisser l’objet …Sorted trié à l’issue de l’opération. Par exemple, un add sur un SortedSet en Java n’a pas besoin d’être suivi par un tri pour qu’une itération ultérieure sur l’instance se fasse toujours dans l’ordre de tri.
À l’inverse, un objet suffixé par able est par exemple Triable et
non Trié, ce qui n’est pas du tout la même chose. Ainsi, une classe
nommée SortableArrayList possédera une méthode sort() et l’ajout d’un
objet à cette liste pourra ne pas forcément garantir que l’objet soit
constamment dans un état trié. Il sera alors possible d’appeler la
méthode sort() pour rétablir l’état trié au moment voulu.
C’est assez simple. Je dirais que ça peut d’ailleurs souvent être lié à des questions de performances. Il sera en effet certainement plus coûteux de chercher à maintenir un état particulier constamment si ce n’est pas absolument nécessaire. Auquel cas, il semblera alors plus approprié d’utiliser le suffixe able et la méthode permettant de revenir à cet état.
Si par contre, vous avez souvent, voire toujours besoin d’accéder à l’objet alors que celui-ci est dans l’état voulu, utilisez le suffixe ed pour que toute opération touchant à la structure de l’objet conserve l’état à son retour.
Je suis en train de jeter un oeil à un cours de Java pour ma culture. Dans la deuxième partie de ce cours, on part en vrille :-) :
Je vous laisse en exercice de trouver d’où vient ce cours. J’ai vérifié, c’est très facile avec Joujeule… Mais ne vous moquez pas trop vite, celui qui a créé ce cours sait très bien ce qu’il dit (enfin, le plus souvent, quoi :p).
Note pour Vincent : Oui oui, c’est bien notre foufou à nous… Tu auras de plus reconnu “Le Mal®”.
Depuis maintenant un peu moins d’un an, Mediawiki a été installé dans mon entreprise.
C’est un peu amusant, parce que je pense en être le principal instigateur, mais je ne peux pas le dire avec certitude. En effet, à l’époque, j’en parlais en effet souvent à celui qui allait devenir mon responsable aujourd’hui. Je discutais avec lui de toutes ces technologies, de tous ces outils modernes, connus ou moins connus, à la mode pour des raisons justifiées ou non.
Je lui parlai donc de ce qu’était un wiki, lui expliquai le principe. “Une bonne démo valant mieux que de longs discours”, ainsi pourrait-on détourner la formule consacrée, je lui montrai successivement ChuWiki, puis Mediawiki. Je me souviens que c’est à ce moment que, sentant que de l’intérêt était présent face à moi, j’ai beaucoup cherché des arguments me permettant de mieux défendre l’idée d’utiliser un wiki dans l’entreprise. Je cherchais surtout ces arguments pour convaincre si besoin les responsables de l’entreprise.
Pour moi, l’intérêt majeur d’un wiki d’entreprise réside dans la centralisation de la documentation. Toutefois, il ne fallait pas que le wiki impacte le processus de certification qualité en cours de mise en place, utilisant déjà largement word et ses modèles… Je défendai donc la pertinence du wiki pour ce que j’estime être sa plus grande utilité : la rédaction de toutes ces petites documentations, ces FAQ, qui devraient être utilisables et modifiables par tous, tout le temps. Mais aussi SURTOUT qu’on puisse être certain de disposer toujours de la dernière version d’une doc, ce qui est loin d’être trivial lorsque vous travaillez avec des gens qui ont pris l’habitude depuis longtemps de passer leur temps à s’échanger des fichiers word par mail. Personnellement, ma plus grande hantise lorsque je dois écrire une documentation avec un traitement de texte est de savoir où je vais bien pouvoir la mettre… Avec un wiki, je ne m’occupe que de choisir un nom de page qui exprime le plus clairement possible son contenu (sémantique, mon enfant, sémantique, ya qu’ça de vrai !), le stockage n’est plus mon problème.
Un jour, Lionel est revenu me voir en me disant : “Bon, la direction veut qu’on installe un wiki, rapidement.”. Je pense que ceci est arrivé parce qu’à l’époque, 01 Informatique commencait à en parler. Alors, comme ça faisait un peu plus “DSI-hype” qu’avant, on a eu carte blanche pour le monter. Dès la semaine suivante, la moitié du centre de développement était invitée à une présentation/formation sur le sujet, faite par Lionel, à laquelle j’ai assisté pour l’assister :-).
La formation devait partir de très loin. Une partie non négligeable des développeurs de l’entreprise utilisent encore leur navigateur de façon très épisodique, et ne connaissent que les outils qu’ils utilisent depuis longtemps. Il fallait donc parfois non seulement expliquer ce qu’est le code wiki, mais aussi montrer qu’on pouvait changer le nom par la barre d’adresse du navigateur, etc.
Cette formation avait évidemment pour objectif de présenter la philosophie générale d’un wiki, en plus de son utilisation. Ceci nous paraissait indispensable de présenter notre wiki de la sorte afin d’éviter que l’auditoire ne prenne par exemple le wiki pour un simple marque-page vers les documents word actuels ou futurs qui continueraient à être disséminés sur les serveurs de l’entreprise…
Le wiki a continué à grossir et à prendre sa place. Il a été modifié très majoritairement par Lionel ou moi jusqu’à récemment. Les projets actuels ont fait que nous l’avons beaucoup utilisé pour documenter notre processus de développement J2EE. Nous mettons ainsi beaucoup de code Java et (X)HTML.
Plus cela allait, plus il nous apparaissait indispensable de chercher à ajouter la coloration syntaxique au wiki, afin d’améliorer la lisibilité des différents morceaux de code présents. J’ai donc cherché une solution et trouvé l’extension GeSHI pour mediawiki. En suivant précisément la documentation fournie, l’installation de l’extension prend 5 minutes maximum. Appliquez bien les bugfix spécifiés sur le lien ci-dessus.
La première question qui vient à l’esprit pour tout utilisateur de CSS
est de se demander quelle est la forme du code généré par GeSHI. Et
bien, c’est très propre. Par défaut, le code généré utilise les styles
inline pour colorer le texte. Il est toutefois simplissime de modifier
ce comportement. En lisant la documentation de
GeSHI, on
trouve l’appel à la méthode enable_classes(true).
Ajoutez simplement $geshi->enable_classes(true); avant le return de la
fonction formatCode de l’extension et ça marche ! Après, il vous reste
bien sûr à écrire le code CSS pour mettre la forme et les couleurs qui
vous conviennent.
Note : J’ai essayé l’extension sur la dernière version actuelle (Mediawiki 1.5.5). Pour faire ça, j’ai dû migrer de la version 1.4.3 vers la dernière. Suivez la documentation de mise à jour à la lettre (notamment la mise à jour de latin1 vers utf8 si besoin, primordiale) si vous êtes dans le même cas que moi.
J’ai voulu ajouter un bouton pour ajouter rapidement les balises <code type=“java”></code> autour du code sélectionné, à la manière de ce que permettent les autres boutons pour mettre en valeur, faire un lien, etc.
C’est très simple à faire :
getEditToolbar().array( 'image' =>'button_hr.png',
'open' => "\
\
",
'close' => '',
'sample'=> '',
'tip' => wfMsg('hr_tip'),
'key' => 'R'
)
Et remplacez ce qui doit l’être pour faire ce que vous voulez :
array( 'image' =>'button_java.png',
'open' => "<code type="java">\
",
'close' => '</code>',
'sample'=> '',
'tip' => wfMsg('codeJava_tip'),
'key' => 'J'
)
Ceci fait, il vous reste deux choses à faire :
'codeJava_tip' => 'Code Java',
Ça y est, ça marche. Vous avez la coloration syntaxique et un joli bouton pour gagner du temps :-). Je vous laisse en exercice la manipulation précédente pour insérer un bouton pour du code XML :-).
Revenons à mon entreprise. Il a été question récemment de savoir où nous allions bien pouvoir stocker les mots de passe utilisables par notre équipe… Ça commence à faire du monde… Les utilisateurs/mots de passes de :
Étant donné que le wiki est devenu l’emplacement le plus logique pour nos documentations communes, j’ai naturellement pensé à utiliser des pages invisibles à d’autres que nous. Étant donné que nos comptes sont tous sysop, cela doit bien être possible sans trop d’efforts.
Après quelques investigations, il s’est avéré que c’était un peu moins simple que prévu, étant donné que ce n’est pas un comportement standard et intégré à mediawiki. En effet, il existe la possibilité de définir des pages en lecture seule, mais pas d’empêcher carrément la lecture. La raison énoncée est que ce n’est pas la volonté d’un wiki de permettre le masquage d’une partie de l’information. Toutefois, cette fonction est maintenue sous forme de patch pour certains contextes, tels qu’une entreprise, où ce type de page peut s’avérer très utile.
J’ai donc testé le patch en question sur mediawiki 1.5.5. J’ai utilisé le principe de namespace secret. Celui-ci fonctionne parfaitement. Si vous souhaitez mettre en place cette fonctionnalité sur votre mediawiki, voici une version raccourcie et simplifiée de la configuration à ajouter en fin de votre LocalSettings.php :
$wgExtraNamespaces = array(100 => "Secret", 101 => "Discussion_secrète");
$wgRestrictedNamespaces = array(100 => "namespacePriv", 101 => "namespacePriv");
$wgGroupPermissions['sysop']['namespacePriv'] = true;
Ces trois lignes définissent un namespace Secret (exemple : la page bonjour du namespace Secret s’appelle Secret:Bonjour) et sa page de discussion associée “Discussion secrète” (attention à enregistrer votre fichier en utf8 si vous voulez voir l’accent de secrète s’afficher correctement). Tous les utilisateurs appartenant au groupe standard sysop pourront voir et éditer ces pages.
Notons que le patch est bien fait : si vous n’êtes pas de ce groupe, vous ne verrez pas apparaître les modifications sur ces pages dans vos “Modifications récentes”. Ça peut paraître évident, mais heureusement toutefois que c’est fait afin d’éviter que des utilisateurs puissent avoir envie de hacker la lecture de ces pages en les voyant sans cesse dans les pages modifiées. Bien sûr, si un utilisateur qui n’est pas du bon groupe tape directement le nom d’une page cachée, il ne pourra tout de même pas la voir, donc tout va bien :).
Voilà, ce sera tout pour aujourd’hui. Je vous laisse passer une agréable fin de week-end et à bientôt.
Aujourd’hui, dix kitesurfers toulousains motivés au Cap. Arrivés sur place, 5.5°C au thermomètre d’une des voitures :-).
Avant de m’arrêter, lorsque je revenais à pieds après avoir pas mal dérivé, à cause du fait que je ne sais pas encore remonter au vent, j’ai compté rapidement le nombre de planches-à-voiles et d’ailes de kite dans l’eau : une trentaine de planches et entre 10 et 15 kitesurfs.
Comme me l’a dit un habitué, quand on voit le monde qu’il y avait aujourd’hui par 6 ou 7°C, imaginez un peu le monde qu’il y a au printemps lorsque le temps est plus propice !
Entendu sur R&R. Pour ceux qui connaissent cette chanson de Corynne Charby, ça devrait au moins vous tirer un sourire :
Chui comme une couille de dauphinnn
Et bonne année, sinon :-).
Mon chef, déconneur devant l’éternel, en train de lutter contre une erreur dans le développement d’une application Web J2EE :
Mais p****, pourquoi il trouve pas l’haricot dans le faisceau
faisceau => scope, haricot => je vous laisse trouver :-)
Puis, quelques minutes plus tard :
Nom d’un Form Bean !
Bon, je replonge… Ça va pas fort, moi :)
@ bientôt…
Je reprends le titre utilisé par Bix dans ce billet sur la loi DADVSI.
Vraiment n’importe quoi. Pour ceux qui ne seraient pas convaincus des problèmes que peut occasionner cette loi, je vais essayer d’en illustrer avec deux exemples simples : un mondialement connu sur le code développé pour pouvoir lire des DVD sous Linux et un exemple beaucoup plus proche.
“toute personne contournant, de manière directe ou indirecte, un dispositif sera présumée coupable du délit de contrefaçon (3 ans de prison et 300.000 euros d’amende)”.
Voilà une partie de la loi sur le droit d’auteur et les droits Voisins dans la société de l’information qui concerne très clairement les exemples suivants :
Un cas très connu qui aurait été directement concerné par cette loi, c’est DVD Jon, un garçon qui voulait lire le DVD qu’il avait acheté avec ses sous, le salop… (Le Cinquième Élément je crois, pour la petite histoire).
Problème : ce jeune homme utilisait alors (et utilise encore) Linux et ne pouvait à l’époque pas lire le DVD puisqu’aucun lecteur ne disposait des codes de décryptage DVD (ce code s’appelle CSS comme Content Scrambling System)…
Passionné d’informatique, il a décidé de chercher à le lire quand même, a fini par réussir et a expliqué publiquement comment faire (je simplifie l’histoire). Pour faire cela, la seule solution existante est la rétro-ingéniérie (je vous laisse suivre le lien si vous voulez en savoir plus sur ce procédé).
Il a été attaqué en justice et cela a occasionné l’un des plus importants procès sur le sujet. Il a été relaxé entièrement le 7 janvier 2003. Il a gagné ce procès contre deux mastodontes, dont la MPAA… Mais l’utilisation de son outil permettant de lire les DVD sous Linux (appelé DeCSS) est pourtant toujours illégale dans certains pays…
Qu’aurait-il dû faire ? Est-ce que le législateur aurait osé lui répondre : “Hep, tu restes tranquille ! Tu achètes Windows, un logiciel de lecture de DVD et tout ce qui va avec hein !”. J’espère bien que non…
Enfin bref, tout ça peut paraître lointain. Si ça vous parait trop lointain, j’ai un exemple beaucoup plus proche
J’ai acheté à ma copine un double CD de Norah Jones. Après l’avoir acheté, j’ai aperçu un logo au dos du paquet indiquant (de mémoire, je ne l’ai pas sous les yeux) “Protégé contre la copie”.
J’ai payé ce CD. Je ne suis donc pas un voleur. Mais je le promet ici solennellement : si jamais il m’est impossible de le lire sur tous les appareils dont je dispose chez moi (un petit poste cd/radio/mp3, ordinateurs), je n’hésiterai pas une seconde à faire tout mon possible pour faire sauter cette protection afin de pouvoir lire ce CD QUE J’AI PAYÉ !!!.
Étant donné que j’ai laissé ce billet en attente depuis déjà un bon bout
de temps. Deux ou trois semaines je dirais (cf. billet de bix en
référence ci-dessus). J’en avais écrit une bonne partie, mais n’avais
pas trouvé pris le temps de le finir.
Entre temps, Noël est arrivé et le fils de Tristan Nitot a eu droit pour Naouëlle à une toute moderne chaîne Hi-Fi, capable de lire des CD, des CD mp3 et tout et tout. Avec cette chaîne lui a été offert un double-CD… Je vous laisse lire la suite de l’histoire chez Tristan
Une chose absolument incroyable est en train de se produire. Mais bien sûr, elle arrive tellement progressivement que nous ne nous en plaignons que faiblement. D’un standard ouvert grâce auquel il était pourtant initialement possible de faire qu’un CD^[1]^ soit lisible partout, nous sommes en train de parvenir à une aberration qui fait qu’il devient aujourd’hui de plus en plus courant de voir écrit sur les emballlages une mention “Lecture non garantie sur tous les lecteurs”.
Eh oui, les CD soit disant protégés contre la copie le sont aussi souvent contre la lecture par un effet de bord inévitable : il est strictement impossible de permettre la lecture de quelque chose et d’en empêcher la copie. C’est logique : une chose que vous pouvez lire est forcément copiable. Tout procédé technique affirmant pouvoir l’empêcher est une blague.
Les “têtes pensantes” de l’industrie de la musique ont sans doute refusé de le croire pendant longtemps, et je pense que c’est cela qui a fait naître un grand nombre de procédés techniques “infaillibles”, cassés en quelques minutes par n’importe quelle personne disposant d’un lecteur CD, désireux de le lire, son CD, le salop (encore)…
Finalement, à force d’échecs sur le plan technique, il ne restait plus qu’une ultime solution : le plan légal.
Vous ne comprenez pas ? Vous allez voir, ce n’est pas compliqué : on vous colle encore un des nombreux procédés techniques de protection contre la copie, cassable techniquement en trois minutes, mais ce coup ci, c’est devenu clairement illégal de la contourner (3 ans de prison et 300.000 euros d’amende, cf. plus haut). Tout simplement génial, non ? Il fallait y penser, bravo à eux !
Mise à jour :
[1] Notez d’ailleurs que le nom Compact Disc est déposé et que son dépositaire (Philips, semble-t-il) refuse justement qu’il soit utilisé pour des disques mettant en œuvre un système de protection anti-copie. Il est donc théoriquement illégal d’utiliser le terme CD pour parler d’un disque protégé…
Message personnel… :-)
Après cette sortie de samedi dernier qui s’est révélée être idéale (air ~ 15°C, eau pareil) bien couvert (intégrale 5/3 + gants + chaussettes néoprène), j’ai vraiment hâte d’y retourner pour progresser.
Justement, lorsque j’y retournerai… Eh ben pour ça, en ce moment, je pense à deux choses qui me seraient bien utiles pour le kitesurf, lorsque je m’y remettrai vraiment vers mars/avril prochain :
Bref… À bon entendeur :)