Un kit pour tuer un vampire. On voit bien l’étape 1 pour les vampires faciles, puis 2 si ça marche pas, puis 3 dans la casse du bas, pour finir.

81 % des entreprises devraient virer leur inutiles managers en soif de management.

Car les entreprises s’en foutent : la direction et les actionnaires, je suis sûr qu’ils n’en ont rien à foutre d’où sont les employés, du moment que l’argent rentre. Mieux : chez eux, les employés ne leur coûtent rien en électricité ni en chauffage.

Ce sont les managers qui veulent revoir les gens à fliquer. Eux ne sont rien sans les employés à regarder toute la journée. Ce sont eux qui ont peur que ça finisse par se voir qu’ils sont parfaitement inutiles, et que les gens sont parfaitement capables de bosser tout seuls.

Elle explique avoir ainsi contacté 75 personnes pour un poste d'analyste de données dans une entreprise connaissant une croissance de 400 % par an, la possibilité de télétravailler et pas de limites de congés. Elle se souvient n'avoir reçu que 5 réponses, dont 3 « non merci ».

… et l’entreprise ne se remet pas en question quant au contenu de l’offre d’emploi ? Le salaire, au hasard ?

Mais continuez de vous plaindre et de dire que les gens ne veulent pas bosser. Sachez juste que c’est faux. Les gens ne veulent pas bosser pour vous. C’est tout.

Et puis faut aussi qu’ils arrêtent de dire « notre boîte connaît une croissance de 400 % » s’ils ne sont pas prêt à augmenter les salaires de 400 % aussi. C’est bien beau de dire « nous on a de la thune ! ». C’est mieux de dire « et on la partage avec vous ! ».

Si vous sortez une annonce avec un salaire à la hauteur de la croissance que vous vantez, les dév feront la queue pour venir chez vous, je vous le garantis, et c’est alors vous qui pourrez choisir quel dév vous voulez parmi eux.

Parce que le télétravail, oui, les congés, oui, mais faut quand-même de quoi payer son loyer, sa bouffe et ses factures. Avant de pouvoir prendre congé, d’ailleurs.

Enfin, ce qui est rare est cher. C’est pas pour ça qu’ils vendent hyper-cher leur produit hyper-rare ? Donc s’ils veulent un dév rare, ils le payent cher. Plus cher que leur salaire actuel, en fait. Sinon il ne bougera pas d’un poil, et il aura raison.

Et les dév sont en général pas con et communiquent beaucoup (beaucoup sont nés dév sur Internet et les forums de discussion). Cette communauté est très ouverte avec peu de tabous (évitez juste de leur parler de vim ou emacs).

C’est pour ça qu’ils ne restent généralement pas dans les boîtes qui les prennent pour des cons, et tendent à aller là où ils sont mieux payés ! Tant mieux si ce sont les dév qui recrutent les boîtes, maintenant. Ça change.

Donc encore une fois, je vais pas les pleurer.
Si vous cherchez du monde mais que vous ne voulez pas les payer alors que vous affichez une croissance à 3 chiffres, ma foi : crevez. En silence, merci.

Et ne nous parlez pas de baby-foot. On s’en branle, du baby-foot

Plop !

La panne du site d’hier est corrigée !

C’est un module MySQL qui a planté et à provoqué une charge anormale si le site (saturation mémoire + swap, entre autre).
Même si je ne n’utilise pas du tout MySQL (uniquement SQLite), s’agissant d’un serveur en mutualisé, MySQL a dû planter sur un des sites et ce sont tous les sites qui tombent en cascade ensuite.

Le truc c’est que chaque visiteur qui arrive sur le site arrive dans une sorte de file d’attente. Si l’attente est moins longue que le temps de traitement de sa requête (généralement quelques millisecondes), tout va bien : la file n’a pas le temps de se former.

Mais il suffit qu’une requête d’une personne prenne un peu de temps pour que les personnes qui arrivent ensuite attendent et forment une file (et y un visiteur toutes les quelques secondes ici). Or la gestion de cette file coûte également chère en ressources, d’autant plus que généralement quand ça répond pas, le navigateur ou l’internaute se met à bourriner sur la toucher "recharger", aggravant le problème.

Une façon de gérer serait de déprioriser les requêtes lourdes et de laisser passer les gens avec des requêtes rapides : comme ça seulement une personne attend, mais les autres passent normalement. Alors que si on traite les requêtes par heure d’arriver, t’en as un qui bloque et agace tout le monde et la queue n’en finit pas de grandir et subsiste même une fois le client chiant servi depuis longtemps (c’est généralement ce qui se passe à LaPoste ou au supermarché).

Ce genre de gestion est utilisé sur les gros sites, où les arrivants sont triés par un serveur de tri puis renvoyé sur un autre serveur approprié pour sa requête.
Du coup les gens avec les requêtes simples sont toujours servis rapidement, mais ceux avec des requêtes compliquées vont attendre (normal, si la requête est compliquée).

Mais sur des petits sites, ça ne se passe pas comme ça. Il faut donc faire gaffe à ses scripts.
L’an dernier j’avais le problème où une requête buguée ressortait tous les articles du site (1200+) en une page HTML. Un petit malin a dû s’en apercevoir car tous les jours des dizaines de requêtes sur cette URL étaient faites très rapidement et plantant le serveur à chaque fois. Depuis, j’ai débugué le script et j’ai bloqué des IP et il n’y a plus aucun soucis. J’ai aussi banni tout un tas de robots spammeurs de requêtes.

Le bug d’hier est un plantage plus ou moins aléatoire comme ça arrive tout le temps et partout.

Mon hébergeur a pu corriger le soucis hier soir très tard, merci à eux pour l’efficacité et la correction du soucis !