Je ne suis pas opposé à la pub, je peux comprendre que certains en vivent, soit.

Mais je m'attends à un minimum d'intelligence de la part de ceux qui en mettent sur leur site, surtout dans le respect du contenu, qui doit bien entendu primer. Pour cela, l'espace qui lui est réservé est important, mais aussi le contraste entre lui et les pubs, qui ne doivent pas (trop) s'imposer au visiteur.

Voilà l'exemple parfait de mise en place débile de publicité sur cette page de CMSWire³ :

5 —oui CINQ— fois la même publicité, sous différentes formes mais avec exactement le même message, le même visuel. Le contenu disparaît complètement sous cette avalanche, je suis écœuré, je ferme la page.

Si vous mettez de la pub sur vos pages, faites le bien, avec discernement, sinon vos visiteurs repartiront directement, à moins qu'ils aient un bloqueur de pub, ce qui revient au même pour vous.

Pourquoi voudrait-on le faire ?

Déjà, sur tous les sites permettant de s'authentifier, la procédure devrait être systématiquement sécurisée avec TLS¹, mais ce n'est malheureusement pas toujours le cas. Quand on parle de saisie de données personnelles, éventuellement confidentielles, voir sensibles —système de paiement par exemple—, il devrait de toute façon être interdit de passer outre.

Ce que l'on fait couramment

La pratique la plus courante reste de ne sécuriser que le strict nécessaire, ce qui conduit à avoir certaines pages en HTTP et d'autres en HTTPS. Cela peut conduire —si l'on n'est pas suffisamment prudent— à des pages en HTTPS qui tentent de charger des ressources en HTTP. Jusqu'à présent, seul Internet Explorer se plaignait avec une popup incompréhensible pour le commun des mortels, mais bientôt Firefox 23 refusera tout simplement de charger la ressource. Ce qui nous poussait initialement à rester en HTTP tant que possible était si je ne m'abuse l'impact en termes de performance de TLS, tant côté serveur que client. Cet impact est à priori aujourd'hui négligeable, y compris sur la plupart des smartphones qui débordent de puissance de calcul.

Pourquoi ne pas tout mettre en HTTPS dans ce cas, être certains ainsi que tout est sécurisé, et ne plus risquer de faire des mélanges HTTPS/HTTP ?

Pourquoi ne pas le faire ?

En discutant du sujet autour de moi, j'ai eu les alertes suivantes² :

Les performances

Les performances de ton HTTPS vont beaucoup dépendre des performances de ton fournisseur de certificat SSL et en particulier de ses fichiers de liste de révocation.

Côté performances, il y a https://revocation-report.x509labs.com qui permet déjà de ce faire une idée. Mais ça ne prends en compte que les contrats de SLA publics non négociés, et s'il existe d'autres comparateurs du même type ce sera souvent la même chose.

En tout cas le mois dernier StartSSL (qui est sûrement le fournisseur SSL le moins cher du marché) se targuait d'être en pôle position : https://twitter.com/startssl/status/324975028712116225

Le lien entre certificat(s) et adresse(s) IP du(des) serveur(s)

Côté hébergement on est toujours bloqué à 1 certificat SSL par IP à cause des vieux OS, en particulier Windows XP qui ne supportent pas le SNI (pour Server Name Indication, sorte de vhost SSL pour résumer). La seule vraie solution de contournement qui fonctionne partout c'est le SAN (Subject Alternative Names) qui consiste à embed plusieurs certificats SSL en un seul, mais alors ça implique que tous tes certificats soient chez le même presta SSL.

Les coûts

Il y a également le coût de la requête quand on utilise des CDN. L'écart de prix est en général de 30%, comme chez CloudFront.

Autre impact sur l'usage d'un CDN

Concernant le CDN attention : ton fournisseur ne te laissera peut être pas la possibilité d'utiliser ton propre certificat, […] nous sommes obligés de charger tout le contenu CDN depuis le domaine *.cloudfront.net sous peine d'avoir une erreur de chargement SSL

L'impact sur les choix d'architecture

Varnish ne gère pas le HTTPS. Donc en fonction de tes moyens, si tu ne peux pas te payer un load balancer HTTPS, tu risques de devoir rajouter de la complexité dans ton architecture avec un reverse proxy SSL comme Pound ou Nginx devant Varnish et perdre la capacité de Varnish à gérer très rapidement les ouvertures de connexions.

Commentaire auquel un autre répond :

Les différentes mesures que j'avais effectuées avec Pound sur une archi FreeBSD il y a 2 ans (déjà) montraient que les différences de temps de réponse entre HTTP et HTTPS devant un varnish voire un nginx ou un apache étaient négligeables.

Mais ça ajoute la complexité de maintenir une archi un peu spécifique (en même temps, quand on commence à monter du varnish, c'est qu'on sait qu'on part dans des archis aux petits oignons)

Et vous, qu'est-ce que vous en pensez ?

Finalement, il semble qu'il y ai effectivement des impacts non négligeables, mais pas insurmontables tout de même.

Qu'en dites-vous, des retours d'expérience à partager ?

J'ai la chance d'avoir un superbe écran sur mon MacBook Pro, un ancien modèle avec une résolution « HD » de 1680x1050 pixels dans 15 pouces de diagonale. C'est très utile pour pas mal d'usages, du développement dans un IDE au développement de photos dans Lightroom, mais ça donne une taille réelle un peu petite aux textes définis par défaut à 16px dans les navigateurs.

J'ai donc passé cette taille par défaut à 18px dans les préférences de mon Firefox :

Modifier la taille de texte par défaut dans Firefox

Sur le Mac mini relié à la TV Full HD de mon salon — soit 1920x1080 pixels dans 52 pouces de diagonale — se pose en plus le problème de la distance, puisque je suis à environ 3,5 mètres de l'écran. Bien entendu je l'utilise plus comme media center qu'écran de surf¹ Web, mais pour que ce soit faisable, j'ai dû passer cette taille par défaut à 24px.

Le confort de lecture est bien meilleur dans les deux cas… sur les sites qui respectent ma préférence !

Malheureusement, ces sites ne sont pas légion, la plupart forçant une taille de texte de labeur bien plus petite, souvent aux alentours de 11px comme le soulignait Romy il y a déjà 2 ans. Même sur un écran plus commun et dans des conditions d'utilisation standards, c'est bien trop petit.

Alors vous pourriez vous dire « OK, je passe la taille de texte de mon site à 16px, ça fera plaisir », mais cela ne suffit pas, cela ne peut pas contenter tout le monde ! Certains visiteurs veulent encore plus, comme moi sur mon Mac mini, mais ceux qui utilisent des écrans à faible résolution² veulent peut-être choisir d'avoir une taille de texte inférieure.

Pour compléter, ma liseuse Bookeen Cybook Odyssey a une taille de texte par défaut de 21px dans le navigateur. Certes je ne l'utilise pour ma part jamais pour surfer, ayant toujours un autre appareil plus adapté à portée de main, mais le fait est que toutes les tailles sont dans la nature, il faut l'accepter.

L'unique solution valable et pérenne est donc d'enfin respecter les préférences de vos visiteur, de lâcher prise, comme y invitait Élie Sloïm dans « Web, lâcher prise et libération » sur le blog de Temesis il y a déjà quelques années :

Lâcher prise, c'est comme faire du vélo sans roulettes. Quand on ne sait pas encore, il y a des risques de se faire très mal. Mais quand ça marche, quelle libération.

Bien entendu, je n'ai parlé ici que des préférences de vos visiteurs en termes de taille de texte par défaut, mais ils peuvent modifier bien d'autres préférences, voire même si cela ne suffit pas appliquer des feuilles de styles supplémentaires pour « corriger » vos erreurs³…

Vous savez ce qu'il vous reste à faire.

Voilà le texte de présentation de ce Tumblr :

Difficulté à gérer le succès ? La grosse capitalisation boursière ? La perte de Steve Jobs ? Il y a trop de petits signes négatifs qui entâchent l'image de perfection jusqu'au-boutiste d'Apple ces derniers mois pour ne pas s'inquiéter. Voici quelques preuves…

Le Tumblr est à cette adresse : http://leverestdanslapomme.tumblr.com/.

Bonne visite, et n'hésitez pas à proposer des contenus !

Et je ne dis pas ça juste parce que j'ai eu l'honneur d'être invité à participer à sa relecture par ses auteurs Armel Fauveau et Lionel Pointet¹, c'est vraiment un condensé — très complet et didactique tout de même — des principales bonnes pratiques à respecter pour développer des sites performants, et donc plus agréables pour les visiteurs.

L'optimisation de la vitesse des sites web est en effet un des éléments clefs aujourd'hui de la satisfaction des Internautes, et de leur envie de continuer leur navigation sur le site, voire même d'acheter des produits et/ou services.

En plus, ce mémento a le bon goût de citer mon billet où j'explique pourquoi « PageSpeed et YSlow ne sont pas des indices de performance »… ;-)

Bravo à Karine Joly de Eyrolles pour cette nouvelle référence et merci à Armel et Lionel pour le travail réalisé !

Pourquoi changer ?

Avant de parler des fontes retenues voici une illustration de ce problème que posent les fontes chargées via @font-face aux utilisateurs à faible bande passante.

Le site de Smashing Magazine utilise deux fontes différentes pour la titraille et le corps de texte, chacune étant définie avec une instruction @font-face et nécessitant donc le téléchargement des ressources correspondantes. Ces fontes font partie des éléments importants du récent redesign du site, et participent à sa qualité visuelle, ce serait dommage de s'en priver :

Mais si on va sur le site avec une connexion pas géniale, on obtient très rapidement certains éléments graphiques, et beaucoup moins vite les fichiers des fontes, d'où un affichage assez étonnant :

On constate assez simplement d'où vient le problème :

Nous sommes donc en attente des fichiers des deux fontes, et pendant ce temps là le navigateur ne peut pas afficher le texte.

Quand @font-face a commencé à être largement implémenté dans les navigateurs, ils ne se comportaient pas de la même façon. Firefox par exemple présentait d'abord les textes avec des fontes web safe présentes sur le poste client, avant de redessiner les textes avec les bonnes fontes une fois celles-ci téléchargées. Cela donnait un effet très pénible bien décrit dans le billet de référence sur le sujet, Fighting the @font-face FOUT par Paul Irish. Aujourd'hui, le comportement des navigateurs est plus homogène, ils attendent tous quelques secondes sans rien afficher avant de se rabattre sur le fallback si nécessaire. Il faut donc que les fichiers de fontes soient téléchargés le plus vite possible par le navigateur pour réduire la durée de non affichage.

Dans le cas de Smashing Magazine illustré ici et de tant d'autres sites, une difficulté supplémentaire s'ajoute. Le service Fontdeck que l'on voit dans la base de tâche ci-dessus fait partie des leaders des solutions SaaS de fourniture de fontes, avec notamment Typekit maintenant dans le giron d'Adobe, et Google Web Fonts en alternative gratuite.

Quand un site utilise ce type de service, le navigateur demande les fichiers de fonte à un autre serveur que celui du site, ce qui ajoute un petit délai supplémentaire pour la requête DNS. Les fichiers de fontes arrivent donc plus lentement, pénalisant un peu plus l'Internaute.

Que de points qui peuvent paraître bien négatifs, mais il faut avouer que la richesse offerte par la multitude de fontes maintenant disponibles pour le web permet de développer une grande créativité qui fait beaucoup de bien au Web.

Sauf que mon pauvre blog n'a rien d'un site professionnel dont le design¹ nécessite l'usage de telles fontes. Il doit bien y avoir dans les fontes web safe, c'est à dire ne nécessitant pas de chargement supplémentaire avec @font-face, de quoi proposer quelque chose de suffisamment « joli » — à mon goût en tout cas — et original.

En quête donc…

Mes choix de fontes

Ayant lu et entendu depuis quelque temps que les fontes à empattements ne posent plus de problèmes avec les écrans modernes, voire même améliorent la lisibilité des corps de textes, j'ai décidé de me jeter à l'eau.

Histoire de faire un peu original et éviter les classiques, j'ai cherché un peu ce qui pourrait être disponible suffisamment largement, mais essayer de trouver un ensemble cohérent dans une liste telle que ces most common fonts on all systems to 5 April 2012 n'est clairement pas à ma portée de béotien de la typo. Heureusement, un peu aidé par une recherche sur Google, je suis retombé sur ce billet Revised Font Stack de Amrinder Sandhu qui avait pas mal circulé il y a 3 ans, et je suis immédiatement tombé sous le charme de la font stack issue de Sushi & Robots, battis sur une base de fonte « Hoefner Text »

Un aperçu de la fonte Hoefner Text

Côté titraille, je voulais du coup une fonte linéale pour contraster avec la sérif du corps de texte.

C'est en parcourant la liste des fontes ajoutées à iOS 6 que j'ai découvert la famille de fontes Avenir conçue par Adrian Frutiger pour Linotype, et déclinée en 2003 en Avenir Next. Cette fonte est arrivée ensuite sur Mac OS X avec Moutain Lion puis sur iOS avec la version 6.0.

Un aperçu de la fonte Avenir

Un extrait de la page Wikipedia présentant Adrian Frutiger présente ainsi la famille Avenir (l'emphase est de moi) :

C'est en 1988 qu'il présente le caractère Avenir (dont le nom est un clin d'œil au Futura), le juste milieu entre une Linéale indéniablement géométrique et une Grotesque humaniste, dont l'harmonie des formes génère l'équilibre optique. Avenir s'impose naturellement comme une alternative de qualité au Futura et à l'Avant-Garde, il est moins radical et abrupt, plus chaleureux et avec plus de personnalité. Son utilisation en capitales, que l'on réservera aux titrages, donne beaucoup de stabilité à la composition et également de la classe, grâce à la rigueur de la structure des lettres ; il évoque une certaine prestance, la stabilité et le professionnalisme, la beauté et la féminité. Ses bas de casse possèdent les avantages des Linéales géométriques classiques sans leurs inconvénients : plus faciles à lire, ils peuvent s'utiliser pour des articles de presse ou des rapports relativement courts.

Comment hésiter plus longtemps ?

Les nouvelles font stacks

Du coup, avec ces deux fontes de base qui sont essentiellement présentes sur Mac, le choix des font stacks complètes n'a pas été très simple, mais voici la conclusion :

Pour la titraille :

h1, h2, h3, h4, h5, h6 {
 font-family: "AvenirNextCondensed-Medium", "Avenir Next Condensed Medium", "Gill Sans MT Condensed", "Arial Narrow", "DejaVu Sans Condensed", Calibri, sans-serif;
}

Pour le corps de texte :

body {
 font-family: "Hoefler Text", Constantia, Palatino, "Palatino Linotype", "Book Antiqua", Georgia, serif;
}

Voilà ce que ça donne sur Mac :

Je suis preneur de retours d'utilisateurs de Windows et Linux, en espérant que la théorie des fallbacks s'applique pas trop mal…

Et maintenant ?

Je l'avoue bien volontiers, je suis complètement ignare en termes de typographie. J'ai par exemple beaucoup appris en terminologie avec la conférence « La typographie comme outil de design » de David Rault à Paris Web en 2010.

Il est donc probable que la démarche que j'ai suivie, ainsi que le résultat, ont de quoi faire hurler d'horreur les spécialistes du domaine. Mais tant pis pour eux, je suis plutôt satisfait du résultat, jusqu'à ma prochaine remise en question…

Je ne vais pas pouvoir l'aider sur sa recherche de solution « sans y mettre des sommes folles », mais ma configuration peut être intéressante tout de même :

J'ai donc un Mac mini avec CrashPlan qui sert d'une part, comme je l'envisageais il y a 6 mois, de destination de backup pour tous mes autres ordinateurs, et est d'autre part lui-même¹ backupé sur CrashPlan+.

Le stockage sur le mini n'est pas suffisant pour recevoir les backups de tous mes ordinateurs, donc j'ai un Drobo S de Data Robotics connecté dessus en Firewire 800. Il contient 5 disques de 2 To et est configuré avec 2 disques de fail over pour être un peu plus sûr de ne pas avoir de problème.

J'ai par contre fait l'erreur d'acheter les 5 disques dans la même série, je m'en suis rendu compte trop tard, donc si l'un flanche à cause d'un problème de conception ou construction, la série risque de faire de même dans la foulée.

En tout cas, j'ai déjà eu une défaillance d'un disque, et j'ai eu le plaisir de constater que l'alerte était donnée rapidement, et que la reconstruction du RAID après remplacement du disque s'est faite de façon totalement transparente, sans empêcher l'accès au disque.

Autre point important, les services après vente de CrashPlan et Drobo sont exemplaires, j'ai eu à faire avec les deux à quelques semaines d'intervalle, et ils ont été tout aussi réactifs, pertinents et efficaces. Cela compte aussi beaucoup.

Tout l'accent est mis ici sur la multiplication des appareils avec lesquels nous accédons au Web, du smartphone à la Smart TV en passant par la fablet/tabphone et l'ordinateur traditionnel¹, cela étant indiqué comme un danger pour le Web actuel, qui n'aurait pas les outils nécessaires.

Par exemple, cet extrait m'a particulièrement fait tiquer :

plus d'un an avant sa sortie, Sony a annoncé que sa prochaine PlayStation 4 supportera une résolution de 4096 x 3072 !

Comme je l'ai déjà dit via Twitter, et puisque j'ai été invité à détailler mon point de vue :

Et alors ?!?!

Le viewport du navigateur intégré à cette PlayStation 4 sera sans doute bien inférieur aux dimensions natives supportées, et les supports mis en place pour les écrans Retina actuels suffiront dans 99.99% des cas. Détecter les pixels sur un écran Retina nécessite déjà une bonne vue, voir ceux d'écrans 4K relèvera du miracle ou de la bionique. Ces résolutions seront sans doute réservées aux écrans de grande taille que l'on regarde à bonne distance.

Il faut arrêter le FUD. Arrêter de se faire peur.

Les techniques actuelles sont certes perfectibles, mais le W3C y travaille — notamment au sein du Responsive Images Community Group — et il y a déjà largement de quoi faire aujourd'hui des sites qui se comporteront bien sur les écrans prévus pour se démocratiser dans 3 à 5 ans.

Pensons déjà de manière plus générale à faire de l'Adaptive Web Design, en ne se limitant pas au trop restrictif et technocrate Responsive Web Design.

Faisons déjà bien ça et on avancera ensuite là où cela deviendra nécessaire. Incroyable le nombre d'horreurs qu'on voit qui se targuent honteusement d'être en RWD…

Ce thème me tient particulièrement à cœur depuis pas mal de mois, au point que j'avais proposé d'en parler à Sud Web cette année. Ma proposition n'a pas été retenue², donc je trouverais un autre moyen de présenter ce que je fais murir tout doucement…

Mais sinon, oui, mille fois oui, il faut participer aux community groups du W3C, tout comme il faut participer à la documentation sur MDN, à l'évangélisation sur OpenWeb et à tant d'autres projets. Mais pour de bonnes raisons.

Non content de participer à 4 ou 5 associations de l'école, dont le BDE, j'avais trouvé le moyen de prendre en charge la radio interne, et d'animer une émission de pur délire avec mon comparse de l'époque Philou.

J'ai retrouvé deux des émissions que nous avions animées ensemble, justement parce que c'étaient les plus travaillées, ayant nécessité des heures de recherche¹ d'illustrations sonores à assembler pour raconter des histoires. Tout ce travail avait nécessité un ordinateur, et donc un format numérique stockable, alors que toute les autres n'étaient qu'en live, et malheureusement pas enregistrées.

Je vous laisse découvrir ces monuments de l'insouciance d'étudiants en école d'ingénieur — vous savez, ces écoles ou on trime comme des malades et ne voit jamais le jour, plongés dans nos cahiers et exercices —, merci d'avance pour votre indulgence² :

J'ai rapidement constaté que je suis loin d'être seul à avoir ce problème, de multiple discussions ayant été lancées sur le support Apple, dont une qui occupe déjà 17 pages de mécontents : « itunes chopping off end of songs now that i signed up for match ».

Mon entourage¹ est aussi touché, c'est donc bien relativement fréquent² :

@nhoizey ça m'arrive de manière un peu aléatoire, mais ça coupe au début même parfois

— Maurice Svay (@mauriz) Novembre 20, 2012

@nhoizey Je l'ai aussi depuis peu... Très pénible !

— Vincent Lemaire (@vlemaire) Novembre 20, 2012

En fouillant un peu³, on peut trouver un billet de Kirk McElhearn intitulé « What's Going On With Truncated iTunes Downloads ? » avec quelques explications, et surtout un lien vers un script iTunes développé par Doug Adams⁴ permettant d'identifier les morceaux tronqués : « Find Truncated Tracks ».

Je vous laisse lire ses explications sur le fonctionnement du script, mais il faut juste retenir qu'il va parcourir une de vos playlists et mettre les morceaux tronqués dans une nouvelle playlist nommée « _Truncated Tracks ».

Ensuite, la méthode recommandée sur le support Apple⁵ est de supprimer ces morceaux de votre iTunes — mais surtout pas de iTunes Match — puis de les télécharger à nouveau.

Pour supprimer un morceau depuis une playlist, il ne suffit pas de presser la touche Suppr qui va juste supprimer le morceau de la playlist. La page des raccourcis clavier iTunes proposée par Apple indique qu'il faut presser Option et Suppr en même temps.

J'espère que iTunes / iTunes Match sera corrigé pour détecter automatiquement ces morceaux tronqués et les télécharger intégralement…

The New Yorker

Édition du 6 novembre 2006

Tentative de traduction :

Montessori m'a appris la joie de la découverte. Cela a montré que vous pouvez être intéressé par des théories plutôt complexes comme celle de Pythagore, par exemple, en jouant avec des cubes. Il s'agit avant tout d'apprendre par vous-même, plutôt que laisser un enseignant vous expliquer des choses. SimCity vient directement de Montessori — si vous donnez aux gens ce modèle pour construire des villes, ils vont en déduire des principes d'urbanisation.

Cette citation est extraite d'un passionnant article de The New Yorker sur Will Wright.

A vous de jouer si ce projet vous intéresse aussi :

Déjà, le titre de son billet — « Ce week-end c'était Backup day » — ne me plait pas du tout, comme le titre de ce billet vous l'aura déjà fait deviner. Dire qu'il y a un jour particulier pour faire les sauvegardes, c'est risquer d'oublier de le faire. Et s'il est possible d'automatiser les sauvegardes pour ne pas les oublier, pourquoi ne pas les faire en permanence ?

Tout comme Éric, j'ai de plus en plus de données numériques auxquelles je tiens, et j'ai déjà eu une mauvaise expérience¹, donc j'ai pris en compte cette problématique assez vite au sérieux.

Le postulat de base de Éric, auquel je souscris complètement, est celui-ci :

Il vous faut deux backups, dont au moins un non synchrone ou avec historique, dont un hors site, avec quelque chose qui vous alerte dès que l'un des deux devient inutilisable. Hors cela, point de salut.

Or la sauvegarde hors site de Éric est constituée de supports optiques — CD, DVD, BluRay — alors que c'est un support très peu fiable. Même en y faisant attention — température, lumière, humidité, etc. — j'ai déjà perdu des backups faits sur CD, heureusement que j'avais des doubles.

L'objectif d'une sauvegarde, c'est bien entendu de retrouver ses données en cas de perte à la source, soit par plantage du support — physique ou logiciel — soit par le fait d'une mauvaise opération humaine².

Dans les deux cas, il faut bien entendu avoir une image des données perdues la plus récente possible, mais il faut aussi en avoir au moins une plus ancienne, au cas où la plus récente serait déjà altérée.

Si vous utilisez Dropbox pour synchroniser vos fichiers entre plusieurs appareils³, vous avez déjà un historique de 30 jours des modifications et suppressions de fichiers, ça peut aider. Si vous pensez avoir besoin de plus de 30 jours de délai, il y a bien le package Packrat qui retire la limitation, mais c'est surtout que vous avez besoin d'une vraie solution de sauvegarde historisée, car comme le rappelle Éric, « une synchronisation n'est pas une sauvegarde ».

Éric attend d'avoir une grosse bande passante montante pour se lancer dans la sauvegarde en ligne via Internet, disant ceci :

Sauvegarder 100 Go par une ligne ADSL, même de bonne qualité, ça va vite ne pas être raisonnable. Vous ne profiterez réellement de Crashplan ou de ses concurrents qu'avec la fibre.

Je conseille plutôt de s'y mettre tout de suite, cela étant devenu plutôt simple de nos jours, et les sauvegardes incrémentales étant transparentes, très rapides, une fois la sauvegarde initiale réalisée. Certes, le délai de réalisation de celle-ci dépendra évidemment du volume à sauvegarder et de votre bande passante montante, cela m'a pris plus d'un mois pour quelques centaines de Go, parce que j'ai une très mauvaise connexion ADSL. Mais il est très clair que je veux bien attendre quelques semaines pour cette initialisation si cela me permet une meilleure protection par la suite.

J'avais choisi Mozy il y a quelques années, mais leur politique tarifaire a complètement changé et est devenue bien moins intéressante pour les gros volumes, donc j'ai changé pour l'offre CrashPlan+ Family Unlimited pour sauvegarder tous les ordinateurs de la famille.

Pour la seconde sauvegarde, je n'ai pas pour l'instant de stratégie bien déterminée, chaque ordinateur ayant un usage différent. Mon MacBook Air est sauvegardé avec Time Machine sur le merveilleux disque dur externe LaCie Little Disk⁴, mais heureusement que Time Machine m'alerte de temps en temps parce que je ne pense pas à le brancher suffisamment souvent.

Mon Mac mini qui me sert essentiellement de media center est sauvegardé avec Time Machine sur une baie de 5 disques Drobo-S reliée en Firewire 800. L'usage de Time Machine sur le réseau étant impossible de base⁵, je vais plutôt faire des sauvegardes des autres machines sur cette même baie grâce au logiciel CrashPlan qui sait gérer plusieurs destinations de sauvegarde simultanément.

Je compte de plus ajouter à cette artillerie des clones d'au moins certains de mes ordinateurs, afin de pouvoir les réinitialiser très rapidement en cas de gros plantage⁶. J'ai acheté Carbon Copy Cloner pour cela⁷, c'est la référence depuis des années sur les Mac.

Homebrew annonce par exemple savoir fonctionner juste avec XCode 4.4, mais installer les Command Line Tools est en fait nécessaire, c'est en téléchargement sur Apple Developer.

Si vous voulez installer Subversion ou tout autre package dépendant de serf, il faudra faire un lien symbolique, le chemin de OSX10.8.xctoolchain ayant changé :

sudo ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain

Pour l'installation de l'éditeur joe — que je préfère à vi —, il faut corriger un défaut avec sed en forçant la locale :

export LANG=en_EN ; brew install joe

Je complèterais au fur et à mesure si je trouve d'autres bugs et leurs corrections…

Si quelqu'un sait ce qu'est devenu « Derf », je suis preneur !

Il existe différentes solutions d'élégance variable, à base d'extension Tab Mix Plus par exemple, mais le plus simple est tout simplement de changer une configuration de Firefox via about:config.

Il faut modifier la valeur du paramètre browser.tabs.tabClipWidth¹, qui défini la taille minimum à partir de laquelle le bouton apparaît.

Sachant que la taille minimum d'un onglet est de 100 pixels par défaut — c'est modifiable dans UserChrome.css ou avec l'extension Custom Tab Width —, il suffit de mettre une valeur de 99 à browser.tabs.tabClipWidth pour toujours avoir le bouton de fermeture.