Talk comments

J'ai pour ma part trouvé le sujet intéressant même s'il était un peu négatif. Mais il en est surtout ressorti qu'Atoum n'a pas pris l'essor espéré à l'international et que les raisons en sont difficiles à cerner. Même le lien avec Hoa/Praspel ne semble pas avoir donné l'élan pour améliorer cet état, mais il convient de dire également que Hoa est dans une situation assez similaire à bien des égards, avec les mêmes interrogations.

Le problème évoqué concernant la documentation, en particulier la version en anglais a été évoqué. Mais je m'interroge, pas tant sur le fait que cette documentation soit en anglais que sur le contenu même de cette documentation : vise-t-elle la bonne cible ? Et, le cas échéant, est-elle conçue pour le cible visée ?

Content is too large and each subject is treated too quickly to my point of view.
Less and more detailed (technically) should be better.

Anonymous at 20:22 on 24 Nov 2015

Merci pour le talk, pas assez de temps pour toi et on en aurai voulu plus

Very good presentation on how a startup built its products from the dev team point of view. Both technical and methodological approach of the topic brings clever insights on how to manage growth of base code and team while keeping quality in sight.

Bonsoir Grégory,

utopique.. non ; compliqué, un peu, oui :)

Une fois encore, le manque de temps ne m'a pas permis d'expliciter mieux le processus. Une grande partie des réponses qu'il convient d'apporter aux questions d'architecture sont effectivement issues de l'expérience - il faut être pris pour être appris, dit-on :)

Ces réponses sont à leur tour des "principes d'architecture" ; l'architecte dispose de cette boîte à outil pour définir l'architecture des projets. Avec l'expérience, une grande partie de ce travail - notamment concernant la macro architecture - ne prend virtuellement plus de temps.

Quand à la micro architecture, du temps lui est consacré de fait. Simplement, si ce temps est dilué dans le développement, il enfle. La conclusion c'est, qu'en ne lui consacrant pas un temps défini, précis, en début de projet, on lui en consacre beaucoup plus !

En fin de compte, savoir "perdre" un quart d'heure pour gagner une heure...

"Every day is a school day". Even when you think you have a good knowlegde of regexpes, there are always some new things to learn. Thank you Jordi!

I regret that the conf has been mainly a reminder of the history of PHP dependencies (manually downloaded files, PEAR, frameworks, Composer...)