Blogue

Inopinément

Les « paniques du noyau » (kernel panic) sont des événement rares sous Mac OS X. J’en ai vu une l’autre jour : l’écran s’assombrit puis un message apparaît en plusieurs langues demandant de redémarrer l’ordinateur. Au redémarrage, un message apparaît :

L’ordinateur a redémaré après que Mac OS X a quitté inopinément.

Une panique du noyau n’est pas supposée arriver souvent — pas du tout en fait — alors peut-être que ça explique qu’il ait pu se glisser une faute de grammaire ici sans que personne ne s’en rende compte. Êtes-vous capable de la trouver ?


Mise à jour sur Multi-Safari

C’est drôle de voir combien de personnes sont devenues intéressés tout d’un coup à Multi-Safari dans les dernières semaines. Ces dernières semaines, Apple a sorti Mac OS X 10.5 Leopard, avec Safari 3, et la mise à jour 10.4.11 pour Tiger, aussi avec Safari 3, laissant beaucoup de monde à la recherche d’une façon de tester leurs sites web sur les anciennes versions de Safari.

Il semblerait que les différents paquets de Multi-Safari fonctionnent bien sous Leopard… c’est vrai, à moins d’effectuer la mise à jour 10.5.1, dans un quel cas vous obtiendrez un message d’erreur vous disant que cette version de Safari ne fonctionne pas sur Leopard. Je n’ai pas Leopard d’installé ici donc tout ce que je vous dit est basé sur ce qu’on m’a communiqué par courriel. Et malheureusement, puisque je n’ai pas encore Leopard, il ne m’est pas possible d’enquêter plus en détail dans le but de trouver une solution.

Ceci dit, ça me semble étrange, dans une mise à jour mineure, qu’une application cesse de fonctionner. Peut-être qu’une nouvelle mesure de sécurité inactive dans la version précédente de Leopard s’est soudainement mise à fonctionner, ou peut-être qu’Apple a bloqué délibérément les versions plus anciennes de Safari (ce qui ferait du sens vu qu’en temps normal rouler un vieux Safari sur un nouveau système n’est pas quelque chose à faire). Si quelqu’un a un indice, j’aimerai bien l’entendre.

En attendant, il faut donc utiliser une installation de Tiger (10.4) pour rouler Safari 2, ou utiliser Leopard sans la mise à jour 10.5.1.


Le mode « sans HTML » de PHP Markdown

On m’a souvent contacté en me demandant comment désactiver le HTML dans PHP Markdown. Jusqu’à il y a quelque mois, j’était opposé à offrir cette possibilité parce que le HTML fait tout simplement parti de la syntaxe Markdown. Après tout, Markdown a été conçu pour que lorsqu’il n’y a pas d’élément de la syntax qui fait ce que vous voulez, ou si vous ne connaissez tout simplement pas la syntaxe, vous n’avez qu’à l’écrire en HTML.

Enlever le support pour le HTML dans ce contexte voudrait dire plus de pression pour implanter une syntaxe spécifique à Markdown alors que Markdown (avec HTML) n’en a pas vraiment besoin. Ça force aussi les utilisateurs qui ne sont pas familier avec la syntaxe à l’apprendre puisqu’ils ne peuvent plus écrire en HTML. La meilleur option, à mes yeux, est de simplement restreindre l’usage des balises et attributs HTML à ce qu’on désire permettre.

À force de répondre à des questions, je me suis aperçu que beaucoup n’était pas vraiment intéressés par mes arguments. Et la réponse au problème technique n’était pas toute simple : à moins de sacrifier les blocs et les étendues de code, ainsi que les liens automatiques, il n’est pas possible de simplement échapper à l’avance les caractères plus petit que < utilisés pour l’ouverture des tags.

En gros, plusieurs ont implanté ça incorrectement sans même s’en rendre compte (parce qu’ils n’utilisent pas beaucoup les étendues et les blocs de code ou les liens automatiques). J’ai réalisé que c’était probablement plus problématique pour les utilisateurs qui apprennent Markdown que le manque de HTML. J’ai donc changé mon attitude par rapport au problème et décider d’aider ceux qui veulent désactiver le HTML complètement.

Si vous voulez désactiver le HTML dans PHP Markdown, ne modifiez pas le code !

PHP Markdown a dans sa dernière version un réglage (caché) qui fait exactement ça. Vous n’avez qu’à instancier le parseur et vous-même et à changer la propriété no_markup comme ceci :

$parser = new Markdown_Parser; // or MarkdownExtra_Parser
$parser->no_markup = true;
$html = $parser->transform($text);

Il y a aussi une propriété no_entities que vous pouvez mettre à true pour désactiver les entités de caractère.

Notez qu’en interdisant les balises HTML vous refusez aux utilisateurs de votre script, CMS, ou application web la seule alternative pour créer des éléments que Markdown ne fourni pas, tel que <sup> et <sub>, <ins> et <del>, <q>, <bdo>, <abbr>, <object> (nécessaire pour insérer des vidéos), et plusieurs autres. Une meilleure alternative serait de simplement filter la sortie HTML en utilisant quelque chose comme kses, mais je vous laisse juger par vous même de ce qui convient le mieux à vous et à vos utilisateurs.

Avec le pouvoir viens des responsabilités : s’il vous plait assurez-vous d’offrir à vos vos utilisateurs la meilleure expérience possible avec Markdown. Merci.


Drôle, ces garanties prolongées

On achète un ordinateur, ou un électroménager, et on nous offre toujours une garantie prolongée qui s’étend au delà de ce qu’offre de base le manufacturier. C’est bien connu que ces garanties sont profitables pour les commerces, et il est évident que si ça l’est c’est parce que, en moyenne, les coûts de réparation pour ce type d’appareil sont plus faibles que le coût de la garantie. Uniquement de ce point de vue, sauf rare exception, il serait moins coûteux de payer soi-même pour les réparations.

Hors il y a encore plus étrange : ces coûteuses garanties n’offre généralement rien qui n’est pas déjà couvert (gratuitement) au Québec par la loi sur la protection du consommateur. Je vous sort quelques articles :

  1. La présente section s’applique au contrat de vente ou de louage de biens et au contrat de service.

Bon, on sais de quoi on parle quand on parle de contrat maintenant. Passons aux choses sérieuses.

  1. Un bien qui fait l’objet d’un contrat doit être tel qu’il puisse servir à l’usage auquel il est normalement destiné.

  2. Un bien qui fait l’objet d’un contrat doit être tel qu’il puisse servir à un usage normal pendant une durée raisonnable, eu égard à son prix, aux dispositions du contrat et aux conditions d’utilisation du bien.

Donc si le vendeur nous dit que l’appareil est fait pour durer 10 ans, que le prix est raisonnable, et qu’il brise après seulement deux ans, le vendeur est responsable.

  1. Le consommateur qui a contracté avec un commerçant a le droit d’exercer directement contre le commerçant ou contre le fabricant un recours fondé sur une obligation résultant de l’article 37, 38 ou 39.

Autrement dit, si un tel appareil vous lâche après deux ans, même si vous avez dépassé la période de la garantie de base, vous pouvez demander au vendeur qu’il le répare, à défaut de quoi vous pouvez porter plainte à l’Office de protection du consommateur et intenter une poursuite aux petites créances. C’est mon interprétation, et ça semble correspondre à l’opinion d’Option consommateurs.

Donc la garantie prolongée, en plus de coûter sensiblement plus cher que ce que le coût probable des réparations couvertes, revient généralement à payer pour quelque chose de déjà couvert par la loi québécoise. Son seul avantage serait d’être plus facile à faire respecter par le commerçant, mais est-ce que cet avantage vaut vraiment son prix ?



  • © 2003–2024 Michel Fortin.