06 mar 08 Cyberarmy, AOL illimité et e-zines: nostalgie,nostalgie :)

cyberarmy logo C’était le début des années 2000 et AOL proposait enfin un forfait illimité à internet en 56K… On avait rapidement flairé le bon coup avec les copains et vite fait de convaincre les parents de dégager de chez Wanadoo: il faut dire que de toute façon les forfaits de 15h ça faisait longtemps qu’on les explosait et les factures avec :) AOL avait rapidement été victime de son succès (comme Free quelques années plus tard) et avait pris quelques mesures drastiques: timer de 30 minutes pour empecher les connexions sans interruptions, liste noire (mythique) pour les abonnés qui faisaient péter les scores (nous). Il n’a pas fallu 48h pour qu’un programme permettant la reconnection immédiate ne fasse son apparition. Napster était encore la première plate-forme P2P et on découvrait la liberté dans le téléchargement…

A cette époque j’ai commencé à m’intéresser au hacking, au phreaking… une tripotée d‘e-zine dédiés au hack circulaient sur le Net et ça me laissait réveur.

De fil en aiguille j’ai fini par atterir sur le site de la Cyberarmy, qui proposait un jeu en ligne (peut-etre le premier?) permettant de tester ses capacités d’apprenti hacker sur différents niveaux. Je pense pouvoir dire que ce site a été un grand repère de barbus au début des années 2000, avec un dynamisme impressionnant! Faut dire que le système de grade permettaient aux gens de se prendre pour quelqu’un..

Cyberarmy était initialement une communauté internet d’hacktivist, organisée comme une vraie armée avec sa propre hiérarchie allant de trooper à CiC (Commander in Chief) et qui a peu à peu évoluée vers une organisation dédiée à la promotion d’un Internet libre.

D’après la CyberArmy.net Wikibase:

Cyberarmy is a community of computer enthusiasts who provide assistance to individuals and organisations to help them make effective use of the Internet as a tool for education, communication and collaboration.

Je ne suis pas vraiment au courant de l’impact effectif qu’elle ait pu réellement avoir :)

Toutefois elle proposait ce fameux jeu, Zebulun, qui était reconnu comme un très bon exercice. Malheureusement mis hors-ligne en 2003.

Mais hier alors que dans un accès de nostalgie je retourne fébrilement sur le site, que vois-je? Zebulun is dead, but Sered was born! Et le petit frère reprend la recette de Zebulun remis au gout du jour…
Du coup j’ai craqué :)

Moi j’en suis au niveau beta et vous ? ^^

Filed in Geekerie with 0 Comments

No related posts

27 fév 08 Accelerer significativement le chargement de vos pages avec YSlow!

yslow logo Sous ce titre racoleur au possible se cache un petit bijou d’extension pour Firefox: YSlow, qui s’intégre au non moins merveilleux add-on Firebug.
Aparté: si tu es webdeveloper mais que tu ne connais pas Firebug, fais-toi du bien et installe-le vite!

Bon ok, mais YSlow c’est quoi?

YSlow analyse les pages web et détecte tout ce qui ralentit le chargement de celles-ci. Il fait un rapport de performance, la liste des composants chargés et inclut des outils comme JSLint.
Et surtout vous pouvez ensuite facilement obtenir de l’aide sur les points qui bloquent grâce aux règles d’optimisation qui sont détaillées. Qu’est-ce que j’ai pu apprendre avec ce truc…

Let’s go

Revenons à nos moutons, à savoir YSlow. Il faut donc prélablement installer Firebug dans votre Firefox, puis YSlow lui-même.

Vous allez alors voir apparaitre un discret bouton dans votre barre grise en bas:
yslow barre des taches

Magiiique!!

Ensuite il suffit de cliquer dessus pour lancer la bête (après vous être rendus sur la page que vous voulez analyser, cela va sans dire!), puis de cliquer sur « Performance » pour obtenir le premier rapport:

Ce rapport sanctionne chaque point d’optimisation d’une note allant de A à F. A c’est OK, F c’est bouh! Bon il est un peu sévère sur la note globale (le rapport ci-dessus est issu de ce blog)… mais peu importe. En cliquant sur chaque point vous etes renvoyés vers la page des règles qui contient des conseils pour améliorer chaque domaine.

Ensuite en allant dans l’onglet « Stats » on obtient un rapport plus chiffré de la page avec/sans cache. Généralement là ça commence à faire mal aux yeux quand on voit la taille cumulée des javascripts…

YSlow stats

Enfin, last but not least, dans l’onglet « Components » on trouve une liste détaillé des composants chargés avec plein d’infos utiles comme le temps de réponse, son état de compression (ou non), la durée du cache..

Bref, c’est à installer absolument car:

Cela permet de détecter des faiblesses éventuelles dans l’optimisation des pages, sans omettre aucun point
et de travailler ces faiblesses grâce aux conseils!
et surtout, d’en apprendre encore plus sur le pourquoi du comment d’une page web…

Tout le monde aura compris, je suis fan. D’ailleurs maintenant vous passez tous à la moulinette :)
Je n’ai pas trouvé d’autre outil plus exhaustif pour l’optimisation des pages mais si vous avez, je suis interessé!!

Filed in Geekerie with 1 Comment

Articles en rapport (ou pas!) :

21 fév 08 Easter egg dans la page de maintenance de Blogmarks.net

Je viens d’aller faire un tour sur www.blogmarks.net à la recherche d’un compte oublié là-bas. Il se trouve qu’ils sont en pleine maintenance.

Heureusement ils ont une page pour le signaler, plutôt bien fichue, et qui rappelle les meilleures heures de la télé…

Regardez la vidéo un moment, easter egg inside !

Désolé pour le son pourri.. j’avais oublié qu’il était aussi capturé :D

Edit: J’ai envoyé un message à l’adresse indiquée et il vient de m’être retourné…
Edit2: Je l’avais envoyé à une mauvaise addresse donc forcément…

Filed in Geekerie with 0 Comments

Articles en rapport (ou pas!) :

19 fév 08 Du developpement offshore

Motivations

De plus en plus de sociétés déplacent leurs équipes de devéloppement à l’étranger. Pour 2 raisons principales:
- la première, évidente, faire des économies en s’installant dans un pays où la main d’oeuvre est moins chère (Europe de l’Est, Maghreb, Asie).
- la seconde, moins immédiate: trouver des gens compétents.

Peut-être avez vous déjà envisagé de délocaliser votre développement pour faire créer vos produits offshore. Et peut-être ne l’avez vous finalement pas fait, de peur de ne pas avoir suffisamment de controle sur une équipe pas suffisamment compétente? Cet article a pour but de vous convaincre d’y réflechir encore une fois!

Reglons tout de suite un point crucial et souvent bloquant: les développeurs offshore ne sont ni moins bon ni meilleurs que par chez nous ou aux US. Ils sont tout autant compétents. Par ailleurs, pour des raisons purement démographiques, il y a de fortes chances que vous en trouviez PLUS là-bas :) Oubliez-donc le préjugé selon lequel un développeur local travaillera mieux que 3 Indiens, c’est bas et infondé.

Le principal problème, ou plutôt la contrainte la plus importante est le fait que la communication devient évidemment plus difficile à assurer dans de bonnes conditions. Cela se décline sous plusieurs aspects, mais à chaque fois, c’est bien la communication qui est en jeu.

Des contraintes dont il faut être conscient

Il y a évidemment la barrière de la langue. Vous allez dire, pas de problèmes, de nos jours tout le monde parle anglais, surtout dans l’informatique. C’est pas faux. Sauf que 2 anglais discutant entre eux c’est différent d’un français conversant avec un chinois… Les quiproquos sont déjà fréquents quand on utilise les emails ou la messagerie instantanée en temps normal, alors imaginez entre 2 personnes n’utilisant pas leurs langues maternelles. Ca y est vous voyez? Alors bien sur il ne faut pas le voir comme une énorme barrière mais juste être très vigilant lors des échanges pour être sur que tout est bien compris (de la même façon!) de chaque coté. Quitte à insister lourdement. On vous sera toujours reconnaisant d’avoir pris le temps de réexpliquer et vous pourrez ensuite avoir l’esprit tranquille…

Une seconde contrainte est le décalage horaire. Cela parait difficile d’avoir une équipe en Inde travaillant au même moment qu’une équipe en France. Toutefois, dans ce cas comme dans tout travail avec l’Asie vous aurez quand même un créneau horaire (réduit) commun. A vous de l’utiliser au mieux pour effectuer les taches demandant d’être en contact direct avec l’équipe offshore. Le reste peut attendre qu’ils soient rentrés chez eux. Car on oublie aussi trop souvent une chose: si vous commencez votre journée, eux la finissent, et comme tout le monde en fin de journée, ils peuvent être moins réactifs alors que vous êtes frais et d’attaque!

Enfin, et comme avec toute équipe travaillant à distance, il est plus difficile de tisser des liens alors que vous nous vous rencontrerez probablement jamais face-to-face (pardonnez l’anglicisme). Par ailleurs cela peut éventuellement s’accompagner d’un léger décalage culturel. Alors oui, il n’est pas si facile de jauger les gens au début.
Il ne faut pas non plus que l’équipe offshore soit éloignée des utilisateurs. Au contraire, même si elle n’est pas à leur contact direct, elle doit se sentir concernée par leurs attentes! Si vous êtes l’intermédiaire c’est à vous de leur transmettre les requêtes des utilisateurs, mais aussi de leur dire combien ce qu’ils développent a du succès (ou pas) !

Il est très facile d’en demander trop à quelqu’un qu’on ne voit jamais. On s’autorise bien plus de choses dans le monde virtuel… Pourtant il est encore plus important que dans une organisation classique d’être conscient du niveau de stress de l’équipe et de parer à tout coup « de moins bien ». Il faut à tout prix éviter la démobilisation car elle peut être difficile à detecter et avoir des conséquences malheureuses sur l’avancement ou même le succès d’un projet.

Une méthode adaptée

Puisque le problème potentiel se situe au niveau de la communication il s’agit pour les commanditaires de s’assurer que tout ira pour le mieux de ce coté là.

Une première chose importante est d’avoir une vision précise votre équipe offshore. Savoir distinguer l’administrateur système d’un développeur Java ou de l’intégrateur XHTML/CSS. Cela rassure et vous disposez des ressources humaines de façon plus pertinente. Evidemment c’est la tâche du chef de projet d’allouer les ressources, mais garder un oeil sur ce qui est fait et montrer que l’on suit est primordial comme dans tout business. Vous êtes a priori le lien entre eux et les clients!
Vous pouvez imaginer aussi d’avoir un contact privilégié avec un des membres de l’équipe pour servir d’intermédiaire, sans oublier que les décisions se prennent avec le chef de projet. Il ne s’agit pas de titiller un ego…

Il ne faut pas hésiter à diversifier les canaux de communication. Il parait qu’on est passé au Web2.0? Alors il est temps de se servir de quelqu’uns de ses outils emblématiques:

Le Wiki:

Déjà utilisé depuis quelques temps par les équipes de développements, il permet de centraliser certaines ressources comme la documentation. Cela peut inclure les spécifications qui sont ainsi disponibles de façon transparentes pour chaque membre et qui peuvent être discutées, expliquées ou remaniées rapidement.
Une parenthèse concernant les specifications: si vous devez spécifier pour une équipe offshore, spécifiez 2 fois plus (ce qui reste peu dans le cas d’un développement Agile), et autant que possible en utilisant des images (quand c’est possible, par exemple pour tout ce qui touche au front-end). Pouff la barrière linguistique, à dégager! Il est très important de prendre le pli de centraliser toutes les informations dans le wiki dès que possible et de dissuader l’utilisation des e-mails, source de confusion. N’oubliez pas non plus d’expliquer le « pourquoi » d’une demande et d’éclaircir les attentes des utilisateurs. Cela rendra plus compréhensible la tâche à effectuer pour le développeur.

Un Blog:

Je sais que le blog a du mal à faire son entrée dans les entreprises… la plupart ont déjà compris son utilité en matière de communication avec les clients mais pas l’usage qu’elle pourrait en faire en interne. En voilà quelques uns: notifier à un groupe de personnes (couplé à l’utilisation du flux RSS), tenir au courant de l’avancement d’une tâche (cela peut servir pour le rapport quotidien dans le cas de la méthode SCRUM par exemple), signaler un prochain meeting..

Last but not least: la messagerie instantanée, Skype

Pas besoin de faire un dessin, cela fait un moment que tout le monde a compris l’utilité de Skype pour les discussions quotidiennes ou les questions qui appellent une réponse immédaite. Toutefois je preconiserai l’utilisation du multi-chat. L’idée étant d’avoir un channel de discussion ouvert pour toute l’équipe à n’importe quel moment. Cela permet de garder une trace de ce qui se dit, de tenir tout le monde informé et fait office d’enregistreur en cas d’absence :)

Enfin

Le développement offshore est encore trop jeune pour pouvoir garantir son succès. Toutefois la tendance semble se confirmer et même certaines start-up commencent à franchir le pas en voyant une occasion de réduire leur problèmes de fonds… Je connais des gens qui le déconseilleront. Mon avis est que bien managée il n’y a pas de raison que cela se passe plus mal qu’avec une autre équipe.

Quelques ressources: