L’un des sessions de TED est particulièrement intéressant. Simon SINEK parle essentiellement de ce qui fait que des gens/entreprises réussissent en dépit d’autres. Il prend l’exemple de Apple, de Martin Luther King et des frères Wright expose l’idée du Cercle D’or (The Golden Circle). A voir absolument!
PS : La session est en anglais, mais vous pouvez activer le sous titrage en français.

Pour ceux qui n’ont pas eu la chance d’assister a la conférence Symfony Live 2010 (dont je fais partie), voici les slides de l’ensemble des conférences.

Jour 1

• I18N with Symfony (pdf) par Thomas Rabaix
• Working with the Admin Generator par John Cleveley
• Symfony internals par Geoffrey Bachelet
• Using Doctrine Migrations par Dennis Benkert
• Doctrine 2 – Not the Same Old PHP ORM par Jonathan Wage
• The Symfony Community – How to (get) Help par Stefan Koopmanschap.
• Live discussion with the core team videos (partie1 et partie2) oar Ben Haines

Jour 2

• Okapi meets symfony, Symfony meets Okapi. par Lukas & Jordi from Liip
• Optimizing PHP Performances par Xavier de Cock
• Git 101 par Scott Chacon
• Using Zend Framework with Symfony par Matthew Weier O’Phinney
• Using symfony events to create clean class interfaces par Dennis Benkert
• Symfony in the Cloud par Kris Wallsmitsh
• Debugging and Profiling symfony applications par Alvaro Videla
• Build a platform from Open Source at Yahoo! par Dustin Whittle
• Symfony 2 revealed par Fabien Potencier

La gestion des sessions dans une application web est une tache critique, spécialement quand vous voulez réduire vos entrées/sorties et aussi de décharger la base de données si vous écrivez un gestionnaire de sessions personnalisé (session handler). Aussi, si votre application utilise plusieurs serveurs web, la tache de partager et des gérer les données de session devient un vrai casse tête. Ceci montre l’importance d’un gestionnaire  central de sessions pour que votre application tienne la charge.

Pour palier a ces problèmes, vous pouvez utiliser Memcached a l’aide de l’extension Memcached développée par  Andrei Zmievski et son equipe. Ceci vous permettra d’isoler le stockage des données de session par rapport aux serveurs web.

1. Installer le serveur Memcached

Sur une distribution debian/ubuntu :

1

apt-get install memcached

2. Démarrer les instances memcached

Nous allons démarrer deux instances sur la même machine. Cet article est une simple démonstration. Dans un environnement de production, vous pouvez déployer plusieurs instances sur plusieurs serveurs dans le même réseau.

1
2

memcached -d -l 127.0.0.1 -p 11211 -u  -m 16
memcached -d -l 127.0.0.1 -p 11212 -u  -m 16

Les deux commandes précédentes vont démarrer deux instances de memcached écoutant sur les ports 11211 et 11212, sur la même machine IP 127.0.0.1. Chacune d’elles va avoir une allocation de 16 Mo de mémoire.

3. Installer l’extension PECL memcached

Nous allons procéder a l’installation de l’extension memcached de PECL. Cette nouvelle extension dépend de la librairie libmemcached que vous pouvez télécharger de  https://launchpad.net/libmemcached et compiler sur votre machine. Assurez vous que les dépendances sont satisfaites.

1
2
3
4
5

wget http://launchpad.net/libmemcached/1.0/0.34/+download/libmemcached-0.34.tar.gz
tar -zxvf libmemcached-0.34.tar.gz
cd libmemcached-0.34
./configure
make && sudo make install

Ceci installe libmemcached, installons maintenant l’extension a l’aide de la commande pecl install :

pecl install memcached

Si tout va bien, le resultat sera comme suit :

Build process completed successfully
Installing '/usr/lib/php5/20060613/memcached.so'
install ok: channel://pecl.php.net/memcached-1.0.0
configuration option "php_ini" is not set to php.ini location
You should add "extension=memcached.so" to php.ini

Assurez vous que memcached.so existe dans votre répertoire extension_dir (ici /usr/lib/php5/20060613). Ajouter la ligne “extension=memcached.so” dans votre php.ini et redémarrez le serveur.
Pour vous assurer que tout est bien installée, vérifiez que votre phpinfo() vous fournit bien une section memcached avec les paramètres version, libmemcached version, session_support et lgbin support.
Il nous faut maintenant faire des changements dans le fichier php.ini pour enregistrer Memcached comme étant le gestionnaire de session :

1
2

session.save_handler=memcached
session.save_path="127.0.0.1:11211, 127.0.0.1:11212"

Redémarrez votre serveur, et le tour est joué! Vos donnes de session sont enregistrées et servis depuis les serveurs memcached, vous n’aurez plus de problèmes puisque vous pouvez étendre votre installation en ajoutant d’autres serveurs memcached.

Nos projets ont toujours des « deadlines » et des budgets, et nos clients attendent de nous de livrer le travail dans le budget et avant les « deadlines ».

Dans cet article, je vais essayer de partager mes connaissances par rapport à la question « combien cela va-t-il prendre de temps ? ».

L’importance des estimations

Vous ne connaissez pas peut être la vraie importance de l’estimation si vous n’auriez jamais eu à faire de la gestion de projet ou que vous n’auriez jamais eu une relation directe avec un client. Aussi, quand on est au poste de développeur et que l’on ne se soucie que du code qu’on écrit, on ne voit pas vraiment l’importance du sujet. Mais les estimations servent à déterminer plusieurs points importants:

- Déterminer les dates limites « deadlines »

Déterminer la date limite du projet est souvent la tâche du commercial. Mais dans la plupart des cas, les avis de l’équipe de développement influencent la décision en déterminant le temps que va prendre le développement d’une telle ou telle fonctionnalité. Le gestionnaire de projet peut suite à cette estimation élaborer un plan de projet qui prend en considération les requis de délai et la charge de travail.

- Déterminer les coûts

Avant qu’un client accepte d’acheter un produit ou un service, il veut toujours savoir combien cela va lui coûter. Aussi, dans le cas ou le projet nécessite plusieurs parties, le coût devient un facteur important. Même si le coût n’est pas vraiment le plus grand facteur pour beaucoup de projets (la ou la qualité et la confiance le sont), c’est toujours un facteur essentiel à prendre en compte.

- Déterminer la valeur

La valeur est différente du coût. En particulier dans le cas des estimations de nouvelles fonctionnalités dans un projet existant, votre estimation va beaucoup aider pour déterminer la valeur de cette fonctionnalité. Un client peut vouloir une liste de fonctionnalités, mais pas à n’importe quel coût. Il va comprendre qu’une fonctionnalité « fantaisiste » va avoir un coût significativement important de temps, il va alors vouloir repenser si elle est bien utile et s’il en a vraiment besoin ; ou à sa priorité s’il en a vraiment besoin.

- Éliminer la mal-compréhension

Si vous êtes ouvert à propos de vos estimations, vous allez découvrir les mal compréhensions et les mauvaises interprétations à un stage précoce. Si vous estimez par exemple une fonctionnalités à 3 jours de travail, et que vous discutiez ceci avec le client, il pourrait vous dire que c’est bien au-delà de ce qu’il pensait et qu’il voyait la chose plus simplement que vous ne la voyez. Si au contraire vous l’estimiez à 5 minutes, il va vous faire comprendre que vous l’avez peut être sous estimation. Spécialement dans les projets ou le prix est fixe, il est commun que les estimations ne soient pas ouvertes avec le client, mais en effet, le fait qu’elles soient ouvertes fait plus de bien que de mal !

- Améliorer vos estimations

La meilleure façon d’avoir de meilleures estimations est d’estimer, et d’évaluer par la suite les estimations. Si un projet est fini, analysez vos estimations et voyez ce qu’il y a eu de bon et de mauvais. Ceci va vous aider à être plus au courant combien de telles tâches prendront.

Le syndrome de l’étudiant !

J’aime bien cet exemple, j’avais lu ça il y pas longtemps et je trouve que ça fait beaucoup de sens :
En général, les développeurs sous-estiment plus qu’il ne sur estiment. L’une des raisons est ce qu’on appelle « le syndrome de l’étudiant ». Si les étudiants ont trois semaines pour finir un travail, ils vont glander les deux premières semaines et ils vont commencer à travailler la troisième semaine. Quand le travail s’avère plus important qu’ils ne l’auraient pense, la date d’échéance serait venue et ils auraient dépasse les délais.
Ceci est également le cas pour les développeurs, même si ils ne le font pas exprès, si vous aviez une tâche qui prend 4 heures, les chances sont grandes que vous allez utiliser plus que ces 4 heures. Même si vous pouviez la faire en 2 heures, vous voulez avoir un truc plus fantaisiste et passer plus de temps pour vos tests etc. c’est lorsque les 4 heures soient finies que vous réalisez que vous avez besoin de plus de 4 heures pour la finir, mais le temps serait déjà écoulé.
Une bonne façon pour éviter ceci est de vous donner moins de temps au lieu de plus. C’est un peu controverse mais si vous dépassez beaucoup vos estimations, vous tendez à les augmenter. Si vous n’avez pas pu finir la tâche en 4 heures, vous allez vous donner 6 heures la prochaine fois pour la finir. Mais si vous vous donnez 6 heures la prochaine fois, il y a de fortes chances que vous auriez besoin de plus de temps, et ainsi de suite.
Au lieu de ce faire, la prochaine fois, si vous estimiez une tâche à 4 heures, donnez vous 3 heures pour la faire lorsque vous commencez le travail. Vous aurez une heure de tampon à la fin de la tâche (l’heure tampon est calculée dans les estimations) et la chance de joindre vos estimations augmente.
En effet, quand vous êtes au courant du syndrome des étudiants vous allez faire de meilleures estimations et vous allez être capable de finir a temps.

Doubler les estimations

Ce scénario est très courant, on tend toujours à dire arbitrairement quand on a du mal à faire une bonne estimation : « ok, on va doubler les nombres ». C’est la décision la plus mauvaise que vous pourriez prendre. Si vous doublez les nombres, le syndrome de l’étudiant sera toujours présent et vous allez passer plus de temps dans le développement qu’il n’en est nécessaire. Aussi cette méthode va rendre les estimations arbitraires. A un certain moment, les estimations vont être plus importants que leurs valeurs commerciales, ce qui veut dire que l’équipe va passer tellement de temps sur un projet que ce dernier ne sera plus vraiment viable. Vous allez alors entendre vos client dire: « je ne vais vraiment pas payer CECI pour un simple site web ! », et vous aller savoir que vous avez certainement a revoir comment vos estimations ont été créées.

« Doubler les nombres est la chose la plus mauvaise que vous pouvez faire dans une estimation »

Au lieu de doubler les nombres, ce qu’il faudrait faire est plutôt de penser à un nombre dans lequel vous pensez que vous pouvez réellement développer la fonctionnalité, sans avoir à calculer un tampon pour chaque fonctionnalité. Ajoutez ensuite 30% au projet en entier. Ceci va aider à ne pas avoir le syndrome de l’étudiant parce que chaque fonctionnalité est basée sur une estimation réaliste et que vous vous êtes donnés une bonne période tampon si vous rencontrez un problème.

Les tâches non reliées au développement
Le temps non alloué au développement est souvent mal estimé et négligé. Ce temps comprend le temps de gestion de projet, de test, de mise en place des environnements, d’assistance pour la mise en production etc. Si vous estimez un projet, donnez de l’importance à ces tâches. Vous allez savoir par le temps combien qu’ils prennent de temps. Le temps de mise en place d’un environnement est constant, le temps de gestion de projet tend à être un certain pourcentage du temps total du projet, bien qu’il dépende de plusieurs facteurs comme le facteur client. Certains clients nécessiteront plus de temps de gestion de projets que d’autres. Ceci dépend en fait de la complexité du projet.

La meilleure estimation est la votre

Dans les grands projets, l’estimation est souvent faite par quelqu’un d’autre à part vous. Cela peut être par exemple un développeur senior qui a beaucoup d’expérience, bien que ce n’est pas lui qui va écrire le code. Toutefois, si vous travaillez sur un projet avec des estimations, traitez ces estimations comme votre budget, mais créez toujours vos propres estimations au préalable. Si vous trouvez que vos estimés sont très différents de votre budget, parlez avec la personne qui les a faites et essayez de comprendre le pourquoi de la chose, pour savoir si vous avez mal compris une partie, ou peut être que cette personne a dépassé quelques détails inconnus lors de son estimation. Le fait d’en parler va certainement permettre de faire une meilleure estimation.