<%= link_to ‘Le blog de VDU’, … %>

Bonjour,

Je pense que certains l’auront remarqué, le peu de posts qui caractérisent ce blog depuis les derniers mois est assez inquiétant. Je ne dis pas que j’en suis fier,  mais il y a des périodes des fois dans une vie où il faut savoir revoir ses priorités.

Comme je n’ai plus le temps de blogger, je préfère m’en tenir là pour le moment. Je ne dis pas que ce blog ne réouvrira pas ses portes un jour, mais pour l’instant, autant ne pas s’illusioner…
C’est avec donc un petit pincement que je déclare ce blog fermé -pour l’instant-

Peut être à la revoyure…
Collaborateur VDU

C’est avec beaucoup de fierté que j’annonce, après un mois de travail dessus, la sortie de continuous4r, ma première vraie contribution au monde Ruby on Rails. Continuous4r répond au besoin pour Ruby on Rails d’une solution de regroupement pour l’intégration continue. En effet, beaucoup d’outils d’intégration continue excellents existent (dcov, rcov, saikuro, etc…), mais aucun dénominateur commun ne permet de les réunir.

Continuous4r permet, à partir d’un simple fichier de description de projet au format XML, de générer un site entier de rappports à la façon de Maven.

Voici l’exhaustivité des rapports générés :

• Informations du projet
• Equipe projet
• Dépendances
• Informations SCM
• Informations bugtracker
• Liste des rapports des différents outils
• Changelog (changements Subversion)
• Statistiques Rails
• Couverture rdoc
• Couverture des tests
• Génération rdoc
• Complexité du code
• Complexité cyclomatique/Code dupliqué/…(kwala)
• Graphes pour controleurs et modèles
• Stress HTTP de l’application
• Logs des tests unitaires
• Cohérence du format des tests unitaires
• Déploiements avec Capistrano

Bon effectivement cela n’est pas complet, mais cette version n’est qu’une première beta, et j’espère qu’il y aura plein de retours et de commentaires dessus pour me permettre de l’améliorer.

Je viens d’ajouter dans la page Intégration continue Ruby On Rails un paragraphe sur dcov, un outil d’analyse de couverture de documentation ruby (rdoc). C’est un outil intéressant, simple à utiliser et à mettre en oeuvre. Profitez-en !

Cela part d’un bon sentiment. Tous mes chers confrères qui travaillent dans le milieu du développement informatique me comprendront, la perte d’un travail effectué est une chose vexante. C’est d’autant plus vexant au moment où l’on doit rendre des comptes. C’est ce qui m’est arrivé très récemment; un client m’a réclamé des sources d’éditions JasperReports qui n’avaient jamais été publiées sur le CVS du projet.

A ce point précis, seul un miracle pouvait me sauver, car à priori avec seulement un fichier binaire d’édition, je ne pouvais pas faire grand chose. Une solution élégante m’a été proposée par un collègue, je me permets donc de la partager avec vous ici.

Voici un programme Java qui permet de passer d’un fichier finaire Jasper Reports (extension .jasper) à un fichier source Jasper Reports (ouvrable avec iReport par exemple) :

package net.free.vdu.tools;

import net.sf.jasperreports.engine.JasperReport;
import net.sf.jasperreports.engine.JRException;
import net.sf.jasperreports.engine.util.JRLoader;
import net.sf.jasperreports.engine.xml.JRXmlWriter;

/**
 * Classe permettant de passer d'un fichier binaire .jasper
 * (Jasper Reports) à un fichier source .jrxml
 * @author JasperSoft, VDU
 * @version 1.0
 */
class JasperToJrxml {

   public static void main(String [] args) {
      // Chemin du fichier binaire .jasper
      final String sourcePath = args[0];

      // Chemin du fichier source généré .jrxml
      final String outputPath = args[0].replace(".jasper", ".jrxml");

      // Génération du fichier source à partir du fichier binaire
      generateJrxmlFile(sourcePath, outputPath);
   }

   /**
    * Méthode de génération du fichier source à partir du fichier binaire
    * @param pSourcePath le chemin du fichier binaire en entrée
    * @param pOutputPath le chemin du fichier source généré en sortie
    */
   public static void generateJrxmlFile(String pFileName, String pSourcePath, String pOutputPath) {
      try {
         // Chargement du fichier binaire sous forme d'objet JasperReport
         final JasperReport jasperReport = (JasperReport) JRLoader.loadObject(sourcePath);

         // Ecriture du XML généré à partir de l'objet JasperReport dans le fichier de sortie
         JRXmlWriter.writeReport(jasperReport, outputPath, "UTF-8");

      } catch(JRException e) {
         e.printStackTrace();
      }
   }
}

Voici comment utiliser ce programme :

javac -cp .: JasperToJrxml.java
java -cp .: net.free.vdu.tools.JasperToJrxml

Et voilà, plus qu’à récupérer votre fichier source .jxrxml !

Quand je vois le nombre de personnes qui bloggent juste pour blogger, ça fait peur. Et en plus, ça n’est même pas complet.
La gestion des exceptions en Ruby, c’est :

begin
...
rescue
...
ensure
...
end

Exemple :

begin
 file = open("/tmp/some_file", "w")
 # ... écrit dans le fichier ...
rescue
 # ... gère les exceptions ...
ensure
 file.close   # ... et ceci arrive dans tous les cas.
end

Je suis certain que les développeurs minutieux que vous êtes pensent à faire des tests de couverture de code. Si cela ne vous évoque rien, vous devriez vous inquiéter très vite, et vous devriez écrire des tests pour les contrôleurs de votre application (voir la page qui en parle). Pour Ruby on Rails, l’outil de test de couverture de code de prédilection est rcov.

Pour ma part, l’écriture des tests des contrôleurs de l’application Rails sur laquelle je travaille m’a permis de démasquer de nombreux problèmes que j’aurais pu regretter plus tard. Je peux l’annoncer fièrement : quand je lance rcov, j’obtiens

Loaded suite /usr/bin/rcov

Started

.............

Finished in 13.016636 seconds.13 tests, 320 assertions, 0 failures, 0 errors

Puis : résultat final
Je rajoute bien entendu la partie concernant rcov à la page Intégration continue Ruby on Rails.

Un nouveau plugin Rails vient de sortir ces derniers jours : c’est un plugin qui permet d’annuler n’importe quelle commande de génération. Pour ma part, je pense que c’est vraiment quelque chose qui manquait à Rails. Voyons comment l’installer :

ruby script/plugin install svn://rubyforge.org/var/svn/beyondthetype/undo_generator_plugin/trunk

Maintenant, testons ce petit bijou :

ruby script/generate model users
      create  app/models/
      create  test/unit/
      create  test/fixtures/
      create  app/models/users.rb
      create  test/unit/users_test.rb
      create  test/fixtures/users.yml
      exists  db/migrate
      create  db/migrate/001_create_users.rb

Diantre, une erreur ! Il ne faut pas mettre de “s” pour générer un modèle ! Heureusement, le plugin undo est là :

ruby script/generate undo
Undo: "script/generate model users"  [yn]? y
    notempty  db/migrate
    notempty  db
          rm  db/migrate/001_create_users.rb
          rm  test/fixtures/users.yml
          rm  test/unit/users_test.rb
          rm  app/models/users.rb
       rmdir  test/fixtures
    notempty  test
       rmdir  test/unit
    notempty  test
       rmdir  app/models
    notempty  app

On n’attend plus qu’une chose, que ce soit intégré dans Rails :p

Selenium est un outil puissant d’automatisation des tests unitaires bien connu des développeurs web. Il existe un moyen d’intégrer cet outil dans des projets Rails, c’est pourquoi j’enrichis aujourd’hui ma page “Intégration continue Ruby on Rails” avec une étude du plugin en question, et avec la réalisation d’un petit TP. Allez, sélénisons ensemble !

Bonjour, comme vous avez pu le constater, j’ai pris mon quota de vacances, et cela fait longtemps que je n’ai pas écrit un petit billet. En fait, j’ai du mal à me dire que l’été est déjà presque fini alors qu’en fait, on ne peut pas dire qu’il  ait vraiment commencé…

Si je fais un billet aujourd’hui, c’est pour vous parler d’un service de hosting Ruby On Rails gratuit qui gagne à être connu. Faisant partie des bêta-testeurs, je peux vous dire que liveror est valable. Certes, à l’heure actuelle le site est un peu soft, les outils pour manipuler les comptes sont un peu légers, mais l’équipe du site va jusqu’à vous demander par mail si votre déploiement s’est bien déroulé, et des outils supplémentaires sont en cours de développement. Après ça, que demande le peuple ?

Je vous engage fortement à vous inscrire, ils ont même un service un peu plus intéressant, il vous faudra par contre débourser 5 euros par mois dans ce cas là. Si liveror.com décolle, il se pourrait que bientôt  le service fourni soit très, très intéressant

A l’heure où tout le monde parle en sigles dans l’industrie informatique, je me devais de traduire quelques concepts. Certes, vous connaissez déjà certainement les AD (Agile Development), TDD (Test Driven Development), et autres XP (eXtreme Programming), mais connaissez-vous ceux-ci ?

Asshole Driven development (ADD)

N’importe quelle équipe où le plus gros connard prend les grandes décisions est de ce type. Toute sagesse, logique ou procédure disparait quand Monsieur Trouduc est dans la pièce, faisant de manière égoïste ce qui lui semble le mieux. Il se peut qu’il y ait des règles établies, mais Monsieur Trouduc s’en fout et les gens de l’équipe le suivent aveuglément (et oui, ça existe, malheureusement…).

Cover Your Ass Engineering (CYAE)

Ceci caractérise la force employée par chaque individu de l’équipe pour s’assurer que si le projet explose, ils ne s’en prendront pas plein la tronche.

Not My Problem (NMP)

Approche par laquelle toute décision/fonctionnalité/problème sont mystérieusement poussés vers le module de quelqu’un d’autre (non non, jamais entendu parler de ça auparavant… )

Blog Driven Development (BDD)

Consacré aux développeurs qui pensent constamment au sujet de leur prochain post. Presque chaque ligne de code intéressante qu’ils produisent finit en post sur leur blog.

Copy/Paste/Modify patterns (CPM)

Over-engineered Über-specified Development (OÜD)

90% du temps de développement est passé à outre-définir l’architecture, les interfaces de services, les exigences et autres choses qui ne verront pas le jour, car le projet avec trois années de retard a été annulé.

Budget Driven Development (BDD) : un de mes préférés

Le temps passé sur le projet est déterminé par le prix que le client va payer, non par le temps que doit prendre un tel projet. Cela mène généralement à des projets massivement sous-évalués. (jamais entendu parler de ce genre de pratiques ).

NKWYWUYSI (Not Knowing What You Want Until You See It) Design

On y a droit très souvent. La MOA sait qu’elle veut quelque chose mais elle n’est pas sûre de quoi, et donc il n’y a pas de cahier des charges, ou alors une feuille volante. Ce qu’ils veulent est communiqué à l’équipe de développement de manière très succinte, et à la fin du développement, le projet entre dans la phase NESD (Never Ending Story Development).

WAILDD - Worry About It Later Driven Development

Nous l’avons tous fait ! Cela s’applique surtout aux problèmes de performance et de proportionnement.

L’article de référence est ici, vous y trouverez d’autres sigles.

J’en rajoute un dernier, de ma propre expérience :

Développement de la pieuvre (DP)

Caractérise un projet dans lequel chaque sous partie (base de données, gros système, rédaction des dossiers de conception générale, et même sous traitement de certains développements) est à synchroniser. Quand les développements externalisés ne sont pas en retard, ils ont fait leur travail de façon très moyenne, et c’est très long à intégrer. Quand les programmes gros système sont disponibles, il ne respectent pas les normes et ne sont donc pas accessibles correctement. Quand des procédures stockées sont disponibles, votre user n’a pas les droits de les exécuter. Au niveau des dossiers de conception détaillés, on vous en demande beaucoup. On finit par le pompon, car la MOA relivre sans arrêt des modifications des dossiers de conception générale. Cela finit généralement par des projet TRES en retard. Non, je ne donnerai pas de noms