Chouette article expliquant bien les avantages d'emacs et de vi pour replacer Atom dans son contexte. Ca montre particulièrement que si emacs a influencé tous les éditeurs de logiciels, la voie choisie par vi n'est pas idiote du tout et aurait mérité un héritage plus vaste.
Dix ans ? Déja ?
Je dois lire Coding Horror (de façon régulière, dans mon journal du matin, quoi) depuis pas loin de six ou sept ans, et j'y trouve exactement ce que Jeff y met : de l'inspiration, et l'affirmation que pour réussir, il faut travailler. Enfin, ça, et pleind e détails sur le métier de développeur professionnel.
via http://www.codinghorror.com/blog/
Sapristi, j'ai un Heisenbug !
Tiens c'est pas con comme idée de découpage des tests : appeler la classe dans laquelle on place les paquets de tests OnTestedTests, et mettre dans cette classe des classes internes When*, qui contiennent à leur tour les différentes méthodes de test. Faudrait que j'essaye, ça me paraît malin.
Très chouette article sur Devops "en vrai". Je reconnais en tout cas bien des choses ...
Très chouette explication du workflow recommandé par GitHub. C'est loin d'être aussi complexe que les workflows que je voie passer habituellement (l'exemple typique étant le "successfull git branching model"). Et ça semble facilement utilisable, ce qui est loin d'être une mauvaise chose.
Je suis une tanche en expressions régulières.
Et ce plugin a le bon goût de me proposer le seul truc qui puisse m'aider : une représentation graphique de mon expression régulière.
C'est très pratique.
Il est bien cet article sur les tests unitaires. On croirait que c'est Eric Lefebvre qui l'a écrit.
Il se trouve que c'est ce que je fais de plus en plus : des tests linéaires, dont les méthodes portent des noms expliquant le comportement testé. Et surtout, SURTOUT, des tests réalisés avec hamcrest ou FEST-assert pour avoir le fameux assertThat(bidule, is(machin));
Un framework web Java qui m'attire pas mal, je dois dire.
J'aime son expressivité, son utilisation des conventions, et ses possibilités qui semblent assez ... importantes
Eh, mais je pourrais utiliser ça pour mon lfiestream, plutôt que de passer par le moche export HTML ... Ou alors peut-être que je devrais garder l'export dans un coin, et mettre ça en place dans un autre module ... Faut que j'y réfléchisse, tiens
via http://sebsauvage.net/links/?CYW2Qg
Tiens c'est marrant,c 'est ce que je fais de plus en plus. C'est spécialement pratique pour les tests utuilisant Weld : je démarre Weld dans mon test, et je lui demande de me charger une instance de ma classe de test, et ça roule
via http://java.dzone.com/
La doc pour le Javascript dans indesign. Toutes les versions d'Indesign disposent de leur doc, en HTML et (joie) CHM
Je m'en suis servi vendredi pour surveiller une fin de process en Groovy, et c'était bien pratique !
Excellent article sur l'état du développement côté client (lire mobile).
J'aime particulièrement son expression "explosion cambrienne" qui montre bien à quel point le développement client voit chaque jour émerger sa nouvelle idée qui se révèle à chaque fois ou presque soit une fausse bonne idée, soit une réinvention d'un truc largement préexistant.
Si vous avez un Mac avec Java 6 ... ça pourra vous aider à faire marcher Cobertura, par exemple ....
Un article très sérieusement documenté sur le coût des exceptions Java sur la performance de l'application. J'y ai découvert plus d'un truc un peu dingue ... Le pire étant pour moi le coût de remplissage de la stack trace.
C'est drôlement bien ce truc !
Je vais tester avec les enfants prochainement, tiens.
via http://sebsauvage.net/links/?QT6ubg
Oh, tiens, un guide "complet" pour découvrir Angular.js en un jour. Ca pourrait être une lecture intéressante.
Chouette micro-framework MVP en Javascript ... J'aime beaucoup le fait qu'il s'appuie autant que possible sur jQuery, qui me paraît - de loin - être quand même une sacrément bonne idée pour faire du "bon" Javascript événementiel
Vous avez déja lu "PHP, a fractal of fail" ? Non ?
Bon, ben ce message explique une partie de la mentalité de l'auteur, je trouve : son histoire de table de hash des noms de fonction basé sur strlen() fait un peu mal, parce que c'est juste moche comme pas possible. Et le gars expliqu tranquillement que ça ne le dérangeait pas tant que ça ... Ca fait mal, je trouve.