Ma configuration de i3wm

Cette semaine, j'ai décidé de tester une nouvelle interface graphique pour ma Debian. J'utilisais Gnome 3 depuis quelques temps, mais je cherchais quelque chose de plus orienté développement. Contrairement à Awesome qui ne m'avais pas paru très pratique, i3wm a su me convaincre très rapidement.

i3wm est une interface graphique pilotable au clavier et un peu inspirée du fonctionnement de Vim avec la possibilité de "splitter" l'écran verticalement ou horizontalement.

Ma configuration est proche de la configuration initiale avec la touche "Windows" comme touche Mod. J'ai principalement ajouté : le Alt+F4 pour quitter les fenêtres, quelques informations dans la barre de statut. La prise en charge des touches screenshot, volume (monter, descendre, muet) et la luminosité de l'écran (cette dernière n'est pas forcément compatible avec votre ordinateur). Pour la gestion du réseau j'utilise WICD.

Sources : http://forum.manjaro.org/index.php?topic=2080.0 (exemples de config) et http://i3wm.org/docs/userguide.html (doc officielle très bien faite).

Mes astuces et configuration GNU/Linux : http://amoweb.fr/static14/gnu-linux

Aide-mémoire des principaux raccourcis

Chez moi Mod = touche "Windows". D'origine, il s'agit de la touche Alt. Notez que je n'ai pas encore eu besoin d'utiliser d'autres raccourcis que ceux décrit ci-dessous.

  • Mod + left/right/up/down : se déplacer entre les fenêtres
  • Mod+ Shift + left/right/up/down : déplacer la fenêtre
  • Mod+f : fullscreen
  • Mod+d : barre de lancement d'une nouvelle application
  • Mod+enter : lancer un terminal
  • Mod+v/h : split horizontal ou vertical (définit où la prochaine fenêtre sera lancé)
  • Mod+&/é/"/'/5/-... (touches "chiffres" en minuscule) : changement d'espace de travail
  • Mod+Shift+&/é/"/'/5/-... (touches "chiffres" en minuscule) : déplacement de la fenêtre dans un autre espace de travail
  • Mod+Shift+A : Fermer la fenêtre (j'ai configuré Alt+F4 avec le même effet)
  • Mod+Shift+E : Quitter i3wm

Fichier .i3/config

Lire la suite de Ma configuration de i3wm

Ciné-concert : Koko le Clown (Out of the Inkwell, 1919)

Spectacle/Projet de Koko le Clown.

Projection d'épisodes de la série "Out of the Inkwell" de Max Fleischer, années 1920. La bande son est jouée en direct : contrebasse, saxophone, MAO. Le film est une interaction permanente entre le dessinateur et son dessin (mélange de "réel", et de dessin).

Ma critique : Vraiment bien. Les courts métrages drôles. La bande son jouée en directe, cela ajoute du relief au film grâce au jeu et aux effets de la contrebasse. Dommage que les musiciens ne soient pas plus mis en valeur (position sur la scène...).

Dossier de presse (pdf)
Article du monde

Raspberry Pi : une chaine hifi radio Internet

Mini-projet d'une demi journée (ou plutôt 2h) : permettre d'écouter des radios Internet depuis le Raspberry Pi sans écran. J'ai utilisé une souris comme IHM. Le principe est simple : le programme lance cvlc avec un flux, l'appui sur un bouton de la souris change le flux. Le nom de la radio est annoncé avant la lecture.

#!/bin/bash
next()
{
        /home/pi/RadioPi/mouse
        while killall vlc; do
                echo "kill";
        done
}
while true; do
        echo "Jazz radio" | espeak
        sudo -u pi cvlc http://radio/flux.mp3&
        next
        echo "BBC Radio 1" | espeak
        sudo -u pi cvlc http://radio/flux.asx&
        next
done

La fonctionnement n'est pas très propre car cvlc ne nous offre pas de possibilité de le fermer autrement que par un kill. Le programme mouse rend la main dès qu'un bouton de la souris est appuyé.

Le programme est appelé dans rc.local par :

sudo -u pi /home/pi/RadioPi/radios.sh&

On note le sudo -u pi qui permet de lancer le script par l'utilisateur pi, car VLC ne peut pas être exécuté par le root.

Code source de mouse :

Lire la suite de Raspberry Pi : une chaine hifi radio Internet

Hipster PDA : bilan après 4 mois d'utilisation

J'ai écris, au moins d'août, un article sur ma méthode de gestion du temps : hPDA, TODO-list, ce que certain appellent de la "procrastination". Si vous n'avez pas lu l'article, lisez-le avant celui-ci.

Le bilan est assez simple : je n'ai pas trouvé grand chose de mieux, et mon argumentaire n'a pas réellement changé. Cependant, j'ai déjà appliqué quelques modifications. Bilan.

Tâches du lendemain (plugin)

J'ai ajouté un petit "plugin" : un quart de feuille A6 mis à jour tous les jours permettant de sélectionner les tâches à faire le lendemain. L'idée est de libérer les listes de TODO (Perso et Travail) de toutes les tâches courtes qui l'encombrent et m'obligent à recopier régulièrement les listes (assez long...).

Cette méthode est aussi plus efficace, car je parcours les listes de TODO chaque soir, et je peux créer une liste très courte pour le lendemain et écrire les rendez-vous de la journée dessus.

Noter les dates proches

L'autre légère modification est de réserver le tiers supérieur de chaque liste de TODO pour écrire les rendez-vous : j'utilise pour cela un point en début de ligne.

Calendrier annuel en deux feuilles

Vraiment pratique ! Dépasse largement le calendrier d'un smartphone.

Les feuilles pour le mois courant et le mois prochain

Utile lorsque l'on a beaucoup de dates à noter. Je les utilise très peu en ce moment.

Mes conseils de programmation

Je vais essayer de décrire dans ce documents quelques principes de base que j'applique en programmant. Pour trouver l'essentiel, il m'a fallu prendre du recul sur mes habitudes.

Le nom doit permettre de comprendre ce que fais la fonction ou la variable

Pour les fonctions, l'habitude et de mettre un verbe d'action dans le nom. Pour les plus courants on trouve :
récupère (get) : elle renvoie quelque chose (il n'y a aucune raison que dans son code elle modifie une quelconque variable !! sinon, lui trouver un autre nom)
modifie/ajoute/supprime (set/add/del) : modifie une valeur/une liste ou un tableau
On peut l'étendre à n'importe quel verbe d'action : tri, analyse, nettoie...

Si la fonction est dans un package, il peut parfois être pratique (en C, par exemple), de donner le nom du package aux fonctions. Par exemple : donnéesInit, donnéesReset, donnéesAjout...

Important : si on modifie le contenue d'une fonction, il faut penser aussi à mettre à jours son nom si son but change, ou au moins sa documentation.

Pour les tableau, utiliser le terme "tab" dans le nom est souvent assez pratique.

Documenter ses fonctions (toutes)

Description de la fonction
Paramètres : liste des paramètres avec l'utilité. Indiqué s'il sont modifiés.
Retour : ce qui est retourné.

Sur les fonctions ou procédures complexes, on peut ajouter les champs suivants : Requis : ce qui doit être fait avant l'appel. Par exemple : appel à "init" requis.
Garantie : ce que l'on assure après (par exemple, "le tableau T est trié ou vide")

Dans le cas où le champ requis a été utilisé, il est peut-être intéressant de placer une assertion en début de fonction, pour assurer que cela a été fait.

Être capable de dessiner sa structure de données

Prendre une feuille de papier et dessiner ses tableaux, ses listes chainées... Ce conseil est sans doute le plus "scolaire" que je puisse donner, mais il vous propulse instantanément au rang de serial coder, surtout dans les langages comme le C où les pointeurs rendent le code peu lisibles.

Apprendre à dessiner une structure de donnée
Il n'y a plus qu'à faire la correspondance. En C, le tableau deviendra [], les pointeurs, dessinés par des flèches, deviendront des étoiles...

Classer ses fonctions par package (même en C, avec les .h)

Permet de leur donner une logique globale. Cela facilite aussi la factorisation du code. Être capable de classer ses fonctions traduit le fait que l'on comprend l'architecture de son programme. Dans le meilleur des cas, il faut décrire quel seront les packages avant même de commencer à coder. Il est intéressant aussi de décrire les interactions entres les différents packages.
Nb. Pour la programmation objet (Java, C++), c'est encore plus vrai.

Éviter les effets de bords (modification de variables)

Il faut éviter de modifier des variables du programme depuis une fonction (mais c'est parfois indispensable ou juste plus lisible). Dans ce cas, on doit comprendre ce qui est modifié juste en lisant la documentation de la fonction et son nom.
Exemple (trivial), en lisant la documentation de la fonction int get_numéro(), on ne s'attends pas à ce qu'elle modifie une variable. On s’attend juste à ce qu'elle renvoie le numéro.

Pour les procédures c'est moins vrai : "l'effet de bord" est leur seul moyen d’interagir avec l'extérieur. Cependant, si elles modifient plusieurs variables, il faut se demander si le développeur s'y attend, juste en lisant la doc.

Appeler ses fonctions avant de les écrire

Cela permet de s'assurer qu'elle est utile avant de l'appeler et d'évaluer quels seront les paramètres. Parfois, j'aime même effectuer les appels de toutes mes fonctions, et les écrire ensuite. Ça peut être inutile, si vous savez exactement quoi coder.

En conclusion, nous voyons que la programmation nécessite une certaine rigueur : savoir à tout instant POURQUOI j'écris cette ligne. Le code est à destinations de machines, mais il doit surtout être lisible par des humains, c'est pourquoi il est important de le rendre compréhensible.