In computer science, the ostrich algorithm is a strategy of ignoring potential problems on the basis that they may be exceedingly rare. It is named after the ostrich effect which is defined as "to stick one's head in the sand and pretend there is no problem". It is used when it is more cost-effective to allow the problem to occur than to attempt its prevention.
This branching model was facilitated with the advent of very lightweight branching that came with Git and Mercurial in the mid-2000’s, though there is evidence that Google were effectively doing the same in their Monorepo for some years before.
Comment rendre une organisation aussi adaptable et polyvalente que son environnement ? Comment pouvons-nous préparer une entreprise à survivre et à prospérer au 21e siècle ? De nombreux modèles et frameworks vous proposent des solutions statiques ou pré-packagées. Il est temps de trouver une alternative à SAFe, LeSS, l’holacracy, le “modèle Spotify” ou encore aux organisations matricielles. Nous avons besoin de quelque chose qui porte la flexibilité à un nouveau niveau. Voici ma suggestion. Je l’appelle UNFIX.
Action–domain–responder (ADR) is a software architectural pattern that was proposed by Paul M. Jones[1] as a refinement of Model–view–controller (MVC) that is better suited for web applications. ADR was devised to match the request-response flow of HTTP communications more closely than MVC, which was originally designed for desktop software applications. Similar to MVC, the pattern is divided into three parts.
Le design pattern ADR est basé sur le triptyque Action – Domain – Responder. Il est l’une des alternatives au design pattern MVC.
Il est possible de vulgariser le pattern de la façon suivante :
- Action : l’équivalent d’un contrôleur, dédié à une opération HTTP (une route) de l’application ;
- Domain : le point d'entrée logique vers le code métier ;
- Responder : en charge du traitement et du rendu de la réponse.
A short summary of the patterns in Patterns of Enterprise Application Architecture (P of EAA).
These pages are a brief overview of each of the patterns in P of EAA. They aren't intended to stand alone, but merely as a quick aide-memoire for those familiar with them, and a handy link if you want to refer to one online. In the future I may add some post-publication comments into the material here, but we'll see how that works out.
Deadlines are the bane of every software engineer’s existence. We’ve all been there: the project is “due” in two weeks, and we’re nowhere near done. So we pull all-nighters, do poor testing, and cut corners just to get it done. And what happens? The project is buggy, the customers are unhappy, and we’re all exhausted.
Sometimes, the software will be too buggy even for a software engineer’s standard. When that happens, managers set a new deadline, revealing the first one shouldn’t have existed in the first place. Now, guess what happens if you miss the second deadline? Exactly right, you get a new one. Don’t you love deadlines?
The C4 model is an "abstraction-first" approach to diagramming software architecture, based upon abstractions that reflect how software architects and developers think about and build software. The small set of abstractions and diagram types makes the C4 model easy to learn and use. Please note that you don't need to use all 4 levels of diagram; only those that add value - the System Context and Container diagrams are sufficient for many software development teams.
- Context
- Containers
- Components
- Code
Apdex (Application Performance Index) is an open standard developed by an alliance of companies for measuring performance of software applications in computing. Its purpose is to convert measurements into insights about user satisfaction, by specifying a uniform way to analyze and report on the degree to which measured performance meets user expectations. It is based on counts of "satisfied", "tolerating", and "frustrated" users, given a maximum satisfactory response time t, a maximum tolerable response time 4t, and where users are assumed to be frustrated above 4t. The score is equivalent to a weighted average of these user counts with weights 1, 0.5, and 0, respectively.
L’effet Dunning-Kruger, aussi appelé effet de surconfiance1, est un biais cognitif par lequel les moins qualifiés dans un domaine pourraient surestimer leur compétence.
On peut le rapprocher de l'ultracrépidarianisme.
I. Base de code - Une base de code suivie avec un système de contrôle de version, plusieurs déploiements
II. Dépendances - Déclarez explicitement et isolez les dépendances
III. Configuration - Stockez la configuration dans l’environnement
IV. Services externes - Traitez les services externes comme des ressources attachées
V. Assemblez, publiez, exécutez - Séparez strictement les étapes d’assemblage et d’exécution
VI. Processus - Exécutez l’application comme un ou plusieurs processus sans état
VII. Associations de ports - Exportez les services via des associations de ports
VIII. Concurrence - Grossissez à l’aide du modèle de processus
IX. Jetable - Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux
X. Parité dev/prod - Gardez le développement, la validation et la production aussi proches que possible
XI. Logs - Traitez les logs comme des flux d’évènements
XII. Processus d’administration - Lancez les processus d’administration et de maintenance comme des one-off-processes
