Archive pour March 2008

Pourquoi je n’aime pas Microsoft?

Publié le 28 March 2008, par Babozor

ballmer.jpg

Titre volontairement (un peu provocateur)… on me reproche souvent d’être plus que partial et de ne pas laisser sa chance à la société de Redmond en lui préférant celle de Cupertino [Microsoft versus Apple pour les ignares], etc… mais c’est plutôt un (vieil) amour déçu plus qu’une haine tenace.

De bons produits
Malgré tout ce qu’on peut dire, Microsoft sort tout de même de très bons produits, ne serait-ce que la suite Office, qui aujourd’hui n’a aucun réel concurrent (même si OpenOffice ou iWork sont des efforts louables, ils n’arrivent pas à la cheville de MS Office je pense que tout le monde en conviendra). Pour continuer sur les bonnes notes, pour moi Windows 95 (SE off course) était un grand pas en avant dans les OS (comparé à Windows 3.1) et globalement un bon produit.

L’ogre informatique, suprématie affichée et revendiquée
Une des chose chez Microsoft qui me gêne le plus c’est son quasi monopole sur le monde informatique et sur l’informatique grand public en particulier… il domine le marché des OS certes, mais le fait avec une arrogance qui me dérange vraiment. Même si on voit une certaine évolution avec une marge de progression intéressante d’Apple et de Linux pour les initiés.

Vista…
En voilà une bonne raison de ne pas aimer Microsoft (sans aller jusqu’à les détester… encore que), un OS censé être novateur, ultra buggé, marketté au bazouka (j’arrête là le lynchage de peur de n’écrire des mots qui dépasseraient ma pensée)

Fait par et pour des développeurs
Au contraire d’Adobe ou d’Apple, les produits Microsoft sont fait par et pour des développeurs, d’où certaines fois une interface et une logique un peu bizarre. Cela peut s’avérer pratique, voir adapté pour certains, mais…

Modèle fermé
Malgré certains débuts d’efforts poussifs, Microsoft (comme Apple d’ailleurs) reste sur un modèle ultra fermé où tout se paye, sans vraiment libérer son code source (et donc en passant à côté de la communauté très active de l’OpenSource et du logiciel libre)

En conclusion?
Ce qui me dérange le plus c’est que pour moi il y a 10 ans, Microsoft était le symbole de l’innovation… aujourd’hui c’est un mastodonte qui sort encore de bons produits (bien que maintenant cela relève plus de l’exception) mais se repose principalement sur sa mainmise sur le parc informatique et son marketting façon wermacht pour imposer ses produits.
Certes Apple est lui aussi sur le même marché (OS, logiciels, sauf qu’ils sont eux même constructeurs) mais bénéficie d’un capital sympathie important (puisqu’il fait partie des outsider) et surtout sort des produits beaucoup plus travaillés et designés (on ne se fait pas d’illusion l’un comme l’autre sont là pour faire du fric).

Bref, je ne suis pas un anti-Microsoft (pas complètement en tout cas), mais j’attends un nouvel OS, un nouveau navigateur vraiment convaincant pour changer mon opinion générale

Peut-on tomber malade?

Publié le 28 March 2008, par Babozor

malade_travail.jpg

Peut-on encore aujourd’hui en tant que Travailleurs du web se permettre de tomber malade?
Que ce soit une petite gripounette ou quelque chose de plus sérieux, tomber malade aujourd’hui dans une entreprise nous coûte très cher:
– en dessous de trois jours d’absence rien remboursé (dû aux trois jours de carence de la sécurité sociale)
– au delà on a toujours les 3 jours de carence et on est payé une misère (ça change suivant le statut et la paie mais apparemment c’est entre 30 et 60 euros par jour)

Petit exemple, il y a de cela quelques mois j’ai eut une vilaine (mais alors vraiment vilaine) gastro: arrêté cinq jours (ce qui est exceptionnel en général je suis jamais ou peu malade).
Bilan: entre 20 et 25% de ma paie en moins et indemnisé royalement d’un peu plus de 70 euros par le sécurité sociale… (calculez le manque à gagner pour une vilaine gastro)

Ma question est donc double: peut-on encore se permettre d’être malade aujourd’hui?
Vous arrive-t-il de continuer à aller au boulot même malade (avec le merveilleux taux de productivité/passage de maladie à son collègue que l’on connaît), pour éviter un salaire amputé?

Pour ma part, sauf incapacité physique totale d’aller au travail, un peu malade (voir un peu plus) je vais au travail, et vous?

Blague (pourrie)

Publié le 28 March 2008, par Babozor

Désolé mais j’ai pas pu m’empêcher de snapper ça sur mon téléphone…
Apparemment MRM se diversifie ou tente un changement de business model?

MRM_nouveauBM.jpg

Je sais c’est nul… désolé

Altaide Dev Drink 3: SIlverlight 2

Publié le 28 March 2008, par Babozor

Voilà donc mon premier vrai essai de vidéo… avec évidemment un son de chiotte (surtout avec le vent au début) la merveilleuse HD (qu’on ne voit pas ici puisque je ne suis pas encore MotionMaker pour DailyMotion, voir ses boutons sur les nez en HD c’est quand même top pas de doute) et un montage pas encore complètement au point (mais je fais de mon mieux).

Dev Drink sympa mais très axé développeurs .Net (et c’est un peu normal), quelques remarques:
1. pas de démo de “killer app” (ou appli qui tue en bon frenchy), de la démo de code d’intégration, d’environnement, etc… deux petites démos mais rien de révolutionnaire (au niveau fonctionnel en tout cas)
2. Le plugin Silverlight dispo sur IE, Safari et FireFox sous Windows et Mac (Linux pas encore devrait être porté par les gars de Novel) ainsi que sur plateformes mobiles (Sybian et Windows Mobile… pas de détail sur l’iPhone et oublié de poser la question)
3. Une intégration apparemment bien faites sous l’environnement de dev Microsoft (càd Visual Studio) très orientée code et pas vraiment designers (qui ont leur propre logiciel pour permettre de designer l’interface)

J’ai dû me sauver un peu plus tôt que prévu, donc pas de Drink (pour la prochaine fois), démo intéressante pour les dev .Net mais qui ne m’a pas convaincu de switcher sur l’environnement de dev MS (même si certains aspects de Silverlight ont l’air sympa)

Faits et erreurs du développement logiciel

Publié le 26 March 2008, par Babozor

dev_day.jpg

Voilà un article fort intéressant de Codding Horror que je ne m’empêcher de traduire, tellement les conseils sont selon moi avisés…
[ces conseils proviennent d’un livre: Facts and Fallacies of Software Engineering (Agile Software Development)]

Les gens
1. Le facteur le plus important dans le développement est la qualité des développeurs.
2. Les meilleurs programmeurs peuvent être jusqu’à 28 fois meilleurs que les pires programeurs.
3. Ajouter des gens à un projet déjà en retard ne l’accélère pas.
4. L’environnement de travail a un impact profond sur la productivité et la qualité.

Outils et techniques
5. Les modes (pour les outils et technologies) sont un cancer pour le développeur.
6. Les nouveaux outils et techniques créent une perte initiale de productivité et de qualité.
7. Les développeurs parlent beaucoup d’outils mais les utilisent peu.

Estimation
8. L’une des deux causes pour un projet en déroute est une mauvaise estimation.
9. L’estimation arrive le plus souvent au mauvais moment.
10. L’estimation est faite la plupart du temps par les mauvaises personnes.
11. Les estimations ne sont la plupart du temps pas corrigés durant l’avancée du projet.
12. Ce n’est pas une surprise que les estimations soient mauvaise. Mais ce sont elles qui nous font vivre ou mourir demain!
13. Il y a une déconnexion entre les managers et les développeurs.
14. La réponse à une étude de faisabilité est quasiment toujours “oui”.

Ré-utilisation
(je dois dire que j’ai eut du mal à traduire ce morceau là… pas évident du tout à traduire, pour les anglophiles mieux vaut se fier à la version originale)
15. Ré-utiliser ponctuellement du code peut résoudre votre problème.
16. Ré-utiliser globalement du code ne résoudra pas vraiment votre problème.
17. La ré-utilisation globale marche mieux dans une famille ou un système similaire.
18. Les éléments ré-utiliables sont trois fois plus dur à construire et devraient être testés dans trois environnements différents.
19. La modification d’un code ré-utilisé est particulièrement source d’erreurs.
20. La ré-utilisation de Design Patternes est une solution pour résoudre le problème de ré-utilisation du code.

Besoins
23. L’une des deux causes de déroute d’un projet est des besoins instables (fonctionnalités demandées).
24. Les changement des besoins (et donc de fonctionnalité) sont les plus coûteux durant la production.
25. Les besoins manquants sont les fonctionnalités les plus dures à corriger.

Design
26. Les conditions explicites ‘explosent’ alors que les conditions implicites pour une solution évoluent.
27. Il y a toujours une solution de design triviale pour un problème logiciel.
28. Le design est un processus itératif complexe. Le design initial est le plus souvent mauvais et pas optimal.

Code
29. Les ‘fondamentaux’ des designers vont rarement de pair avec les ‘fondamentaux’ des développeurs.
30. COBOL est un langage vilain, mais tous les autres sont bien pires.

Supprimer les erreurs
31. Supprimer les erreurs est le processus le plus long du cycle de vie d’un programme.

Tester
32. Une application est souvent testée au mieux sur 55 à 60% de son tout.
33. Tester 100% de son application est tout de même loin d’être suffisant.
34. Tester les outils est essentiel, mais rarement fait.
35. Les tests automatiques sont rarement mis en place. La plupart des tests ne peuvent pas être automatisés.
36. Un mode-debug créé par un développeur, se doit d’être rajouté dans la liste des outils à tester.

Reviews et Inspections
37. Une inspection rigoureuse peut enlever jusqu’à 90% des erreurs avant même le premier test.
38. Une inspection rigoureuse ne doit pas remplacer les tests.
39. Des rapports post-livraison, postmortem et rétrospectifs sont important et peu ou jamais fait.
40. Les rapports sont techniques et sociaux, les deux facteurs se doivent d’être présents et adaptés.

Maintenance
41. La maintenance consomme entre 40 et 80% du coût de votre application. C’est sans aucun doute la phase du cycle de vie de votre application la plus importante.
42. Les améliorations représentent en gros 60% des coûts de maintenance.
43. La maintenance est une solution – pas un problème.
44. Comprendre le produit existant est la tâche de maintenance la plus difficile.
45. De meilleurs méthodes amènent plus de maintenance et non moins.

Qualité
46. La qualité est une somme d’attributs.
47. La qualité n’est pas la satisfaction de l’utilisateur, la satisfaction des besoins, rentrer dans les coûts et le planning ou la fiabilité.

Fiabilité
48. Il y a des erreurs que la plupart des développeurs font.
49. Les erreurs ont tendance à se condenser.
50. Il n’y a pas qu’une seule approche pour la résolution d’un problème.
51. Les erreurs résiduelles resteront persistentes. Le but doit être de minimiser ou éliminer les erreurs sévères ou critiques.

Efficacité
52. L’efficacité vient plus souvent d’un bon design que d’un bon code.
53. Un langage de haut niveau peut être à 90% aussi efficace qu’un code similaire en assembleur.
54. Il y a un gouffre entre optimiser le temps de réponse et optimiser l’espace occupé.

Recherche
55. La plupart des chercheurs tentent de convaincre plutôt que d’investiguer.

Après ces 55 faits, l’auteur nous présente donc 10 erreurs communes, qui ont l’apparence de la vérité…

1. Vous ne pouvez manager ce que vous ne pouvez mesurer.
2. Il est possible de suivre la qualité d’une application.
3. La programmation n’est pas une question d’ego.
4. Outils et techniques: un pour tous.
5. Les applications ont besoin de plus de méthodologies.
6. Pour estimer le coût et les délais, estimez d’abord le nombre de lignes de code.
7. Des tests au hasard est un bon moyen d’optimiser les tests.
8. “Given enough eyeballs, all bugs are shallow”. (celui là j’ai pas vraiment réussi à le traduire correctement donc je le laisse comme ça)
9. Pour prédire les futurs coûts de maintenance, il faut regarder dans les projets antérieurs.
10. Vous apprenez aux gens à programmer en leur montrant comment écrire du code.

Aucun doute il me FAUT ce livre… apparemment pas encore traduit en français, mais qui liste une bonne partie des problèmes qui existe dans notre profession.
Evidemment certains de ces faits sont difficilement praticables (surtout dans un contexte web), mais c’est cela que tout bon développeur et travailleur du web doit tendre.

Des réactions?