Le blog du Pere-nono

mercredi 29 février 2012

Billet d'humeur : Que privilégier?

Dans nos métiers, ils nous faut souvent concilier maintenance et nouveautés mais comment faire?

Lire la suite

vendredi 19 novembre 2010

Les designs patterns

J'ai appelé cela "Les designs patterns" mais j'aurai plutôt du appeler cela "entretien comique". Et oui tout commence avec un entretien. Face à moi une personne avec beaucoup d'expériences et un beau CV mais qui semble ancré dans le passé pantalon et veste velours d'un autre temps. La personne se dit sûr d'elle et me dit connaitre juste MVC en design pattern. Questionnement : vous devez bien en connaitre d'autres singleton et fabrique ( qui reste les plus connus ). Et là me dit oui il s'agit de réduire l'allocation mémoire :S Ok pour le singleton mais la fabrique est loin du compte.

Cela m'a questionné et je me suis dis qu'il était peut être utile de revenir sur ce patron au combien utile pour ceux qui souhaitent construire une application modulaire. L'exemple le plus connu est l'ouverture d'une connexion JDBC :

Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql", connectionProps);

DriverManager est justement une factory, elle va par l'appel à la méthode getConnection renvoyer en fonction de l'URL et des drivers chargés créer et renvoyer une instance de la classe fille de Connection. On aura ainsi si on attaque une base Oracle ou Sql Server pas la même instance d'objet mais comme elles héritent toutes de la classe Connection on va pouvoir les utiliser de manière indifférenciée.

Ce que nous venons de voir est bien l'utilisation la plus standard des fabriques. Il existe des dérivées dont une pour la gestion des pools qui va en plus d'instancier de manière masquée les objets en contrôlera aussi le nombre mais il ne s'agit pas du véritable patron "fabrique".

Si je dois conclure concernant cet entretien: avant de tenir tête à la personne en fasse mieux vaut tourner sept fois sa langue dans sa bouche et chercher à comprendre où elle veut en venir!

Quelques liens utiles :
http://gfx.developpez.com/tutoriel/conception/pattern/fabrique/

http://abrillant.developpez.com/tutoriel/java/design/pattern/introduction/

dimanche 26 septembre 2010

Distributed Source Control Management

Considéré par beaucoup comme l'avenir des SCM classique ( CVS / SUbversion / ... ) il ne se contente plus de synchronizer les fichiers avec un serveur central mais transforme tout les postes à la fois en client et serveur ce qui permet d'être plus résistant à des pannes réseaux ou d'une machine.

Une présentation très intéressante au JUG de Lyon a permit de comparer les deux outils gratuits les plus utilisés : GIT et Mercurial. On s'apercoit vite lors de la présentation qu'effectivement les concepts sont intéressants et que les deux systèmes sont très proches. Seuls les intégrations dans les IDE et OS différent vraiment avec un leger avantage à Mercurial tout particulièrement en environnement Windows. Personnellement j'en retiendrai surtout la possibilité de pouvoir utiliser une hierarchie de serveur permettant par exemple aux developpeurs de commiter leurs sources vers les architectes qui vont pouvoir vérifier et se porter garant du bon fonctionnement et commiterons à ce moment sur les serveurs utilisé pour générer les versions de production et patch.
Un autre aspect qui est souvent associé à ces systèmes est la gestion des branches qui est censé être beaucoup plus souple mais la demonstration ne m'a permis de me faire une idée. Le moteur et l'utilisation semble plus simple mais je n'ai pas particulièrement l'impression que cela change grand chose.
Il est en tout cas très aisé de passer de SVN/CVS à ces systèmes grâce à de nombreux outils qui permettent le transfert tout en conservant l'historique.

Maintenant le système peut poser plusieurs problèmes :

_le stockage ne se fait pas par différenciel comme avec CVS et SVN ( les intervenants annoncent que l'espace de stockage n'est pas plus important grace à des algorithmes très étudiés ),

_il pousse à travailler plus longtemps avant de commiter réellement sur le serveur ( ce qui peut augmenter la difficulté des merges ).

En tout cas cette présenation dont je remercie les intervenants m'a permis de mieux comprendre cette technologie mais elle souleve aussi de nombreuse questions pour lesquels il faudra que je me fasse ma propre idée.

A tout ceux qui ont des retours d'expérience je suis preneur d'entamer un dialogue

samedi 14 août 2010

La spécialisation dans l'informatique

Hier j'ai été confronté à nouveau au résultat de la spécialisation des métiers dans l'informatique et à sa professionnalisation. Tout ceci sans que l'éducation n'ai vraiment suivi le mouvement!
Si on revient 10-15 ans en arrière, on demandait aux informaticiens de tout connaitre : développement / métier du client / administration / graphisme et d'assumer l'ergonomie de l'application.
Depuis des progrès ont été fait avec une spécialisation des métiers. On trouve ainsi de nos jours sur un même projet :

  • développeurs,
  • testeurs,
  • graphistes,
  • ergonomes ...

Ceci va dans le bon sens, mais cela peut entrainer des gels temporaire d'un projet ou son retard, si :

  • un dialogue n'existe pas entre les équipes ( souvent le cas quand il y a des prestations extérieurs ),
  • on ne double pas les compétences.%%

Pourquoi cela? Tout simplement par incompréhension, ou méconnaissance d'outils que l'on utilise pas directement. L'exemple le plus probant et celui qui m'a amené à rédiger ce billet : l'incompréhension entre graphiste et développeurs.
En effet, le premier travaille avec Photoshop ou illustrator et ne parle que "layer" avec des images qui se superposent pour donner le rendu final sur une maquette. Le second manipule des "composant" ou il cherche au contraire à avoir le minimum de recouvrement.
A mon sens l'éducation a un rôle à jouer pour réduire cette fracture. En effet, les filières ce sont spécialisées et il est rare qu'un développeur ne comprenne un outil tel que Photoshop. Inversement un graphiste n'a pas connaissance de la construction d'un client lourd, ni même un client léger. Vous allez me dire que c'est normal! Et je répond que oui, les temps de formations sont limités et on doit se contenter de voir ce dont le ROI sera le plus rapide. Cependant beaucoup d'écoles d'informatique réunissent plusieurs filières qui se complètent. Qu'est ce qui empêcherai de prévoir un projet commun entre ces filières qui permettrai aux étudiants de mieux comprendre à la fois ce qu'est un projet et les contraintes de chacun? La question est posée! Qu'en pensez vous?