Un très bon site de comics pour développeurs
Personnellement, je disais beaucoup ça quand j'étais jeune. Et avec l'expérience, j'ai compris qu'il est assez facile de reproduire les fonctionnalités, mais plus difficile de reproduire les bugs. Sans compter toutes les fonctionnalités non documentées. Et de ce fait, quand on me propose de réécrire une brique, j'ai de plus en plus tendance à d'abord demander pourquoi tout réécrire.
Ca m'a l'air une bien belle suite d'outils divers pour ceux qui ont le triste plaisir de travailler avec K8s
C'est le mode d'écriture de la documentation des développeurs que je préfère. C'est simple, efficace, et ça garantit une documentation à jour ... pour peu que les développeurs soient des professionnels.
Epatant : les femmes et les jeunes développeurs retiennent mieux les noms de variable insignifiants que les vieux comme moi.
C'est une vision très intéressante de notre métier, et qui marche dans le contexte ultra-libéral de Yegor ... Est-ce projetable ailleurs ? J'ai l'impression que oui.
L'article semble énervé, mais franchement, je suis d'accord. Aujourd'hui le web est une zone hautement militarisée pour des raisons pas toujours intelligentes, la première étant la mauvaise démographie des développeurs.
Une très belle checklist de ce qui fait la différence entre coder et développer
J'ai eu le plaisir de bosser avec Xavier pendant quelques mois (et c'était vraiment chouette) et je retrouve dans cette interview son amour du travail bien fait.
Une série d'opinions parfois intéressantes, parfois non. Mais c'est toujours intéressant de se confronter à des opinions différentes. Je retiens en particulier "Have some personality: web dev is a pop culture and rewards personality"
Cette version de la phrase traditionnelle est à mon avis bien meilleure que l'originale (même si la vérité se situe entre les deux)
L'idée est super chouette. Et j'imagine que ça marchera bien dans l'ubuntu qui tourne dans WSL (mais pas dans Windows).
Il y avait à un moment dans le jeu vidéo une tradition de lister les développeurs sur un écran "à propos". J'aimerais beaucoup que cette tradition s'étende à toutes les applications, ne serait-ce que pour pousser les développeurs à être fiers des produits réalisés, plutôt que des méthodes appliquées.
C'est marrant, parce que pour moi, c'est ça la vraie définition du fameux "10x engineer" : la personne qui enlève les freins de l'équipe, et surtout pas celle qui la tire comme un dingue.
Un découpage des typologies d'entreprises employant des développeurs avec lequel je suis assez d'accord (y compris dans les défauts). J'aime de plus particulièrement le concept de la frustration en tant que peste, virale, transmissible, dangereuse
Je suis d'accord avec Yegor : le travail d'un développeur est hautement mesurable, sans même avoir besoin d'utiliser des métriques stupides comme le nombre de lignes de code, mais plus le vrai travail accompli.
Un article tout à fait pertinent sur la définition de soi à travers les obstacles qu'on veut surmonter pour être reconnu comme compétent.
Une série d'arguments vraiment chouettes contre le mode sombre à la mode chez les développeurs.
Je vais devoir créer un plugin Shaarli pour étendre l'export (pour y ajouter l'image et le permalink, notament). Souhaitez-moi bon courage, parce que le PHP, c'est pas ma fête.
Cet article fournit une analyse intéressante de différents langages utilisables dans le cas de Fuschia, c'est-à-dire le développement d'un OS.
Bon, j'allais dire "oh merde, je suis le maverick". MAIS la transition du rôle vers le rôle d'architecture porté par l'équipe fait partie que je promeus fortement, donc ça va un peu mieux 😊
C'est chouette cet article ! Et ça montre bien la puissance de la patience.
Je suis d'accord : les développeurs doivent comprendre leur pouvoir et les obligations qui vont avec. Sinon, d'autres personnes décideront ...
Oui, je sais ce que je vais faire de ce tweet (et ce sera peut-êtrre intéressant)
Et paf, ça me fera un bon support pour un moment d'auto-critique publique.
Wow. L'approche de l'entretien est curieuse, mais la motivation derrière est extrêmement intéressante (et je vais garder sa classes sous le coude, parce qu'il y a là-dedans quelques anti-patterns bien typiques)
Un bel ensemble de bonnes pratiques dans le design d'une API REST. C'est joliment détaillé et assez clair. Il ne manque qu'une version checklist pour que ce soit parfait 😋
Hélas, je n'ai pas atteint ce niveau de maturité, et parfois je livre des choses incompréhensiblement complexes ... Heureusement, maintenant, je suis architecte et donc je ne livre plus en prod !
ok, il va vraiment falloir travailler en ce sens.
En tant que développeur, je trouve ça très intéressant !
Oh un git simplifié ! Ca doit couvrir la plupart des besoins des développeurs, non ?
OUI ! Codez ... si vous voulez. Si vous ne voulez pas coder en-dehors du boulot, ne vous laissez pas forcer par la pression des pairs !
La présentation est très intéressante ... même si je crains que le passage direct au monde fonctionnel ne soit un peu ... rapide 😉
C'est une belle histoire racontée par ce commit.
Mais quand je travaille sur un bug, j'ai tendance à me poser plein de questions et à noter ces questions dans l'issue GitHub/Mantis/Whatever. Le résultat est le même, mais la méthode différente.
La citation qui fait mal ...
Ah ah ah ! C'est tellement vrai !
Le vrai problème de Yegor, c'est qu'il écrit trois articles bien trollesques pour une pépite comme celui-ci. Parce que son exemple de README est vraiment très bon.
C'est vrai qu'il est bon de passer du temps à faire autre chose que coder.
Il y a dans cette liste tout un paquet d'outils de développement très, mais alors très intéressants.
Tiens tiens tiens, j'aimerais bien un truc un peu comme ça, pour les services Docker, mais avec une page listant les différents services démarrés ...
Quand Linus se trompe de continent, on déplace le kernel summit pour le suivre ... Je trouve que c'est une anecdote assez révélatrice de l'état d'esprit Linuxien ...
J'espère que mes collègues femmes ne me contrediront pas, mais je n'ai effectivement pas l'impression d'être mysogyne/supérieur/...
Comme toujours avec Yegor, c'est assez tranché, mais très intéressant. Et en l'occurence, j'ai déja été dans la situation du développeur qui aurait bien voulu un peu plus d'analyse des risques
Très bonne métaphore sur ces différentes évolutions du métier de développeur
Pas bête du tout, d'autant plus que j'utilise de pluis en plus de conteneurs simplement pour isoler mon travail
Chouette (au café près)
Très intéressant article sur l'état de l'écosystème Javascript. J'ai l'impression de revoir des choses qu'a vécu la communauté Java il y a des années ...
Très chouette article sur l'optimisation de performances en java. j'aime beaucoup le fait qu'ils se posent en premier la question des performances demandées. Rien que ça, _ça fait du bien.
via http://java.dzone.com/
Comment intégrer un build Javascript "moderne" dans un build Maven standard.
Très chouette histtoire des User-Agent des différents navigateurs web. Pour en comprendre parfaitement l'ironie, il faut imaginer que les développeurs de site webs sont obligés de faire un UserAgent.contains("Opera") pour savoir que la navigateur est Opera ...
via http://the.taoofmac.com/space/links/2013/11/06/2022