Ah la la, que c’est difficile de choisir un “bon” framework php… chez findawine on en est au stade de la réflexion, qui tient plus du casse tête chinois. Mais comment faire pour choisir de façon cohérente et précise le framework qui nous convient le mieux?

1. Quelle utilité
Une des première question à se poser est: pourquoi je veux adopter un framework?
Et bien évidemment cette première question en appelle d’autres, mais principalement quelles sont les tâches que je veux que le framework prenne en charge et quelles sont celles qui me reviennent.
C’est important puisqu’on peut séparer les frameworks actuels en deux clans: les frameworks complets et les autres (ce qui n’est pas réducteur ou mauvais, c’est juste deux modes de fonctionnement différent).
Le premier clan couvre 98% des problématiques qu’un développeur pourra trouver devant son chemin, alors l’autre est plus là pour aider ou délester le développeur des tâches rébarbatives.

2. Quelles fonctionnalités obligatoires
Une des premières tâche est de faire la liste des fonctionnalités obligatoires que doit avoir le framework, et ainsi analyser ses besoins.
Pour nous:
- Structure MVC stricte
- Scripts exploitable en ligne de commande
- Gestion de profils Base de données (plusieurs types, mais aussi plusieurs serveurs en simultanée)
- Gestion efficace et hautement configurable du cache
- Support full UTF8

3. Quelles fonctionnalités supplémentaires/optionnelles
La tâche suivante est de définir le liste des fonctionnalités supplémentaires ou optionnelles qui peuvent nous rendre la vie un peu plus agréable.
Pour nous:
- Outil scaffolding / Back Office
- URL rewriting
- Localisation (multi-langues)
- Connecteurs webservices/api
- Documentation
- Tests unitaires métiers
- Surchargement des fonctions et classes simple
- Possibilité d’ajout de plugins

4. Quelles technologies
Vient ensuite la liste des technologies choisies: pour nous rien de plus facile, du classique: AMP (Apache, MySQL et Apache)

5. Se renseigner
Vient donc la tâche longue et fastidieuse d’aller à la pêche aux infos, trouver des sources, voir les spécifications, vérifier, etc…
Quelques sources pour cela:
- liste des framework PHP (via WikiPedia pas complète loin de là, mais un bon début)
- un article de JDN développeurs (qui date un peu) sur 12 framework PHP
- un thread du forum developpez.com sur le choix des frameworks php (lancé par l’ami vinch si je ne m’abuse?)
- ou encore un comparatif de 10 framework sur PHPit
C’est une liste non exhaustive des différentes sources utilisées…

Nous avons donc établi une liste des différents frameworks qui correspondaient (plus au moins) à nos attentes:
CakePHP
Jelix
CodeIgniter
Copix
Kohama
SolarPHP
Symfony
Zend
eZComponents

6. Coût d’entrée / mise en place / support / communauté / contraintes
Ce sont des éléments extrêmements importants à ne pas négliger… le coût d’entrée et de mise en place est crucial, il vous dira quel sera votre investissement initial et en combien de temps votre équipe sera opérationnelle avec ce nouveau framework.
Il vous faut aussi être conscient des contraintes inhérentes à votre choix: les limitations, les choses que vous ne pourrez pas faire ou qui vous prendront beaucoup plus de temps qu’aujourd’hui… les bibliothèques ou classes que vous risquez de devoir modifier pour matcher vos besoins, la difficulté de ceci, etc…
Enfin en dernier c’est important de savoir quels projets ont déjà été réalisés avec tel ou tel framework, la communauté derrière tel ou tel projet, la roadmap de développement, la fréquence des releases, etc… cela vous permet de vous rassurer (ou vous faire craindre la pire).

7. Tester
Là c’est la partie la plus longue, la plus ingrate et sans aucun doute la plus partiale.
C’est là où vous allez installer et tester le framework. C’est aussi le moment où vous pourrez voir si non seulement les fonctionnalités sont au rendez-vous mais surtout si la façon de coder du framework vous correspond (ça peut paraître annexe, mais pour moi c’est un des points les plus importants). Chacun sait que chaque développeur à sa façon propre de coder, et vous allez voir si le code du framework vous correspond ou pas.
Pour ma part l’installation d’un framework est assez révélateur de la façon de coder des gens… une installation difficile et brouillonne me fais penser que les codeurs n’ont pas suffisamment penser aux autres, alors qu’un framework même avec quelques fonctionnalités en moins mais beaucoup plus accessible me plaît beaucoup plus (mais là c’est mon avis à moi).
Bref, pas de tergiversation, il va falloir s’y mettre.

8. Faire son choix
Le choix en gros revient à deux ou trois framework.
Nous avons éliminer les postulants suivants:
- Copix, parceque Jelix semble une évolution plus maintenue et plus avancée de Copix
- CodeIgniter (à mon grand regret) car codé en PHP4
- Kohama, pour son peu de visibilité (et parceque des frameworks très similaires voir identiques existent déjà)
- Zend pour sa lourdeur
- eZcomponents idem

Il nous reste donc CakePHP/Jelix contre Symfony (pas encore eut le temps de tester SolarPHP, qui à l’air prometteur mais un peu en dessous de Jelix/Cake en terme de fonctionnalités), la bataille des framework agiles contre l’omnipotent.

Pour l’instant on se donne un peu le temps de la réflexion (une décision comme celle ci est importante et ne se prend pas à la légère) et on continue de tester.

Quelques frameworks qui n’ont pas été retenus mais semblent intéressant/prometteurs:
- Atomikframework un seul script 15 Ko, et des capacités très raisonnables (pseudo MVC, système de packages, bdd, cache, erreor, command line, etc… je le test en ce moment à titre perso, c’est très efficace et très agile, j’adore)
- Qcodo: pas sûr d’avoir tout compris, mais apparemment un framework événementiel basé sur votre modèle de données. Le principe à l’air sympa, bien que pas exploitable sur ce projet.

Et vous vous utilisez quoi comme framework? Quels sont les critères qui vous ont fait choisir tel ou tel produit?

Tout le monde connaît plus ou moins le “crowdsourcing” qui consiste plus ou moins à confier une tâche à une foule, en espérant le meilleur résultat pour ensuite élire le meilleur résultat et le récompenser (en espérant gagner du temps et de l’argent).

Apparement 99designs est un de ces sites sur lequel cela semble marcher.
Vous soumettez votre brief (et payez les droits d’entrée de 39$) et donnez un prix pour le résultat final, une date limite et des graphistes vous soumetterons leurs travaux. A vous sept jours (maximum) après la fin de la date du concours passée de choisir le gagnant, de le payer, en échange il vous enverra son travail sous un format exploitable et vous cèdera ses droits sur sa création.

Plutôt un bon plan quand vous êtes en panne d’idée créative, même pour un prix minimal, cela peut vous donner quelques pistes ou idées à approfondir.
Par contre c’est vrai que vu les prix pratiqués (entre 100 et 500$ en moyenne, mais avec des prix pouvant atteindre les 5000$, et avec un fort risque que votre création ne soit pas choisi), pas spécialement une bonne affaire pour les graphistes (à moins d’être ultra productif et talentueux), mais un bon moyen de se choper de la clientèle.

Et vous vous en pensez quoi?

[Article extrèmement intéressant, très juste, que je m’empresse de traduire et d’adapter…]

Qu’est ce qui fait vraiment un bon développeur? Certains diront une attitude positive, d’autres diront une bonne dose de sucre et de caféine, alors que d’autres parieront pour une absence de lumière et autant d’écran qu’un bureau peu supporter.
Tout le monde a des anecdotes avec des développeurs avec lesquels ils ont travaillé qu’ils trouvaient brillants. Malheureusement, la plupart du temps, ce jugement n’était pas basé sur la qualité du code produit, ou le fait de respecter les deadlines, mais sur des critères bien moins importants, comme le fait que le développeur connaissait le nom de ses collègues, le nombre de lignes de code qu’il était capable de produire ou combien ils semblaient professionnel en parlant de leur travail.
Malheureusement, les meilleurs développeurs sont une race difficile à apprivoiser. Voici donc une liste, qui n’est certes pas applicable à tous, mais qui pourrait vous aider à repérer un bon développeur.

Pessimiste
Les bons développeurs son toujours pessimiste par rapport à leur travail. Cela ne veut pas dire qu’ils sont abattus, sans vie ou même ronchons, mais juste qu’ils pensent toujours aux choses qui iront de travers et comment gérer cela.
Ils estiment qu’à un moment ou un autre ils devront casser une partie du code déjà effectué, que le hardware risque de crasher, que la sécurité risque d’être compromise, et que de façon ultime le bureau risque de partir en cendres. Les plus brillants penseront à tous ces événements arrivant en même temps. Et ils ne seront pas content avant d’avoir un plan spécifique, mis en action et testable pour contrer tous ces problèmes. Même avec ça ils ne seront toujours pas complètement tranquille.
Les développeurs pessimistes seront ceux qui trouveront toujours des défauts dans les idées, et la chose importante en travaillant avec eux à se rappeler c’est qu’ils ne le font pas pour ruiner votre merveilleuse idée, ils le font pour s’assurer que l’idée qui se transformera en projet a bien été pensée et que la plupart des problèmes possibles ont été anticipés. Cette attitude névrotique, paranoïaque et pessimiste est exactement ce que vous devez chercher chez un développeur, si vous chercher un code robuste, sûr et fiable.
Au contraire, un développeur optimiste sera enclin à penser que le code fonctionnera correctement, ou qu’il est sûr et vous donnera une deadline pour votre projet sans se soucier des problèmes qui l’attendent au tournant.

Feignant
La feignantise n’est jamais vu comme une qualité, et la plupart du temps ce n’est pas le cas. Ce qui par contre est désirable est la personne qui ne veut pas des tâches répétitives, ou gaspiller du temps à faire ce qu’une machine pourrait faire à sa place, ou encore écrire du meilleur code maintenant pour éviter d’y retoucher plus tard. Un développeur feignant est celui qui construit une librairie de code réutilisable, ou veut un processus de fabrication automatisé, plutôt qu’une série de copier/coller, ou encore des procédures de test unitaires rapides et simples, ou écrire du code surchargeable même si ce n’était pas demandé (plutôt que d’avoir à le refaire plus tard).
En bonus, en général un développeur feignant est celui qui essayera de garder le projet dans les rails et centré sur son objectif principal.
Par exemple, en designant une structure de catégorie, un développeur feignant assumera une structure 1-N (ou N-N), même si pour l’instant les besoins sont de type 1-1. Pourquoi? Parceque cela peut arriver un jour, et c’est plus simple de le faire maintenant que de le modifier après.

Curieux
Les bons développeurs s’ennuient souvent avec des tâches répétitives (cf Feignant) et passent une partie de leur temps à tenter de trouver des problématiques intéressantes à résoudre.
Les développeurs curieux seront constamment à la recherche de nouveaux problèmes à résoudre, et de meilleurs moyens pour résoudre d’anciens problèmes. Ils seront ceux qui encourageront à utiliser de nouvelles façons de travailler et transformeront constamment les systèmes existants. Ce seront aussi les plus conscients des problèmes actuels dans leur environnement de travail, et essayant de corriger ces problèmes. Les développeurs curieux ont en général une grande connaissance, pas seulement dans leur domaine ou langage, mais aussi de langages, solutions ou technologies alternatives.
La curiosité engendre souvent la créativité, un point aussi très désirable chez un développeur. Un profond désir de trouver des voix alternatives à un problème quand toutes les façons conventionnelles ont été usées est toujours utile. C’est ce genre de mentalité qui engendre “une pensée en dehors de la boîte” et du code créatif.

Méticuleux
Beaucoup de bons développeurs s’attachent aux détails. Ils demanderont de la constance dans leur travail, en particulier dans leur équipe (ils prennent en main par exemple, les standards et conventions de nommage par exemple). Ils voudront des tests unitaires et une revue de code régulière. Ils voudront que tout le monde dans l’équipe documente et annote son code. Ce seront ceux aussi qui vous embêteront avec les messages de log sous SubVersion (ou un autre logiciel de versionnning).
Ils seront aussi les plus pointilleux dans la communication, n’hésitant pas à poser des questions paraissant évidentes, juste pour être sûr de bien avoir compris la problématique. C’est d’autant plus vrai dans les rapports de bug par exemple. Même si ils ne sont pas souvent des communicants passionnés, ils sont souvent capables d’expliquer les concepts de façon clair et précise. Cette clarté est un avantage indéniable dans un environnement de production, en particulier si l’apprentissage est encouragé.

Article merveilleux qui résume toutes les qualité d’un bon développeur (en tout cas pour moi).
Par expérience, la bonne maîtrise d’une technologie ou d’un langage ne suffit pas, c’est surtout l’approche de la personne face au travail ou à certaines problématiques qui font de cette personne est très bon développeur.

Et vous vous en pensez quoi de cette définition?

Depuis Vendredi dernier… vilaine chute pour pas mal de blogs français (ou francophones) dans le nombre d’abonnés sur leur compteurs Feedburner.
Inquiétudes et questions (beaucoup sur twitter btw…)

La réponse semble assez clair sur les graphiques:
le 23 - 318 abonnés Netvibes

le 28 - plus que 49…

Pourquoi? ça c’est une autre question…

[et oui encore un article vilainement repompé sur WebWorkerDaily et remodelé… je sais j’ai honte, mais celui là, j’ai tenté de l’aborder plusieurs fois, 5 ou 6 brouillons sans succès, voilà qui me facilite un peu la tâche…]

Qu’est ce que tu fais?
Voilà certainement une des questions les plus durs à répondre. Certaines personnes ont plus qu’un job (dans la définition que les gens ont du job), d’autres ont une façon différente de travailler, alors que d’autres encore font un travail qui juste n’existait pas il y a encore 5 ans.
En tant que travailleur du web, vous faites sûrement partie d’une de ces catégories. Si vous pouvez répondre à cette question entre vous, pour les non initiés (vos amis ou la famille), la tâche s’avère plus compliquée.

Je suis développeur web, mais j’ai bien dû entendre une demi-douzaine de versions de mon boulot par différentes personnes. Certains pensent que je bosse chez Google, d’autres que je suis un vilain Hacker, que je passe mes journées en caleçon devant mon ordi, alors que la plupart disent que je “construit” des sites web.

Alors, quoi répondre à cette question dans votre futur dîner mondain, sans causer confusion et incompréhension pour ceux qui ne sont pas familier du milieu assez particulier du web?

Commencez avec la définition la plus simple de votre job
Tentez d’utiliser les mots les plus simples possibles, mais assurez vous que chaque mot compréhensible par votre public. Evitez d’utiliser du jargon trop technique. Beaucoup de gens n’ont jamais entendu parler d’Optimisation de Moteur de recherche (SEO encore moins), d’applications Web 2.0, ou encore de blogs.

Je suis développeur web = je construis la structure d’information de sites web
Je suis chef de projet tech = je dirige une équipe de développeurs
Je suis blogger = je partage mon savoir avec les autres

Ne vous inquiétez pas d’être trop simpliste et de dénigrer un temps soit peu votre travail. La plupart du temps, cela intrigue les gens et ils sont suffisament curieux pour vous demander des précisions, ce qui veut dire que vous pourrez enfin rentrer dans les détails de votre travail et pour qui vous travaillez.

Préparez des réponses aux questions les plus communes
Après avoir établi les bases, certaines personnes veulent en savoir plus - en particulier si vous mentionnez que vous êtes freelance ou en télétravail, ou un titre de travail particulièrement énigmatique. “Où trouvez vous du travail?” “Comment vous faites vous payer” “C’est comment de travailler en caleçon?” “Mais en fait vous avez une vraie vie, pas comme dans les films”. Répondez clairement à toutes ces questions (même les plus absurdes) et vous êtes sûr que les gens comprendront un peu mieux quel métier vous faites.

Dissipez les mythes
Vu le caractère restreint des Travailleurs du web, il est de bon ton de balader quelques mythes et idées reçues. La plupart du temps les gens les rapportent avec la ferme conviction de leur véracité, ne vous énervez pas, corrigez justes ces malheureux poncifs.

Malgré le fait qu’expliquer son travail en tant que travailleur du web, n’est toujours pas aussi simple… cela devient de plus en plus connu. Ces silences embarrassés et questions sur notre job risquent de disparaître d’ici peu.

Moi je dois dire que j’en ai assez d’expliquer 20 millions de fois mon travail, en général je botte en touche en disant “Je fabrique des sites web”. C’est débile mais au moins tout le monde comprend et ceux que ça intéressent me poseront des questions plus précises si ils veulent (et les autres me laisseront en paix, je sais c’est côté geek-associal qui ressort).
Et vous, c’est quoi votre méthode pour décrire votre travail?