Julien Carnelos Blog – Archives

J’ai passé trop de temps à chercher sur Internet comment réaliser la validation d’un code IBAN en C#.

Ce bout de code valide donc que le n° IBAN saisi est correct. Attention il ne valide pas en fonction du pays mais calcule seulement la clé « checksum ».

Ce n’est pas du grand art mais cela permettra à d’autres d’éviter de passer une heure à chercher !

Et si vous êtes plutôt VB.NET, pas de problème, http://www.codechanger.com/ est là…

private static bool ValidateIBAN(string ibanValue)
{
  string iban = ibanValue.Substring(4, ibanValue.Length - 4) 
		+ ibanValue.Substring(0, 4);
  StringBuilder sb = new StringBuilder();
  foreach (char c in iban)
  {
    int v;
    if (Char.IsLetter(c))
    {
        v = c - 'A' + 10;
    }
    else
    {
       v = c - '0';
    }
    sb.Append(v);
  }
  string checkSumString = sb.ToString();
  int checksum = int.Parse(checkSumString.Substring(0, 1));
  for (int i = 1; i < checkSumString.Length; i++)
  {
     int v = int.Parse(checkSumString.Substring(i, 1));
     checksum *= 10;
     checksum += v;
     checksum %= 97;
  }
  return checksum == 1;
}

Un gestionnaire de source est toujours la 1ère étape dans une démarche d’industrialisation.

Si vous n’avez pas vos sources dans un référentiel au moment où vous lisez ces lignes, arrêtez-vous de suite et prenez le temps de le faire (Subversion).

La gestion de ce référentiel implique une certaine rigueur et une liste « officielle » de bonnes pratiques vient d’être publié sur le site de Subversion. J’ai repris les idées les plus intéressantes :

• Utiliser une arborescence propre

Quand on initialise le référentiel, il est facile de créer une arborescence inefficiente qu’il faudra supporter jusqu’au bout du projet. La recommandation officielle est de créer les trois dossiers : /trunk, /branches et /tags.

• Archiver des modifications fonctionnelles

Lorsque vous archivez vos modifications sur le source, celles-ci doivent être cohérentes et former un tout. Cela permettra un meilleur suivi des changements. De plus, ce changement pourra plus facilement être lié à un bug ou autre…

• Relier le gestionnaire des bugs

Il est fondamental de pouvoir être capable de relier un changement du source avec une « unité de travail ». Cette unité pouvant être un bug, une demande de changement, une évolution, etc. De ce fait, il faut associer à chaque archivage l’ID de l’item traité.

• Patient avec les gros fichiers

Subversion sait gérer le versionning des fichiers binaires mais de manière générale, manipuler ces fichiers engendrent des problèmes de latence qui peuvent devenir important. En effet, les fichiers sont copiés plusieurs fois en plusieurs endroits (dans le temp, dans le working local, …) et sur de gros transferts, le développeur devra être patient.

• Savoir quand créer une branche

Point critique, car la création d’une nouvelle branche n’est l’affaire que d’un compromis. Compromis entre l’avantage de pouvoir écrire du code non dépendant de la branche principale avec l’inconvénient de devoir un jour fusionner la branche avec le code principal.

A cette problématique, la réponse est question de contexte. Néanmoins trois stratégies se distinguent :

1. Aucune branche : Demande une forte discipline de la part des développeurs qui devront minimiser les risques de « break » du build.
2. Branche pour toute évolution : Chaque évolution est micro-managée et validée avant intégration dans la branche principale. Adapté aux gros projets possédant une équipe dédiée aux builds.
3. Branche pour les dev > 10j. Il s’agit de définir une limite où les développements qui nécessitent plus de temps se feront dans une branche à part. Pour information, c’est la technique employée dans l’équipe de développement du serveur Subversion.

Comme toujours, beaucoup de ces pratiques sont l’œuvre du bon sens. Si vous possédez également des techniques intéressantes, n’hésitez pas à partager 😉

Pour une fois, je fais un « méta-post » en bloggant sur les blogs…

Jakob Neilsen (gourou de l’ergonomie) a posté il quelque temps, en octobre 2005 (c’est à dire il y a des siècles en années Internet) une étude sur les erreurs communes trouvées sur les blogs. Cette liste étant toujours d’actualité, il est intéressant de revenir dessus :

1. Pas de biographie de l’auteur
2. Pas de photo de l’auteur
3. Des titres non descriptifs
4. Liens qui ne disent pas où ils vont
5. Les BestOf ne sont pas mis en avant
6. Le calendrier est la seule navigation
7. Fréquence de publication irrégulière
8. Mélange des sujets
9. Oublier que l’on écrit pour son futur boss
10.   Avoir son nom de domaine sur un service de blogs.

Le plus intéressant est évidemment de confronter ces points à mon blog. Alors voyons :

1 et 2 (Biographie et Photo) : je plaide coupable à 50%. En effet, je n’ai mis qu’une courte biographie sur la page A Propos et pas de photo. Le but était d’avoir une certaine indépendance entre mon travail au quotidien dans la société qui m’emploie et les différentes opinions que je donne ici (pas de mélange des genres). Pour la photo, je crois finalement qu’il est important de pouvoir mettre un visage sur un nom et j’ai donc modifié la page A Propos pour intégrer ma photo…

3,4 : Concernant les titres, la navigation et la destination des liens, j’essaye dans la mesure du possible d’être descriptif.

5: Les article BestOf étaient mis en avant sur le précédent blog mais n’apparaissent plus dans celui-ci. Il faudra que j’y réfléchisse à nouveau.

6 : Pas de calendrier, le problème est reglé…. enfin j’espère ?

7 : Voilà le point noir de tout bloggeur. Parmi tous mes proches qui ont souvent commencé à blogger avant moi, peu continuent aujourd’hui avec une fréquence inférieure au mois ! Pour ma part, j’essaye d’être régulier avec une écriture hebdomadaire. Parfois je me laisse aller et j’atteinds les deux semaines, mais je sens alors la honte m’envahir et je me force à trouver l’inspiration. Un blog est un jardin qu’il faut entretenir avec un minimum régulier…

8 : Point important pour moi, je n’évoque pas ma vie privée. Je peux partager avec vous des événements personnels importants mais ils ne seront jamais la majorité du contenu présent ici. D’ailleurs je vais encore une fois faire évoluer le sous titre et le contenu de la page A Propos afin de préciser l’intention de ce blog qui s’éloigne de plus en plus des articles purement techniques pour décrire plutôt le domaine de l’ingénierie logicielle en général.

9 : J’ai toujours ce point en tête quand je blogge. Tout ce que l’on écrit un jour sur Internet restera visible à jamais…

10 : Et oui, ce n’est pas pour rien que ce blog se trouve sur son propre nom de domaine . Ainsi je garantis que tout lien pointant vers mon site restera dans la mesure du possible vivant. (Vous pouvez donc me donner autant d’amour que vous voulez !)

Conclusion : j’ai l’impression que je ne m’en sors pas si mal. Si vous avez des remarques sur des évolutions possibles sur ce blog ou des défauts dont je n’aurais pas conscience, c’est le bon moment !

Au bon vieux temps des gros systèmes, il suffisait de maitrîser un langage de programmation (au hasard le COBOL) pour répondre aux besoins métier.

Ce temps est terminé et désormais le moindre développement nécessite l’utilisation de plusieurs technologies pour arriver à nos fins.

Exemple pour un développement WEB J2EE standard :

• Java
• XML
• Javascript
• HTML
• CSS
• SQL

Et je décris ici le minimum vital. Il est donc illusoire de croire qu’il suffit de connaître le Java pour coder des applications web Java. C’est d’ailleurs généralement la première problèmatique que rencontrent les débutants : on passe plus de temps à traiter des problèmes d’affichage en HTML avec CSS qu’à implémenter la couche métier objet.

La solution à ce problème n’existe pas, et il faudra apprendre à jongler avec les nombreux langages utilisés tout au long de notre vie. Et ne croyez pas être à l’abri avec un langage « plateforme » Java ou .NET car Java peut devenir le nouveau COBOL…

Bonus – je me fais plaisir : Parfois il est possible d’éviter le syndrôme de l’hyperpolyglotte :

En février dernier, j’avais joué l’oracle en prédisant le succès de OpenID comme gestion de l’identité unique.

Force est de constater qu’en 6 mois (longue durée en temps Internet), les choses n’ont pas vraiment bougé. Jan Miksovsky apporte sur son blog des éléments de réponse :

OpenID reste une bonne idée mais n’est pas adapté au grand public.

Je ne peux que constater la véracité de cette affirmation tant on sent que OpenID est une solution technique dont le discours n’est compréhensible que par des personnes techniques. Je n’imagine que trop bien l’utilisateur lambda souhaitant passer par OpenID :

• Quel fournisseur OpenID j’utilise ?
• Pourquoi je dois saisir une URL comme identifiant et pas un email ?
• Le fait de passer de passer par le fournisseur lorsque je m’authentifie la première fois et perturbant et pas forcément clair
• …

C’est un travail de vulgarisation qui nous attend si nous voulons que OpenID soit enfin la révolution telle qu’elle est promise. A chacun de jouer à son niveau mais le plus important serait de mettre en place un « langage » commun. La vulgarisation passe par une standardisation des différentes boîtes d’identification, par un standard sur les messages d’erreur, de choix de profil, d’acceptation, …

Le design des différentes pages et messages devront être pensé pour un utilisateur non technique. La preuve est qu’aujourd’hui quand on va sur le site de référence openid.net, voilà sur quoi on tombe :

Dans la description de ce qu’est OpenID, on a d’abord la définition pour les « geeks« , et seulement après la définition pour le commun des mortels… Edifiant 🙂

Des études ont montré que lorsqu’une personne passait devant une caméra de surveillance, son comportement changeait :

L’impression d’être épié renforce notre sentiment d’altruisme  et nous pousse à se comporter comme un modèle pour ceux qui, potentiellement, nous regarderaient.

Ce qui est intéressant avec cette théorie, c’est qu’elle paraît plausible pour expliquer une des forces de l’open source.

En effet, on qualifie souvent les outils Open Source (Firefox, Linux, …) plus robustes que leur équivalent propriétaires (Windows, IE, …). En se mettant à la place du développeur qui travaille dessus, une explication s’impose. Car il sait que chacune des lignes de code qu’il tape pourra être lu, relu, vérifié par une autre personne inconnue. Potentiellement, il a 1 million de développeurs qui pourront un jour regarder son code et le juger.

Dans ce cas, il n’est guère étonnant d’imaginer qu’une attention plus grande sera portée au code réalisé avec pour résultat une meilleure qualité.

Référence : L’altruiste, l’oeil et le totem (Le Monde)

Ce blog passe désormais en mode ouvert : Tous les commentaires postés compterons pour Google.

Pour ceux qui ne connaissent pas, depuis quelque temps il existe la technique du « NoFollow » qui indique à Google que les liens marqués avec ce tag ne doivent pas être suivi. C’est pratique pour éviter que les commentaires SPAM soient pris en compte sur les blogs.

Néanmoins, ce système est pénalisant pour les « vrais » commentaires. Etant donné que les commentaires de ce blog sont modérés, il n’y a pas de commentaires SPAM.

Je peux donc activer sereinement le Dofollow…

Vous pouvez commenter, ça compte pour votre référencement 😉

Via VoxinaBlog, je viens de lire que le moteur n°1 de recherche (Google pour ceux qui suivent 😉 ) va effectuer quelques changements sur l’interprétation des URL.

• Le caratère « _ » devient un séparateur

Auparavant, une url de type http://www.example.com/lecteurs_dvd/ était interpreté avec le mot unique « lecteurs_dvd » et non « lecteurs » puis « dvd ».

• Les paramètres Query String sont traités comme faisant partie de l’URL.

http://www.example.com/lecteurs_mp3/ipod/ sera équivalent à http://www.example.com/voir.php?cat=lecteurs_mp3&pdt=ipod

• Le nombre de slash dans l’url n’indique pas la profondeur de l’article et donc du classement.

Intéressant pour les blogs par exemple.

• Les extensions n’influent pas sur l’url

Plus besoin d’avoir forcément une URL qui se termine par « .html ».

Les impacts de ces mesures sur les développements peuvent être conséquents. En effet, c’est aujourd’hui une demande constante de la part des clients d’avoir des URL « jolies » améliorant le référencement. Cela avait pour conséquence de devoir parfois jongler avec des règles d’URL Rewrite relativement complexes.

Exemple: (j’accepte les regexp de résolution en commentaire 🙂 )
http://www.example.com/index.php?cat=media&pdt=dvdrw&paginate=2
en
http://www.example.com/media/dvdrw/2.html
puis inversement.

Désormais, on pourra donc éviter une partie de ces traitements pour des raisons de référencement. Quand on sait que 80% des visites passent par Google, la nouvelle est d’importance.

En revanche, un autre aspect des URL Rewrite est l’aspect joli pour l’oeil humain (par opposition au robot référenceurt google). Dans ce cas, il pourra toujours être intéressant de rechercher à améliorer l’url, mais cela sera moins critique…

Si comme moi, vous pensez que la motivation est le critère numéro un de productivité des développeurs, vous devez alors vous poser la question de savoir comment entretenir cette motivation. L’auto-gratification est un de ces principes psychologiques.

Il s’agit d’adapter son style de développement en mode incrémental. L’idée est de développer bout par bout plutôt que de chercher à réaliser de « grosses » fonctions en one-shot.

Prenons l’exemple d’une fonction « Réaliser une interface de gestion d’utilisateurs avec création/suppression/consultation« .

On peut utiliser deux stratégies : Soit construire chacune des couches (interface, puis métier et enfin données) en mode horizontal, soit construire en vertical chaque sous fonction (d’abord faire toute la consultation, puis la création, etc.)

Et bien le principe de gratification voudrait que l’on utilise la stratégie verticale afin de découper la fonction en petits morceaux réalisables unitairement. Pour la bonne raison que pour chaque sous fonction réalisée, il sera possible de constater que notre bout de code donne un résultat. La voilà notre motivation : voir que notre code fonctionne !

C’est exactement ce que nous encourage à faire le développement orienté par les tests (TDD) : En effet, vous codez un test qui échoue, et vous écrivez le code suffisant qui fait passer le test. A chaque barre verte affichée (le signe que le test passe), c’est une satisfaction de constater que l’on « avance », que le programme se construit et qu’il fonctionne…

Sans vouloir refaire la célèbre maxime du bon développeur et du mauvais développeur, je cite souvent une étude du livre Peopleware qui explique que l’on retrouve un écart de productivté entre développeurs pouvant aller sur un ratio de 1:6.

En clair, un développeur efficace peut aller six fois plus vite qu’un autre. Plusieurs études ont prouvé la réalité de cet écart mais cela reste difficile à admettre et en particulier par les managers.

Hint: Si vous allez voir votre manager demain matin pour négocier une augmentation, ce n’est pas la peine de venir vous plaindre que lui montrer mon post n’a pas marché. 😉

Bref, l’idée est plutôt de savoir reconnaître les talents afin de profiter au mieux de leurs capacités et surtout de repérer les boulets en puissance…

Comment les reconnaitre ? « facile » grace à cette liste des 6 signes d’un bon développeur :

• Un bon développeur sait prendre le contrôle : C’est le fameux « ingénieur à la tâche ». Vous donnez une tâche à quelqu’un avec les moyens, il doit s’approprier la tâche et la réaliser. C’est une attitude active et pas attentive.
• Un bon développeur écrit du code avec moins de bug : De son expérience, il sait que le zéro défaut est impossible mais il applique des pratiques reconnues et saines dans le code.
• Un bon développeur écrit du code maintenable : La règle d’or : 1€ de développement = 2€ de maintenance. Il le sait et réfléchit en permanence en codant : « Est-ce que quelq’un qui lit ce code/commentaire comprendrait ? »
• Un bon développeur écrit moins de code : L’invention de la roue commence à dater… mais certains frameworks aussi ! Et pourtant tellement de développeurs partent bille en tête à implémenter une fonction qui existe déjà… 
• Un bon développeur sait rapporter : Il est capable de savoir où il en est, et surtout il est capable de délivrer cette information à son chef de projet. De ce fait, il sait remonter les difficultés rencontrées afin de trouver les solutions adéquates au plus tôt.
•  Un bon développeur s’adapte au niveau de ses collègues : Il est illusoire de croire qu’une équipe de développement sera composée uniquement de stars (sauf à travailler chez Google?). Le développeur doit donc s’adapter en ne montrant pas une attitude élitiste et négligeant les moins forts que lui. Au contraire, il doit être le catalyseur qui pousse l’équipe vers le haut. D’ailleurs lui aussi a été débutant un jour…

Inspiration :  http://haacked.com/archive/2007/06/25/understanding-productivity-differences-between-developers.aspx