Un article de Ploum sur la connexion constante aux flux d'informations de notre société
Des questions très intéressantes à demander en entretien d'embauche.
Le but est de déterminer si l'entreprise à un produit pérenne, une stratégie de vente qui tient la route et une culture tech acceptable.
Quelques exemples:
- Votre produit a t-il trouvé son marché ?
- À quelle vitesse "brûlez" vous votre argent ? Quand pensez-vous atteindre la rentabilité ?
- Quel est le turnover ? Comment faites vous pour garder vos employés ?
Collection d'avis (réels ou pas) sur Jira 🙈
Excellente bande dessinée sur la diabolisation d'une partie de la gauche sous l'étiquette "extrême gauche" par LREM en opposition avec l'extrême droite qui lui est préférée.
Enfaîte c'est plutôt la droite qui rejoint l'extrême droite, naturellement.
L'histoire dingue d'un mec qui a été payé pendant des années à écrire des faux articles de presse commandés par des lobbies dans le but d'influencer la population en fonction de leurs intérêts.
Des exercices pour progresser avec l'utilisation des types en TypeScript !
Grâce aux corrections c'est aussi une très bonne source d'informations pour résoudre des problèmes de définition de types 🔥
Earthly est un framework pour définir ses jobs de CI.
On écrit le job dans une syntax qui ressemble à un Dockerfile et ensuite on peut l'exécuter dans une CI (Github, Gitlab, Jenkins, etc) mais aussi sur sa machine en dev !
Ça permet de tester le fonctionnement des étapes de CI en local donc énormément de temps gagné lors de la mise en place.
# Earthfile
VERSION 0.6
FROM golang:1.15-alpine3.13
RUN apk --update --no-cache add git
WORKDIR /go-example
all:
BUILD +lint
BUILD +docker
build:
COPY main.go .
RUN go build -o build/go-example main.go
SAVE ARTIFACT build/go-example AS LOCAL build/go-example
lint:
RUN go get golang.org/x/lint/golint
COPY main.go .
RUN golint -set_exit_status ./...Puis dans la CI où en local: earthly +all
Une awesome liste de moteurs de recherche et autres ressources liées à la sécurité informatique et la recherche d'informations sur une cible.
Mon best-of:
- Virus Total excellent antivirus en ligne
- Have I Been Pwned savoir si votre adresse e-mail a été compromise et surtout par qui
- Spy On Web identifier des domaines liés entre eux, notamment via les trackers (l'arroseur arrosé 😉)
- That's Them annuaire inversé pour téléphones et e-mails
- Exploit DB chercher un exploit pour une version spécifique d'un logiciel
- Shodan basé de données de TOUS les services exposés sur internet
Decathlon à organisé un live bug bounty, cela s'apparente à une compétition type hackaton mais dont le but est de trouver des failles de sécurité.
A priori cela a porté ses fruits car entre autre une RCE (Remote Code Execution, une faille parmi les plus critique) et une injection SQL ont été découvertes.
La cible était la plate-forme e-commerce réalisée avec Prestashop.
Amazon annonce une alternative à Copilot (Github/Microsoft).
Il y a fort à parier que leur IA a aussi été entraînée avec le code open source sur Github.
A noter que Github Copilot est maintenant payant (10$/mois)
Les Service Workers ne vont pas magiquement améliorer les performances d'une application notamment car l'envoi de données entre les processus (postMessage) est relativement lente comme tous les autres mécanismes d'Inter Process Communication (IPC)
En général pour faire des calculs intensifs il est préférable de le faire durant le temps restant après que le navigateur ait terminé le rendu d'une frame de la page Web avec requestIdleCallback
Un meta article qui résume pleins de choses sur les Service Workers des navigateurs.
Très bon explication sur les différences entre les Map et les POJO en Javascript.
En substance:
- utilisez les POJO lorsque le nombre de clé est connu d'avance et en tant que Data Transfer Object (DTO)
- utilisez les
Mappour tout ce qui s'apparente à un cache RAM et nécessite des insertions/deletions arbitraires
Lorsqu'elle sont bien utilisées, les Map auront une meilleure performance, utilisent moins de RAM et offre une meilleure API plus complète POJO (e.g. Map.clear) au prix d'une perte en DX (e.g. initialisation, spread operator)
Un article très complet sur le fonctionnement des lexer / parser de v8 (Chrome, Node.js) et SpiderMonkey (Firefox)
On comprend notamment que v8 se "plie" aux conventions des outils de minification du code ou encore que le point virgule est bien nécessaire ;-)
Un article très complet sur l'utilisation de AbortController pour annuler des requêtes réseau en cours notamment.
Je ne savais pas qu'il était aussi possible d'arrêter un listener de cette manière ! C'est pratique car il n'y a pas besoin de garder une référence sur la callback.
const controller = new AbortController();
const { signal } = controller;
window.addEventListener('resize', () => doSomething(), { signal });
// later
controller.abort();Un runtime Javascript (comme v8 qui est utilisé dans Chrome et Node.js) qui utilise seulement 8.5 Ko d'espace disque et minimum 34 octets de RAM!
Le but est d'utiliser du Javascript dans des micro contrôleurs qui pour la plupart ont 64 Ko de disque et 2 Ko de RAM.
L'auteur défend son projet avec notamment l'argument du single thread de javascript qui consomme moins de ressources que le multi thread.
On peut aussi ajouter qu'il est nettement plus simple et maintenable d'écrire du JS à mémoire managé que du C.
Un mix entre bash et javascript pour écrire des scripts bash avec plus d'aisance. (Car oui écrire des scripts un peu compliqué en bash est une chienlit..)
#!/usr/bin/env zx
await $`cat package.json | grep name`
let branch = await $`git branch --show-current`
await $`dep deploy --branch=${branch}`
Analyse détaillée d'informations extraites de Tinder via des bots connectés sur leur API.
Les explications des outils d'analyse (Python, Panda, Numpy, etc) et les snippets sont bien expliqués 👍
Un framework CRUD "fullstack": le code pour manipuler le CRUD des modèles est le même en front et en back.
Sinon c'est basé sur Express avec des classiques règles de validations.
En gros ça expose une API pour du CRUD à la manière d'un backend clé en main qui peut être manipulé dans du frontend ou un autre backend
Très bon article sur les Design System et leurs limites:
- trop de couplage entre composants et logique métier spécifique (data fetching, state, etc)
- manque de documentation à jour (le plus vieux problème des développeurs)
J'aime aussi la distinction qu'ils font entre front-frontend qui s'occupe principalement de l'UI via le design system justement et le back-frontend qui est plus dans la récupération des données et la gestion du state.