Chouette façon de décrire les différentes lciences open-source et leurs avantages comparatifs.
Belle liste de sites pour améliorer son code. il manque toutefois codingame, mais bon, c'est aps trop grave puisqu'on y trouve project Euler :-)
Chouette présentation d'outils Java qui font vraiment gagner du temps
Excellent ce quizz !
Il n'y a rien qui me motive plus à quitter mon job actuel que de voir que Tuleap est encore mieux et que, alors que j'ai proposé son utilisation il y a près d'un an, il soit dans un tiroir et qu'on utilise toujours une version pourrie de mantis à la place.
Si j'ajoute que notre mantis ne supporte même pas Eclipse Mylyn, la déprime atteint une sorte de sommet ...
Très chouette rapport sur l'état du développement en Java. Et je suis bien content de m'y retrouver majoritairement (sauf pour le (no)SQL).
Très chouette article. Le lien avec CQRS exposé sur les castcodeurs rend la méthode encore plus limpide
J'ai gardé ce texte de Jeff Atwood une semaine dans mon lecteur RSS avant même de dire à quel point il est bien. Et il est bioen, mais alors, BIEN.
Il dénonce tous les éléments qui font le sexisme et donne de bonnes pistes pour lutter contre.
La crypto, de nos jours, c'est plus aussi sûr que ça ...
Il est vrai que certains contributeurs de piètre qualité se posaient des questions :-)
Suertout que mes bridges à base de cache de page HTML mériteraient sans doute un peu de rework (et peut-être l'utilisation d'une lib de parsing RSS)
«Les programmeurs font de la veille technologique. Ils savent ce qu’est un MOOC et en utilisent déjà. Restreindre l’accès à Internet depuis l’entreprise est donc un frein à leurs développements et leur envie d’apprendre.»
Hrm ... Si je pouvais faire passer ce messaage, ce serait bien.
J'aime bien cet article qui explique clairement pourquoi les applications hybrdies ne sont pas tant "le mal" que ça.
Très chouette article sur toutes ces choses qu'on fait sans forcément se poser de questions, et qui se révèlent finalement débiles et pénibles pour les utilisateurs
Un article bien pointu sur l'intérêt (ou pas) de rendre une méthode final ... Mais également de l'intérêt (ou pas, encore une fois) des méthodes redéfinies/surchargées pour la performance.
C'est vrai, mais en même temps non.
C'est vrfai parce qu'il y a des nigauds qui considèrent qu'il suffit de livrer le source chez GitHub pour que le projet soit complet.
C'est faux parce qu'il n'y a pas de difficulté majeure de migration (il suffit de déplacer l'upstream de github vers gitorious ou bitbucket). Sauf, bien sûr, pour les bugs qui ne sont pas visibles dans git, hélas.
via http://sebsauvage.net/links/?KOE6Tg
Oh oh oh
Je viens d'avoir la discussion avec un collègue, qui m'expliquait qu'il est préférable de livrer des nouvelles fonctionnalités sans bugs.
Et du coup, j'ai fait un peu d'introspection (ça n'était pas glorieux) et je suis tombé sur cet article assez intéressant sur le rapport coût/bénéfice de la correction de bugs ...
J'avais déja entendu parler de ce concept complètement dingue, mais j'avais oublié le nom du (ou des) frameworks qui peuvent permettre la mise en application du concept. Là, avec l'intégation maven/ant, c'est très chouette.
Oh, tiens, une web-app centralisée pour gérer les fichiers de propriétés dans différents environnements. Ca paraît une idée plutôt chouette, et assez pratique pour les dev-ops, non ?
via http://java.dzone.com/articles/mule-meets-zuul-centralized
Sacrément intéressant. je me demande ce que ça donnera avec les method references de Java 8 ...
Bon, par contre, je suis peu satisafait par le "AT ENTRY" en chaîne de caractère pour spécifier le moment où renvoyer l'exception. Les enums sont faits pour ça, nom d'un chien !
Explqiuer HeartBleed en quatre images ? C'est possible.
Et parfaitement réussi, d'ailleurs.