Haskell, demander l’enfer (ou pas)

Régulièrement à Octo, on organise des dojos, des séances d’entrainement pour coder. On a pu réaliser un jeu de la vie en javascript, faire un peu de BDD avec rSpec. Un jour on s’est dit mais pourquoi ne pas essayer un langage purement fonctionnel ? Comme on a plusieurs fan d’Haskell dans nos murs, nous avons choisi celui-ci.

C’est comme ça que nous avons organisé notre premier dojo en Haskell. Et aussi étrange que cela puisse paraître, nous avons réussi à dompter ce langage à la syntaxe et au paradigmes étranges, pour nous développeurs objet.

Regardons plus en détail ce que nous avons fait et appris.

Lire la suite

Faut-il supprimer la MOA ?

Chez OCTO, avant de publier un article, on effectue une revue interne. Et il faut dire que cet article a lancé un grand débat. Il y a eu deux camps : ceux qui pensent que ce n’est applicable que sur les projets innovants, et ceux qui pensent que c’est applicable sur tous les types de projet.

Et vous qu’en pensez vous ?

Disclaimer : Nous allons parler du rôle MOA, pas des personnes de la MOA. De plus, nous parlons ici de la MOA informatique « classique », pas de l’expert fonctionnel/métier (le business analyst hors de nos frontières).

Le nom MOA nous vient des métiers du bâtiment. Elle représente l’entité porteuse du besoin, définissant l’objectif du projet, son calendrier et le budget consacré à ce projet (source Wikipédia). En informatique, elle représente les sachants fonctionnels : ceux qui connaissent les utilisateurs/le métier et qui retranscrivent le besoin en texte compréhensible pour la MOE, nous informaticiens.

Ce rôle dans un projet est-il vraiment encore utile, surtout au vu des nouvelles méthodologies Agile et Lean ? N’oublions-nous pas un peu rapidement le vrai but d’un projet informatique : rendre les utilisateurs plus efficaces dans leurs tâches (ou sur le web : améliorer la vie des utilisateurs).
Lire la suite

La technique au service du Lean Startup

À ChooseYourBoss, un site d’emploi informatique, on fait du Lean Startup. Plus précisément, on applique la méthode du Build-Measure-Learn (Construire – Mesurer – Apprendre). Tous les jours on construit notre produit, on l’améliore. Mais une partie importante de celui-ci est un logiciel que l’on développe.

Bien évidemment tout ce que l’on développe est au service du produit ou de nos clients.

Notre but étant d’apprendre le plus possible et surtout le plus vite possible, nous avons mis en place un certain nombre de pratiques qui nous aident. Ce sont des pratiques tout ce qu’il y a de plus classique. Mais mises ensemble elles nous permettent de nous améliorer. Nous allons donc vous les décrire succinctement.

Lire la suite

Paris Scala User Group @Octo, le 26 septembre

La prochaine session du Paris Scala User Group (PSUG) aura lieu le mercredi 26 sept à 19h15 à Octo.

Pour cette session vraiment exceptionnelle, Mathieu Poumeyrol nous fera une présentation et retour d’expérience sur la stack logicielle qu’ils utilisent chez fotopedia.

En substance il sera question de l’utilisation de scala avec unfiltered, salat et MongoDB, ainsi qu’un parallele avec la stack Varnish / Rails / MongoDB.
Pour ceux qui ont vu Mathieu à Devoxx, cette présentation sera enrichie par la partie unfiltered/scala et bien entendu nous auront la possibilité d’échanger en live avec Mathieu et discuter par la suite autour du buffet.

Penser à vous inscrire (pour la logistique) : http://www.doodle.com/n4v55i3c3xtqcu2x

Lieu :

50 avenue des champs élysées
75008 Paris

5 ème étage

Performance côté client avec Rails & Heroku

À ChooseYourBoss on développe une appli web tout ce qu’il y a de plus classique : HTML5, JS, CSS3 + quelques API (Linkedn, Viadeo, Google Maps, Google Analytics, etc). Côté serveur on est en Rails sur Heroku. Bref, rien d’exceptionnel quoi.

Puis un jour, on a jeté un œil sur le graphe de temps de chargement de notre appli – merci Google Analytics. Et là le drame : une moyenne de plus de 5 secondes pour la page d’accueil, et je ne vous parle pas sur mobile. On se dépêche alors d’aller faire un petit tour sur Google Pagespeed, notre score : 44/100 (bof bof).

On décide d’investiguer point par point nos hypothèses, en voici un résumé.
Lire la suite

Comment ne plus avoir de NullPointerException en Java ?

NullPointerException : l’erreur la plus courante dans un programme Java. On est tous à un moment ou à un autre tombé sur cette exception. Malheureusement, ce n’est qu’en production à 4h du matin qu’elle arrive. On corrige donc le bug suivant :

MonObjet monObjet = null;
…
monObjet.maMethode(); // => NullPointerException

Par un rapide :

if(monObjet != null) {
  monObjet.maMethode();
}

Ce correctif est tout à fait honorable, mais pourquoi ne pas essayer de ne plus avoir aucune exception de ce type ?

Il existe plusieurs méthodes validées par le compilateur pour l’éviter, et donc avant la mise en production. Aucune n’est nouvelle, certaines controversés, mais elles sont toutes étudiées dans la suite de cet article.

Lire la suite

Tests par propriétés

Vous êtes déjà un expert TDD, votre application a une couverture de tests de plus 80%. Mais vous avez le sentiment que tout n’est pas testé, qu’il reste d’obscurs cas que vous n’arrivez pas exprimer.

Pourquoi ne pas demander à un programme de vous aider à tester ?

Vous pouvez déjà passer par le mutation testing. Cette méthode donne une première approche, mais il en existe une autre : les tests par propriétés.

Cette méthode se résume à exprimer des propriétés et de laisser un programme la vérification de celles-ci.

C’est une façon de tester qui provient des langages fonctionnels et donc qui peut paraître étrange si on vient du monde objet « classique ».

Donc regardons plus en détail son fonctionnement et à quoi elle pourrait servir.
Lire la suite

Rails += Tests

Si vous avez déjà créé une application Ruby on Rails, vous avez déjà dû voir un étrange répertoire : tests.

N’ayez pas peur, tout a été fait pour faciliter la mise en place de tests de bout en bout avec Rails.

Je vais donc vous donner les méthodes que j’apprécie et que je considère efficaces pour l’écriture de tests en Rails. Que vous soyez novices ou expert, j’espère pouvoir vous en apprendre un peu.

Tous les exemples donnés seront pour Rails 3, mais ils sont pratiquement tous compatible Rails 2.

Le code source des exemples est disponible sur ce github.

Lire la suite