Un article qui me parle rudement en ce moment
Un livre sur le développement logiciel ... qui évite l'écueil de plonger dans la technique pour s'intéresser sans doute plus à l'aspect social de l'expérience.
Je trouve cet article inspirant à de multiples niveaux.
Le découpage de roadmap en différentes parties, le calculateur de confiance, la méthode de construction d'un produit. Tout ça est très chouette.
Tiens tiens tiens, un outil permettant de développer un driver Windows en Rust (avec signature et compagnie). Ca me donne presque envie de relancer mon driver vidéo vers UPnP (pour transformer facilement n'importe quelle télé en écran)
Certains éléments dans ce manifeste sont de bonnes idées, et certains sont de terriblement mauvaises idées.
Un article intéressant, qui peut paraître déprimant à première vue, mais qui (grâce à mon hubris sans doute) me rassure plutôt.
J'ai tendance à penser que ce qu'écrivent les grands anciens de l'agilité sur la documentation est globalement à côté de la plaque, mais ça n'est que mon avis ...
Les histoires d'horreur du monde du développement de jeux vidéos sont vraiment pathétiques.
Des éléments vous permettant de mettre en oeuvre différents outils alignant les évolutions de votre produit avec la vision que vous construisez pour celui-ci
Une série d'articles potentiellement très intéressante sur les microservices et leur coût (oui, je suis assez d'accord avec ce que je lis)
Tout un tas de solutions de tunneling http, avec des prix et des contraintes différentes
Un tunnel permettant d'exposer un port de machine de dev sur internet ... Pratique pour, par exemple, développer une app Slack
C'est une idée aussi simple qu'amusante : un serveur http auquel on donne des dumps https préparés, et qui se contente de trouver le dump correspondant à la requête. C'est sans doute très pratique pour des dévs front.
Sur la papier, cet outil d'automatisation de dépploiement a l'air sympa. Mais quand j'y réfléchis un peu, ça vaut juste un docker-compose.yml, non ?
Au-delà de npm audit, ce qui est expliqué dans cet article est valable pour tous les scanners de vulnérabilité. En fait, le mode de fonctionnement de ces outils est ... mauvais, franchement mauvais.
Une discussion sacrément intéressante sur les estimations et leurs mauvais côtés
Je suis franchement d'accord. J'ai bossé dans un certain nombre de petites boîtes qui étaient d'une efficacité folle.
Ah Lombok, ce truc ... certains aiment. personnellement, j'ai très vite ressenti ça comme les portails de téléportation d'Hypérion : un truc qui rend un service mineur, au prix de l'exploitation de ton âme pour une durée ... forcément trop longue
Donc le mec a créé sa propre plateforme de blog. ok ...
Et il la garde en source fermée parce que globalement, il a peur de ce que pourraient faire les gens si ils voyaient le code source. PAS OK DU TOUT.
Franchement, à sa place, j'aurais pris un wordpress qui gère déja tous les problèmes ... même si c'est pas hype. (en fait, surtout parce que c'est pas hype).
Alors ça, ça ressemble à un figma open-source, et c'est une belle idée
C'est tellement vrai !
Tiens ça m'aurait bien aidé quand j'ai faut de la compilation rust enfin je crois...
L'idée est super chouette. Et j'imagine que ça marchera bien dans l'ubuntu qui tourne dans WSL (mais pas dans Windows).
Très bonne série d'articles sur le green IT. Celui-ci, en particulier met l'accent sur les solutions qui sont nombreuses. Et qui vont également à rebours de bien des envies et des modes.
C'est complètement fou, cette réinvention du concept de PL/SQL dans PostgreSQL, non ?
Très chouette description de ce vieux truc
On disait beaucoup de mal sur maven sur ces sujets-là il y a quelques années ...
Chouette ! un moteur de recherche dans les biblothèques de glyphicones les plus connues.
Ca existe aussi en Java, mais je ne sais plus trop où
Un texte très court, mais très frappant, sur l'intérêt des microservices
Je ne sais pas trop quoi penser de cette "enquête" qui regarde la passion des développeurs d'un oeil curieux, c'est vrai, mais qui me semble un peu méprisant.
Surtout parce qu'il passe sous silence le fait que, sans dév, aujourd'hui, plus rien ne marche. Alors, le développeur, star ou cheville ouvrière du capitalisme ?
Quant au chapître sur la mobilité des dévs, j'en reparlerai ... prochainement.
Putain mais heureusement que maven a pas déja créé le même format avec une meilleure validation.
Très bonne interview. j'ai déja regardé les slides de sa présentation, et ça donne envie de le rencontrer ...
La rétrospective est un bon outil agile. C'est encore mieux quand le coupable est Raoul Abdaloff.
J'ai l'impression qu'il s'agit d'une critique honnête du fameux harcèlement du développeur.
Ce qui est drôle, c'est quand on lit cet article dans une entreprise dont le climat social se dégrade ...
via http://sebsauvage.net/links/?NEcpKw
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
Rho, alors ça c'est une sacrée modification des habitudes de travail des développeurs ... Bon, en fait, c'est plutôt une grosse évolution de la façon de faire des code reviews, mais j'en comprends parfaitement le principe. Dommage que je n'aie pas les moyens de l'appliquer actuellement.
Très chouette article à rapprocher évidement de CQRS (c'est E. Bernard qui el dit dans l'épisode des castcodeurs). dataiku a l'air d'une boîte quif ait des trucs bien chouettes ...
Très chouette tribune sur l'inutilité absolue des estimations sans facteur d'erreur (enfin, je le prends comme ça)
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 ...
Et je découvre que je suis plutôt bon en termes de déploiement (merci amven/jenkins) mais assez pauvre pour le test automatisé et la distribution de code.
Ah, ça, c'est moi il y a 1/4 d'heure !
Comment monter une boîte de logiciel, par Jeff Atwood ...
Il y cinq ans, je n'aurais pas apprécié - ni même compris - cette histoire de complaint driven development. Mais, comme pour bien des choses, je crois qu'il a maintenant fondamentalement raison : avoir l'idée initiale et la développer, c'estf acile et rapide. Répondre aux besoins des utilisateurs, c'est un enfer sans nom qui va manger la motivation de chaque développeur. MAIS c'est ça qui fera du logiciel un succès.
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 ...
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.
Une gallerie de composants HTML5(+Javascript, j'imagine) réutilisables ... Ca pourrait servir
Très bon site expliquant pourquoi certaines choses sont mauvaises à l'aide de koans zen.
Ce projet, et le manque de version française, me donne sacrément envie d'y contribuer .... au moins pour traduire des koans.
Je sens que je vais en reparler ...
Très très chouette présentation sur Groovy. Bravo ! (en bonus, je découvre Geb qui m'a l'air bien pratique).
Au passage, en tant que fan du code compilé, j'aimerais bien savoir si on peut faire en sorte que le @StaticCompile soit "par défaut" dans un projet ...
Très très chouette exemple de l'utilisation des lambdas pour faire de Java un langage sacrément cool.
Vous allez voir, Java8 sera encore plus différent des versions précédentes que Java5 n'a pu l'être.