Désormais le simple fait de “ liker ” une page, pourra poster sur votre profil tout un tas d'informations. Le titre de la page, une description et pourquoi pas une image. En fait c'est exactement le même modèle de ce que faisait le vieux bouton bleu moche Facebook Share.

Le bouton like fonctionne avec le protocole Open Graph. Concrètement ce protocole permet à Facebook de s'insérer dans n'importe quel site web. Dans ce protocole, Facebook a définit certaines balises Meta qui vont contenir la carte d'identité de la page web. Le titre, l'URL, la description, la catégorie etc.

Vous pouvez trouver une liste exhaustive de ces attributs sur la documentation de Facebook.

Ces éléments sont nécessaires pour profiter à 100% du widget Facebook. Le bouton en lui-même s'insère facilement.

L'attribut href, vous l'avez compris, pointe vers la page à partager. C'est sur cette même page que les balises Open Graph devront être. Maintenant prenant l'exemple d'un blog, sous WordPress. Chacun de vos articles aura dans le header les balises Meta qui le décriront en gros, et un bouton like présent à la fin du billet pour le partager. Ce qui peut être sympa, c'est de récupérer une image de l'article en question pour l'afficher lors du partage.

Pour cela il faut modifier un peu le thème du blog. On ouvre functions.php, et on ajoute cette fonction :

Avec cette fonction, on va maintenant éditer le fichier header.php du thème pour modifier les balises meta.

Et voilà ça devrait suffire !

Maintenant on peut se poser la question de la pertinence de la chose. On avait à la base l'action de partager et l'action d'aimer. Désormais le simple fait d'aimer un truc, nous le fait partager. Admettons. Mais si je veux partager sans aimer ? :)

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 ;)

Dans ce billet nous allons voir un peu de CSS 3 afin de réaliser des boutons qui auront le style des applications Mac (Cocoa).

Pour arriver au résultat, il nous faut principalement 3 fonctions CSS 3 :

• border-radius qui va s'occuper d'arrondir les angles
• box-shadow pour les ombres
• linear-gradient pour les dégradés

Fonctionne sur les derniers Firefox, Safari, et Chrome (et tout ce qui est à base de Webkit ou Gecko). Malheureusement Opera ne supporte pas encore les dégradés. Je ne parlerai même pas de cette daube d'Internet Explorer.

Démo + Source

Introduction

Nous allons installer et configurer Dwm en utilisant makepkg et l'Arch Build System. Ce qui va nous permettre de créer proprement des paquets, et éviter de "salir" le système avec un make install. Pour ceux qui n'utilise pas Arch Linux, il y a toujours moyen de faire la même chose avec d'autres outils. Pour tester rapidement dwm :

sudo pacman -S dwm

Gardez à l'esprit que si vous l'installez comme ça, vous passez à côté de toute la partie customisation.

Préparation

Nous allons avoir besoin du paquet base-devel pour la compilation et abs pour récupérer l'arbre des PKGBUILDs.

sudo pacman -S base-devel abs

Récupérons maintenant les PKGBUILDs de tous les programmes installables avec pacman. On va donc pouvoir ensuite récupérer celui de Dwm pour pouvoir le compiler à notre sauce.

sudo abs
cp -r /var/abs/community/dwm ~/dwm

Rentrons maintenant avec un cd, dans le dossier dwm fraichement copié dans notre home et lançons la compilation.

makepkg -i

Ceci va récupérer les sources, compiler et installer Dwm.

Configuration

Allez faire un petit tour dans le dossier dwm copié dans votre home. Vous y trouverez un fichier config.h. C'est dans ce fichier que l'ont va pouvoir configurer Dwm. Une fois ce fichier à jour, il faut recompiler Dwm :

makepkg -efi --skipinteg

Conclusion

Voilà ce qu'il faut faire pour mettre à jour et configurer Dwm. Je vous laisse faire un tour sur le site officiel pour avoir des infos supplémentaires sur la configuration, avec des exemples et des plugins.

Sur mon prochain billet je vous montrerai ma configuration avec des exemples précis d'utilisation de dzen2, conky etc.

Stay tuned.

Fichiers de configuration par défaut

• /etc/ssh/sshd_config - Fichier de configuration du serveur SSH.
• /etc/ssh/ssh_config - Fichier de configuration du client SSH
• ~/.ssh/ - Répertoire de configuration SSH d'un utilisateur.
• /etc/nologin - Si ce fichier existe, personne ne peut se connecter à part root.
• /etc/hosts.allow et /etc/hosts.deny : Blacklist et whitelist .
• SSH port par défaut : TCP 22

Utiliser le protocole SSH 2

Le protocole 1 est obsolète et vulnérable à de nombreuses attaques (comme man-in-the-middle). Il doit être évité à tout pris. Vérifiez dans le sshd_config que la ligne suivante existe :

Protocol 2

Choisir les utilisateurs

Par défaut n'importe quel utilisateur à le droit de se connecter en SSH. Par exemple un utilisateur ftp à la possibilité de se connecter. Ce n'est pas super pertinent. Alors on peut restreindre le serveur SSH à n'autoriser que certains compte utilisateur. Pour ça on peut utiliser (toujours dans le sshd_config)  :

AllowUsers root rydgel

Qui autorise ces 2 utilisateurs à pouvoir se connecter. Inversement la commande DenyUsers, permet de refuser la connexion.

Désactiver les fichiers .rhosts

Ces fichiers permettent de se connecter automatiquement au serveur sans avoir besoin de retaper le mot de passe. Sympa pour les feignants mais pas sécurisé du tout. Donc il vaut mieux désactiver l'utilisation de ces fichiers avant que quelqu'un ne tombe dessus ;)

IgnoreRhosts yes

Ajouter un timeout sur l'inactivité

Garder la session ouverte indéfiniment n'est pas non plus une bonne idée. Vous êtes au boulot, vous vous absentez une heure ou deux et vous oubliez de fermer votre session, n'importe qui peut attraper votre shell en root et faire ce qu'il veut pendant votre absence.

ClientAliveInterval 360
ClientAliveCountMax 0

Désactiver le login de root

Une autre manière de sécuriser est de désactiver le login de root et d'utiliser un user avec des droits moindres + sudo.

PermitRootLogin no

Changer le port par défaut d'openSSH

Le port 22 est connu par tous les pirates pour être celui d'openSSH. Les robots scannent en priorité ce port, pour le changer c'est tout simple :

Port 6345

N'autoriser que certaines IP à se connecter

Par exemple si je veux que seulement ces 2 adresses IP ait le droit de se connecter sur mon serveur (192.168.1.5 et 202.54.1.5). Il y a deux solutions. La première est d'utiliser les fichiers /etc/hosts.allow et /etc/hosts.deny. On commence par bloquer toutes les IPs dans le hosts.deny, puis on autorise seulement celles que l'on veut.

dans /etc/hosts.deny :
sshd: ALL
On bloque par défaut toutes les IPs, puis dans le /etc/hosts.allow :
sshd: 192.168.1.5
sshd: 202.54.1.5

La deuxième solution (et la meilleure à mon avis) est d'utiliser le firewall du système (iptables, pf) et d'autoriser seulement les IPs que l'on veut sur le port d'OpenSSH.

Utiliser un bon mot de passe

On voit encore trop souvent des mots de passe du style '12345' ou 'admin'. Le plus simple est de se créer un mot passe aléatoirement avec des chiffres, des lettres (majuscules et minuscules) et des caractères spéciaux. http://www.goodpassword.com/ est un site qui permet de le faire pour vous :)

Personne ne doit avoir un mot de passe vide

Vérifiez que les utilisateurs de votre machine n'ont pas de mot de passe vide. On peut aussi dire à OpenSSH de ne pas accepter les connexions d'utilisateurs sans mot de passe.

PermitEmptyPasswords no

Garder OpenSSH et votre système à jour

On ne le dira jamais assez mais les mises-à-jour sont vraiment importantes. Elles corrigent la plupart du temps des failles qui peuvent être utilisées par des pirates pour compromettre votre système. Personnellement je regarde si des mises à jours de sécurité sont disponibles tous les jours.

Désactiver OpenSSH si vous ne l'utilisez pas

Ça ne sert à rien de laisser des services ouverts sur l'ordinateur si vous ne vous en servez pas. Désinstallez le serveur openSSH s'il n'est pas utilisé. Ça fera toujours une porte de moins pour accéder à votre machine.

Conclusion

Il y a encore des dizaines de manips possibles pour augmenter encore plus la sécurité, comme le chrootage des utilisateurs, la configuration d'un firewall, l'installation de fail2ban contre les attaques brute-force etc. Mais je pense que ce petit article est un bon début, pour éviter de faire des bêtises sur son serveur.

Ces fichiers sont au format HFS+, il nous faut donc les outils nécessaires pour manipuler ce format. Le nom des paquets changeant suivant les distributions, faites une recherche sur le mot hfsplus dans votre gestionnaire de paquet.

Dans une console en mode root, il suffit de taper :

mount -o loop -t hfsplus image.dmg /dans/votre/repertoire

Soyez sur que le répertoire de destination existe avant de faire la manip.

De la même manière on peut ouvrir des partitions OS X. Utile pour ceux qui ont installé Linux sur leur Mac comme moi :)

Alors.. oui il existe déjà des implémentations de Wine sur Mac. Comme par exemple CrossOver, mais celui est payant et non libre. Je m'ennuyais un peu et je m'étais dit que ça serait marrant de compiler Wine sous OS X (ouais on s'éclate comme on peut). Du coup je vais vous partager la façon de faire.

Pré-requis

Cette manipulation ne peut pas fonctionner sur toutes les configurations.

Intel

Il vous faut un Mac avec un processeur Intel. Les derniers Mac le sont tous. Pour vérifier il suffit d'aller dans le menu pomme et de choisir "À propos de ce Mac" pour vérifier votre processeur.

Xcode

On aura besoin des outils de compilation traditionnels (make, gcc etc.). Pour les avoir il suffit d'installer Xcode. Vous le trouverez sur cette page.

Macports

Les macports simplifieront l'installation de Wine et de ses dépendances. Pour son installation et son utilisation, je montre quelques exemples sur un précédent billet.

Installation

Avec les Macports c'est tout facile :)

sudo port install wine-devel +universal

Le flag +universal permet de compiler Wine et ses dépendances en 32 bits (car Wine ne fonctionne pas en 64 bits). Si on ne rajoute pas ce flag, le compilateur sous Snow Leopard essaiera de compiler Wine en 64 bits (ce qui ne peut pas fonctionner).

Et voilàààà

Voici le fichier urxvt.ds utilisé pour ma console (urxvt-unicode) :

(if
 
(matches (window_class) "URxvt")
  (begin
    (undecorate)
  )
)

Devilspie c'est magique, on peut faire plein de trucs, comme jouer avec la transparence.

Alors concrètement ça marche comment ? En fait on va créer un utilisateur du nom de gmail, et on va lui construire un environnement de bureau pour lui. On va en prendre un très léger comme ratpoison. Quant au navigateur, uzbl sera parfait pour ce que nous voulons faire.

La première étape va consister à installer ratpoison et uzbl. Je vous laisse vous débrouiller avec vos distributions respectives. Pour les archers c'est simple (comme toujours) :

sudo pacman -S ratpoison
yaourt -S uzbl-git

Ensuite nous allons créer notre utilisateur et tout ce qu'il faut pour qu'il est sa propre session :

sudo useradd -p password gmail
cd /home/gmail
echo "exec ratpoison" > .xinitrc
echo "exec uzbl google.com/mail" > .ratpoisonrc
mkdir -p .config/uzbl
echo "set always_insert_mode = 1" > .config/uzbl/config

Le .xinitrc est le fichier de script appelé par Xorg lors de son démarrage (startx), on lui dit de lancer le WM ratpoison. On configure ratpoison pour qu'il lance uzbl avec la page d'accueil de gmail. Ensuite on dit à uzbl de rester constamment en mode insert.

Il suffit donc de se logguer avec le compte gmail/password pour avoir une session gmail !

Bien sur ici gmail n'est qu'un exemple, et ça peut marcher avec plein de choses :)

Creusez vous un peu la tête :p

Via matthewbauer

Donc vous devriez avoir à ce moment précis une installation minimale d'Arch Linux fonctionnelle. Avec le choix entre OS X et Arch Linux au démarrage du Macbook Pro.

Modèle du clavier sous tty

Il n'y a pas de modèle pour mac par défaut sous Arch Linux. Pour y remédier, téléchargez ce petit fichier et placez le dans /usr/share/kbd/keymaps/mac/all . Ensuite dans le rc.conf :

KEYMAP="mac-fr-ext_new"
CONSOLEFONT="lat9w-16"

Installation du son

Le son ne fonctionnait pas du tout chez moi après l'installation normal d'alsa. En cherchant sur internet je suis tombé sur un forum d'Ubuntu qui indique qu'il faut utiliser les derniers drivers d'alsa unstable.

wget ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
tar xf alsa-driver-unstable-snapshot.tar.gz
cd alsa-driver-unstable
sudo ./configure --enable-dynamic-minors  --without-oss --with-cards="hda-intel"
sudo make
sudo make install

Et pour les beaux gosses qui ont Arch Linux un beau PKGBUILD :

pkgname=alsa-snapshot
pkgver=1
pkgrel=1
pkgdesc="Alsa snapshot (rentre en conflit avec alsa du kernel)"
arch=(x86_64)
url="http://ubuntuforums.org/showpost.php?p=7627817&postcount=98"
license=('GPL')
groups=()
depends=()
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
source=(ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz)
md5sums=('504b779d3dd9a2ec96b043ed83210d59')
 
build() {
  cd "$srcdir/alsa-driver-unstable"
 
  ./configure --prefix=/usr --enable-dynamic-minors --without-oss --with-cards="hda-intel"
  make || return 1
  make DESTDIR="$pkgdir/" install
}

Après l'installation, lancez un petit alsaconf pour initialiser votre carte son. Et ça devrait être bon. Néanmoins à l'heure actuelle le driver ne supporte pas totalement la carte. Je n'ai du son que d'un côté. Il est aussi possible que cette opération doit être recommencée à chaque mise à jour du kernel.

Pommed

Ce démon s'occupe par exemple du rétro-éclairage de votre clavier et de la luminosité de l'écran. Le nom du paquet est pommed, rajoutez le démon dans le rc.conf.

Wifi

La carte est une Broadcom et elle utilise le driver broadcom-wl disponible dans AUR. Installez le et ensuite dans le rc.conf :

MODULES=(lib80211_crypt_tkip wl !b43 !ssb)

iSight

La carte fonctionne après l'installation du firmware, via AUR :

yaourt -S isight-firmware-tools

Je n'ai pas rencontré d'autres problèmes pendant l'installation, le plus gros problème ayant été le son. Dans une troisième partie nous verrons la configuration du Mac dans un environnement de bureau, la gestion du clavier dans X, du touchpad et des touches multimédia :)