Et voici un nouveau numéro !

Bon, faudrait que j'arrive à me caler sur trolldi pour publier, ça pourrait être un peu plus marrant...

Quoi qu'il en soit, j'ai essayé de faire ça un peu mieux en catégorisant un peu plus, même si c'est pas encore parfait. Les liens sont plutôt inclus dans le texte, à vous de dire si c'est mieux ou si vous préférez de bêtes listes.

Pour cette fois, principalement trois thèmes :

  • Des histoires de boulot
  • Quelques news de sécurité
  • Un peu de développement

Alors commençons avec le boulot.

Connaissez-vous le principe de Peter ? Non, je ne parle pas du [syndrome de Peter Pan](http://fr.wikipedia.org/wiki/syndrome de peter pan). t Le Principe de Peter est un principe vraiment intéressant qui dit, en gros « Avec le temps, tout poste sera occupé par un incompétent incapable d'en assumer la responsabilité ».

En résumé rapide (si vous voulez en savoir plus allez lire le lien) lorsqu'on est compétent à un poste, qu'on réussi, on a tendance à monter dans la hiérarchie. Le truc c'est qu'on est probablement moins compétent dans ce nouveau poste. Et ainsi de suite on s'élève jusqu'à un niveau d'incompétence problématique alors qu'initialement on était compétent.

A méditer lors des choix d'évolution de carrière...

En parlant de postes, pour vous développeurs (enfin ça peut sûrement s'appliquer à d'autres) comment se passe votre temps de travail ? Etes-vous contraint par des horaires strictes ? Horaire libres ? Finalement, dans quel cas êtes vous le plus productif et combien d'heures par jour de boulot ? Voici deux articles sur le sujet, l'un sur le fait d'avoir 2 à 3 heures par jour de réellement productives, l'autre sur le fait d'Être comptable de son temps.

Pour ma part je suis plutôt d'accord avec ces posts. Souvent, avoir un décompte trop précis ou vouloir que chaque minute soit réellement productive a l'effet inverse. Combien de fois trouvons-nous des solutions en regardant par la fenêtre ou une fois sorti du boulot ?

Je me souviens que, lorsque je travaillais à 100km de chez moi, je faisais alors pas mal de voiture (ok, 2h en temps normal, 2h20 si c'était sous la neige). Histoire de rajouter un peu, le temps était mesuré, en gros je pointais... Mais quelle connerie au final ! Parfois, j'étais bloqué sur un problème en fin d'après midi. Pas moyen de s'en sortir. Et pas question de quitter puisque je pointais et avait un nombre d'heure mini à faire (le résultat de la pointeuse était aussi que personne ne faisait plus lorsqu'il l'aurait fallu). Donc j'attendais en gros. Je cherchais quand même, j'étais pas en train de me promener sur facebook (faudrait que je regarde la date mais ça n'existait peut-être même pas, en tout cas je ne connaissais pas - et de toute façon j'avais pas le net sur mon poste...). Puis, arrivé l'heure fatidique, je repartais prendre ma voiture et faire 100 bornes. Souvent, au bout de quelques kilomètres je trouvais la solution. Alors je la notais pour le faire le lendemain matin.

Au final, n'aurais-je pas été gagnant (et mon entreprise également) à pouvoir m'échapper un moment puis revenir avec la solution ? Si j'avais pu, j'aurais résolu le problème avant la fin de la journée. En voulant me forcer à rester, la solution n'a été implémentée que le lendemain. En croyant augmenter la productivité au final elle a été réduite, en plus de ne pas donner envie.

Mais d'ailleurs, si on laissait plus de liberté à ces gens qui font des logiciels, ça donnerait quoi ? Et pourquoi pas un ~~plan de domination mondiale~~ Master plan !

Et en parlant de domination, où on en est côté cyberwar ces derniers temps ? Car il semble que ça avance réellement. Notamment côté Stuxnet, où il semblerait que La NSA et l’Unité 8200 étaient à l’origine de Stuxnet.

En même temps, dans certains cas, pas besoin de puissance folle pour bouffer du mot de passe Linkedin. Ils ont oubliés le poivre. Ou le sel. Rha je sais plus :-) An Update on LinkedIn Member Passwords Compromised

Par contre, impossible évidemment de passer sous silence la jolie 0day concernant MySQL et MariaDB. Tellement gros qu'on a du mal à y croire, surtout à quel point c'est facile. On souffle par contre dans l'oreille que certaines debian ne seraient pas concerné, il faut une version suffisamment récente pour que ça se produise :-)

Ces petites news vous ont mis en bouche ? Ok, il ne reste plus qu'à passer à la partie développement alors.

D'ailleurs, pour ceux qui font du java, vous connaissez Guice ? C'est un système d'injection de dépendance vraiment bien foutu, développé par Google. De mon côté ça a complètement changé mon point de vue sur Java. J'ai enfin pu faire du java qui soit agréable avec ça et je conseil à tous ceux qui font du java d'aller voir d'un peu plus près.

Quoi qu'il en soit, je ne suis pas le seul à penser ça. Et on peut le voir par exemple dans Sitebricks :: A Web platform. Il s'agit d'un petit framework web java, utilisant massivement Guice. Je ne l'ai pas encore testé mais ça ne saurait tarder, ça me tente vraiment bien. Ha oui, l'auteur était développeur Google Wave, mainteneur Guice. Pour lui des outils comme GWT mais aussi closure sont overengineered et il a voulu faire quelque chose de plus simple.

Histoire de rester dans le web, quelques petits liens en vrac :

Voici dans un autre registre une comparaison visuelle de C++, Ruby et CoffeeScript. Intéressant, mais peut-on réellement comparer des langages aussi différents et donc les objectifs (notamment d'abstraction) sont plutôt éloignés ?

Pour continuer, voici une présentation pour le moins intéressante : Devops is a verb its all about feedback

Si vous pensiez vous ennuyer les jours qui arrivent, j'ai ce qu'il vous faut. Rien de moins qu'une petite revue du code source de Doom3 ! Mine de rien un sacré travail de réalisé. Ce gars est un peu un malade je crois. Pour ma part je ne l'ai pas encore lu. Par contre je suis convaincu que c'est entre autre en lisant ou étudiant les codes d'autres personnes qu'on peut s'améliorer. C'est loin d'être négligeable, alors un titre pareil.

Ha oui, et il y a aussi twitter qui vient de libérer zipkin. Si j'ai bien compris c'est utilisé pour tracer une application dans un contexte distribué. Et il est vrai que nous en avons de plus en plus. Tous ceux qui bossent avec de multiples machines, de multiples services, savent combien il est difficile de savoir précisément ce qui se passe entre l'arrivée du requête et sa réponse. Comment visualiser ceci et pouvoir agir ensuite ? C'est un peu le but de cet outil. Et c'est construit à partir du papier de Google Research sur le sujet, Dapper.

Et pour finir ce petit épisode, un peu de lol !

PairHero: A game of collaboration for pair programming Vous trouviez le pair programming ennuyant ? Ce petite plugin Eclipse est fait pour vous alors !

J'aimerais vraiment bien mettre en place ce qui suit. Si les gens le prennent bien il y a vraiment moyen de rigoler. D'ailleurs, certains d'entre vous ont-ils déjà mis en place lolcommits ?