tyPouypOblOg

Quel est le plus performant ? Quel est le plus sécurisé ?

Aujourd’hui, nous utilisons principalement un frontal web qui redirige ensuite, au travers d’un bien souvent, les requêtes sur un serveur d’application. C’est le cas des techno Java avec les Tomcat et Glassfish, et par les techno Ruby avec Mongrels entre autres, mais même les petits nouveaux s’y mette: thin, ebb.

Ebb justement est le serveur d’application auquel je m’interesse ces dernier temps, c’est apparement un des plus performants. Ce qui m’interesse également c’est la possibilité d’utiliser les socket unix.

J’ai un peu de mal à mettre en place cette solution pour le moment, dès que c’est fait, je pourrais faire des test de performance.

Mais une question me harcèle: Est-ce qu’il est mieux d’utiliser les sockets ou bien les redirection de ports ? En mettant à part cet histoire de chrootage.

Le courage fait parti des clefs de l’eXtreme Programming [wikipedia]. Il est nécessaire lors du refactoring. Bien trop souvent les développeurs n’osent pas modifier du code existant. Il existe plusieurs raisons à cela:

• C’est le code de… AAah et bien si c’est le code du grand guru maison, qui oserais modifier sont code. Il penserait surement que l’on critique son code, qu’on ne le trouve pas assez bien. Et c’est peut-être le cas, ou alors tout simplement, ce code à besoin d’évoluer. Et plutôt que d’ajouter de nouvelle chose, il faut reprendre, modifier une partie du code existant. Cela évitera les redondances, les erreurs, et le code mort. Je garde mon apologie du refactoring pour un autre billet.

• Trop compliqué à lire Justement ! C’est qu’il faut le reécrire ce code ! Quel horreur du code illisible. Source de bugs, peut-être que ce source fait beaucoup trop de chose par rapport au besoin. Simplifions le !

• Je n’ai pas le temps Je crois qu’il faut de temps à autre avoir le courage de prendre le temps, de perdre du temps. Cela pourrais s’avérer bénéfique par la suite. Si j’ajoute plutôt que de modifier, qui me dit que je ne vais pas devoir y revenir une fois, deux fois, n fois pour corriger un bug, un disfonctionnement, un effet de bord ?

On parle du courage du codeur, le courage de modifier du code, mais je voudrais juste aborder ici un autre courage, celui-ci c’est pour les divers responsables et autres chefs de services: le courage de revenir sur une décision quand elle s’avère être mauvaise.

Trop de projets sont ecrasé contre un mur (ou alors y vont tout droit) parce qu’en haut personne n’ose, personne n’a le courage de tirer les leçons d’une série d’échecs, personnes n’ose revenir sur une méthodologie mauvaise.

Personnellement, je fais de l’informatique pour rendre service à des utilisateurs. Si je vois les utilisateurs heureux lors d’une livraisons, je le suis aussi. C’est un bon moyen de vérifier que nous sommes sur la bonne route. Mais justement, je m’égare de la route du courage dont je voulais parler :-)

N’ayons pas peur de modifier du code. Pour nous aider dans ce sens nous avons plusieurs outils à notre disposition:

• Outils de gestion de configuration (ou versioning): Ces outils nous permette de revenir à une version précédente avec une facilité déconcertante. Alors bien sur il faut en choisir un qui corresponde bien à nos besoin, mais je crois qu’aujourd’hui nous avons l’embarras du choix !

• Test unitaire: Les tests ! En voilà un outil. Avec une bonne batterie de test, nous sommes sur de ne rien casser. Comment ne pas oser un refactoring avec ça ? On modifie, on relance les tests, ça passe ? bien ça marche alors :)

• Langage et architecture: Tout cela est bien beau, mais c’est vrai qu’avec un langage et/ou une architecture ou tout élément et imbriqué dans l’autres, une architecture ou tout est lié, une architecture ou l’on gère plusieurs fonctionnalité dans un même source, c’est beaucoup plus effrayant de modifier un morceau. C’est une des raisons qui me font adorer l’Objet et les architectures associé. Un objet à une responsabilité, et une seul (enfin, il devrait). Pas de code cherchant à tout faire, souvent mal. Au moins c’est simple.

Courage et KISS DRY

Non, je n’étais pas vraiment parti (quoique presque), mais surtout très occupé.

C’est un peu l’inconvénient d’être dans chez un client qui pratique le mode projet brouette. J’entends par là que l’on developpe en sous-marin et que l’on déverse l’ensemble de l’application, directement en production, aux utilisateurs. Quand en plus ils n’ont pas demandé à avoir une nouvelle application, c’est pire.

Donc voilà, je suis arrivé au moment où l’on vient de verser l’ensemble du projet, et du coup, faut passer un peu la serpière, colmater les fuites… Ca me promet quelque jours bien chargé encore, mais ça commence à aller mieux.

J’ai eu la chance (si on veut) d’aller avec l’équipe vider la brouette en production sur place: en République Tchèque, a Pragues. Malheureusement, je n’ai pas vu grand chose: L’hotel, la filialle, le chemin entre les deux, et les rare restaurants prêt de l’hotel qui était encore ouvert après 23h30 (quand on rentrais à l’hotel pour dormir un peu).

Ca faisait longtemps que je n’avais pas fait autant d’heures.

Je ne sais pas ce qui me gène le plus dans tout ça, le fait de gacher une bonne équipe en la faisant travailler n’importe comment (grosse pertes d’energie en broutille) ou bien de fourguer aux utilisateurs une application qui ne correspond pas vraiment à leurs besoins :-/ Le deuxième point est le pire je crois.

Je commence à avoir trop de mission dans le genre à mon actif, ça me fatigue. Vivement la prochaine, en espérant que je pourrais influancer un peu plus la façon de travailler au moins, voir la façon de recueillir le besoin et de mettre en place la meilleur solution pour les utilisateurs. Ou bien, que je tombe sur une équipe qui soit dans ce genre d’objectif !

A suivre…

Les utilisateurs de Ruby nous connaissent bien l’outils de gestion de paquet (ou librairies, c’est comme on veut) RubyGems. Cet outil permet d’installer des paquets ruby enrichissant le coeur de notre langage préféré.

Cependant la plus part des systèmes d’exploitations de la famille des “*nix” (comprendre les divers distribution linux, les divers bsd et autre opensolaris) bénéficient déjà une gestionnaire de paquet permettant l’installer des applications.

Bien souvent certaines gems (c’est ainsi que l’on désigne les paquet ruby disponible via RubyGems) sont porté dans le gestionnaire de paquet de système que nous utilisons. Alors pourquoi avoir deux gestionnaire de paquet pour ruby : celui du système et RubyGems ?

RubyGems à l’avantage d’être disponible sur toute les plateformes, et ne serait-ce que pour les utilisateurs de fenêtre ou de pomme, c’est indispensable pour une meilleur gestion de l’installation Ruby.

Mais je pense qu’il faut utiliser en priorité les paquets spécifique au système (pour OpenBSD il y a aujourd’hui dans -current environ 75 paquets ruby disponible). En effet, ces paquets sont là pour s’intégrer au mieux avec le système. Et bien qu’ils s’installent de toute façon au même endroit qu’avec RubyGems, certain patch ou autres flavor spécifique peuvent être mis en place pour le bien de l’installation et l’intégrité du système d’exploitation.

Alors RubyGems n’est pas inutile sur ces systèmes, loin de là, ne serait-ce que pour avoir la collection complète des applications ruby, mais j’utilise personnellement les paquets du système en priorité.

Et vous ?

ps: RubyGems offre d’autre fonctionnalité interessante mais ce n’est pas le sujet ici :-)

1er mai rime avec nouvelle version d’OpenBSD Et comme d’habitude, c’est Theo qui l’annonce pile à l’heure L’annonce de la sortie au journal officiel

Je suis très content de voir que Jean-mi essaie OpenBSD peut-être sera-t-il convaincu :-)