Should you know about how Postgres handle the physical storage? Maybe not, but knowing how it works can be useful if you need to investigate some problems.
C’est long mais excellent. J’aimerais en lire plus des comme ça.
Should you know about how Postgres handle the physical storage? Maybe not, but knowing how it works can be useful if you need to investigate some problems.
C’est long mais excellent. J’aimerais en lire plus des comme ça.
Plus j’avance et moins je crois aux branches et aux livraisons unitaires. Pour plein de raisons, quitte à sacrifier un peu de performance, je conseille la livraison en production de tout le code, même s’il n’est pas fini.
L’important c’est l’interrupteur, la possibilité d’activer ou désactiver un comportement.
Feature toggles are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it’s important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system.
L’article est long, il n’aborde pas vraiment le comment, mais résume beaucoup de choses sur l’approche et le quoi.
Rien de très étonnant ni nouveau mais tout de même intéressant :
Je comprends tout à fait l’origine de cette dernière donnée mais sa pertinence m’interroge.
Pourquoi l’entreprise dépenserait plus pour des informaticiens sur Paris plutôt qu’en région alors qu’ils vont produire la même chose ? Ou vu de l’autre côté, pourquoi paierait-on moins un informaticien hors Île de France alors qu’en plus les locaux et l’encadrement y coûtent moins cher pour l’entreprise ?
Si on considère que c’est uniquement l’entreprise qui est légitime à payer le moins possible, pourquoi donc est-ce qu’on continue à tout concentrer sur Paris ? Je ne vois pas la logique dans tout cela.
Des entreprises qui viennent de Paris et qui décident de migrer en région sans en changer les salaires risquent d’avoir un avantage compétitif significatif tout en descendant leurs coûts (pas sur le salaire, mais sur les locaux, les négociations annuelles, les coûts de recrutements…)
Attention quand vous faites des filtres assez sélectifs, la base de réponses reste assez limitée.
on est dans la phase de l’adolescence. Ça cri, ça bouge, ça a plein d’énergie, et ça mérite des baffes.
L’installation est devenue un enfer. Entre les dépendances dépréciées, les libs incompatibles, les différents outils de build, et les options de config et les plugins, c’est une merde incommensurable. Plusieurs standards d’installeurs (et outils joints) se tirent la bourre : AMD, CommonJS et Harmony. Vous vous souvenez du temps ou on copiait juste jQuery dans le répertoire static ?
[…] On peut faire plus de choses qu’avant. De manière plus propre […] Mais l’écosystème, c’est le bordel général, l’anarchie totale, et ça continue d’avancer, en laissant tout le reste derrière.
Les projets JS s’accumulent, de freelances en SS2I qui se pointent, codent ou (surtout) recodent, et repartent en laissant un projet qu’il sera imbuvable à reprendre, déprécié avant même d’être terminé, non documenté, non testé.
Livré sans commentaire, mais j’aimerais bien les vôtres.
Il y a de tout et de rien dans cette présentation de Rasmus à Paris, mais je reste impressionné par le gain en performance annoncé partout pour PHP 7. Si on en obtient même la moitié de ça, ça reste une révolution pour PHP.
On parle de +30% de requêtes traitées dans le même temps au minimum, souvent +50% et plus, le tout en utilisant moins de mémoire.
J’ai envie de mettre des graphiques mais on va me dire qu’il ne sont pas représentatifs, alors faites les vôtres.
- Checks for calls and instantiations of undeclared functions, methods, closures and classes
- Checks types of all arguments and return values to/from functions, closures and methods
- Supports
@param
,@return
,@var
and@deprecated
phpdoc comments including union and void/null types- Checks for Uniform Variable Syntax PHP 5 -> PHP 7 BC breaks
- Undefined variable tracking
- Supports namespaces, traits and variadics
- Generics (from phpdoc hints – int[], string[], UserObject[], etc.)
- Experimental dead code detection
Je me rappelle les bidouilles sur PHP_Code_Sniffer à SQLi à partir du tokenizer, et les essais d’analyse statique de Pascal sur les montées en version de PHP à TEA.
Là Phan semble un vrai outil, basé sur un AST natif au langage. Je suis certain qu’on n’en est qu’au début des possibilités offertes par l’AST de PHP 7. Rien que l’aide à la migration ne va pas être inutile.
J’ai un peu peur qu’on entre dans le monde Java, d’autant plus que les type hints sont maintenant la norme et que le langage se complexifie, mais pas mal de portes s’ouvrent en ce moment pour PHP, et c’est sacrément cool.
Many of us ride elevators every day. We feel like we understand how they work, how they decide where to go. If you were asked to put it into words, you might say that an elevator goes wherever it’s told, and in doing so goes as far in one direction as it can before turning around. Sounds simple, right? Can you put it into code?
J’adore l’idée : Le défi de programmer un ascenseur, avec une explication initiale, quelques tests, et le défi de tout faire… pour se rendre compte que c’est quand même bien plus complexe que ça ne semble à-priori.
C’est du python mais la syntaxe ne représente très clairement qu’une très faible part de l’exercice. Avec la doc en ligne ça doit être faisable sans être limité par l’utilisation d’un langage qu’on ne connait pas vraiment.
J’ai presque envie d’essayer, mais juste peur de commencer, me rendre compte que ça va me prendre des jours, et abandonner. Je sais que c’est un peu l’objet de l’exercice, mais si je commence sans arriver à quelque chose ça ne va pas me mettre dans un état d’esprit très positif.
- Fluent Interfaces break Encapsulation
- Fluent Interfaces break Decorators (and sometimes Composition)
- Fluent Interfaces are harder to Mock
- Fluent Interfaces make diffs harder to read
- Fluent Interfaces are less readable (personal feeling)
- Fluent Interfaces cause BC breaks during early development stages
J’ai parfois l’impression d’être dans les dino quand je me bats contre cette mode alors je suis heureux de voir ne pas être le seul.
Ce type d’écriture est juste magique pour créer des filtres successifs, essentiellement dans les objets de construction (builder).
Pour tout le reste, c’est juste un faux raccourci d’écriture. On casse beaucoup de choses pour gagner quelques caractères. Le plus souvent on ne les gagne pas vraiment puisqu’il faut bien penser à faire le return $this/self
dans la méthode appelée et à gérer correctement l’indentation dans la méthode appelante.
Comment faire un code qui évite les mauvaises pratiques et reste maintenable en éliminant les risques ? La présentation de Marco Pivetta est à regarder.
Il y a pas mal d’idées. Tout n’est pas forcément à reprendre tel quel à mon avis, mais ça permet au moins d’y penser.
Je suis de ceux qui laissent souvent les thèmes par défaut dans les éditeurs de code.
Je ne supporte pas les colorisations sapin de Noël. Les bleu clair sur bleu foncé ne m’enthousiasment pas plus, j’ai commencé l’informatique avec ça et suis heureux d’être passé à autre chose.
Par contre je tombe sur DuoTones, et je me vois bien utiliser ça. On garde du contrastes, trois couleurs, mais des tons pour différencier les choses. Je me vois bien l’utiliser, dommage qu’il n’existe pas pour SublimeText.
Sinon pour Sublime, dans un genre très différent, il y a le Material Theme, assez sympa aussi.