Catégorie : Développement

Publié le

L’aventure Karnott, 2 ans déjà !

L’an dernier, j’avais déjà écrit un premier article racontant mes 12 premiers mois chez Karnott. Cette année, je voulais réitérer l’expérience, histoire de faire le point sur ce qui a été accompli, nos réussites et nos échecs. J’ai beaucoup cogité, ne sachant par où commencer, et je suis tombé sur ce tweet :

L’article pointé apparait comme une évidence aujourd’hui, mais ça ne l’était pas il y a un an.

Remise dans le contexte

Juin 2018. Equipe constituée de 3 développeurs, dont moi. Nous avions commencé à prendre le virage de « la data », ce qui voulait dire être capable de la stocker, la traiter, la partager. Autant dire que les 3 sujets sont très propices à l’over-engineering. En août et septembre 2018, nous nous sommes renforcés avec 2 personnes de plus, expérimentées. Plutôt Backend et Devops, avec l’objectif de sécuriser notre plateforme.

Techniquement, où en étions-nous ?
Une API redéveloppée en Golang, de l’intégration continue qui produit des JARs, du Ruby, du Go, du JS, et des scripts bash de déploiement sur des VMs plus que fragiles. Pour notre Devops, le premier chantier tombait sous le sens : rationaliser notre déploiement continu, et plus globalement, notre hébergement.

Choix technique, scalabilité et résilience…

A J+500 dans ma vie de CTO chez Karnott, Il était temps de faire l’un de ces fameux choix critique qui impacterait notre façon de travailler, mais aussi notre SRE, le cout de notre infra (et donc le modèle économique de l’entreprise), et qui restera surement plusieurs années : passer sous Kubernetes et Google Cloud Platform.

J’entends d’ici les critiques classiques : « c’est pour la hype, vous n’en n’aviez pas vraiment besoin, vous avez introduit plus de problèmes que vous en avez résolu… ». Reprenons le cahier des charges que nous nous étions fixés :

  • Avoir un DSL décrivant nos services et notre infrastructure (même si bon sang, le YAML…)
  • Uniformiser la façon dont nous déployons tous nos services
  • Gérer du 0 downtime pendant nos montées de version
  • Avoir une façon simple de monitorer et gérer la montée en charge
  • Ne pas avoir à se soucier de la captation de logs, et être capables d’en générer des métriques simples (ai-je des erreurs sur l’un de mes services ?)
  • Pouvoir profiter de services managés si besoin, et ne rien s’interdire techniquement (capacité à faire un POC rapidement dans une nouvelle techno)

Et franchement, la stack choisie a répondu à toutes nos attentes. La mise en place a été très rapide (moins d’un mois à mettre en place, avec la dockerisation de nos services), même si, avec le recul, trois éléments ont facilité la migration :

  1. La base de données n’est pas « Kubernetisée », mais gérée à côtée.
  2. Nous n’avons aucune problématique réseau compliquée, tous nos messages internes transitant à travers Google Cloud PubSub
  3. La personne de l’équipe qui a mis tout ça en place, David, avait l’expérience pour le faire

La conception produit et les interrogations

D’un point de vue technique, le reste de l’année a été consacré en grande partie à l’amélioration de notre scalabilité dans la gestion de la flotte de Karnott. Cela revient à améliorer notre capacité à stocker, transformer, visualiser la donnée, mais aussi améliorer notre gestion du support pour fournir les bons outils à l’entreprise pour diagnostiquer au plus vite le moindre soucis. Ces problématiques seront toujours un fil rouge chez Karnott, et mériteraient pas mal d’articles pour parler de la vente d’objet physique à l’échelle d’une startup… (Coucou Amaury, Guillaume et Georges !)

ça commence à avoir de la gueule non ?

Et la création produit dans tout ça ?

Revenons-en au développement de l’application Karnott, que nos clients utilisent tous les jours.
Lors de la première année, nous avons développé une application.
Lors de cette seconde année, nous avons essayé de développer la bonne application.
Mais encore ? C’est maintenant que je vous renvoie à l’article cité premier paragraphe. Nous n’insisterons jamais assez sur le fait que pour construire le bon produit, le développeur en startup doit être pragmatique, ne pas avoir peur de s’approprier le métier, et faire parfois des concessions sur la technique pour satisfaire un besoin urgent, que l’on ne comprend pas toujours, ou que nous aurions souhaité différer pour X raisons. Oui nous introduisons tous les jours de la dette et je suis persuadé qu’il est important de le faire. Finalement, nous ne faisons que caler notre modèle sur celui de la startup. Ce n’est pas de la dette, mais de l’investissement, qui nous permet d’avancer.

Mais est-ce vraiment le BON produit ?

C’est la grande question. Comment éviter la surcharge featurale ? L’empilage de fonctionnalités en espérant que cela convienne ? Cette seconde année, nous avons pris le parti de prendre un maximum d’initiatives. Concrètement, chaque développeur a travaillé main dans la main avec nos différentes équipes : Customer Success et support ( <3 ), l’équipe commerciale, l’équipe marketing, le Design, et bien entendu nos fondateurs pour garder la vision d’un produit utile et simple, profondément ancrée dans l’ADN de l’entreprise. Cela passe aussi par une réflexion UX de tous les instants. Un résultat simple implique toujours une conception compliquée.

Quelques choix forts de l’année : nous avions absolument besoin d’une présence sur les stores Android et iOs, ce qui a amené une nouvelle stack technique chez nous ( React Native). Autre exemple qui peut paraitre anecdotique, un client, ça n’aime pas le CSV. Quand on lui fait télécharger un export, c’est du format excel obligatoirement ! Nous avons aussi fait de la dataviz autour de la Geodata et expérimenté des choses rigolotes…

D3js, leaflet, de la donnée sympa, et on peut faire de belles choses !

Bilan

Le bilan de cette seconde année, c’est que nous sommes fiers du travail accompli. Maintenant pour passer un cap, et continuer à construire le bon produit avec toute la connaissance métier et client accumulée, nous savons que nous avons besoin de nous structurer différemment. Cela passe par le recrutement obligatoire d’un Product Owner / Product Manager (poste ouvert!) qui sera le pivot de l’entreprise, le carrefour entre toutes les approches clientes différentes. Mettre sur papier les persona, les obstacles et les opportunités, prioriser, analyser plus profondément les besoins et la pertinence de chacun, c’est notre limite d’aujourd’hui. Les besoins en UX sont aussi très présents. Comme je l’ai évoqué, nous attachons beaucoup d’importance à la simplicité du produit. Cela passera aussi par le recrutement d’un UX à temps plein.

J’en profite pour mettre un petit lien vers notre page WelcomeToTheJungle, cette page donne un bon aperçu de nos différents corps de métier, et de la bonne humeur générale 🙂

Un dernier mot pour les développeurs qui auront travaillé chez Karnott cette année. François, Georges, David, Guillaume, Paul et Amaury. Développeur en startup, ce n’est pas jouer au ping pong et rigoler toute la journée… Cette année, il y avait de la solidarité, de l’envie, de la compétence et c’était vraiment chouette. Merci à eux.

A l’an prochain !
LB.

Publié le

Postgis, GeoJSON et approximations

Chez Karnott, nous usons et abusons de Postgis, cette extension PostgreSQL qui permet de stocker de nouveaux types géographiques et ajoute beaucoup de fonctions bien pratiques pour requêter en SQL dessus.

Pour bien comprendre, rien de mieux que leur exemple sur leur page d’accueil :

SELECT superhero.name
FROM city, superhero
WHERE ST_Contains(city.geom, superhero.geom)
AND city.name = 'Gotham';

On comprend tout de suite qu’une ville a une entité géométrique geom, qu’un superhero a une position, et qu’il est possible de requêter tous les superhero de Gotham.

L’une de nos dernières fonctionnalités avec Postgis, c’est d’avoir importé l’intégralité du parcellaire français (anonymisé) pour faciliter la vie de nos agriculteurs lors de la saisie de leur parcellaire chez Karnott. Ils n’ont plus qu’à faire clic clic dans l’interface, les parcelles étant déjà dessinées pour eux.

Mais côté technique, comment cela se déroule ? Comment représenter une parcelle agricole à travers une API ? Il y a beaucoup de formats et de standards pour représenter des polygones. Par homogénéité avec le reste de notre API, nous avons naturellement choisi de représenter tous nos objets géographiques en GeoJSON (RFC 7946) . Et pour cela, Postgis est plus que pratique !

SELECT ST_AsGeoJSON(field.geom) from field limit 1;

Par défaut, nous allons avoir quelque chose du genre :

{
    "coordinates": [
        [
            [
                0.584523334321845,
                42.9562400255637
            ],
            [
                0.585194166712806,
                42.9565556385987
            ],
            [
                0.586094811603247,
                42.9566130759021
            ],
            [
                0.586148521684631,
                42.9564425054839
            ],
            [
                0.584523334321845,
                42.9562400255637
            ]
        ]
    ],
    "type": "Polygon"
}

Vous remarquerez que les coordonnées sont fournies en Degrés Décimaux, et non en Degrés Minutes Secondes. Pourquoi pas. Cela dit, si l’API doit retourner une centaine de parcelles comme sur l’écran vu précédemment, la taille du JSON associé est trop conséquente. (Une parcelle contient rarement 4 points comme dans mon exemple, mais plutôt une 20aine!)

Se pose alors une question : Quel intéret d’avoir 15 décimales après la virgule ?

Nombre de chiffres après la virgule Equivalent en mètres
0 111.32 km
1 11.132 km
2 1.1132 km
3 111.32 m
4 11.132 m
5 1.1132 m
6 111.32 mm
7 11.132 mm
8 1.1132 mm

8 chiffres après la virgule : 1mm. Autant dire que 15 chiffres, ça n’a aucun sens!

Heureusement, Postgis vient encore à la rescousse. Pour 6 décimales, il suffit de demander…

SELECT ST_AsGeoJSON(field.geom,6) from field limit 1;
=>
{
    "coordinates": [
        [
            [
                0.584523,
                42.956240
            ],
            [
                0.585194,
                42.956555
            ],
            [
                0.586094,
                42.956613
            ],
            [
                0.586148,
                42.956442
            ],
            [
                0.584523,
                42.956240
            ]
        ]
    ],
    "type": "Polygon"
}

 

Et voilà une API qui a divisé sa taille par 2!

En Conclusion

Postgis est vraiment un outil puissant et pratique. En contrepartie, Postgis embarque avec lui toute la complexité du monde de la GeoData, avec son système de projection, ses transformations et ses approximations. Si nous avions un retour d’expérience à faire, c’est de bien lire la documentation de chaque fonction, et de ne jamais se fier aux valeurs par défaut.

Publié le

Un an en tant que CTO, retour d’expérience

Il y a tout pile un an, le 1er juin 2017, j’ai rejoint Karnott en tant que CTO.  Durant cette année passée, on m’a souvent posé la question suivante : « Mais finalement, un CTO dans une startup, ça fait quoi ? » J’avoue que je n’en savais pas grand chose, ayant travaillé pendant 10 ans principalement pour des grands comptes, et d’ailleurs je ne sais pas si il y a une unique réponse à cette question. Je vais juste essayer de faire un petit retour d’expérience, et raconter ce qu’il s’est passé durant cette année.

Mais revenons encore un an en arrière. En 2016, Antoine Dequidt et Alexandre Cuvelier, les deux fondateurs de Karnott, ont confié la concrétisation de leur idée à des développeurs de leur connaissance. Le truc quand on a une idée, c’est qu’on est très loin d’imaginer du premier coup le produit parfait. On ajoute à ça une pincée de développement au forfait, des spécifications fonctionnelles imprécises, et des technologies pas toujours adaptées, et on arrive à un projet qui fonctionnait tout de même, sans répondre totalement au besoin initial.

Je suis donc arrivé dans ce contexte. Mon premier job a été de m’approprier le projet, le fonctionnel, le code, et d’y mettre ma patte. Fiabiliser le bousin, mettre des tests, de l’intégration continue… Ce qui a toujours été super chez Karnott, c’est que dès le premier jour, j’ai eu la contrainte de devoir être au petit soin avec la prod’. En effet, nous avions déjà des utilisateurs, et même si certains jours cela démangeait de tout défaire pour repartir de zéro, il fallait se réfreiner, planifier, réfléchir, et prévoir des plans de migration. Avec le recul, je me dis que cette contrainte de la prod’ m’a aidé à concevoir un système plus solide et pragmatique.

Sur certaines parties, j’ai aussi compris que j’avais besoin d’aide. Typiquement je suis un très mauvais intégrateur web… Et j’en ai tiré la première leçon primordiale :

En tant que CTO, je n’ai pas la science infuse

Alors on s’est entouré. Tout d’abord avec de la prestation, des partenaires en qui nous avions confiance (Coucou Sfeir et Tymate <3 ), avec en parallèle la volonté d’embaucher une équipe de développeurs à embarquer dans l’aventure… Fin aout puis début octobre 2017 nous ont donc rejoint François, dev Front React, et Georges, Fullstack Ruby. 3 développeurs, avec 3 profils complètement différents. Il a fallu apprendre à se connaitre, et cela fit apparaitre la composante la plus importante de mon boulot de ces 12 derniers mois :

En tant que CTO, je m’assure de la cohérence de l’équipe et du projet

Je considère la cohérence humaine et technique comme intimement liée. La technique doit répondre à un besoin fonctionnelle et des contraintes (IOT, scalabilité…), mais dès le premier jour, nous étions tous d’accord sur le fait que tout le monde travaillerait sur l’intégralité de la stack. Il a fallu se mettre d’accord sur des technos que nous avions tous envie d’apprendre, avec lesquelles nous serions productifs. Le choix le plus significatif a été de refondre l’api en Golang. On pense ce que l’on veut du langage (à titre personnel j’aime beaucoup cet article de Sylvain Wallez qui résume bien ma pensée), mais il a eu le mérite de nous permettre de refondre une API complète en quelques mois, de résoudre nos soucis de performances et surtout d’être « facilement » maitrisée par toute l’équipe.

La mise en place d’une équipe, c’est aussi mettre sa casquette d’agiliste, et proposer tous les rituels qui nous permettent de partager et collaborer tous les jours. Daily Meetings, Rétro, Pull Requests systématiques, Sessions de Code Reviews… Si l’on veut travailler sur l’intégralité de la stack et ne pas risquer l’isolement de la compétence, ces étapes sont juste indispensables.

En parlant d’isolement, un autre risque est que l’équipe de devs s’isole du reste de l’entreprise. Chez Karnott, toute l’équipe commerciale est issue du monde agricole. La connaissance métier, c’est eux qui l’ont, et nous ne devons jamais l’oublier. Il est tellement facile de développer des fonctionnalités techniquement sympa, mais complètement à côté de la plaque… Alors voilà :

En tant que CTO, je m’implique dans la réflexion autour du produit

Si l’équipe commerciale vient du monde agricole, je ne leur ferai pas offense en disant qu’ils découvrent tous l’univers du développement d’une application Web. Alors toute cette année il a fallu apprendre à communiquer, qu’ils m’expliquent leur métier, et que nous leur expliquions le notre, et nos contraintes de développeurs. « Tout est possible, tout n’est qu’une question de délai et de priorités » a sans doute été la phrase que j’ai le plus répétée. Mais dev ou commerciaux, nous avons tous fait de notre mieux pour nous impliquer dans la construction du produit Karnott, et être au plus prêt de ce que nos utilisateurs réclamaient. L’arrivée prochaine d’un Product Owner devrait nous faire franchir une étape de plus en ce sens…

Et puis avec le temps et le succès commercial, les priorités et les contraintes changent. Très naïvement, je n’avais pas du tout anticipé cette partie là, mais Karnott est à une période charnière dans sa structuration et nous devons construire un SI d’entreprise. Automatiser la logistique, le monitoring, les prises de parole, la facturation, bref, tout ce qui fait que nous pourrons accueillir sereinement beaucoup plus de clients. C’est techniquement pas mal de travail, ce qui force à ralentir les évolutions du produit Karnott lui-même, mais c’est indispensable.

Un easter-egg se cache sur cette photo. Sauras-tu le retrouver ?

Tout ça pour dire que j’attendais du challenge, et je n’ai pas été déçu ! Je pourrais encore parler du monde agricole que je découvre tous les jours et que je trouve passionnant, de l’équipe géniale et enthousiaste, des raisons pour laquelle nous venons d’annoncer une deuxième levée de fonds, ou encore vous encourager à venir nous découvrir sur WelcomeToTheJungle. Mais là tout de suite, j’ai juste envie de savourer une année riche en émotions (ah oui, je suis papa aussi ! <3 ), et d’attendre avec impatience l’année prochaine !

L.B.

Publié le

Google Appengine : git push to deploy

Google App Engine 2013Avez-vous lu cet article ? le « Git Push to deploy » pour Google App Engine. Je passerais sur PHP et Python pour m’intéresser à Java, l’intéret étant de voir la capacité du service à compiler et packager le projet. J’étais vraiment curieux de voir ce qui était faisable sans la main sur la configuration du serveur de build, ou sans les plugins Jenkins qui vont bien.

Les fonctionnalités

Comme décrit dans l’article, nous allons pouvoir lier très simplement son projet App Engine à un repository Github. Le Hook de notification va parfaitement se mettre en place, et à chaque changement sur la branche Master (ah oui tiens, ce n’est pas personnalisable…), les sources vont être récupérées (accessibles via l’onglet « source »), et un build va être lancé.

Pour que cela fonctionne, le projet devra être un projet Maven standard, le pom.xml à la racine. La suite se déroulera en 3 étapes : Compilation, Tests et Déploiement. Nous avons un feedback à chacune de ces étapes, et tout s’arrêtera au moindre échec.

Au final, un fichier de log est généré, et téléchargeable. Si il y a un problème, ce fichier sera votre seule aide, heureusement, il est exhaustif : c’est la sortie console de Jenkins (oui, un jenkins a l’air d’être utilisé en arrière plan, je suis plein d’espoir pour la suite 🙂 )

L’interface

Capture git push to deploy

 Elle est claire, très simple et efficace. A chaque Release, une ligne va s’ajouter, affichant le dernier commit, la possibilité d’examiner le git diff pour la release, et une icône de feedback pour les différentes étapes. Je mettrais un petit bémol plus général sur la console d’administration des projets, qui a été refaite en 2013, et qui souffre de certaines lenteurs…

Bilan

J’étais très enthousiaste par la sortie de cette fonctionnalité: tout ce qui peut fluidifier le travail en équipe et faire gagner du temps sur une usine de développement est bon à prendre !
Cependant, la jeunesse du service me fait me demander dans quel cas c’est réellement utilisable… En effet, pas de possibilité de conditionner le déploiement, ou de choisir quelle branche git est la branche principale, par exemple…
Mais le plus handicapant, et de loin, c’est qu’aujourd’hui la plupart des projets Web vont aussi intégrer une usine de développement côté Front, et on aura besoin de Node / Npm / Grunt / Bower… D’ailleurs, nous n’avons accès à aucun de nos chers plugins Jenkins… Bref, dans ces cas là, il faudra se tourner vers des services plus complets comme le service @Dev chez Cloudbees.
Bref, pour démarrer un projet simple, ou en pur backend comme une API, c’est une bonne solution, gratuite et immédiate. Cette fonctionnalité aura le mérite de vous mettre sur de bons rails, votre projet étant standardisé, et les Tests Unitaires étant lancés régulièrement dès le début de votre projet, c’est un moindre mal !

En tout cas c’est un premier pas qui va dans le bon sens et j’espère qu’ils iront le plus loin possible pour deux mots d’ordre : Intégration Continue et Qualité !

LB.

 

Publié le

Bilan 2013 et Objectif 2014… Qu’ai-je appris cette année ?

Nous sommes en 2014, et j’aime bien faire un petit bilan professionnel de l’année passée. Qu’ai-je appris ? Aurais-pu faire plus ? Me suis-je amusé ?

Du Classic

J’ai commencé 2013 par ce qu’on appelle communément « un grand compte », avec  un projet Titanesque. Je ne rentrerai pas dans les détails, mais sur le contenu, j’ai eu droit à de l’Oracle / Hibernate, Spring, des pages et des pages de formulaire, le tout porté par un bon gros Liferay. Et tout ça était relié à plein d’autres applications du même genre, à travers des Web Services SOAP. résultat : 22693-le-plat-de-spaghettis   De la frustration, mais des technos solides qu’il est bon de maitriser, dans une ambiance positive avec quelques personnes avec qui j’ai pris plaisir à travailler.

De la Mobilité

Changement de registre. Un client arrive, avec un besoin un peu flou, et peu d’argent (en gros un mois de développement). « Je veux un site web, une application mobile, Android, iOs, stocker des photos, scanner des choses, gérer des données de référence, des droits d’accès, etc… Carte blanche sur la techno employée ». Ah. En 20 jours, donc… Et bien cela m’a permis de bien m’amuser :-). Et une mission comme celle-là, c’est une formation accélérée pour n’importe qui ! L’objectif étant d’avoir très rapidement une usine de développement, une application web et une API pour communiquer avec mes applications mobiles, j’ai choisi des technos que je savais adaptées, sans obstacle pour moi. Bref, à la fin de la première matinée, j’avais mon application sur Github, le hook Cloudbees / Jenkins qui va bien avec mon déploiement sur Google AppEngine. Une dépendance Maven vers Jersey, et j’aurais mon API sans soucis au fur et à mesure de mon développement. L’API, un jeu d’enfant. Un coup de Twitter Bootstrap et AngularJS pour le front, et ça irait tout seul. Mais même avec la meilleure volonté du monde, comment produire ces deux applications mobiles dans le temps imparti ? Nous sommes partis sur la solution Apache Cordova, couplé à JQuery Mobile pour le thème et éviter de se poser des questions. Pour des raisons fonctionnelles, nous avons aussi utilisé AngularJS côté mobile, ce qui devait nous simplifier la vie, et ce choix a été payant. Heureusement que nous n’avions pas Windows Phone en cible, la stack choisie n’aurait pas fonctionné. Bref, je me suis éclaté ! On apprend à coder vite, à s’appuyer sur des choses fiables, à s’adapter très très vite quand on rencontre un problème (aaaahhh les plugins Cordova… *soupir*), et on écarquille les yeux quand on se rend compte à quel point on peut produire vite, sans contrainte.

Mes coups de coeur :

cordova            appengine

(Oui, Cordova est quand même très chouette, malgré si l’on entend que c’est l’application mobile du pauvre…)
(Et oui, on y a passé un chouilla plus de temps que prévu 😉 )

Du WEB

On enchaîne avec une mission pure WEB… Environnement Google AppEngine, un besoin simple, mais on passera un peu plus de temps sur le design. AngularJS est alors incontournable, j’essaye de m’y intéresser plus, de penser aux directives, aux bonnes pratiques… Autant la courbe d’apprentissage est très rapide pour les besoins primaires, autant je trouve que ça se complique aussi très vite dès que l’on pense « composant ».
Mais clairement, ça aurait été difficile de passer l’année 2013 sans y toucher.angularjs

De l’Intégration

Oui, des EIP : Enterprise Integration Patterns. Je ne pensais pas compléter ma panoplie de développeurs par ce domaine, mais certaines opportunités m’y ont amené, sans que je ne le regrette le moins du monde !
L’intégration de données peut paraître moins sexy. Pourtant, en quelques mois j’ai croisé de vraies problématiques importantes, formatrices ! On pensera fiabilité, performance… On s’adapte aux contraintes systèmes, on se devra d’être flexible, on découvre de nouveaux patterns, et on pensera un peu différemment.

Mon nouvel ami : apache-camel-logo

De l’Associatif

En 2013, j’ai encore rencontré plein de gens vraiment passionnants et passionnés. J’ai assisté à des JUGs, à des meetup, j’ai assisté à Devoxx France, et j’ai même eu la chance d’être speaker au Jug Summer Camp.
Grâce à l’équipe du Google Developer Group Paris, j’ai aussi pu m’impliquer un peu plus dans l’organisation de plusieurs soirées, pour des technos et une communauté que j’apprécie.
Je ne suis resté qu’à peine deux ans à Paris, mais je pense ne pas avoir perdu mon temps sur place… Merci à toutes les personnes qui m’ont appris autant, c’était vraiment, vraiment bien.

Et maintenant ?

Et 2014, c’est Lille ! Je sens qu’ici aussi il y a des choses à faire. Un Chti Jug est actif, un ChtiJS aussi, et j’ai moi-même quelques ambitions.

Autour des technos Google, il y aura toujours des choses à faire, et des gens à rencontrer ! J’en ai profité pour créer deux choses :
– le Meetup GDG Lille : www.meetup.com/GDG-Lille/
– Le Twitter qui va avec : https://twitter.com/GDGLille/
Les premières soirées vont arriver courant février ! N’hésitez pas à me contacter si vous avez des envies ou des besoins.

J’ai aussi une liste de technos auxquels j’ai envie de m’intéresser de plus prêt :
– Docker
– Dart
– Java 8
– suivre encore et toujours le monde Javascript, en pleine effervescence…

Et vous, avez-vous ciblé vos technos de 2014 ?