Plein de svgs!

Un petit script python qui permet de lancer SimpleHttpServer en python avec le rewriting pour les SPA (angular / react)

J'adore DHH, il a la même vision que moi sur l'overcomplification du monde du dev (pour le plaisir de faire comme les grands éditeurs qui ont des problématiques qui ne seront jamais les notres) :
<<I think microservices and the hype around it is probably one of the most damaging, uh, trends that has hit web development in the last 10 years. Um, I think very few things have done more damage to sort of the integrity and the productivity of software development teams.
Then the premature application of microservices. I am a stound, stout and proud supporter of the majestic monolith. This idea that you have a single application that a single person can fully grasp, comprehend, understand, deploy, operate, and then as far, far preferable to this idea of having a fleet of microservices, a building, a hundred different toolkits and languages that no one knows how to sort of operate and go on.
Microservices is a great example of an organizational tech pattern. It’s not actually a programming tech pattern. Microservices is what you do when you have teams so large that they essentially need dominion over their own domain. Right. They need to sort of control their own boundaries and so on. And when you have 50,000 programmers, yeah, it’s a completely reasonable pattern and it makes total sense trying to apply it.
While when you have two, five, 2050 programmers... Jesus, no, just no.
[...]
Even if I think that the single page application front end is a horrifically overuse pattern, far more so than than even microservices. And I think, so the crimes, against programming humanities that have been done in the service of single page applications are far worse than the ones that have been done in the service of microservices.
But then of course, as it is, lots of people combine the two. So it’s a fleet of microservices serving a single page application, and that’s just where it go. Like. Co plan, my head explodes with like, yeah, I would rather retire and fucking, I don’t know, make weaved baskets than deal with that shit.>>

Pour publier sur le web un environnement local. Genre votre API locale pour tester depuis une app téléphone buildée <3

+1000000000

Un assez bon article sur le sujet.
Qui pourrait être résumé en 1 phrase : "Si votre société fait passer ses priorités budgétaires avant ses considérations humaines et la qualité de ce qu'elle livre, alors elle ne fait pas de l'agile."
Je suis content de voir que la société où je bosse (et où je passe officiellement scrum master ^^) ne coche qu'un seul point parmi les exemples de "fausses pratiques" agiles.
L'agilité c'est, pour moi, et comme je l'ai déjà dit : du caca. C'est le plan Z. La pire des solutions. Mais c'est la dernière à protéger le développeur.
Car on fait de l'agilité pour une seule raison : car le client n'a aucune FUCKING idée de ce qu'il veut vraiment. Il exprime ses besoins et solutions attendues, et veut pouvoir tester chaque semaine en changeant tout à chaque fois, sans que cela impacte la date de livraison (imaginez cette phrase appliquée à la construction d'un batiment.......).
Et du coup qui prend la responsabilité de ça ? L'équipe technique.
L'agilité (via Scrum) sert à poser un cadre et des règles. Un cadre permettant de remettre le dev au coeur de la création du logiciel (il ne doit pas être un simple exécutant) et à le protéger des accès de folie du client (non vous ne pouvez pas changer de roadmap intégralement à partir de demain...)
Mais en soi, l'agilité est un buzzword depuis 15 ans maintenant. D'ailleurs, quand une société dit "on fait de l'agile", je me méfie plus qu'autre chose. Car il y a 9 chances sur 10 que ce ne soit pas le cas.

"J'ai remplacé la taille de 4.1rem par 4vw et ça marche nickel".
C'est l'équivalent "non-tech" de "J'avais plus de tomates pour ma soupe de tomates, j'ai mis des fraises car c'est rouge aussi".
Merci pour ce fou-rire cher collègue. Mais pour info : "ON NE REMPLACE PAS UNE TAILLE FIXE EN PIXELS PAR UN POURCENTAGE DE TAILLE D'ECRAN !"

Mon article préféré sur le sujet. (avec l'exemple de Diaspora et le fail de MongoDB : <A href="http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/" rel="nofollow">http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/</A> )
NoSQL, c'est une techno de fainéant. C'est une techno "agile" pour les gens qui veulent des résultats immédiats sans s'occuper du coût à moyen long terme. C'est parfait pour stocker des pétaoctets d'archives en gardant une bonne disponibilité... mais ça s'arrête là.
Pour moi, on ne peut utiliser une base NoSQL que si trois critères se rejoignent :

• Quand ton modèle de donnée n'a pas de relations entre objets, et n'évoluera pas
• Que tes objets peuvent évoluer avec le temps et que tu veux t'économiser les migrations et évolutions de ton modèle
• Que tu as besoin d'ultra grosses performances en lecture
  Si tu ne coches pas ces 3 cases, le NoSQL n'est pas adapté.
  Le NoSQL est depuis 10 ans un buzzword, un truc à la mode. Les devs trouvent ça cool car on peut arrêter de "galérer" avec les migrations et les SQL. Mais pour moi ça crée bien plus de problèmes que ça n'en résout. Car tu déportes les problématiques de relations, intégrité et cohérence de données sur ton applicatif... alors que les SGBD ont toujours parfaitement fait ça.
  Bref, je n'aime pas le NoSQL.

Petite discussion au taf, où j'expliquais aux collègues que j'étais contre les ids numériques pour les notions basiques de sécurité web (car si on a une URL où la sécurité manque, n'importe qui peut pomper des datas en augmentant / diminuant l'ID dans l'URL).
Un collègue m'a dit "oui mais le problème c'est pas l'id numérique, c'est le fait de ne pas avoir de vérification du droit pour consulter/modifier la donnée cible"
Ma réponse : "Oui mais c'est comme partir de chez toi avec la porte ouverte, ou partir de chez toi avec la porte fermée mais pas verrouillée. Evidemment que c'est mieux d'avoir fermé et verrouillé ta porte... mais si jamais tu oublies, autant qu'elle paraisse fermée... plutôt que grande ouverte."

Je vais commencer à bosser sur la qualité à mon taf aka implémenter des tests automatisés ! <3

Excellent : une application d'exemple de l'équipe qui a travaillé sur Ionic 4. Bon à prendre pour checker les bonnes pratiques en dev Ionic.