Astuces pour la Fonera 2

Voici quelques astuces pour La Fonera 2, qui seront utiles à toutes personnes souhaitant profiter au mieux de sa petite boite blanche.

Changer le mot de passe pour activer les services d’accès

La Fonera 2 contient un petit bug peu connu qui ne permet pas d’activer les services tels le WebGUI ou le FTP vers l’extérieur si le mot de passe ne contient pas 8 caractères dont un chiffre. Changer le mot de passe pour suivre ces recommandations et rebooter la Fonera 2. Si vous avez deja activé les services en question, désactivez-les, validez et réactivez. Ceux-ci devraient alors être disponible de l’extérieur.

Passer en mode développeur pour obtenir la connexion SSH

Si vous souhaitez accéder via SSH à votre Fonera 2, vous devez impérativement passer en mode développeur, présent sur la page plugin du dashboard. Votre interface Fonera 2 passera alors en vert. Vous pourrez même fournir un accès SSH depuis l’extérieur a votre Fonera 2. A utiliser avec précaution. L’accès se fait avec le compte ‘root’ et votre mot de passe d’administration.

Interface Fonera 2 en mode developpeur

Interface Fonera 2 en mode developpeur

Accéder aux fichiers via un réseau partagé avec Vista

Vista a changé son implementation de Samba pour accéder aux fichiers via un réseau partagé. A cause d’un petit bug, celui-ci n’est plus disponible directement. Vous devez modifier la clé de registre suivante pour y accéder.

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel = 3 -> passez sa valeur a 0, le deblocage devrait être immediat. J’ai le même souci sous XP, mais cette astuce ne fonctionne pas. Si l’un de vous a plus d’info, qu’il m’en fasse part dans les commentaires. Je tiens mes infos de cette page.

Plugin Firefox pour ajouter des torrents et fichiers RapidShare/MegaUpload

L’équipe de la Fonera 2 a développé un petit plugin qui permet d’envoyer les torrents et fichiers RapidShare/MegaUpload en téléchargement sur sa Fonera 2 en un clic. Je vous le conseille fortement. C’est particulièrement utile.

  • FoneraDownloader (ne fonctionne qu’avec le firmware 2.2.6 de la Fonera, une mise à jour est nécessaire)
Plugin Firefox pour Fonera 2

Plugin Firefox pour Fonera 2

Liens à suivre pour tout connaitre de La Fonera 2

Logo FonShare

Logo FonShare

Retrouvez également sur CodePlex le projet FonShare, qui permet de partager des fichiers via FTP sur des groupes de Fonera 2 en toute sécurité.

Scrum, XP : A qui profite l’agilité ?

Il y a un très bon article dans le magazine Programmez du mois de Juin 2009 qui décrit Scrum, XP et la journée d’un développeur agile.

Formé à l’ancienne sur des méthodes de cycle en V, et ayant appliqué XP de manière intensive, j’étais dubitatif mais enthousiaste et intéressé par les nouvelles méthodes agiles, Scrum plus particulièrement. Je ne pensais cependant pas que la nature des concepts était si révolutionnaire que cela.

Pratiquant Scrum depuis maintenant 6 mois dans ma nouvelle entreprise, je dois dire que l’ensemble de mes concepts a été remis à zéro, sur de nouvelles bases, et de nouvelles méthodes. Et après ces 6 mois, je peux dire que mon opinion est faite. Scrum est une des meilleures méthodes de développement logiciel actuelles. Il était temps que l’informatique innove pour s’améliorer. Maintenant les entreprises vont devoir intégrer les méthodes, c’est un point plus difficile.

Mais revenons au titre de mon sujet. A qui profite l’agilité ?

Vraisemblablement, pour Programmez, la personne bénéficiaire est le développeur, et puisqu’il est plus productif, par conséquent, son employeur l’est également. Mais commençons avec le développeur.

Le développeur

Par un développement progressif, auxquels se succèdent tests unitaires, tests d’intégration et couverture de code, puis compilation sur un serveur de référence, le développeur gagne en retour, positif ou négatif, sur son travail. Il est alors mieux à même de connaître les impacts de ses nouveaux développements sur le code existant. Il est plus sûr de lui, plus confiant et donc plus à même de modifier, d’améliorer et progresser dans son travail. Le gain de productivité est très important. Avec la démonstration de son travail à la fin de chaque itération, les progrès sont concrets et perceptibles immédiatement par le métier, une relation de confiance s’instaure, la compréhension des partenaires métier et technique s’intensifie. La qualité des développement s’améliore.

L’architecte

L’architecte n’ayant « qu’à » dessiner les bases de l’application sur des besoins réels immédiats, en préservant tout de même des choix en cas de modifications ou d’améliorations importantes, il évite un travail d’approfondissement contraignant, souvent inutile et trop abstrait, et couteux en temps. Cette agilité lui permet donc de s’économiser pour travailler sur des tâches réellement importantes et à retour sur investissement court. Il gagne beaucoup en productivité. Le logiciel perd en complexité inutile et préméditée.

Le chef de projet

Il est difficile de définir un chef de projet en utilisant des méthodes agiles comme Scrum. On peut le confondre avec un ScrumMaster et/ou un chef d’équipe. Il peut également être assimilé à l’architecte. Cependant en faisant interagir les membres de son équipe comme un tout, directement avec le métier, la transmission de la connaissance et la fluidité de la communication lui permettent de diminuer les risques d’erreur ou d’incompréhension métier et/ou technique. Toutes questions étant posées lors des réunions quotidiennes et/ou lors des réunions de planning. Les temps morts, retours en arrière, frustation sont diminués, l’équipe gagne en productivité et connaissance métier, le chef de projet gagne en sérénité.

Le chef de produit

Celui-ci s’exprime directement avec les développeurs lors des plannings et démonstrations. Il est a même d’expliquer ce qu’il attend, ce qui va et ce qui ne va pas dans ce qui a été produit. Il fournit ainsi un dialogue direct qui permet aux développeurs de comprendre plus facilement ce qui doit être fait et comment. Avec des déploiement fréquent, il reçoit également son logiciel dans des délais plus courts et en fonction de besoins réels immédiat. Son équipe gagne en productivité, par l’utilisation de fonctions développées en priorité, selon ses propres recommandations. Il gère mieux son travail, celui de son équipe et le futur de son organisation. La productivité métier est accrue.

Les décideurs

Le premier objectif des décideurs dans l’application des méthodes agiles est d’augmenter la productivité des développeurs pour que ceux-ci augmentent la productivité du métier, et afin que ces derniers augmentent le chiffre d’affaire et surtout le bénéfice de l’entreprise. Si la productivité des développeurs est assurée, celle du métier sera alors encore plus importante, le pari est donc gagné.

Mais revenons sur le terme de l’agilité. Le fait que le retour sur investissement (ROI) avec les méthodes agiles soit court, 2 à 3 semaines, va permettre aux décideurs de pouvoir décider (c’est leur métier après tout) et faire appliquer leur décision sur des cycles plus courts, vraisemblablement une à deux itérations. Ils pourront ainsi s’adapter plus rapidement aux marchés et emprunter des chemins aujourd’hui impossibles sur des méthodes traditionnelles, type cycle en V.

Reprenons le schéma que j’avais fourni lors d’un précédent post : Scrum : De l’intérêt des méthodes agiles

Comparaison des coûts de production et productivité entre Scrum et méthode standard

Comparaison des coûts de production et productivité entre Scrum et méthode standard

Ce schéma montre les coûts de production logiciel et la productivité du métier.

Dans le cas de développement avec la méthode de cycle en V (ligne verte), le décideur n’a d’autres choix que d’attendre le déploiement du logiciel en production avant de placer ses équipes sur un autre développement, plus stratégique (sauf à retirer quelques ressources, mais en impactant le planning de déploiement de son logiciel en cours).

Avec les méthodes agiles, le métier est plus productif dès la seconde itération (ligne rouge). Si le décideur choisit d’interrompre les développements logiciels, il peut le faire, premier point, mais il peut également calculer le gap entre la productivité actuelle et maximum du métier avec les développements restants et choisir de réorienter une partie ou l’ensemble de son équipe sur des points plus stratégiques.

En définitive, s’il est un acteur de l’entreprise qui gagne en agilité avec les méthodes agiles, c’est le décideur. Des décisions en connaissance de cause, moins pénalisante, plus stratégique, plus rapide et plus efficace.

L’agilité est aux décideurs. A eux de faire les bons choix.

Travailler plus, non, travailler mieux, oui !!!

Voila un refrain que l’on entend rarement.

Dans les métiers de l’informatique, qui sont en crise actuellement (sauf dans la petite bulle de Saskatoon, qui semble résister à tout), le refrain qui revient souvent c’est « travailler plus pour satisfaire nos clients », « soyez plus motivé, soyez plus investi ».

C’est une belle phrase mais qui sonne souvent comme un non-sens lorsqu’on la vit de l’intérieur.

Employés, employeurs, arrêtez de dire n’importe quoi.

Au premier, chers développeurs, je dirais :

« Affûtez votre outil » ou comme le disait Abraham Lincoln « If I had six hours to chop down a tree, I’d spend the first four hours sharpening the axe. » Littéralement « Si j’avais six heures pour couper un arbre, je passerais les 4 premières heures à affûter ma hache. »

Ce qui veut dire, Messieurs, Mesdames les développeurs, réfléchissez avant de faire afin d’être plus efficace. Restez au fait des technologies, prenez le temps d’étudier les outils qui peuvent vous rendre plus efficaces, expérimentez et appliquez, en un mot, Osez !!! Vous aurez besoin de moins de temps pour la même charge de travail.

Bien sûr certains vont me répondre, mais nous n’avons pas le temps de réfléchir ou d’étudier ou d’expérimenter. En clair,  « Je n’ai pas le temps d’affûter ma hache, il faut que je coupe cet arbre. » Ben voyons !

Lorsque vous créez votre environnement de travail, prenez le temps de le configurer afin d’être le plus efficace, même si cela doit vous prendre une heure, deux heures ou huit heures. Si grâce à cette configuration, vous êtes capable de gagner 10 ou 20 minutes par jour, vous verrez que l’investissement est très vite rentable.

Il en est de même pour vos développements. J’ai l’exemple d’un développeur qui s’est « amusé » à écrire son parser pour un format de fichier XML fait maison. Alors qu’il existe des outils qui vous permettent de générer le code afin de parser automatiquement votre fichier. Dans le deuxième cas, le code est optimisé, rapide à mettre en place ou à mettre à jour. Dans le premier cas, il faut le temps de l’écrire, de le tester, le remettre à jour manuellement. Mais voila, le développeur n’avait pas le temps d’étudier l’outil. Dommage.

Au second, chers employeurs, je dirais :

Arrêtez de rogner sur des coûts, qui certes font baisser vos dépenses, mais font baisser également votre production. Alors, oui, vous pouvez compenser en faisant travailler plus vos employés, mais si ceux-ci pouvaient l’être sans toujours avoir à travailler plus.

Pour cela, quelques règles simples et rapidement rentables :

  • Fournissez un second écran voire un troisième écran à vos employés : une étude de Microsoft montre que la productivité augmente de 9 à 50%. Coût de l’opération : 200€, pour un ingénieur avec un coût de 1000 euros par mois et une productivité accrue de 15%, l’investissement est rentable en seulement un mois et demi, et vous gagnez 15% de productivité sans travailler plus. Ce qui signifie sur une journée de huit heures, une bonne heure et demie de gagnée, (mon employeur actuel l’a bien compris, j’ai eu un second écran dès le premier jour et tout le monde en a un, même la secrétaire)
  • Fournissez un espace de travail suffisamment grand. Je vois des managers expliquer qu’ils ont réussi à faire rentrer un développeur dans moins d’un mètre carré et qu’ils peuvent ainsi économiser 5000 euros par an en frais de structure. Super, mais le développeur n’a pas les moyens de poser son clavier et un cahier sur son bureau. Perte de productivité, facilement 15%, si ce n’est 25%. Par rapport au coût sur la marge totale, ça fait une belle différence et pour le salarié également. Permettez au moins à vos collaborateurs de respirer et de poser plus de 2 feuilles sur leur bureau. Fournissez leur également de quoi ranger leurs affaires, un placard, des tiroirs et pas dans la pièce d’à côté, s’il vous plaît,
  • Fournissez les outils qui augmentent la productivité. Imprimante, téléphone, logiciels et matériels de qualité. Je me rappelle avoir vu une fois, une imprimante, type imprimante personnel basique pour 80 personnes, à un autre étage dans un autre local, fermé à clé. Tout de suite, vous découragez vos développeurs d’imprimer, belle économie de papier et d’encre. Mais belle perte de productivité également. J’en ai vu d’autres qui préféraient des outils Open Source gratuits plutôt que l’investissement dans un logiciel performant mais payant. J’ai un bel exemple avec MS Project. Je passais mes vendredis entiers à essayer de mettre à jour mon super logiciel gratuit afin d’avoir des dates de fin pour mon projet, alors que la même chose était possible avec MS Project en moins d’une heure. Coût du logiciel : 1000 euros, gain de productivité : +20%. Rentabilité garantie. Je suis fan de logiciels libres, mais il faut également savoir réfléchir.

Alors à toutes ces règles simples, vous me répondrez, oui, mais moi qui vends des hommes, ça me coûte. Un développeur qui travaille plus, ça ne me coûte pas plus cher, il est payé le même prix. Et en temps de crise, il le fait même sans qu’on lui demande.

Et je ne peux que répondre :

Super !!! Logique implacable.

Accompagnez vos développeurs

Depuis quelques temps, je lis beaucoup de documentations sur la gestion de projet avec Scrum, le Lean Development, l’eXtreme Programming et l’agilité. Je suis toujours ravi de voir qu’une des bases de ces concepts est de fournir un produit avec une structure technique de qualité. Qualité de l’architecture, qualité de la documentation, qualité du code.

Mais chaque fois que j’arrive dans une nouvelle entreprise, je suis toujours étonné de la qualité de ce qui a été conçu.

  • On parle d’architecture, mais il n’y a pas d’architecte.
  • On parle de documentation, mais il n’y a pas de document.
  • On parle de logiciels, mais lorsqu’on étudie le code, on voit clairement le concept principal, « je code vite, je code pour que çà marche, le reste (bon code, commentaires, syntaxe généralisée) on verra plus tard (c’est à dire : jamais)« .

Je crois avoir presque tout vu :

  • Des classes avec le nom du développeur, très pratique quand il ne fait que passer sur le projet,
  • Du code très très technique qui marche à moitié, mais dont on ne sait pas grand chose car il n’y a aucun commentaire, aucune doc et puisque le développeur est parti depuis de nombreuses années,
  • Du code de base, mais sans aucun commentaire, aucune règle, aucune organisation,
  • Des méthodes très longues (+ de 2000 lignes),
  • Du code avec plus de codes commentés que de codes exécutés,
  • Des classes avec des méthodes sans paramètres, les membres de classe sont utilisés comme paramètres, imaginez l’enchevêtrement lorsque le code n’est pas exécuté dans le bon sens,
  • Des membres de classes définis par le constructeur mais jamais utilisés, pratique lorsqu’on se dit que la classe pourrait répondre à nos attentes avec un paramètre mais qu’il n’en est rien,
  • Des projets où tous les fichiers (pages web, classes, javascript, images, fichier de properties…) sont à la racine du projet, aucun dossier, super pour rechercher ses fichiers,
  • Des classes avec l’ensemble de toutes les valeurs utilisées éparpillées dans le code, en dur, répétées des dizaines de fois. Vous changez le nom d’une valeur, il faut le changer dans 10 classes différentes, imaginez lorsque vous travaillez sur un fichier xml et que l’ensemble des balises est répété à plusieurs endroits, comprendre le code, le modifier ou le réutiliser sont un vrai bonheur,
  • Des logs en dur avec System.out partout, avec marquez « toto3, « test1 » ou « passe par ici », « passe par là »,
  • Des centaines de lignes de code copier-coller, avec une ou deux lignes qui changent, comme ça, pour corriger les bugs, ce sera le bonheur,
  • Des développeurs qui, pour adapter leur projet à un process particulier, préfèrent créer une nouvelle branche et faire les quelques modifications qui s’imposent, plutôt que de faire fonctionner leur esprit afin d’ajouter un paramètre dans une méthode,

Ce ne sont que quelques extraits, et ils ne sont pas réservés à des développeurs junior, bien au contraire.

La seule société où j’ai pu travailler sur un code de qualité remonte à ma première expérience en Suisse. Certes les Suisses sont connus pour la qualité de leur travail, mais on peut dire qu’ici le code (et le développeur) était traité avec le respect qui lui est du. Règles de développement, commentaires, documentations, process strict, packages, rôles… Débuter dans cette société m’a permis d’intégrer un point essentiel que tout développeur devrait maitriser. Le développement de qualité.

Et lorsque vous croisez un ‘mauvais’ développeur (mauvais dans le sens où il ne respecte pas de standard en développement, commentaires, organisation), vous ne pouvez pas le blâmer. S’il n’a pas été éduqué pour faire du bon code, il faudrait qu’il prenne sur lui afin d’apprendre seul, ce qui n’est jamais facile.

Qui blâmer alors si on ne peut pas blâmer le développeur ?

Facile, son supérieur direct. Le chef d’équipe ou le chef du projet. On entend souvent qu’un chef d’équipe ou un chef de projet informatique n’a pas besoin de connaitre l’informatique pour être un bon chef. Faites moi rire, vous en connaissez beaucoup des chefs IT qui n’ont jamais fait de développements ? Je n’en ai jamais croisé.

Son rôle est certes de gérer l’équipe ou le projet mais il est également de s’assurer de la qualité de ce qui est produit et pas seulement que le produit répond aux attentes ou non. Ce serait un peu trop facile.

Alors oui, c’est long, oui, c’est fastidieux, oui, il faut répéter, insister, vérifier, re-vérifier. Mais si vous voulez des développeurs de qualité, il vous faut fournir un travail de qualité. Si vous ne faites pas ce travail avec vos développeurs en controlant, expliquant pourquoi vous voulez ceci comme ca, et pas autrement, vos développeurs ne seront jamais de bons développeurs et vous aurez des difficultés par la suite à faire avancer votre projet. Prenez le temps maintenant, vous en gagnerez beaucoup plus tard.

Accompagnez vos développeurs !!!

%d blogueurs aiment cette page :