Sous les Toits

Dans le développement d’applications Web, on s’aperçois vite qu’il faut toujours coder les mêmes chose. A quelques différences près. Pour de simples pages, on utilise des fonctions, mais faut il aller plus loins lorsque les applications sont plus vastes ?

Bon… c’est bien joli le développement d’applications web… mais c’est un peu toujours la même chose…
Alors, comme le développeur est par nature particulièrement fainéant, et la fainéantise étant le moteur de l’innovation, arrive un jour où on se dit, je vais faire du développement durable, c’est à la mode. Je vais développer de jolies fonctions que je vais classer proprement et réutiliser pour mes autres projets. L’idée est bonne.

La routine

Quelques fonctions plus tard, et toujours pour les mêmes raisons, on se dit qu’il ne sert à rien de réinventer la roue. Il suffit de récupérer des fonctions sous licence libre, de les classer proprement et de les réutiliser pour les autres projets. L’idée est encore meilleure puisque l’on a même plus à développer les fonctions de base… Sauf qu’il faut convertir les projets précédents.

Opter pour un FrameWork ?

Et cette situation peut durer un bon moment. C’est mon cas. Puis, arrive un jour où on se dit, mais pourquoi ne pas passer directement à un système de FrameWork. Les fonctions sont déjà développées, les FrameWork sont maintenus par leurs auteurs et il n’y a plus rien à faire si ce n’est laisser libre court à son imagination et créer sur ces jolies bases.

Bon, mais un FrameWork c’est bien joli mais il faut beaucoup de temps pour les apprivoiser. Et il faut en choisir un et s’y tenir. Donc il faut passer beaucoup de temps à tous les apprivoiser pour en choisir un. Ben quoi ? Vous ne choisiriez quand même pas une base de développement au hasard ou sur des « on dit », si ? Moi non.

Ruby sur ongle

Donc j’en ai essayé quelques uns. Et entre nous soit dit, j’ai été séduit par Ruby On Rails [en]. Cependant, Pour RoR il n’existe que peu de serveurs de production. Et je n’ai pas forcément envie de gérer mes propres serveurs de production. Donc, Ruby On Rails serait une très bonne alternative aujourd’hui, mais pour un intranet uniquement. Ce qui veut dire que vous développez en Ruby en interne et avec une autre technologie en externe. La poisse ! Déjà que je cherche à faire des response.write en PHP dès que je fatigue un peu, là, ce serait l’apothéose !

Exit donc le beau Ruby.
Pour les autres FrameWork, et bien ma foi… ils ne me permettent pas forcément de faire exactement ce que je veux et ils sont toujours un peu contraignants par certains côtés. Ne serait-ce que justement parce que ce sont des FrameWork.

Alors que faire ???

Situation très gênante. Sombre impasse au fond de laquelle vous ne voulez pas développer votre propre FrameWork (parce que vous allez vous retrouver avec les mêmes restrictions que les autres) et vous n’en pouvez plus de réécrire encore les mêmes lignes sur chaque page de chaque projet.

Par ailleurs, vous venez d’apprendre que Php va se doter d’ici peu d’un FrameWork propre [en] ainsi que d’un environnement de développement. Mais que comme de bien entendu, vous ne pouvez pas attendre, il faut attaquer les nouveaux projets. Sans parler du fait qu’on ne peut pas juger sans avoir vu.

Le compagnon idéal !

Personnellement, j’ai donc opté pour un bâtard. Un croisé porte et fenêtre (c’est généralement les plus sympa). Un ensemble de fonctions, classées proprement, mais fonctionnant un peu comme un FrameWork sans en être un.
Disons, pour essayer d’être un peu plus clair, que je vise des fonctions spécifique un peu avancées, liées ou non entre elles, basées sur des fonctions Open Source, et qui devraient (si je réussi mon coup) me permettre de développer presque aussi rapidement qu’avec un FrameWork, mais sans les contraintes de ce dernier. Le tout étant paramétrable directement via des fichiers de configuration et l’ajout de blocs modulaires.

Là, je vous sent dubitatif… Ca semble un truc au top mais c’est pas clair hein ?

Un peu comme moi ce soir… en toute modestie bien entendu.
Après tout, il est peut-être un peu trop tôt pour en parler.
Je développe ça un peu plus et je fais signe quand ça commence à devenir fonctionnel.