Julien Carnelos Blog – Archives

A part quelques petits déboires causés par des plugins non compatibles avec la nouvelle version 2.3 de WordPress, ma transition vers l’autre hébergeur s’est bien déroulée.

J’en profite pour remercier la centaine (aujourd’hui 120 sur le compteur FeedBurner) de lecteurs fidèles et j’espère continuer à vous intéresser.

Si vous continuez à venir visiter ce blog par le site web, sachez que vous pouvez utiliser le flux RSS qui se trouve à droite ou même vous inscrire avec votre email. Vous serez ainsi tenu au courant de chaque nouvel article.

Le temps que je transfère ce blog sur nouvel hébergeur, je passe les commentaires en lecture seule.

Je tiens à remercier du fond du cœur Christophe, alias « la chaudière » qui m’aura hébergé durant ces quelques mois. N’hésitez pas à aller voir son site, il parait que la zone recettes est particulièrement intéressante…

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 !