blog.nraynaud.com Langages

Select which gem to install for your platform (i686-darwin8.10.1)

1. hpricot 0.6 (mswin32)
2. hpricot 0.6 (jruby)
3. hpricot 0.6 (ruby)
4. hpricot 0.5 (ruby)
5. hpricot 0.5 (mswin32)
6. Skip this gem
7. Cancel installation

Ah, et on m'informe qu'en plus la version 1.0 de hpricot (aucune idée de ce que c'est) est sortie.

Encore des gens qui n'ont pas lu Cooper Don’t stop the proceeding with idiocy.

J'ai prévu de ne pas aller chercher d'argent pour mon aventure, je veux pouvoir en faire un truc tordu si je veux. Faire entrer d'autres personnes dans l'histoire oblige à adhérer à des normes communes et donc pas tordues. Surtout si ce sont des gens de la banque, ça va sérieusement recentrer la norme commune vers les parquets, lambris et costumes anthracites, assez loin de la veste en cuir et de la guitare.

Donc bootstrap, je démarre tout seul. Avec tous les inconvénients et les avantages de la chose. Mais surtout du Rock'n'roll

Sauf que ... même seul dans mon aventure, je ne suis pas seul dans le monde. Et les questions pleuvent : Sais-tu combien il y a de licenciés dans les clubs de sport amateur en France ? Aucune idée de toutes façons je vise pas les licenciés spécifiquement As-tu un budget prévisionnel ? Ben j'pense que pour 1500€ par mois je peux vivre, me loger + ADSL Tu sais combien ça rapporte la pub en France ? Heu ben ... .

Finalement, j'ai eu un chiffre aujourd'hui en discutant avec un collègue (je quitte mon entreprise demain) : 3000€, il existe un site de particulier francophone qui fait 3000€ par mois de revenu publicitaire avec google adwords. Maintenant se pose la question de la comparaison, j'ai un public plus ciblé, ça veut dire que je vends des pubs plus cher ou qu'elles seront moins vues parce que mon public est plus restreint ? Aucune idée.

Bref, aucune idée de l'avenir, mais ça va bien se passer ...

Puisque le combat moderne est la lutte pour le standard de vie, alors je veux habiter à côté d'un spot de surf. Plus dur : j'ai pas le permis, et je veux un logement pas trop cher. Il me faut l'ADSL et un train pas trop long pour Paris.

voilà voilà voilà

Bon, c'est le grand saut, j'ai démissionné le 10 septembre, mon boulot se termine le 24 décembre. Probablement mon dernier emplois salarié. L'équipe de développement est la meilleure que je n'ai jamais vue, et en 2 ans elle s'est transformée plus qu'il n'est imaginable. Dommage que le reste de l'entreprise n'ait pas suivi.

J'ai appris beaucoup, en positif comme en négatif. J'ai enseigné beaucoup aussi je crois. Bref, un petit voyage initiatique. J'en sors avec un bagage en marketing produit, avec un bagage en product management (même si je n'ai pas eu le poste de product manager que je voulais), et un bagage en développement.

Le plus dur reste devant : pas de CV, pas d'entretiens d'embauche, négociation, nouveaux collègue etc. Mais trouver un logement sans contrat de travail, monter un site web, attirer du monde, répondre intelligement à leurs besoins et arriver à en vivre.

Pour l'instant, je télécharge glassfish, j'ai acheté la license Intellij IDEA avant-hier. Ma connection ADSL est en panne à la maison, le support technique de free est inefficace, je vais résilier tout de suite, j'irai dans le cybercafé à côté de chez moi.

Je vais donner l'évolution de mon projet ici pour les intéressés.

DONE :

• sortir du chômage
• trouver une boite pas trop mal
• quitter Paris
• partir en dev
• devenir cadre

TODO :

• sortir des petits salaires (avoir un salaire de débutant au bout de 2 ans de boulot, c'est un peu minable)
• sortir du dev par le haut
• écrire un bouquin sur le génie log./objet
• écrire un bouquin sur les env. d'exécution peut-être sur les langages aussi
• diriger une petite équipe (et correctement)
• sortir un produit sur lequel j'aurai eu un impact significatif et dont je sois fier
• sortir un produit grand public qui marche
• me débrider le cerveau (peur du vide, manque d'engagement dans les manoeuvres sportives)
• avoir un charisme niveau honorable
• fonder une boite qui marche

Cher chef, tu sais que tu peux prendre une part active dans la réduction de cette dernière liste ....

Je suis toujours sur cet excellent bouquin de Sutton :

In a study in an Israeli Army boot camp, for example, instructors were just told that based on information from a battery of tests on an incoming group of soldiers, it was possible to predict with 95 percent accuracy wich one-third of the soldiers had high command potential. The other soldiers were said to have either regular or unknown potential. The soldiers were actually randomly assigned to the "high", "regular" or "unknown" conditions, and no other information was provided about command potential. Yet, at the end of the 15 weeks in boot camp, soldiers who leaders belived would have high levels of performance did far better on objective performance tasks like firing a rifle, navigation, and multiple choice tests about combat tactics, administrated by instructors who were not informed about the experiment.

C'est ça qu'il me manque, si je n'ai pas confiance dans mes collègues, alors d'une part je les infantilise et j'aspire leurs facultés d'initiative. Si je contrôle ce qu'ils font je les bride et ils sont moins autonomes y compris au niveau mental. Comment moi-même prendre confiance en eux ?

Même si je ne suis pas chef de l'équipe, je sais que j'ai une grande responsabilité, je suis là pour développer le réalisme technique. Faire le lien entre le fric que le client met dans le produit et la ligne de code, et être garant qu'il existe une vision pour cette appli (j'utilise une formule détournée, car il serait idéal que chaque développeur ait une vision cohérente des choses, partagée ou unique). Déjà il faut arriver à convaincre le boss de la responsabilité individuelle de chaque membre de l'équipe, arrêter de contrôler d'aussi près les membres pour qu'ils récupèrent une responsabilité perdue. Les laisser faire leurs compromis, et même ne pas leur demander de les formuler oralement a priori mais uniquement a posteriori pour ne pas que leur "parole donnée au chef" ne soit engagée.

Prendre confiance en moi, prendre confiance en eux, convaincre le chef. Et finir de lire ces bouquins, ils me font du bien, mais qu'en est-il de l'application ?

J'arrive à prendre conscience un peu mieux de mes erreurs de communication. Récement j'ai présenté un nouveau découpage par : "c'est comme ça que sera l'application à partir de maintenant" évidement, c'était infantilisant, j'ai lapidairement présenté un argument en la faveur de ce découpage. L'idée de cette intervention était de ne pas m'étendre, je prenais la parole 10min en fin de conférence, mais ces 10min auraient été mieux dépensées à présenter un chemin logique partant de la situation précédente à la nouvelle. Et le lien avec l'argent du client.

• je peux suggérer une idée sans crainte,
• cette idée peut être une connerie sans que les conséquences soient grave,
• cette idée peut être adoptée,
• je peux reconnaître publiquement que c'était une mauvaise idée sans crainte,
• je peux interrompre l'intégratlité de l'équipe de dev pendant 2h par un essai infructueux,
• on me fabrique une place sur mesure quand on s'apperçoit que je suis pas trop adapté à XP.

Je ne comprends toujours pas pourquoi je ne suis pas heureux. A part que j'ai envie de sortir, le produit. Tout de suite, pas demain.

J'ai implémenté une petite feature sur un fileChooser : un rappel des derniers choix dans une liste à gauche.

Aujourd'hui, entre 2 interruptions j'ai refactoré l'engin jusqu'à ce qu'il soit dans un état à peu près digne. Lors de ce screenshot, la liste ne contenait qu'un seul élément, la boite ne revenait pas automatiquement à son dernier emplacement, les éléments récents n'étaient pas double-cliquable et la liste contenait encore un système de sélection.
Maintenant, j'ai extrait un petit comportement (la partie supplémentaire par rapport à fileChooser) assez sympa. 3 méthodes : "donne moi la liste des choix passés", "donne moi le dernier choix", et "prend en compte ce choix".
La partie miraculeuse est que je n'avais pas pensé à étendre l'usage de la chose jusque là, mais avec ma classe (51lignes) j'avais finalement, l'outil pour créer le menu "Reopen recents projects", équiper le bouton "reopen last project" (la réouverture du dernier est désactivée pendant les développements pour éviter de nous géner pendant le debug) et la signalisation unifié lors de la création ou l'ouverture d'un projet dans les voies normales.
C'est assez rare un emboitement aussi serré qui arrive sans préméditation.

On est pressés, faites moi un truc rapidement, tant pis pour la maintenance.
Ok, on connait tous l'histoire de l'enlisement. L'idée est qu'on reprendra ça bien plus tard mais cela n'arrive jamais et le bloat devient progressivement inmaintenanble.
Il existe 2 visions des choses, la première, très en vogue dans XP parle de dette technique, la seconde, issue du management évoque le pré-engagement.

• Dette technique : l'idée est qu'un produit correctement développé ne coûte pas plus qu'il ne rapporte, mais que le nettoyage coûte. Donc développer vite et mal, c'est engager de la dette, qu'il faudra payer plus tard, puisque l'accumulation de créances sans fin conduit à la banqueroute (l'impossibilité de modifier le bloat). D'autre part, les dettes ont des intérêts, qui sont liées à l'action de nettoyage, plus on le fait tard et plus c'est compliqué.
• Pre-engagement : l'idée est que l'ont fait maintenant, des chose qui nous contraidront dans le futur (pour coller avec le paragraphe précédent, on hypothèque le futur). Si l'ont décide de développer en accéléré maintenant, on se contraint à une phase de nettoyage dans le futur. Il est vrai que dans l'industrie du logiciel gérée par des commerciaux, cette phase sera reculées j'usqu'à une réécriture complète ou un dépôt de bilan, mais l'engagement reste, par exemple dans l'impossibilité de re-cibler le produit vers un autre segement marketting facilement, vers l'obligation de founir une qualité moindre au client.

Il est clair que développer vite conduit à un résultat. Si ce mode de gestion n'est pas pérenne, il est clair que sur des périmètres limités on obtient des résultats très rapidement. C'est évidement sur ce type de produits que se sont développées la plupart des startups. Le virage qui est le plus souvent raté, c'est celui de payer la dette ou d'accepter les engagements pris. C'est là que la faiblesse d'esprit du management entre en jeu, car en général cela implique de ralentir les ventes, les promesses de fonctionalités, et de ne mentir ni aux investisseurs ni aux clients, la baraque est déjà hypotéquée.
J'ajouterai une petite note : certains prétendent que développer vite et sans respect de la qualité ne produit pas du logiciel plus vite. C'est évidement faux, sur des périmètres limités celà fonctionne parfaitement, on a rapidement un produit et son jeu de contraintes. C'est sur les produits complet que cela ne fonctionne pas.