Greg's blog

Et oui de retour après... longtemps. Plein de prévisions, quelques réflexions, plein de projets mais finalement peu de concret sur ce blog. Pourtant il s'est passé des choses depuis. Un nouveau design (quelques changements dans la css) pour changer et pour que vos ecrans consomment moins d'énergie. J'ai finalement mis django de côté, je suis de loin les évolutions qui touchent le projet et m'intéresse toujours aux questions techniques qui concernent le framework mais j'ai plutôt jeté mon dévolu sur des framework bases sur des langages fonctionnels comme haskell (HaPPS) ou scheme (PLT-Scheme Continue). Le distribué et notamment erlang et les framework Map/Reduce (Hadoop, Disco...) m'attirent également beaucoup. Mon intérêt se porte également sur la visualisation d'informations et l'intelligence artificielle (a un niveau basique).

Nouveau job : virtualisation, développement kernel / système et du python. J'ai pu redécouvrir le C++ avec un autre regard. Bien qu'il reste difficile d'avoir le même niveau d'abstraction que des langages comme haskell, ocaml ou scheme; c'est agréable d'avoir :

• un typage plus fort que le C,
• une utilisation la plus systèmatique possible de const (sur lequel g++-4.3 est assez rigoureux comparé a du C avec gcc-4.x)
• les references (pour éviter de passer des pointeurs non initialisés),
• les functions classes pour avoir un mécanisme plus sûr de pointeur sur fonction,
• les exceptions (avec la documentation des expressions susceptibles d'être levées par la fonction, dans son prototype i.e. int fonction(a, b, c) throw (runtime_error);
• les templates pour disposer de structures génériques (avec modération pour ne pas avoir un binaire trop avide de mémoire)

Ca ressemble à des prédictions sans en être :). Je ne suis pas voyant et les tendances que je perçois ou que j'attends sont liées aux domaines qui m'intéressent. Je ne vais donc pas m'essayer à prédire les grands évèments de 2008, mais plutôt énoncer ce que j'attends.

• Les langages fonctionnels vont réellement commencer à être utilisés. Par réellement, j'entends de manière moins confidentielle. L'exemple le plus frappant est l'utilisation d'Erlang pour le service SimpleDB d'Amazon AWS^[1]. Les capacités fontionnelles de certains langages^[2] très appréciés pour le développement agile comme Ruby et Python (pour ne citer qu'eux) sont indéniablement très pratiques et rendent plus productif (et plus succinct, exemple : les list comprehension en Python). Le style fonctionnel dans ces langages est partiel, on trouve en effet des effets de bord. Avec la vogue des architectures multicore et la nécessité de faire du calcul parallèle (distribué ou multithread local), les langages fonctionnels sont très adaptés. Une raison simple à cela, ils sont fondés (pour les langages fonctionnels purs c'est même imposé) sur l'absence d'effet de bord. Par conséquent la concurrence est implémentée avec des processus qui ne partagent pas de mémoire et communique de manière asynchrone par passage de messages. C'est le style fonctionnel qui amène à cela. On trouve une bonne illustration de ce principe dans une description d'Erlang et de la raison de son succès récent What's all this fuss about Erlang? par Joe Amstrong.
  

C'est toujours difficile de choisir un langage de programmation quand on se lance dans un projet. Plusieurs approche se présentent : choisir celui qu'on maîtrise le mieux d'où la proéminence du C/C++, .Net, PHP et Java; choisir celui pour lequel on aura le plus de contributeurs ou développeurs à embaucher (qui a parlé de Java ?? ;) ); choisir les langages les plus appropriés pour traiter chaque composant du projet. hmmm oui vous avez bien lu LES langages. Alors bien sûr en pratique ça finit souvent par un langage, mais il n'est pas proscrit d'envisager l'utilisation de plusieurs langages. C'est d'ailleurs ce que pas mal de projets font déjà depuis longtemps en ajoutant la possibilité d'utiliser des langages de scripts^[3] dans les applications. Paul Graham mets en avant ce choix dans son essai Beating the Averages. Certains y voit l'apologie de Lisp, j'y vois surtout la mise en exergue de ce qui constitue un des avantages majeurs d'une startup sur ces concurrents : le socle technologique. Il faut batir sur de bonnes fondations, celles qui permettront de ne pas perdre de temps et de répondre à la demande. "Faut qu'ça scale!!!". Les gens qui créés des entreprises sont souvent intelligents et l'équipe technique compétente. Ce qui va faire la différence, outre les choix stratégiques, sont les choix qui vont permettre d'aller plus vite et de faire mieux. Ca n'empêche pas d'avoir des startups qui marchent en utilisant du Java, mais certains, comme Frank Sommers, se posent des questions sur l'utilisation du langage dans l'efficacité d'un framework How Does Language Impact Framework Design?. Le seul élément qui n'est pas extensible c'est le temps. Ensuite la grosse question est qu'est-ce qu'un bon langage ? Qu'est-ce qu'une bonne technologie ? Et la chacun a sa réponse en fonction de ses besoins, de son expérience et de son humeur. The Hundred-Year Language de Paul Graham^[4] est une réflexion parmi d'autres sur ce point.

• Comme cela a déjà commencé, les outils, APIs et protocoles permettant la réalisation applications web riches (RIA) vont être plus en plus exploitées à des fins malicieuses. Exemples avec flash: Flash UPnP Attack FAQ et Hacking the Interwebs, et Ajax (déjà traité en 2007 dans la plupart des conférences sécurité). On surveillera d'ailleurs les travaux du W3C sur le Same Origin Policy, Access Control for Cross-site Requests, commenté Browser Security Gets Even More Confusing (Cross-site Request Draft) par Justin Schuh, et traité dans cet article Shaping the future of secure Ajax mashups sur IBM DeveloperWorks.

• Le logiciel libre sur l'embarqué grand public et les téléphones mobiles va se généraliser : Google Android, OpenMoko, The BUG (qui a été gratifié d'un CNET Award au CES et massivement couvert par la presse spécialisée récemment). Je me demande comment va réagir Archos au projet OpenPMA. Soit ils le font ala Apple en essayant de tout vérouiller - ce serait vraiment moche -, soit ils décident de créer une communauté autour de leur produit et de leur plateforme logiciel. C'est un modèle économique différent car actuellement ils vendent des plugins et ouvrir la plateforme logicielle permettrait d'avoir des alternatives à leurs plugins propriétaires et donc ne pas les acheter. Cela peut constituer un pari intéressant sur l'innovation et permettre de rattraper le retard d'Archos sur Apple notamment sur la partie interface utilisateur -- pour le reste difficile de parler de retard. J'aimerais bien un PMP qui sache lire le MKV !

Ce billet est une tentative de réponse à la question soulevée par GML, Le web gratuit a-t-il un avenir ?. Après éclaircissement de sa part, je me suis rendu compte que j'avais mal compris l'hypothèse qu'il avançait. Je vais essayer de reprendre dans le bon sens ici :).

If you have adopted agile development methods, or even just interested in them, Dr. Dobb's published an article Test Driven Development: Does writing software backwards really improve quality? where they tried to evaluate if Test Driven Development (TDD) really improves code quality. The article shows that TDD helps to have less critical (none where found by the QA in the article's case) bugs and less bugs in general. The developer's feedback - the one who wrote the code used in the evaluation - is worth the reading:

• The TDD code was refactored several times during development. Methods were created, then changed, and then changed again with each revision, resulting in code that was tighter or clearer. The developer felt like the code went through an extensive proofreading cycle similar to what is done for newspapers, magazines, or the like.
• There was a freedom of experimentation that led to better design decisions. Once the first working version of a class method was completed and properly tested, the developer could then try new design ideas. The unit tests quickly confirmed or denied that the new code worked, providing a digital safety net.
• On a number of occasions, the developer found that the TDD method forced him to slow down and think more carefully about what he was trying to accomplish. Rather than just banging out code to get the job done, he focused on writing high quality code.

This encourage me to try it in my current projects :). As they say in the introduction, writing tests before the code is not so natural ;) at first sight, but it could be fine to spend less time on bug squashing by taking some additional time to write the unit tests before.