Niveau :
Résumé : la vie avec unix
Unix, ce n'est pas seulement un système, ce n'est pas seulement une marque, c'est aussi une façon de voir les choses, une façon de concevoir des programmes qui feront ce dont vous avez vraiment besoin. Nous allons parler des principes fondamentaux d'unix.
Tout est fichier
On commence à le savoir, les périphériques sont des fichiers qui se trouvent dans /dev, les processus sont des fichiers qui se trouvent dans /proc, les paramètres et données du noyau sont des fichiers qui se trouvent dans /sys et accessoirement /proc, les exécutables sont des fichiers normaux. Seule la carte réseau n'est pas un fichier, pour des raisons de performances paraît-il. Mais les connexions sont tout de même vues à travers des descripteurs de fichier dans les processus.
Les données sont du texte
Dans la philosophie unix, toutes les données doivent être stockées et transmises sous forme de texte. Cela peut coûter légèrement plus de place qu'un format binaire. Mais on y gagne beaucoup.
- Un fichier texte peut être lu par les autres outils unix, et donc respecte de principe faire une chose et le faire bien
- Un fichier texte peut être lu par un être humain et donc respecte le principe kiss
- Un fichier texte permet une interopérabilité avec d'autres systèmes (pas de problèmes d'indiens en iso par exemple)
- Un fichier texte facilite le débugage
On retrouve donc le texte partout :
- Dans les scripts
- Les fichiers de configuration
- Des formats de données d'application
- Dans les protocoles réseau de haut niveau
- La sortie d'informations se vos programmes
On ne le retrouve pas dans les cas où l'espace ou le temps de parsing sont primordiaux, par exemple dans les formats d'image ou de son.
Et la tendance va en s'accentuant puisqu'on utilise de plus en plus un format texte structuré un peu partout et à toutes les sauces : le xml.
KISS
Keep it simple, stupid !
Une petite question se pose sur le sens de stupid. Est-ce un deuxième adjectif présent pour renforcer le simple ou un qualificatif destiné au lecteur ? Je vote pour la première solution, mais ce n'est que mon avis.
Il s'agit ici de disposer d'outils très simples. Plus c'est simple mieux c'est. Ce n'est pas que l'utilisateur soit stupide, c'est qu'il n'a aucune raison d'aller perdre du temps à comprendre le fonctionnement de quelque chose qui est fondamentalement simple. Qui dit outils simples, dit faciles à manipuler, faciles à réutiliser.
Mais on ne parle pas seulement d'usage ici. Il s'agit aussi de garder le code simple, stupide. Cela rejoint un propos sur les commentaires dans le développement. Si votre code est bien écrit, bien architecturé, simple, alors il sera aussi simple à lire, à maintenir et à débuger, pas besoin de milliers de lignes de commentaires.
Faire une chose et le faire bien
Unix a inventé le pipe '|', une méthode simpliste pour faire communiquer 2 programmes entre eux. Cette communication est unidirectionnelle et non formatée, seules des données brutes y passent. Et pourtant, à lui seul le pipe a fait beaucoup plus pour unix que n'importe qui.
Grâce au pipe et au fait que la plupart des programmes communiquent avec un format texte, il est possible de faire des programmes qui ne soient que des filtres, qui ne fassent qu'une chose sur les données qu'on leur donne, et qui le fassent bien. Il est possible de faire des choses qui n'étaient pas prévues mais qui sont rendues possibles par l'apparition d'un nouveau filtre.
Bien sûr après le pipe, on a inventé la socket qui communique dans les 2 sens, ainsi que bien d'autres moyens de communiquer d'un processus a l'autre. Mais ce ne sont que des évolutions servant à pousser toujours un peu plus loin le principe : faire une chose et le faire bien. Quel que soit ce que vous développez, arrangez-vous pour que votre logiciel sache communiquer avec les autres logiciels unix. Ainsi vous garantirez une utilisation bien plus large à votre produit que celle que vous aviez dans la tête.
Puisque les autre outils sont déjà des outils simples qui font une chose et bien, vous pouvez aussi les réutiliser et vous appuyer sur les épaules d'un géant.
Loading ...
Comments