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

Le framework Ruby on Rails offre une panoplie importante de fonctions permettant de tester les controleurs de vos applications, que ce soit pour tester des accès par URLs ou des formulaires de saisie. J’ai donc enrichi à nouveau la partie tests de la page “Intégration continue avec Ruby on Rails”. Bonne lecture !

J’ai enrichi le dossier Intégration continue Ruby On Rails avec une partie sur les tests unitaires. Cette portion du dossier porte sur les bases des tests unitaires avec Rails, car les possibilités sont assez énormes. Pour toute la partie tests, je m’appuierai sur un super guide du site Ruby On Rails : A Guide to Testing the Rails. Bonne lecture.

Il est toujours bon de tester ses connaissances pour savoir ce que l’on vaut. Dans la droite lignée de ce précepte, voici un excellent site qui permet de passer des certifications, ou de répondre à des tests gratuits. Les tests sont tous orientés Java, mais il en existe un pour Ruby qui est très bien fait.

JavaBlackBelt

Pas mal…

Vous avez sûrement remarqué que ce blog a changé de peau pas mal de fois ces derniers jours… Cela est dû au fait que d’une part son contenu commence à être conséquent, et d’autre part, le nouveau design est bien plus compatible inter-navigateurs que le précédent.