WebCamp Québec 2012 - Freaks

Le 17 mai 2012 à l’ENAP, il y a eu la 4ième édition du WebCamp de Québec.

C’était ma première expérience de ce type de rencontre plus ou moins formelle de mini-conférences sur le thème du Web. Il y avait 3 salles du niveau général, niveau intermédiaire (geeks) et niveau expert (freaks). Je me suis concentré que sur la salle des freaks.

La matin, en première partie, on a abordé des problèmes de gestion de contrôle des versions. Voici quelques affirmations que j’ai retenues:

  • Git est le grand « gagnant » de la guerre du contrôle des versions (contre SVN principalement).
  • Gitstack est un serveur Git pour Windows.
  • Tortoise HG est un client Git pour Windows.
  • Il existe un module de comparaison d’images.
  • Git n’est pas un outil de gestion documentaire.

Par la suite, le sujet du déploiement « idéal » a été longuement discuté. Je n’y connais pas beaucoup dans ce domaine mais je reconnais que c’est un sujet important parce que la structure de déploiement est importante pour un bon développement (pour éviter les interruptions de service et permettre les retours en arrière). Dans les discussions, on mentionne le lien entre Git et les notions de déploiement. On a discuté du schéma « classique » qu’on retrouve ici. On a discuté de l’interaction (au sens large) des différentes branches du développement comme feature, develop, hotfix, release et master.

Par la suite, il a été question d’hébergement du code comme github.com qui était intéressant pour les développeurs. Il a été mentionné que les gestionnaires sont souvent craintifs à l’utilisation pour des questions de droits d’auteur ou de vol d’information.

L’outil Fabric pour le déploiement du code sur des serveurs SSH. Capistrano est un autre outil de déploiement Web installé sur un serveur (long à configurer sur un serveur mais on gagne du temps à long terme) et gère le transfert vers d’autres serveurs Web. Capistrano peut être utilisé en collaboration avec Github. Cssh a aussi été mentionné.

Par la suite, l’outil de gestion de métriques Sonar a aussi été abordé. Il y a des comparaisons à faire avec PHP Codesniffer qui est un outil d’inspection des standards de programmation PHP. Pour Java, on retrouve aussi l’outil PMD qui semble intéressant.

Le développement mobile a été discuté du point de vue du déploiement. Les gens d’expérience dans ce domaine ont exposé leur expérience en expliquant que la mécanique du déploiement n’est pas bien avancé et que rien n’est automatisé même sous la plate-forme Android. Certains frameworks ont été mentionnés comme Appcelerator avec Titanium (pour Javascript) et PhoneGap pour le développement HTML5.

Après la pause en après-midi, la question du contrôle des versions pour les bases de données a été une bonne discussion. Le « versioning DB » n’est pas évident parce qu’il n’y a pas de solution évidente. Les développeurs en Ruby on Rails ont parlé de leur expérience. Étant donné que la création, la mise à jour et la suppression des tables et des données se fait par programmation sous Rails, il est possible d’utiliser le contrôle des versions du code pour la base de données. Cela fonctionne très bien apparemment. Une personne a mentionné qu’il existe un outil Oracle pour le contrôle des versions sous Oracle.

Ensuite, il a été question du nouveau « buzz word » dans l’entreprise: dev ops. Ce terme ne désigne pas un conseiller en architecture organique mais un titre de responsable de la qualité sans avoir les pouvoirs décisionnels, position plutôt embêtante. C’est un poste entre développeur et administrateur système.

Le sujet suivant a été les technologies NoSQL. Il y a mention du théorème du CAP d’Eric Brewer qui indique que tout système distribué (comme les SGBD NoSQL le sont souvent) peut répondre aux 3 contraintes suivantes: cohérence (les mêmes données au même moment), haute disponibilité (en cas de panne, les données restent accessibles) et tolérance au partitionnement. Les SGBD Cassandra (Facebook, Twitter), MongoDB, BigTable (Google) et CouchDB. Oracle est plutôt critique et c’est un effet de mode.

Il y a eu quelques discussions sur les méthodes Agile. Un intervenant a mentionné son expérience de la méthode Kanban qui a dit simple à suivre. Il la recommande.

En après-midi, une assez longue discussion sur Javascript a pris une bonne part. Il a été question des engins Javascript existant comme Spydermonkey, V8, etc. Les librairies de type Backbone.js, Underscore.js, Ext.js et Prototype.js ont été mentionnées. Le nouveau langage de programmation Dart développé par Google qui génère du Javascript qui se veut un possible remplaçant au kit de développement Web GWT. OPA, le nouveau langage de programmation de développement d’applications distribuées est inspiré de Javascript. C’est un projet prometteur. Le nouveau protocole expérimental de Google SPDY a été mentionné. Le but est d’augmenter la rapidité et la sécurité des transferts pour Chrome et Firefox.

En dernière partie de la journée, les langages de programmation applicatifs ont été comparés. On a discuté des langages PHP, Ruby on Rails, Python et Erlang/Haskell. Malheureusement, j’ai perdu mes notes pour cette partie mais un concensus est ressorti sur quelques éléments:

  • PHP est un langage limité en terme de gestion des processus légers mais il est simple et facilite la programmation Web.
  • Le développement de PHP semble plafonner. La sortie de PHP 6 est retardée et n’apporte pas grand chose de vraiment motivant.
  • Les frameworks et CMS sous PHP sont matures et donc, à ne pas négliger malgré la ‘vieillesse’ de PHP.
  • Les langages alternatifs comme Ruby on Rails/Python sont intéressants mais ne se démarquent pas.
  • Il y a un certain intérêt à faciliter le développement en Javascript ou vers Javascript (conversion). Il a été question de JQuery qui augmente en taille.
  • Le protocole HTTP est analysé pour l’optimiser (Google SPDY).

Voilà ce que j’ai retenu de cette rencontre très intéressante.