Aujourd’hui deux applications extrêmement utiles pour tous les Travailleurs Du Web qui sont sur Mac (désolé pour les Windowsiens/Linuxiens si quelqu’un veut écrire des articles Win/Linux il est le bienvenu…)

MacFusion
Je vous avais déjà parlé il y a de cela quelques temps de MacFuse et SSHFS qui permettait de monter un accès SSH à votre serveur sur un lecteur réseau… seul problème à chaque ouverture, il fallait retaper le mot de passe, l’adresse ip, etc… aujourd’hui le problème est réglé puisqu’avec MacFusion, vous montez vos lecteurs réseau en un clic.
C’est ULTRA pratique, une des deux raisons pour moi (avec TextMate) pour lesquels tous les dev OpenSource devraient switcher sur Mac (oui je sais je suis un peu extrémiste, mais j’assume totalement).
Vous pouvez trouver MacFusion ici (et je pense que vous devez installer MacFuse avant, à confirmer)

DesktopCurtain
Un petit utilitaire bien pratique si comme moi vous avez un bureau plutôt bordélique (je fais le ménage régulièrement mais 95% du temps ça reste un peu le fouilli), mais que de temps en temps vous avez besoin de faire des captures d’écran ou des screencast sur un bureau vierge et propre…
DesktopCurtain est là pour vous, puisqu’il affiche un bureau clean au dessus de voter Desktop, sans toucher à vos fichiers stockés un peu n’importe où sur votre bureau…
C’est disponible ici et c’est gratuit!

Lors de la conduite d’un projet, les pièges sont nombreux surtout niveau technique, voici donc une petite liste des écueils connus à éviter à tout prix.

1. Conception fermée
C’est souvent une des difficultés majeurs pour le suivi d’un projet technique. Le projet en cours de route évolu, change, se métamorphose… certains fonctionnalités disparaissent, d’autres apparaissent, des contraintes nouvelles viennent s’ajouter au projet. Tous ces changements doivent pouvoir être pris en compte au fur et à mesure et ne pas être un frein pour le bon déroulement technique du projet. La conception aussi bien de la plateforme de production, que de la base de donnée ou de l’applicatif doit être flexible et ouverte… donnant du champ à des modifications.

2. Outils performants
C’est un des pièges récurrents, principalement dans les grandes structures, trouver des outils performants qui ne freinent pas le développement. Cela peut consister en des machines vieillottes ou qui tombent en panne, des problèmes réseau, des serveurs de l’ère du crétacé… ou simplement des procédures de mise en ligne trop longues qui vous bouffent votre temps de développement.

3. Versionning / sauvegarde
Un de vos soucis (si vous suivez un projet) est de s’assurer de deux choses:
- que des sauvegardes régulières sont faites aussi bien des données que du code source, à des intervalles réguliers, en essayant de varier les supports et en archivant régulièrement (je me souviens plus où j’avais lu ça, mais une étude avait montré qu’environ 20% des boites high-tech fermaient les portes après un accident de matériel faute de vraie politique de sauvegarde).
- que les développeurs ne se marchent pas sur les pieds, et donc utiliser un outil de versionning… éviter les cas classiques, qui sont: pierre enregistre un vieux fichier qu’il avait en local et bousille une semaine de boulot de paul, ou encore pouvoir revenir à une version précédente du code, très très pratique.

4. L’euphorie post-démo
Souvent pour sortir une démo à temps, on est tenté (et certaines fois on a pas trop le choix) de couper dans certaines principes qu’on c’est fixé… on fait des dev un peu plus cradocs, on néglige certaines parties, etc… rien de dramatique en soit, si on redresse au plus vite la situation. Le risque majeur est qu’on ait pas le temps de redresser les petites cochonneries qu’on a pu faire pour que la démo marche et que l’on continue dans cette voix. Pansement sur jambe de bois, sur bout de scotch, sur bout de ficelle et on va à moyen terme dans le mur.

5. Garder le cap
C’est une des tâches les plus dures et c’est un des rôles essentiels du Chef de projet technique: emmener tout le monde dans la même direction, avec le moins d’accrocs possibles, avoir une double vision: macroscopique du projet, mais aussi aller dans les détails du code ou de la conception de données pour que le projet fonctionnellement et techniquement ailles dans la bonne direction.

Il doit certainement ex exister d’autre mais ce sont les 5 principaux écueils à éviter quand on gère un projet technique. Et vous des expériences ou remarques à partager?

[oui c’est bien l’un de nous qui comate pied nu à 6h du matin par terre!]

Voilà après près de 21h de code, debuggage, montage, adaptation presque ininterrompu (on a quand même pris le temps de manger de temps en temps, sans compter les X clopes que je me suis envoyé durant la nuit, je sais c’est pas bien) me revoici de retour à mon poste après quelques heures de sommeil.
La démo était prête le jour dit, donc aujourd’hui à 7h du matin environ… hourra!
Un peu la tête dans le sac (j’ai faillit choisir une autre expression, mais non… restons léger et courtois) mais content d’avoir pu délivrer le résultat attendu (ou presque à quelques iotas près) plus ou moins dans les temps.

[6h30 on est super fresh!]

Mais le propos du jour n’est pas vraiment la nuit passé sur la démo (enfin partiellement en tout cas), mais plutôt sur les derniers jours d’un projet qui sont toujours importantes, stressantes et décicives.

1. Jamais dans les temps
Dans toute ma (longue?) carrière, je n’ai JAMAIS (et là un doute m’assaille, est ce que je suis nul? nan…) rendu un projet dans les temps, jamais. Toujours des fonctionnalités qui viennent s’ajouter, des zones d’ombres pas levées avant le développement du module, des difficultés techniques imprévues, etc… Donc si vous voyez que votre projet du retard, c’est (plus ou moins) normal, pas la peine de stresser outre mesure.

2. Eviter le stress non productif
C’est sans doute une des clefs pour boucler un projet… c’est l’ultime conseil que je pourrais donner, ne vous auto-stressez pas avec des angoisses de dernière minute non productive, du type le serveur qui plante et qui veut pas re-démarrer. Calmez vous (et les gens autour de vous), allez faire un tour, buvez un coup, fumez une clope (ou mâchez un cheawing-gum)… revenez serein (même si c’est pas complètement le cas) et résolvez le probème calmement. Souvent du stress vient plus d’erreurs que vous devrez corriger par la suite. Prenez les problèmes dans l’ordre de façon méthodique, même si tout le monde stresse et s’énerve, cri ou pleure… restez serein et concentré sur votre task-list.
Surtout lors du débuggage final, vous trouvez de temps en temps des effets de bord (qui pour une bonne partie se corrigent d’eux même après avoir fixé les principaux bugs déjà listés), ne vous jetez pas dessus, notez les et suivez calmement votre tasklist, sinon vous risquez de vous disperser et de passer encore plus de temps dessus.

3. Se concentrer sur l’essentiel
Vous ne pourrez pas livrer toutes les fonctionnalités à la date prévue? pas un drame… concentrez vous au maximum sur le coeur de votre projet, les fonctionnalités à très forte valeur ajoutée. Si le reste passe à l’ouest, pas grave, vous aurez peut être un peu de temps pour vous y atteler, quand l’essentiel sera réglé.

4. Redimensionner le résultat au besoin
N’hésitez pas à zapper certaines fonctionnalités pour les inclures dans une livraison suivante. Mieux vaut un projet réduit mais bien fini, qu’un produit bordélique, plein de bugs et baclé.

5. Les merdasses de dernière minute
Gardez vous un peu de temps pour parer aux éventuelles merdasses qui ne manquent pas d’arriver, surtout si vous partez pour un environnement hostile (une démo chez un client). Prévoyez un ordinateur de secours si le votre tombe en rade, une sauvegarde sur DVD ou bien un accès via le web… ou suivant les cas, quelques heures pour assurer une mise en ligne correcte (on sais jamais ce qui peut arriver aussi bien à l’export qu’à l’import). C’est souvent les dernières heures qui sont les plus cruciales, qui font que votre travail de quelques semaines/mois seront évalués à leur juste valeur (ou pas).
Prévoyez donc une marge confortable pour tout ce qui peut arriver dans les dernières heures et ne mettez pas en ligne à la dernière minute, prévoyez une mise en ligne intermédiaire quelques heures avant (ce qui vous permettra de voir éventuellement si la mise en ligne est rapide ou si elle nécessitera plus de travail).

[le dernier transfert de la base de donnée en local sur le laptop de mon boss, qu’on a du refaire trois fois!… à 6h43 la dernière ligne droite (on voit d’ailleurs les pieds du comateux en bas de la photo à gauche…)]

Et vous, des anecdotes/histoires de finalisation/mise en ligne de projet?

Chacun à sa méthode, ses outils favoris, pour prendre des notes, organiser ses tâches, plannifier ses todo, etc…
Pour ma part:
- Gmail pour les reminder (je m’envoi des mails à moi même et quand c’est fait je mets en archive avec un label particulier pour les différentier des autres emails)
- Prises de notes sous TextMate (parcequ’il est ouvert en permanence et que j’adore cet éditeur de texte)
- Mon bras gauche (puisque je suis droitier) comme over pense-bête (comme sur l’image, avec un feutre noir bien indélébile) pour ne pas oublier les trucs ultra important.

Et vous c’est quoi vos outils, méthodes?

Cela n’est pas ma dernière provocation ou une question métaphysique débile…
Depuis quelques jours, je me demande vraiment à quoi ça sert. Je suis inscrit sur LinkedIn, Xing, Viadeo, Facebook, Plaxo et à part ajouter des personnes qui sont soit des amis, soit des collègues, soit de vagues connaissances, je ne voit pas trop quoi faire avec tous ces contacts. Je ne les utilisent pas pour trouver un travail (j’en ai déjà un, mais pour ma recherche de taf ça n’a rien donné), je ne les utilise pas pour contacter mes amis, puisque en général je préfère le téléphone ou le mail.

Franchement à part consommer un temps impressionnant, à quoi sert un réseau social?
Certains me diront à étendre son réseau de connaissance… ok, mais pour faire quoi?

Si vous avez des pistes ou des réponses (ou des réflexions) je suis preneur…