A typical pattern describes the problem, the chosen solution, the rationale behind that solution, related patterns that the designer should be aware of, and other relevant details, such as the results of usability testing.– Jared Spool
Die größte Gefahr für Pattern Libraries und Design Systeme ist, nicht mehr aktuell zu sein.
für ein Design Pattern Aktualität viel wichtiger ist, als gründliche Dokumentation
Spart eine Pattern Library keine Zeit oder erzeugt sogar dauerhaft zusätzlichen Aufwand, wird sie automatisch Akzeptanzprobleme bekommen.
Iterationen für Abbildung eines Pattern Library (bei OTTO):
- 2012: Getreu nach Lehrbuch
- 2012-2013: Modularer Ansatz
3, 2013-205: Code Pattern Library = Pattern Library - 2014-2016: Basierend auf den Atomic Design Prinzipien von Brad Frost; responsive patterns, komponenten, templates (bottom-up) oder Grid & breakpoints, content refertence Wireframes, Layout (top-down)
- 2016-heute: ein komplettes tool
Une mise en situation bien complexe ou chacun peut développer selon ses capacités, son expérience, etc...
Le TDD est avant tout une méthode de développement permettant de faire émerger son design et donc son code grâce aux tests
“Baby-step”, c’est la clé pour s’amuser, pas au sens d’enfantillage, mais pour prendre plaisir à développer et comprendre que notre métier est vraiment beau quand on supprime toute forme de “hasard”.
Un cycle TDD "Red, Green, Refactor" correspond une une bribe de spécification écrit sous forme de test et sa réponse. On écrit le code minimaliste pour que ce test "Red" fonctionne et passe au "Green".
Pour cela, il est recommandé d'abuser de son IDE. Par sa construction itérative guidée par les tests, TDD apporte par “effet de bord” un taux de couverture de code par les tests à 100%. Ce n’est pas ce que l’on recherche de prime abord, mais ce code coverage est là, et surtout il est pertinent. C’est ce dernier mot qui est important : cette pertinence permet réellement de se plonger dans la troisième phase de TDD.
Ensuite on refactorise pour donner plus de sens: spécifier les erreurs, de passer d'un constructuer à un builder, ... Nous pouvons nous le permettre car les tests nous soutiennent. Ils seront aussi à évoluer, par exemple pour vérifier que le builder pattern fonctionne correctement.
:D
These statements of architectural principle explain the thinking behind the specifications. These are personal notes by Tim Berners-Lee: they are not endorsed by W3C on anyone else. They are aimed at the technical community, to explain reasons, provide a framework to provide consistency for future developments, and avoid repetition of discussions once resolved.
Feedbacks about the open-source build tool Bazel, backend by Google.
Un retour d'expérience littéraire ❤️
How CSS helped
La lanceuse d'alerte Frances Haugen a témoigné devant une commission du Sénat en présentant des milliers de pages de documents confidentiels qui laissent penser que Facebook est parfaitement conscient que ses plateformes (y compris Instagram) nuisent aux enfants et aux adolescents
Ce qui est clair, c'est que cette désinformation est préjudiciable aux utilisateurs, notamment aux plus vulnérables d'entre eux: les enfants et adolescents. La question qui se pose est donc la suivante: que pourraient faire les plateformes pour protéger les utilisateurs? Et ont-elles même la responsabilité de nous protéger?
Malheureusement, il semble que le fait d'avoir cette responsabilité entre en conflit direct avec ce qui assure la rentabilité et la croissance de ces entreprises.
Quelques points abordés:
- l'utilisation d'Instgram
- les vidéos vraies sont plus facilement moins aimés
- Facebook (Instagram) est pleinement conscient de ces cas
- les photos postées sont éloignées de la réalité. Le contenu
- les enfants sont fortement influencés par le contenu qu'ils y voient
- ces réseaux mettent en avant des contenus les plus divertissants, leur objectif premier pour retenir l'attention, le temps de visionnage afin de générer des revenus. Ce qui ne serait pas un problème si les utilisateurs ne les considéraient pas autant comme des sources d'information fiables et factuelles. Ils sont donc constamment induit en erreur. L'imaginaire et le fantastique sont présentés comme la réalité
- de ce fait, "leur" Internet ne représente pas la réalité.pourtant,
- protéger les enfants et les utilisateurs des contenus rentre en conflit direct avec ce qui assure la rentabilité de ces entreprises
- Idée pour Instagram: développer une fonctionnalité pour vérifier les faits exposés
A homemade social network: https://bluedwarf.top/cackle/index.php
Basically a new one because:
- the big ones are unhealthy
- the alternatives needs resources so that they can not run on a Raspberry Pi
- it is home
Il me paraît fondamental de revenir sur ce point, il n’y a pas un prof qui peut vous prédire ce que vous ferez demain. La notion d’échec ou de réussite est un concept qui n’a que peu de sens. Avoir un diplôme n’est pas un critère obligatoire de réussite ni de bonheur.
On en vient finalement à oublier que l’enseignant n’est finalement qu’un professionnel comme un autre. Il n’y a donc pas d’histoire d’amour ou de désamour, il y a juste une expertise.
Le but de l’enseignant est de contribuer à la construction de la société, expliquer à un jeune qu’il ne vaut rien, qu’il ne fera rien est totalement contreproductif. Par contre, lui mettre un coup de pied aux fesses de temps en temps, lui permettra d’avancer.
Coq est un assistant de preuve. Je commences à en entendre parler tous les mois. Il semble qu'il soit le meilleur dans sa catégorie.
Un témoignage...
Témoignage d'une professionnelle soignante → https://threadreaderapp.com/thread/1475197820747628548.html
- I still don't know very much.
- The hardest part of software is building the right thing.
- The best software engineers think like designers.
- The best code is no code, or code you don't have to maintain.
- Software is a means to an end.
- Sometimes you have to stop sharpening the saw, and just start cutting shit.
- If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system.
- Every system eventually sicks, get over it.
- Nobody asks "why" enough.
- We should be far more focused on avoiding 0.1x programmers than finding 10x programmers.
- One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be.
- People don’t really want innovation.
- Your data is the most important part of your system.
- Look for technological sharks.
- Don't mistake humility for ignorance.
- Software engineers should write regularly.
- Keep your processes as lean as possible.
- Software engineers, like all humans, need to feel ownership.
- Interviews are almost worthless for telling how good of a team member someone will be.
- Always strive to build a smaller system.
A blog post as response to it ?