Review Board – Outil de revue de code

Review Board is under the MIT license, which basically means you are free to do as you want. You must however keep the software under the MIT license.

via Frequently Asked Questions | Documentation | Review Board.
Un outil prometteur pour la revue de code. Lorsqu’on travaille en équipe et qu’on doit faire de la revue de code pour des questions de qualité, on manque en général d’outillage (ou disons que ce n’est pas très courant d’en avoir).
Ici nous avons donc un outil plutôt bien foutu en python (donc installable partout et facilement) et qui a l’énorme mérite d’être sous licence MIT.
A tester !

Python or not ? Premières impresssions

Bien, comme il est question depuis un moment de reprendre un vieux projet web, je me demande si je je vais pas en profiter pour mettre le nez dans une autre techno ou plus exactement un autre langage. Parmi tout ceux qui existent ma tendance est plutôt d’aller vers python (j’en parlais d’ailleurs dans ce billet). C’est un langage assez mature avec plein de qualités. Sans compter que de base je déteste les trucs « tendance » qui n’ont de qualité que d’être « hype » à un moment avant de disparaitre définitivement.
Bon ce n’est pas mon premier langage, j’ai commencé en PHP (plus pratiqué depuis longtemps) pour faire actuellement du Java EE. Le fait est que d’apprendre de nouvelles choses peut faire grandir même si cela peut rebuter clairement au premier abord. Et puis après tout il faut quand même se poser les bonnes questions. Faire du nouveau pour le nouveau ou se perfectionner dans ce qu’on ne maitrise finalement jamais complètement ?
Bref, pour le moment je ne sais pas trop encore quelle sera ma décision et le fait est que beaucoup beaucoup de paramètres rentrent en jeu. Pour l’instant je survole pas mal de documentation python.
La lecture du matin :

Premières impressions
Attention avis purement perso et surement influencé par le premier contact. Il est donc susceptible d’évoluer.
Donc, impressions assez mitigées je l’avoue. La façon de coder, de nommer et de mettre en place les mécanismes me semble assez particulière (cela dit c’est nouveau donc résistance au changement etc).
Par exemple, la façon de faire de l’objet me déplait un peu et me semble quelque peu en mode « a la bonne franquette ». Au hasard, pas d’interface et à la place un héritage multiple. Ne parlons pas du typage dynamique des conventions de nommage disparates qui ont tendance à me faire faire des grimaces.
De plus, le coté bloc d’instruction avec espaces pourquoi pas mais j’ai l’impression de faire du COBOL sur MVS avec ça (attention les x premières colonnes sont réservées @_+). Dans un langage, le fait que des caractères « non visibles » ou positionnels comme l’espace ou la tab aient du sens à la compilation me dérange toujours.
Par contre je reconnais que le langage est sans doute très puissant, très pratique et portable. A première vue j’en ferai un compagnon idéal pour faire des programmes systèmes bien plus qu’un script ou php-cli.
Coté web les choses ne sont pas franchement roses non plus. Niveau framework c’est bien simple il n’y a globalement que Django qui soit de taille et de maturité critique (il a l’air sympa aussi). Il y a quelques autres choses à gauche et à droite mais qui à première vue ne méritent pas trop le détour. Quand on vient du monde PHP ou Java où l’on est habitué à devoir faire le choix entre pas mal de solutions reconnues et matures ça donne un arrière gout bizarre dans la bouche. Du coup la question naturelle se pose est-ce que python est un bon choix pour le web ?
En conclusion mon avis n’est donc pas très tranché mais il est clair que je suis loin d’avoir des étoiles dans les yeux. A la limite j’aurais presque envie de faire du Java EE 7 pour ce fameux projet mais je reconnais volontier que tout ce que cela implique est tout de même très lourd pour un petit projet web. Mais bon, d’un coté me passer de pouvoir faire des choix de composants excitant comme CDI, Arquilian, Selenium, OpenEJB, JPA et j’en passe me donne une impression de sacrifice. Sacrifice pourquoi pas mais dans quel but ?
 

Julien Dollon | Le code ne necessite pas de commentaires – HowTommy | Liens et actu en vrac – Le Hollandais Volant

+1 je te rejoins aussi.

via Julien Dollon | Le code ne necessite pas de commentaires – HowTommy | Liens et actu en vrac – Le Hollandais Volant.
Mouais… Alors oui à 90% sur ce qui est dit. Par contre tomber dans l’extrême 0 commentaire hormis les trucs ultra spécifiques hum hum je dis non non non (d’ailleurs tout ce qui ressemble à de l’extrême je dis non non).
Effectivement je suis peut être historiquement du genre à sur-commenter mon code. Je concède que cela peut vite devenir obsolète. Je suis 100% d’accord sur le nommage des variables méthodes & co et 100% d’accord sur le code simple.
Par contre zéro comment faut pas pousser. Oui les soucis a l’international sont notamment une raison de pas en abuser. Mais bon, sans rire, perso j’aime bien un bout de doc sur une API une librairie etc… Et le minimum qu’on puisse faire et maintenir facilement c’est une Javadoc like… Et oui c’est du comment.
Quand j’utilise un projet, j’aime bien lire une bonne javadoc sur l’API et j’ai pas spécialement envie de m’avaler les 10 000 000 lignes de code pour comprendre ce que je peux faire.
Après oui OK dans le code lui même pas ou très peu de commentaires. J’en ai abusé à une époque, j’en utilise moins. Après aujourd’hui je m’en sers plus pour ventiler mon code. Un peu pour donner un titre a quelques lignes. J’aime pas trop les lignes ramassées qui font un genre de pavé dans ma tronche.
J’en vois venir en disant oui mais ton paragraphe c’est ta méthode tu découpes pas assez. Je dirais oui c’est sur que la théorie c’est de très petites fonctions mais bon en pratique on peut quand même faire un bout de code d’une 20aines de lignes avec différentes étapes. Et après sur découper un problème c’est pas non plus la meilleure solution pour des performances (branchement / débranchement lors de l’execution) et une lisibilité optimale.
En ventilant le code avec des comments en guise de tires, je trouve que le lire est plus simple et visuel. J’ai mes paragraphes, mes titres et hop.
Bon après je ne dis pas que je n’ai plus rien à apprendre. Disons qu’au jour d’aujourd’hui j’en suis la.
 

10 raisons pour lesquelles je suis toujours marié à Python | Sam & Max: Python, Django, Git et du cul

C’est une chance d’avoir un métier qu’on aime. Et l’avantage, c’est qu’on se sent l’énergie d’essayer plein de choses. J’ai codé (à plus ou moins grande échelle) en de nombreux langages : VB, C, C#, Java, Ruby, PHP, Javascript, Lisp, Bash, Erlang, SQL et leurs dérivés (langages générateurs, surcouches, etc).
Et j’en ai apprécié beaucoup. Ils m’ont fait découvrir des choses, on fait de moi un meilleur professionnel. Et m’ont donné des tas de perspectives sur mon métier, sur la résolution de certains problèmes, sur la philosophie de dev…
Je continue à utiliser d’autres langages au quotidien pour divers tâches, j’ai remarqué qu’un marteau était beaucoup plus pratique qu’un tourne-vis pour enfoncer des clous, mais quand j’ai le choix, je reviens toujours à Python.
Et en voici les raisons.

via 10 raisons pour lesquelles je suis toujours marié à Python | Sam & Max: Python, Django, Git et du cul.
J’avoue que j’en suis arrivé à la croisée des chemins. J’ai pratiqué PHP il y a longtemps. Je pratique aujourd’hui Java. Je ne parle pas des autres langages dont la pratique a été trop brève.
Il y a du bon et du mauvais dans les deux. Aujourd’hui je me pose la question de faire un new projet et la question du langage se pose. Je suis bien tenté de tester python mais j’avoue qu’apprendre un new langage me plait moyen… En même temps ça ne peut pas me faire de mal…

Estimer un temps de développement, c’est difficile – HTeuMeuLeu

Estimer un temps de développement, c’est difficile – HTeuMeuLeu.
Tout à fait vrai ! Je partage assez cette vision. C’est d’ailleurs pour cela que vendre et gérer un projet est si difficile dans l’informatique.
Le seul moyen de devenir réellement cohérent est d’avoir déjà fait la route (ou quelque chose d’approchant) au moins une fois. Ce n’est pas toujours possible quand on innove, du moins pour référence les compétences que l’on avait jusqu’ici.
C’est sans doute ce que les différentes méthode projet essayent de gérer tant bien que mal mais il n’y aura jamais de réelle solution à ce mal (sauf avoir déjà fait).
C’est dommage puisque dans l’absolu le client n’attend qu’une chose (hormis le traditionnel pas cher) c’est d’avoir une vision précise de combien il va devoir débourser du début à la fin.