A peine le temps de taper « play restart » et je suis à toi… voilà, ZapTravel est en prod.
Cet article est long. 2 heures pour l’écrire, en une seule fois. Une seule prise. Bonne, mauvaise, peu importe.
Il est là, tu le lis, moi je repars coder. Vivre l’aventure d’une startup, c’est ce que je vais te raconter.
Ca y est, c’est fait, nous sommes en ligne « officiellement ». J’ai envie de partager avec vous le bon, le moins bon, et ce que j’ai appris ces derniers mois. Clairement, dans ma tête, il y a un avant et un après. Je ne serai plus le même développeur. Il fallait se lancer et vivre cette aventure pour comprendre le sens du mot « startup ».
Lorsque l’on parle de Startup avec ses amis, j’ai compris qu’il y avait un certain nombre de lieux communs, qui en fait, sont faux. Le premier : tu vas bosser comme un dingue de 8h à 23h, tu boiras du TaureauRouge à la paille, tes enfants t’appelleront « Monsieur » et tu n’auras plus de vie sociale.
L’organisation
Et bien quelques mois après, je n’ai pas vécu cela. Nous travaillons plutôt en étant organisé. Nous utilisons Asana pour y ranger nos idées, les bugs et tout ce qu’il faut faire pour que ZapTravel.com fonctionne correctement. Tout le design, les idées, la conception et l’expérience utilisateur sont le fruit du travail d’Olivier Desmoulin, fondateur de Super-Marmite. Mon boss, Andrew Lacy, est un pur hacker. Il code l’ensemble du système qui constitue l’énorme volume de données de ZapTravel. Avec 43 villes de départ, nous avons plus de 345 000 combinaisons de voyage en ligne. Tout est calculé en temps réel. Sélectionnez un voyage, le système de validation a été complètement refait par Andrew avec du PHP. Oui, du PHP, tout un ensemble qui permet de constituer les données de ZapTravel. Photos d’hôtels, de lieux, textes touristiques, horaires d’ouverture des musées… nous avons un énorme paquet de scripts qui accumulent, nettoient et enregistrent ces données. Pas une ligne de Java ni de Scala. Ce que j’ai appris : peu importe la solution, l’essentiel c’est que ça marche. Et ça marche vraiment bien.
Play2 et Scala
Ensuite il y a le site ZapTravel.com lui-même. Là c’est du Play2/Scala. Pourquoi Scala ? Moins verbeux que Java, plus simple lorsque vous souhaitez trier/filtrer des collections, facile à exécuter en parrallèle avec Akka, je n’ai pas encore vu de points noirs. Et c’est sacrément efficace. Pas de soucis de mémoire, du code facile à relire, et finalement une bonne productivité. Petit bémol : les temps de compilation sur un projet sont variables. Parfois quelques secondes, il faut attendre d’autres fois jusqu’à 30 secondes pour que la page se recharge. Bon, avant de commenter, je précise : je compte cela du moment où je sauve mon fichier, recharge ma page dans un navigateur, et constate que mon résultat est ok ou non. Parfois cela prend 1 à 2 secondes, parfois plus. Cela dépend de ce que vous êtes entrain de faire dans Play2. Pour relativiser, j’ai vu des projets Webs en Java qui compilent en 2 à 3mn…
Scala a aussi changé ma façon de coder avec Play2. J’ai derrière moi plusieurs projets réalisés avec Play1+Java, puis Play1+Scala et enfin Play2. J’ai remarqué que Scala a modifié la façon dont je développe. Clairement, j’écris peu de tests pour tout ce qui est contrôleur. L’essentiel des tests que j’ai codé est sur la partie model, sur le domaine de notre application. Ensuite une chose importante : je fais peu de TDD. En général je code mon action, puis j’attaque la partie domaine. J’écris rapidement le code qui va chercher sur Redis mes données. Un peu de JSON avec l’API de Play2, ensuite souvent pas mal de Scala pour le métier, et enfin je code la vue. Le typage fort a radicalement modifié la façon dont je développe. Lorsque je faisais du Groovy avec Grails, j’écrivais plus de tests afin de valider mon code métier. Lorsque j’ai codé l’express-board avec Play1 et Java, j’ai fait beaucoup de tests. Le fait de ne pas avoir de typage fort dans les templates Groovy de Play1 finalement est un handicap. Lorsque je code encore sur l’express-board, il m’arrive de ne pas voir des bugs simples, et ça me fait perdre du temps. Avec Play2 et les templates Scala, c’est vraiment différent. Lorsque je souhaite refactorer quelque chose, j’utilise la compilation de Play2 et le typage fort comme une sorte de « Web driven development« . Au passage, c’est l’approche des développeurs Rails et PHP.
La méthode 3JC (« je code, je code, je code »)
Par exemple prenons une action « save(webuserID:String) » chargée de sauvegarder un paramètre. Imaginons que je souhaite passer mon webuserID d’une String à un Long. Comment vais-je faire ? Je vais modifier mon code, lancer une compilation, et attendre de voir ce que Play2 va me signaler. Je verrai ainsi que la route qui permet de faire le mapping d’une URL vers mon contrôleur doit aussi être modifiée. Et ainsi de suite… En quelques sortes, je développe en étant piloté par le typage fort de Scala. Ne cherchez pas sur Wikipedia… ça veut juste dire que j’utilise le fait que Play2 remonte l’erreur dans mon navigateur pour coder. L’équivalent d’un test rouge ? Et bien la page d’erreur de Play2 qui pète. Hop, je fixe, je recharge la page… et j’avance.
Le moment où il parle de la base de données alors qu’il n’y en a pas
Côté base de données, nous avons fait un choix simple : il n’y en a pas. Nous avions au début du projet une base MySQL. Rapidement, nous avons commencé à utiliser Redis, un moteur écrit en C de type « base en mémoire » NoSQL. C’est une excellente solution, très simple à mettre en oeuvre, facile à programmer et sans mauvaises surprises, même plusieurs mois après avoir commencé votre projet. Côté Scala, il existe un driver appelé Sedis, qui est un mapping de Jedis. C’est tellement simple à programmer que nous avons rapidement décidé de retirer notre base MySQL, et surtout, tout ce qui est Anorm. Dans la version 2.0 je n’ai pas été séduit par l’approche utilisée pour accéder à une base de données, particulièrement en Scala. Cela restait trop verbeux, surtout sur des tables compliquées. Cependant je sais que la version 2.1 de Play2 a amélioré ce point. Mais bon, nous avons retiré notre base relationnel. Les utilisateurs sont stockés sur Redis, sur un serveur spécial configuré en mode « sauvegarde agressive » afin de persister sur le disque les données. Redis est par défaut une base en mémoire, que vous pouvez configurer pour stocker sur disque, comme une base classique.
Redis en quelques mots : il s’agit d’un serveur clé-valeur en mémoire, complètement open-source, supporté par VMWare. Ecrit en C, Redis est utilisé par StackOverflow, GitHub, DisquUS, bref des sites « de la vraie vie avec du traffic ». Redis fonctionne sur Linux, sur Mac OS X et donc sans soucis sur votre environnement de travail (car vous bossez sur Mac, comme l’ensemble des développeurs chez ZapTravel non ?). Il suffit de quelques minutes pour l’installer, se déclarer comme étant un « slave » de l’un de nos serveurs… et hop, vous avez 6 mois de vols d’avion, de location de voitures et d’activités sur votre disque.
Nous avons plusieurs instances de Redis selon nos usages. A ce jour, nous avons divisé cela en 3 familles. D’une part les données « froides » qui ne changent pas souvent. Dans ce serveur, vous trouverez les textes sur Paris, les photos de la Tour Eiffel, les horaires d’ouverture du musée Grevin, des indexes pour noter le niveau de romantisme de Paris, des descriptions d’hôtels… bref des données que nous mettons peu à jour (environ une fois par semaine). Ensuite nous avons un deuxième domaine, qui tient sur 5GB en mémoire, pour tout ce qui est prix. Prix de l’avion, de l’hôtel, de la location de voiture, de la place au Musée Grévin ou de l’expo Dali… nous avons un énorme référentiel de données.
Afin que le site ZapTravel soit rapide, nous effectuons aussi des croisements de données directement sur Redis. Je t’explique ma vie : lorsque j’étais con-sultant je devais coder une solution où nous remontions avec du Hibernate un gros volume de données en mémoire, effectuer des traitements, puis tout remettre sur le serveur. Le tout avec du Camel pour passer des messages, un vrai truc d’architecte. Aujourd’hui c’est bien plus simple : nous effectuons directement nos traitements sur Redis. Cela permet de calculer très rapidement nos résultats.
Enfin nous avons d’autre serveurs pour tout ce qui est utilisateurs, achats et réservations et la gestion de notre backend. Nous avons un énorme backend en PHP qui se charge de préparer les données statiques, de les formater et de les stockers sur Redis.
Où cela tourne-t-il ?
Sur Amazon. Aujourd’hui le site ZapTravel tourne sur 2 instances EC2. Nous utilisons le Load-Balancer d’Amazon pour diviser le traffic. Pourquoi faire le choix d’un IaaS alors que j’ai la possibilité d’utiliser Heroku ou la solution de Google ? Et bien je pense que le PaaS n’est pas adapté à l’ensemble des besoins que nous avons (Alexis : je ne suis pas d’accord avec toi). Quelque part, je trouve que l’approche « PaaS » à la Heroku est trop chère pour nous, pour l’instant. Le côté « je clique et ça déploie », je l’ai aussi avec un script exécuté via rsh. Merci, on sait encore écrire des scripts Unix. Le côté « je scale comme un ouf » c’est dans les films. Avec un budget de 1200 USD par mois, nous avons 6 machines, un environnement de staging, un environnement de prod.
Ce que j’ai retenu en utilisant Amazon : vous n’avez pas à prendre de décisions trop tôt. Vous pouvez tester votre serveur sur une machine très puissante « pour voir ». Ce que vous payez finalement avec l’approche IaaS c’est la liberté de pouvoir changer à tout moment. Or des choix et des changements, nous en avons fait pleins ces derniers mois. Nous regardons les solutions comme Heroku mais le coût par rapport à nos besoins est trop élevé, surtout pour ce qui est Redis. Enfin du côté Redis, nous sommes aussi devenu des experts. Et les solutions hébergées ne sont pas assez souples pour nos besoins. Nous avons aussi des traitements, des sauvegardes, des batches… bref pas mal de choses sur lesquelles l’approche PaaS ne me semble pas adaptée. Par contre un hébergeur classique comme OVH pourrait faire l’affaire. Enfin nous n’avons pas du tout de besoins d’intégrations continus. Pas de Java, uniquement du Scala.
Les développeurs
L’équipe a changé durant les derniers mois. Nous avons eu l’aide de Clément Garnier, Guillaume Tardif et Maxime Dantec. Toutes les personnes qui sont passées chez ZapTravel étaient ou sont de très bons développeurs. Trouver par contre une personne est un exercice qui fut difficile. Nous avons eu beaucoup de difficultés à trouver un développeur expérimenté côté Web. C’est finalement Mathieu Seguin, co-fondateur de CupOfTeach, développeur Ruby/Rails, qui est venu renforcer l’équipe. Comme Olivier et moi-même, il a aussi d’autres projets en plus de ZapTravel. Nous avons en commun d’être des développeurs avec le côté entrepreneur. Au passage, ZapTravel n’a que des personnes en freelance. Cela contribue aussi à l’esprit et ne me perturbe pas plus que cela.
Mais bon… il y a quelque chose avec la communauté Java qu’il faut que vous sachiez : nous avons une image assez négative dans le monde des startups.
Nous sommes vu par les autres communautés de développeurs comme étant des développeurs compliqués, chers, assez sûrs de notre légitimité, bien trop formaté « ingénieur » et assez mauvais sur le Web en général. Forcément, qui aurait envie de travailler avec nous pour faire une startup ?
Que manque-t-il à la communauté Java ?
Je pense bien connaître les développeurs Java, mais je pense qu’ils ne connaissent pas le monde des startups. Et ça, c’est dommage. Lorsque vous entendez Olivier dire « il a pitché son projet à la Cantine » la première fois… y’a un monde. Nous ne sommes pas, pour la grande majorité des développeurs Javas, des personnes prêtes à travailler en startup. Nous ne sommes pas fait pour travailler dans une startup.
Nous sommes de bons ingénieurs, en mesure de construire des applications robustes, testées, avec des outils d’industrialisation. Tests unitaires, déploiement continu, tests d’intégration, principes de programmation, patterns, architectures, librairies, outils… Le développeur Java vit dans un monde de frameworks et d’outils, qui entretiennent aussi parfois son image de complexité.
Moi je viens du monde du service, des banques, des projets à plusieurs centaines de journées hommes… Mon échelle de mesure est le « 9 minutes de compilation, douche comprise avec Maven2« . Ma référence était Java, les serveurs d’applications, Spring, Hibernate, Guava… Mon univers tournait autour des JUGs et de toutes les soirées où nous parlions essentiellement d’Eclipse versus IntelliJ… Mais c’est tout. Je n’ai jamais parlé de startups à un JUG.
En dehors du monde du service, le paradis pour nous, les gars qui font du Java, c’est un peu plus délicat.
C’est un univers où tu es content de gagner entre 300 et 400 EUR jour, pendant que ton pote qui fait du Word avec le titre « Architecte » se tartine un bon 800 EUR jour, même quand il pleut. C’est un univers où tu ne sais pas de quoi demain sera fait. C’est un monde réaliste et simple.
Ces derniers mois j’ai travaillé sur l’ensemble de la plateforme. En tant que développeur Scala sur ZapTravel. En tant qu’administrateur système sur Amazon. En tant que développeur Javascript sur la partie AngularJS du site. En tant que développeur HTML/CSS, même si je n’ai plus le niveau de Mathieu, Clément ou Maxime. Parfois c’était génial. D’autre fois terriblement étonnant de se trouver « mauvais » ou à la ramasse, surtout lorsque l’on est formaté.
Ce que j’ai découvert c’est l’énorme fossé entre le développeur Java lambda et le monde des startups. Je suis presque passé de l’autre côté, mais tout n’est pas rose.
Etre développeur dans une startup c’est vivre à crédit, en permanence. La clé c’est la vitesse d’exécution. Vous n’aurez pas 3 jours pour coder une idée. Vous aurez 20 mn car l’article est déjà parti chez TechCrunch. Alors vous prendrez un crédit en faisant le sacrifice de la qualité. Mais est-ce vraiment un crédit ? Est-ce que finalement, si je n’avais pas codé ce truc « tout crade mais qui marche » nous serions encore là ? Plutôt que de voir de la dette qui s’accumule, il faut voir en face ce qui est livré.
Le produit, plus important que le code
Toi visiteur qui vient sur ZapTravel.com, tu ne verras pas qu’il manque un test dans la partie DealCard. A la limite, tu t’en fiches. Il faut en permanence voir non pas « du code Scala » mais un produit. La vision, chaque matin, c’est le produit.
Qu’est-ce que je vais faire aujourd’hui pour délivrer plus de valeurs ?
Demain je vais aller sur Google Webmaster Tools. Celui-ci indexe notre site, et couvre chacune des 340 000 pages du site. Grâce à cet outil, hier nous avons identifié un bug simple avec Andrew. Je n’ai pas écrit de tests unitaires. Je n’ai pas d’intégration continue. J’ai Google Webmaster Tools qui me dit ce qui ne marche pas sur mon site. Et cela ne me coûte rien.
Nous n’avons pas écrit non plus de système pour « pré-cacher » nos pages. Non, au lieu de cela j’ai eu une idée qui m’a demandé 10 mn. J’ai codé et mis en ligne une page sitemap.xml dynamique. Dès lorsque que Google Bots visite notre site… il charge automatiquement en cache nos deals. C’est gratuit.
Je n’ai pas utilisé non plus de solutions de caches digne d’un Architecte. Plutôt des astuces et essentiellement du Web.
Prenez une page comme http://www.zaptravel.com/from-paris/comfort. Cette page se charge en local en 100 ms mais 12 ms en local. Bref presque de manière instantanée. Regardez ce qui se passe dans la barre Google Developer de Chrome lorsque vous rechargez la page… Le serveur vous retourne un status HTTP 304 Not Modified. Et ce status, ainsi que la façon dont je le calcule, c’est du pur Web.
C’est réellement le sens métier de « cette page n’a pas changé ». Je le sais car je calcule un ETag en effectuant une requete sur Redis, pour trouver le nombre de cartes, le prix et surtout, la quantité de deals restantes. A chaque appel il y a bien du code qui s’exécute, avec un appel vers Redis. Bref au lieu d’utiliser un cache, j’ai simplement exprimé la notion de « dernière modification ». C’est le ETag que le serveur a envoyé lors du premier chargement. Et lorsque je vois que les 2 valeurs sont identiques, je retourne un status Not Modified avec Play2. Vous économisez le chargement d’une page de 100kb.
Faire du Web, avec un sacré W majuscule. Ne pas faire d’URLs inutilisables. Si je vous montre http://www.zaptravel.com/from-paris/comfort, vous comprenez ce que nous vous montrons. Simple. Efficace.
Et des petites aventures comme celle-ci, nous en avons un sacré nombre. Dans la première version, j’utilisais Akka pour précalculer mes pages. Inutile. Nous avons utilisé aussi pendant un temps le Streaming. Trop compliqué pour notre besoin, nous l’avons supprimé. Je n’ai jamais autant avancé qu’en retirant du code inutile. Du code de « Nicolas se fait plaisir avec Play2« . J’en ai retiré après avoir retiré mon cerveau de geek. Le plus dur c’est de faire simple. Vraiment tellement simple que personne ne viendra vous demander comment cela fonctionne. Le fait que le site soit rapide est normal. Que les URLs soient propres, idem. A méditer.
Conclusion
Il est tard et si vous avez lu chacune de ces lignes, bravo.
En prenant le chemin de ZapTravel, j’imaginais un autre rôle. Mais je ne regrette pas ce que j’ai appris en quelques mois. Construire une solution, le plus rapidement possible, avec de l’astuce et des choix simples. Ne pas se donner le luxe de prendre son temps. Décider et avancer. Faire le choix de solutions faciles à retirer lorsqu’elles ne fonctionnent pas. Etre prêt à changer chaque semaine toute l’architecture. Avoir 5 idées en tête pour améliorer l’existant, en trouver une 6ème qui prend 10mn et qui sera suffisante pour les mois à venir.
L’aventure d’une startup c’est vivre avec une grenade dégoupillé dans la main. Ne pas dormir, penser simple et avancer.
Vraiment, je vous souhaite de vivre cette expérience dans votre vie de Développeur.
Que vous ayez 25 ans ou 60 ans.
Ne manquez pas cette expérience.
0 no like
Article super interessant, bravo !
La vue d’un Java-iste comme je l’imaginais en étant pure Web.
Ce que tu décris fonctionne super bien, et cela est aussi du à vos compétences et votre maniere de prendre rapidement et souvent de bonnes décisions. C’est en grande partie grace à vos experiences.
Félicitation pour ZapTravel.com !
Armetiz.
Excellent article. La vie en startup est quelque chose de différent surtout lorsque l’on vient du monde SSII, Grosse Boîte, club des architectes et autre couche de hiérarchie …. Mais, ça permet de revenir sur terre, à écrire du code qui crée de la valeur plus que pour se faire plaisir. Quant à l’image des développeurs Java, je pense qu’elle change en mieux. Beaucoup commencé à s’y intéresser. Le plus dur c’est souvent de sauter le pas. Et le système en France n’encourage pas vraiment à prendre de risques. Risque d’apprendre quelque chose différent, de sacrifier son expérience passée à maîtriser la quantité de frameworks pour voir déployer sa web page dans son légale serveur d’applications. Heureusement les technos évoluent et les mentalités aussi.
Bravo pour ZapTravel, le site est agréable. Et bon courage pour la suite.
Retour d’expérience très intéressant!
Comme le commentaire précédent, je pense que l’image des développeurs Java s’améliore vis à vis des startup, parce qu’ils (certains) commencent à s’intéresser au Web.
Le problème maintenant, c’est que tu ne pourra plus jamais retourner en mode SSII. une fois gouté à ce fonctionnement, tu es tellement proche du fonctionnel, de la vraie vie, des enjeux, de la vision marketing et avec une réactivité importante, que le retour dans un mode SSII te fera le même effet qu’une perspective d’un retour chez tes parents…
Merci pour ce billet très intéressant.
J’ai récemment rejoint une start-up (noteo.info) après 5 ans en SSII, et après seulement une semaine d’activité je partage ton point sur plusieurs point.
J’ai cette impression d’être devenu une tortue, que tout les autres s’exécutent à vitesse grand V quand je suis encore entrain de réfléchir à la solution la plus propre possible.
Comme tu le dis, l’important c’est que ça fonctionne.
Grosse différence aussi comparer à ce que j’ai pu voir en SSII(et surtout en clientèle), c’est la cohésion qu’on retrouve dans l’équipe. Tout le monde pousse dans le même sens, on ne retrouve pas ces espèces de guerre de tranchée entre service.
Pour le moment je suis pleinement satisfait du changement, ça fait du bien, ça relance la machine, une sorte de bol d’air « frais ».
Félicitations pour ZapTravel et bonne continuation.
Hello,
Nicolas je crois te comprendre en tout cas sur le fond. Mais sur la forme (et je parle uniquement de cet article pour le reste je n’en sais rien).
Tu y fais énormément de raccourcis dont certains incompréhensibles pour qqun de ton expérience. Non les tests ne servent pas qu’à trouver des erreurs de compilation ou de génération de page par exemple.
Si, dans ta vie d’avant, tu n’avais pas de notion de productivité cela est extrêmement triste. Évidement certaines technos / framework n’aident mais ça aurait toujours dû être un de tes objectifs / points de réflexion.
C’est ton job de prendre en compte les problématique de cout / effort / productivité et ce n’est pas parce que tu semblais ignorer ces questions avant que c’est l’attitude normale ou obligée avec Java (ou un autre langage).
Ce n’est pas nouveau qu’il faille faire des choix et que le mieux est l’ennemi du bien. C’est un arbitrage de tous les jours. C’est ton job. En startup ou ailleurs. Après il faut accepter de le faire (et, dans nombre de job, avoir toute l’attitude de faire ces choix et pas uniquement d’assumer le choix des autres, ou les non choix).
Enfin si vous semblez avoir une mauvaise image dans la communauté (perso je ne lis pas Voici donc suis pas trop au courant) c’est peut être avant tout et surtout pour la forme plus que pour le fond. Dans le cadre de cet article on peut imaginer que la prise unique n’a pas aidé par exemple.
Si tu dis:
– Besoin permanent d’arbitrer sur productivité / robustesse
– Travailler dans un env. avec contraintes (en particulier sur les moyens) est une opportunité
– Certaines technos sont des freins à la productivité et des alternatives plus intéressantes sont disponibles
– Certains devs sont dans leur tour d’ivoire et a des kms du produit
et ainsi de suite je veux bien te suivre. Mais pour ton article précisément cela me semble très maladroit et peu étayé.
Et pour rappel c’est assez flippant de te voir découvrir que l’on peut aller vite pour créer un site et qu’il faut arbitrer sur de nombreux points pour répondre au besoin dans les meilleurs conditions. C’est, à mon sens, la définition même de ton travail. La SEULE différence c’est qu’en startup tu as le pouvoir que d’autres ne te laisseront pas forcement ailleurs (pour ne pas dire, probablement pas, ou carrément pas :-).
@Phil comme tu le dis en conclusion, la différence dans ce projet est la place donnée dans la prise de décision. J’imagine que j’aurais écrit le même article si j’étais finalement chez un éditeur, avec toutes les cartes en main pour prendre les décisions techniques, d’architectures et de recrutement.
Mais dans les faits (j’ai travaillé 5 ans dans ce monde des startups) j’ai vraiment ressenti un fossé assez important entre le monde que j’évoque, le monde du service, et cet univers de startup.
Sur les tests, je ne joue pas la langue de bois. Pourquoi écrire « je fais 100% de tests » si cela est faux ? L’interrogation est de comprendre comment nous arrivons à un résultat, un produit en ligne, des clients, sans avoir eu à suivre le chemin des tests complets ? La réponse, et je le redis, c’est cette notion de crédit, d’emprunt, de choses que tu ne fais pas afin de pouvoir délivrer plus rapidement.
Quand je dis « je découvre qu’il faut aller vite », c’est sans doute un peu maladroit, pour exprimer une pression qui est difficile à restituer par écrit. J’ai travaillé 5 ans en startups, 6 ans chez un éditeur puis 3 ans dans le monde du service en tant que freelance. Je n’ai jamais travaille pour une SSII. Depuis bientôt 2 ans je ne travaille qu’avec des startups. Un univers très riche et très intéressant. Je reviendrai évoquer ce sujet et cette expérience, en prenant le temps d’exprimer différemment les mêmes idées. Merci aussi pour ton retour qui fait réfléchir.
Merci pour le retour d’expérience.
C’est sympa de lire que vous aviez une méthode « je code, je code, je code » tout en ayant en tête la « vision produit » et les notions de « valeurs ajoutée », de l’importance d’être « time-to-market ». Je dis toujours que c’est possible mais j’ai parfois du mal à convaincre 🙂
Cela dit c’est quand même compliqué de trouver des profils qui sont capable de cela et de monter l’équipe qui va bien. Pour moi, un des plus gros enjeux d’une startup est la constitution de l’équipe au départ. Il faut l »Assurance tout risque » ou rien (the A-team, en fait ça passe encore mieux en anglais).
Pour moi votre point fort était d’avoir :
– des développeurs expérimentés motivés (sisi y a des startup Internet qui se lancent sans développeurs, parfois on a quand même des stagiaires)
Les freelance sont de facto motivés (sinon ils seraient pas la), expérimentés (souvent) et ont ses notions de prise de risque, valeurs toussa.
Enfin j’aurais intitulé l’article « Vivre la vie d’une startup *Internet* ». Tous les biais de jugement que tu as (sur les devs Java notamment) viennent surtout du fait que t’as changé d’univers: Service Finance -> Web
Il n’y a pas que des startup dans l' »Internet B2C ». Je pense que ce que tu dépeints est plus l’esprit Web que l’esprit Startup (la simplicité, la rapidité, l’évolution, les urls,…). Je connais des startup « logicielles » qui ont été créées après 2 ans de R&D en labo, qui cartonnent (et qui font du JEE). Comme elles font pas du B2C le grand public les connais pas forcément.
Bonjour,
j’ai travaillé dans une startup et on faisait du Java !
Je ne comprends pas très bien pourquoi vous collez certains problèmes sur le dos de Java alors que cela n’a rien à voir avec Java.
Il n’y a pas que Websphere ou Weblogic dans la vie, il y aussi Jetty, Resin, … après si l’architecte XY impose WebLogic ou WebSphere et un environnement de travail improductif on ne peut pas le reprocher à Java.
On peut être extrêmement productif avec Java et travailler avec un environnement très léger, on peut aussi travailler dans un environnement très outillé (JEE la totale : JPA, JTA, EJB, Maven, …).
Au moins on a le choix !
Mais le problème c’est que certains choix ne sont pas forcément pertinents, surtout quand les gens qui les imposent ne les subissent pas.
Je me reconnais bien par contre dans l’approche « le produit est plus important que le code », c’est exactement ce que j’ai vécu dans la startup ou j’ai bossé.
Ce que je remarque tout de même c’est que ces jolis nouveaux langages qui se succèdent finissent souvent par reprendre des concepts utilisés et largement outillés en Java. La gestion des dépendances, les patterns divers et variés, … ce n’est pas un hasard. Bref on critique Java et puis quand le nouveau langage se confronte à des projets d’envergure on retombe sur les même problématiques (gestion des dépendances, audit de code, débogage, génération de documentation, mapping, …).
Cdlt.
La lecture de cet article fait un peu penser à un rapport de stage (en tout cas, les miens de quand j’étais jeune).
Non pas le côté négatif du rapport de stage mais son côté positif : « j’ai peut-être fait deux ou trois trucs avant mais en fait, je ne sais rien et j’ai tout à apprendre ». On arrête de se prendre la tête avec des stacks complexes et on y va, on commence de zéro et on recommence si ça ne marche pas.
Depuis que je fais du Play! (j’ai commencé avec la version 2), j’ai un peu le même esprit. Je pense que la technos incite un peu à faire ça parce que quand je suis au boulot à faire du Spring, du Hibernate et autres technos « classiques », je recommence à faire des choses compliquées et à coder mes tests avant de coder la fonctionnalité – voire à tester des cas purement techniques qui n’arriveront jamais dans la vraie vie.
Pour résumer : +1 à cet article.
@Alban : merci pour ton retour 🙂
Juste une parenthèse par rapport à Play2 et les frameworks web à la Rails/Django et compagnie.
Je suis aussi à la base un pur « produit » J2EE, et depuis que j’ai découvert Play2, ça m’a inhibé et décomplexé quant à la réalisé des 1000 idées que j’ai à la minute.
Avant, avec ma stack J2EE, je ne me lançais jamais dans la réalisation d’un proto (la flemme de faire un pom.xml avec de l’hibernate et du spring).
Maintenant, un petit coup de « play new ma_nouvelle_idee » suivi d’un petit « git push heroku master » et c’est parti !
Très bon résumé de la transition grosse boite / startups et de l’adaptation en tant que dev aux exigences d’une startups.
Petite question annexe:
Si j’ai bien compris ZapTravel est codé en angularjs + play 2.x scala, j’ai fait le même choix pour un nouveau projet. Utilises-tu les templates play pour générer ta page de base angularjs (par exemple pour précharger certaines données json dans des balises scripts et ainsi réduide le nombre de requêtes ajax initiales). Pour le moment j’ai des pages utilisant angularjs et d’autres générées coté serveur (avec éventuellement une mini app angular pour une petite partie de la page) lorsque j’ai besoin de SEO sur ces pages. Comment gères-tu le SEO avec angularjs ?