Généralement il y a toujours un thread Post your screenshot and configs sur les différents forum des distributions *nix. La config était généralement collée à l'arrache en dessous. Pas pratique pour les retrouver plus tard. Certains utilisent Github, ce qui me semble déjà une bonne évolution mais encore à un niveau en dessous de Dotshare, qui lui est fait seulement pour ça.

Dotshare.it veut donc faciliter le partage et la recherche de fichiers dotfiles. Ils sont triés par applications, avec une capture du résultat. On peut aller chercher tous les fichiers d'un utilisateur en particulier sur sa page profil, suivre cette personne pour être alerté des updates etc.

Le look du site web est minimaliste et c'est une bonne chose. Ça ne devrait pas trop piquer les yeux des adeptes des CLI tools. L'information est bien présentée et l'essentiel est là. Il y a même des petites références au monde de la ligne de commande, comme scrot pour voir la capture du logiciel.

On a donc tout pour avoir un joli petit réseau social pour le partage des fichier de conf. Unix. Reste à voir si les gens vont suivre. Si vous avez des recommendations ou des demandes à faire aux devs vous pouvez toujours allez faire un tour sur #dotshare at freenode.

Via dotshare

Vitesse

La plus importante est le changement du format de la base de données locale. Quand vous synchronisez pacman avec les dépôts distants, il va stocker en local tout un tas d'informations dans divers fichiers. L'astuce a été de réduire considérablement le nombre de ces fichiers, et même dans certains cas de lire les informations directement dans un tarball compressé sans avoir à l'extraire. Beaucoup moins d'accès disques, donc plus rapide, à hauteur de 30% d'après les développeurs.

Ce changement de format nécessite une manipulation de votre part. Après avoir mis à jour pacman, il faut lancer en root :

Sécurité

Ensuite on pouvait facilement exploser son système si on ne faisait pas attention à l'espace disque restant quand on installait des paquets. Maintenant pacman peut automatiquement regarder si il y a assez de place pour ce qu'il veut faire. Personnellement j'ai désactivé cette option, car je sais très bien que je vais pas essayer d'installer la suite KDE  avec 300Mo. Pratique pour ceux qui ont l'esprit ailleurs j'imagine..

Pratique !

Pouvoir choisir les paquets à installer dans un groupe — au lieu d'être obligé d'installer tout le groupe — est revenu dans cette version.

Au final les développeurs d'Arch Linux ont encore fait du bon boulot en allégeant pas mal le moteur de pacman. Vous pouvez voir la liste complète des nouveautés dans le changelog, et aussi dans le readme.

Est-ce que je peux prendre un programme sous la licence _____, l'ajouter à mes propres fonctionnalités et ensuite _____ ?

Notes

1. La MPL ne couvre que les fichiers originaux, ou les nouveaux fichiers contenant du code de ceux-ci. Vos propres nouveaux fichiers sont les votres et les votres uniquement.
2. Ça marche si votre produit n'est PAS uniquement une modification de cette librairie. Mais si votre programme ne fait qu'utiliser cette librairie, c'est bon.

Astuce: Il est possible de modifier le code de n'importe quel programme sous les licences ci-dessus (même AGPL) et de les utiliser en interne dans votre organisation, sans avoir à distribuer le code.

À quelques exceptions près...

Il faut faire attention, car les règles d'utilisation sont parfois spéciales. Prenons exemple de la licence GPL. Cette licence donne une grande importance à l'endroit où s'exécute votre code. Pour un service en SaaS, des parties de votre code (javascript) sont en fait distribué à vos utilisateurs. Donc si vous avez une librairie JS en GPL pour votre SaaS, vous devez fournir le code de toute votre application.

Toutes les licences ne sont pas compatibles avec la GPL & AGPL.

La nature des interactions est importante : vous pouvez communiquer avec un programme en GPL au travers d'API par exemple. Mais à partir du moment où vous faites appel au code directement, vous devez libérez le votre.

Différences entre GPL v2 & GPL v3

À la base la version 3 devait contenir une close contre les SaaS, mais on a crée l'AGPL pour ça. Du coup les différences ne sont pas trop importantes sauf si :

• Vous possédez une marque commerciale
• Vous avez des protections de droits d'auteurs (DMCA)

Avantages de rendre son code libre

Donner le code que vous avez développé à la communauté, peut parfois être une bonne chose financièrement. Si vous ne profitez pas directement de votre code source, ça ne sert à rien de la garder pour vous.

Il y a encore — malheureusement — des idées reçues sur le logiciel libre. Ça ne veut pas dire logiciel gratuit. Ça ne veut pas dire non plus un logiciel codé par 3 gus dans un garage. Des grosses structures commerciales comme Google, Red Hat, Intel, Facebook fournissent du code libre.

Nokia avec Qt est pour moi un bon exemple. Qt étant libre, Nokia se fait aider par la communauté libre. Que ça soit en testant, rapportant des bugs ou même en proposant des patchs. À côté de ça ils ont un business model, une licence commerciale, pour les utilisateurs ne jouant pas le jeu du libre.

Des logiciels de type SaaS ont pour moi intérêt à être libre, dans le sens où l'on vend le service, pas le code.

Donc oui le web designer doit connaître ce que permet le CSS3 à un instant T. Oui le web designer doit savoir intégrer son .PSD, mais c'est un autre débat qui fera office d'article. Bref, je ferme cette grosse parenthèse et vais vous présenter un petit truc sympa.

Ammon Casey a développé un plugin jQuery plutôt cool, qui va vous permettre de changer vos champs de formulaire, de type radio, comme sur l'image. Ce plugin utilise essentiellement du CSS3 pour modifier le rendu, et un peu de javascript pour gérer les clics.

Le code source est disponible, et c'est une bonne lecture pour apprendre à faire des effets comme les dégradés, les ombres internes etc. L'auteur pense mettre en place bientôt un mode dégradé avec des images pour les anciens navigateurs. C'est son choix, pour ma part les anciens navigateurs peuvent allez se faire voire, et leurs utilisateurs aussi. Just kidding.

Maintenant place à la démo — hébergé chez votre serviteur — et un lien vers les sources. Pensez à souscrire au github, pour être tenu au courant des commits.

Démo - Source

Bon ok, vous n'arriverez sûrement pas à chopper avec ça. Mais je n'avais pas vraiment d'idées pour ce titre. Et de toute façon maintenant que vous êtes sur la page ça n'a plus aucune importance.

Le fait est que Vim est sans doute le meilleur éditeur de la planète entière — je vois déjà les fans d'Emacs froncer les sourcils — en termes de puissance et de personnalisation. Et quand nous, pauvres développeurs que nous sommes, passons la journée sur du code, il est quand même pratique d'avoir un thème plaisant.

Mustang

Vitamins

Desert

Vylight

Molokai

Tout ce que vous avez à faire est de placer le thème dans ~/.vim/colors et de l'activer dans le .vimrc avec la ligne :

Et vous ? Quels thèmes utilisez-vous en ce moment ?

Ubuntu font

Pour cela on va d'abord commencer par récupérer les fonts sur le site officiel. Pour l'instant il n'y a que 4 familles disponibles (Regular, Bold, Regular Italic & Bold Italic). D'après ce que je vois sur le site, il semblerai que d'autres familles puissent voir le jour (Light, Medium, Condensed, Monospace...).

Il y a une archive sur le site qui contient ses .tff. Elle est régulièrement mise à jour, à l'heure où j'écris ces lignes on en est à la version 0.68.

Générateur de font-face

@font-face est une propriété CSS qui permet d'inclure n'importe quelle font dans votre document web. L'inconvénient c'est qu'il n'y a pas (encore ?) de format officiel, et donc les navigateurs font un peu ce qu'ils veulent à ce niveau là. C'est là où notre outil rentre en jeu : il va automatiquement, à partir de nos .tff, générer tous les formats pour tous les navigateurs supportant @font-face.

Concrètement il suffit d'aller sur cette page (fontsquirrel), et d'uploader nos 4 ttfs. Prenez le mode expert et laissez tout par défaut, sauf la fonction Style Linking qu'il faut cocher. Car nous avons 4 styles de .ttfs et c'est plus simple de les lier en une seule famille et ensuite de jouer sur font-weight & font-style.

Le site vous génère donc une archive avec les fichiers fonts nécéssaires et une page html avec un CSS modèle.

Démo

Lien vers la démo.

Conclusion

Je pense que la font principale de mon blog va devenir celle-ci quand elle aura d'autres familles dont j'ai besoin (light, condensed & monospace). Pour l'instant je reste avec Proxima Nova Condensed ;)

J'avais parlé de la sortie de Gaia10 il y a quelques temps sur un autre billet de blog. Aujourd'hui je vais vous montrer quelques thèmes sous Linux dans l'optique de Gaia10. Parce que de toute manière les plus beaux thèmes ne se trouvent pas sous Windows & Mac.

Gaia10 Linux by ~gabriela2400

GAIA10 PekWM by ~Izobalax

Gaia2010 by ~fkant

La vitesse de chargement d'une page web est critique en terme d'expérience utilisateur.

Regardons les choses en face : si une page met trop de temps à s'ouvrir, je ne vais pas rester. Le contenu, aussi intéressant soit-il, ne sera pas lu. Sous prétexte que le haut débit est maintenant répandu, les gens oublient de faire au plus léger. Les images non-spritées, le CSS redondant et les vingtaines de requêtes http par pages sont devenus légion. Et on semble se satisfaire de quelques secondes pour ouvrir une page.

Une seconde c'est déjà trop !

Bing et Google sont d'accord pour dire que les pages lentes perdent des utilisateurs. Personnellement je n'attends pas plus de 3 secondes à l'ouverture d'un site web. Je ferme l'onglet. C'est dans cette optique que je me suis mis en tête d'optimiser mon installation WordPress et gagner de précieuses secondes.

Firefox

Je me fais pas de soucis pour vous. Vous devez tous l'avoir. J'espère.. On en a besoin pour Firebug. Au pire on le trouve sur cette page.

Firebug

L'extension reine pour les développeurs web. Vous devriez déjà l'avoir, sinon vous pouvez la récupérer sur cette page. On en a besoin pour YSlow.

YSlow

Un plugin Firebug fait par Yahoo. Il analyse la page web et donne une note suivant plusieurs critères. Dans le but d'avoir une page web rapide. Lien.

Webkit Web Inspector

Disponible à l'intérieur de Chrome, Safari & d'autres navigateurs webkit. Il donne des infos intéressantes, notamment avec son onglet des ressources. Pratique pour voir la taille des différents fichiers, et le temps mis pour les télécharger.

Page Speed

Encore un plugin pour Firebug. Il propose à peu près la même chose que YSlow. Lien.

Webmaster Tools

Un must-have. Google enregistre aussi la vitesse d'ouverture de notre site au cours du temps. Pratique. Lien.

Le code !

La première étape est d'avoir un CSS optimisé au niveau du code. Je vois parfois des devs qui mettent tout le chemin du DOM dans leurs règles CSS. Il faut aller au plus simple :

#footer nav ul li a  /*pas bien */
#footer a { ... } /* bieeeen */

Autrement dit, essayez de voir si vous ne pouvez pas réduire la taille du fichier simplement en écrivant moins de code.

Compression

On peut réduire énormément la taille des fichiers CSS en les minifiant. Les retours à la ligne inutiles, les commentaires et les espaces en trop seront supprimés. À faire uniquement quand on ne touche plus au fichier, car ça devient complètement illisible. Le problème c'est que pas mal de plugins WordPress viennent avec leurs propres CSS pas forcément compressés. Vous pouvez le faire vous même en les remplaçant. Mais à chaque mise à jour du plugin.. on recommence. À vous de voir !

Minify CSS

Placement

Souvent les appels aux fichiers .js se trouvent dans la balise <head> de la page. Le problème avec ça, c'est que pour voir le contenu de la page, ces fichiers doivent d'abord être chargés. Autant que possible je place mes fichiers javascript juste avant la fin de la balise <body>. De cette manière le contenu de la page peut déjà s'afficher et les fichiers javascripts se charger en arrière-plan. J'essaye aussi de charger tout mes scripts de manière asynchrone.

Compression

Sur le même principe que les fichiers css, la compression marche aussi pour le javascript.

Minify CSS

Sprites

15 images = 15 requêtes http. 1 sprite = 1 requête http. Faire un sprite c'est juste mettre toutes vos images dans une seule. Pratique volée aux créateurs de jeux-vidéo ;)

SpriteMe

La taille des images

Vous voulez afficher une image en 150x150, et bien enregistrez la en tant que telle. Google conseille aussi de rajouter dans la balise <img> la taille de l'image en dur, pour accélérer le rendu. Enfin jouez sur la compression de l'image pour gagner de précieux ko.

Il peut aussi nous aider dans notre tâche.

• En compressant en Gzip les données envoyées.
• En mettant des headers spéciaux aux fichiers, pour que les utilisateurs les gardent en cache.

Si vous êtes sous Apache il suffit de rajouter les lignes suivantes dans votre .htaccess (après les règles WordPress). Vous devez avoir certains modules activés (mod_expires, mod_headers, mod_gzip).

La même chose est possible sous Nginx & Lighttpd. Si ça vous interesse je peux en parler dans un autre article.

Plugins à désactiver

Désactivez ce que vous n'utilisez pas. Ça doit être un réflexe. Car chaque plugin vient avec son lot de js/css/php qui se charge à chaque page ou presque.

Système de cache

C'est l'élément le plus important de notre installation. Celui qui va nous faire gagner pas mal de temps et pas mal de ressources serveur. Par défaut, pour chaque page, le blog fait des requêtes SQL pour chercher les infos à afficher. Le truc c'est que le contenu d'un billet change rarement après la soumission. Mettre ces infos en cache permet de sauter l'étape BDD et d'afficher la page comme si c'était une page web html.

J'utilise personnellement W3 Total Cache. Il propose plein de trucs sympathiques : il peut par exemple prendre en compte l'envoi des données en Gzip si vous avez la flemme de le faire à la main dans le .htaccess.

WP Minify

Je vous ai raconté dans la première partie comment réduire la taille des fichiers js et css. Et bien ce plugin le fait pour vous en fait. Et le truc génial c'est qu'il les combine en un seul fichier pour réduire le nombre de requêtes http. Il se trouve ici.

On va dire que tout ça ce sont les grandes lignes. Il y a toujours moyen de faire mieux. Mais disons que c'est la petite todo-list que je vais essayer de mettre en place (j'ai déjà commencé). Il est possible que techniquement vous ne puissiez pas tout faire.. l'important est d'essayer de faire au mieux. Même si vous n'avez pas l'impression de gagner énormément à chaque étape.. le tout cumulé lui sera visible.

En lançant YSlow entre chaque optimisation, on peut vite se rendre compte de ce qu'il reste à faire.

Pour un meilleur web ;)

Hé bien il semblerait que la version finale du wallpaper pour Ubuntu 10.10 soit sortie. Bon on reste dans les nouvelles couleurs, c'est à dire les tons violets. Personnellement je ne suis pas trop fan.. mais les goûts et les couleurs comme on dit.

Donc voilà la bête. Je pense qu'il ne faut pas se plaindre non plus. Parce que quand on regarde le fond d'écran de la beta.. on se dit que ça aurait pu être pire.

Et là tout de suite ça pique les yeux. Déjà à la base le violet c'est pas top comme couleur pour un design (c'est mon avis personnel), mais les boules oranges fluos.. Alors ok, c'est sympa on utilise les couleurs de la distro, mais il y a des couleurs qui ne vont pas ensembles.

Enfin tout ça pour dire qu'ils ont un peu rattrapé le coup avec la dernière version.

Ça me fait penser à une hérésie (oui je sais le mot est fort) que j'ai vu sur le bug tracking d'Ubuntu. Figurez-vous que les wallpapers auraient été faits sur Mac OS X et Photoshop CS3 : lien. Je vous confie que ça ne me choque pas des masses, mais il faut croire que certains ubunteros ont du mal à avaler la pilule. Au point de le remonter comme bug :)

Et puis si le fond d'écran ne vous plaît pas, il y a ceux de mon blog !