Récemment un papier d’étude de Google UK a été publié sur la performance des langages de programmation JAVA, Scala, C++ et Go (Loop Recognition in C++/Java/Go/Scala). Dans ce papier, les performances des langages sont comparées sur la base d’un algorithme de recherche de boucles dans un graphe (Algorithme de Tarjan).

Principalement basé sur la performance d’exécution d’instructions séquentielles (boucles), la gestion de la mémoire, le temps de compilation et le nombre de lignes de code écrites cette étude montre que pour arriver à des hautes performances en C++ les optimisations techniques (au niveau du langage) deviennent trop compliquées pour le résultat produit. Comme le dit Robert Hundt :

We find that in regards to performance, C++ wins out by
a large margin. However, it also required the most extensive
tuning efforts, many of which were done at a level of sophistication
that would not be available to the average programmer.

Cependant, cet article a été critiqué sur son use-case peu pertinent et sur la validité des résultats. Quand même, C++ est le ++ fort ! Bien qu’il ait été maladroit, ce cher Robert a soulevé un point très intéressant : la programmation haute performance n’est-elle réservée qu’à une élite de développeur C++ ? Le développeur moyen peut-il espérer développer des applications haute performance ?

(Lire la suite…)

Users really respond to speed

La citation est de Marissa Meyer, VP expérience utilisateur à Google, en 2006.

Pas grand chose n’a changé depuis, si ce n’est qu’on a des chiffres plus précis, et un peu effrayants, sur l’importance de la performance dans les applications web : Quelques points de performance feront la différence entre une expérience réussie et une application perçue négativement par ses utilisateurs.

Ou plutôt si, ce qui a changé c’est que depuis 2006 on ne se contente plus de sites web, les applications web ont envahi les entreprises et leur SI. Il devient donc primordial de faire attention aux spécificités des applications web : On ne traite pas un navigateur comme un client lourd. (Lire la suite…)

Il y a peu, je participais à une réunion de travail impliquant une trentaine de personnes et j’ai fait une observation qui m’a intrigué. Avez-vous remarqué ce qui se produit lorsqu’un téléphone portable sonne au cours d’une réunion ?

• La personne propriétaire du portable l’éteint rapidement
• Tous ceux qui ne l’avaient pas encore fait vérifient leur portable et activent discrètement le mode silence.

Voilà un exemple de mesure préventive particulièrement efficace! Dans les entreprises où l’on respecte un certain standard de réunion, l’exception que constitue la sonnerie d’un portable ne se produit qu’une seule fois, pas deux. La première “infraction” protège le groupe de toute nouvelle occurrence. Elle agit en quelque sorte comme un “vaccin” sur le fonctionnement du groupe en réunion.

Quelles conditions faut-il réunir afin de créer d’autre vaccins de ce type au sein d’une équipe ? (Lire la suite…)

Cela fait maintenant 3 mois que le projet Natal est devenu une réalité sous la forme d’un accessoire pour la console de jeu Xbox 360 : La Kinect.

Cette technologie de caméra 3D n’est pas nouvelle, mais elle était jusqu’ici réservée à un petit groupe de passionnés travaillant soit dans les laboratoires de recherche soit dans de rares entreprises innovant dans ce domaine. Depuis 3 mois tout ce petit monde est en effervescence et cette communauté d’utilisateurs a explosé ! En produisant sa caméra 3D en masse, et en l’équipant d’un port USB exploitable par le plus grand monde (Mac, Linux, Windows et même PS3), Microsoft a rendu accessible cette technologie jusqu’ici couteuse et confidentielle à tous. C’est ainsi qu’une équipe du MIT a remplacé un couteux matériel par un simple accessoire de 150$ disponible dans tous les magasins !

Voici les dernières nouvelles à propos de cette fameuse Kinect :

• Microsoft a passé la barre des 10 millions kinect vendues au début du mois (en 3 mois ½ donc). Pour rappel, la kinect est entrée dans le Guiness des records en janvier pour « l’appareil électronique de grande consommation qui s’est vendu le plus rapidement de l’histoire » (8 millions en 60 jours)
  Article sur guinnessworldrecords.com

(Lire la suite…)

L’Agile est aujourd’hui un outil puissant d’amélioration de la qualité des produits et de la satisfaction des acteurs, utilisateurs comme artisans du système d’information.

Si la méthode commence à être connue, sa mise en œuvre peut néanmoins se heurter à des difficultés, notamment sur le volet contractuel.

Ainsi, dans les organisations où les pratiques d’achats reposent sur une définition exhaustive des besoins (i.e. cahier des charges) et une obligation de résultat portant sur un périmètre figé et qui ne peut évoluer qu’à l’aide d’avenants, il est souvent difficile voire impossible de concilier ces pratiques avec les principes fondamentaux de l’Agile à savoir : autoriser le changement, affiner et spécifier les fonctionnalités au fil de l’avancement du projet pour répondre mieux aux besoins des utilisateurs.

Alors que faire ? Comment concilier des principes d’achats bien rodés mais a priori antagonistes avec les principes de projet Agile ? Peut-on faire évoluer ces principes ? Chez OCTO, nous avons la conviction qu’il existe des moyens d’y parvenir en respectant les contraintes et les enjeux de votre entreprise.

Nous vous proposons d’échanger avec vous sur ce thème et pourquoi pas vous accompagner dans un travail en profondeur sur vos pratiques d’achats et de contractualisation.

Pour commencer nos échanges, nous offrons 2 séances de travail de 2h gratuites au 3 premières entreprises qui nous contacteront.

Contactez-moi pour cela sur ymartel@octo.com et travaillons ensemble à améliorer un peu plus votre ingénierie informatique!

Travaillant avec les technos Web, j’ai souvent été confronté à Javascript.
Java-iste dans l’âme, j’ai été un peu rebuté par ce langage interprété (non compilé), faiblement typé, basée sur la notion de prototype (donc sans classe !)… bref, trop souple pour être vraiment sérieux !

Si on ajoute à cela qu’il existe un moteur par version de navigateur (actuellement on a Chakra chez IE9, V8 pour Chrome, TraceMonkey chez Firefox3.5, SquirrelFish pour Safari ou encore Carakan pour Opera10…) ce sont les maux  de tête assurés !

La solution: le TDD !
Cette méthode de développement est une bonne façon d’avoir un retour rapide sur son code et ainsi, de compenser le côté « non-compilé » de Javascript.
De plus, les tests unitaires sont particulièrement importants lorsque le typage est dynamique (comme c’est le cas en Javascript, mais aussi en Ruby, Groovy, Python, etc.). Dans ces environnements, c’est le harnais de test produit par le TDD qui permettra au développeur d’avoir la confiance suffisante pour faire du refactoring.

Il existe de nombreux frameworks de tests unitaires Javascript. On retiendra en particulier QUnit (l’outil de tests officiel de JQuery), Jasmine (orienté BDD et successeur de JSunit, le pionnier, sorti en 2001) ou encore le YUI Test de Yahoo.
Dans cet article, je vous présenterai JsTestDriver.
(Lire la suite…)

Uniformiser vos environnements de développement – Gagner en productivité

Marre des merges galères pour cause de formateurs différents ?

Ce tip & trick est pour vous !

Merci à Julien et Olivier qui ont présenté Spring Batch hier au JUG de Lausanne devant un public restreint mais avec beaucoup de discussions et de questions à la clef.

Les slides de la présentation sont disponibles sur le site du JUGL :

Rendez-vous le mois prochain pour parler de performance en Java avec Ludovic Poitou qui nous fera un retour d’expérience sur l’optimisation d’OpenDS. Vous pouvez d’ores et déjà vous inscrire ici, la présentation aura lieu le jeudi 9 décembre à Lausanne.

Cet article s’intéresse aux principes de développement qu’implémente la librairie jQuery Mobile pour offrir des sites Web adaptés aux terminaux mobiles, afin d’en tirer des enseignements pour nos propres développements mobiles, utilisant cette librairie ou non.
Nous entendrons ici par Web Mobile les sites et applications Web pour les tablettes et tous les téléphones portables supportant le Web, depuis les premières version de Symbian S60 jusqu’aux derniers iPhone et Android.
(Lire la suite…)

Groovy / Grails est une bouffée d’air frais pour le programmeur Java, vous permettant d’écrire du code plus expressif et plus lisible, sans les lourdeurs de Java ou de JEE. Groovy vous simplifie également la vie en vous épargnant les écueils classiques du programmeur débutant ou distrait (BigDecimal, equals(), etc…). Ce n’est pas pour autant suffisant pour s’assurer de la qualité du code délivré et il vous faudra là aussi un ensemble de pratiques pour garder un code maintenable malgré les ajouts et évolutions.

Une de ces pratiques est l’analyse statique de votre code source via des métriques et des règles, et la surveillance de leur évolution d’une version sur l’autre, ou de manière plus ciblée pour une version particulière. Dans ce domaine le programmeur Java est sans aucun doute l’un des mieux outillés, avec des outils comme PMD, FindBugs, CheckStyle, XDepend, Sonar etc… Qu’en est-il en Groovy / Grails ? (Lire la suite…)