Simulation de problèmes d'accessibilité numérique.
trouvé via le podcast "Salut les designers" de l'agence Lunaweb
https://media.ccc.de/v/lgm25-upstream...
Images created with digital graphic techniques have played a central role in promoting the seemingly endless growth of a computing culture that many of us now recognize as extractive, polluting and exploitative. Beyond that, something that once promised a utopian future now feels like it has delivered a rather crappy, disappointing reality. FLOSS has undoubtedly played some role in this development, but it also holds a great potential as part of a shift in imagination to new practices and aesthetics that are more verdant, just and humane.
This presentation will propose the concept of "Permacomputing" as a useful lens to consider the role of FLOSS in developing alternative practices. Permacomputing is both a concept and a community of practice oriented around issues of resilience and regenerativity in computer and network technology inspired by permaculture.
We will start with a brief introduction to the concepts and emerging projects around these ideas. With these notions in mind, we can then examine how some of the existing practices of Libre Graphics might inspire or give relevant support to newer, more holistic ways of working. And finally, we will look at some specific examples of software development, education and image making using the generative flora of computing within limits.
Brendan Howell https://pretalx.c3voc.de/lgm25-upstre... #lgm2025
Licensed to the public under https://creativecommons.org/licenses/...
Contrairement à ce que certains titres racoleurs laissent entendre, Signal n’est pas en cause ici.
Le problème vient bien de iOS. Lorsque les aperçus de notifications sont activés (et ils le sont par défaut), le contenu des messages reçus est stocké en clair dans une base de données locale du système iOS, sur ton téléphone quoi.
Oui : en clair. Pour une marque qui met en avant le côté respect de la vie privée de ses utilisateurices, c’est quand même fort de kawa.
Ces données sont enregistrées dans une base SQLite interne liée aux notifications. Et surtout, elles restent stockées même si
Joular Code - Java is a lightweight and efficient Java agent for monitoring the energy consumption of methods and execution branches at the source code level.
This project is part of Joular Code, and is the successor of JoularJX.
🚀 Features
Monitor power consumption and energy of each method and execution branch at runtime
Works as a Java agent — no source code instrumentation or modification needed
Samples the JVM stack at high frequency (default: every 10 ms) and attributes energy every second
Supports three power data source backends from Joular Core:
Shared memory ring buffer (IPC) — lowest latency, recommended
CSV file — file-based polling
HTTP endpoint — remote or containerized setups
Generates CSV files with per-method and per-branch power (Watts) and energy (Joules)
Produces two output sets: one for all methods (including JDK internals), one filtered to your application packages
Configurable method filtering by package/class prefix to focus energy data on your code
Cross-platform: Windows, macOS, Linux, and Raspberry Pi
L'abandon cognitif, c'est le nom donné par les psychologues au fait de consulter une IA et d'adopter son avis, sans faire l'effort de se pencher sur le problème. Je vous explique.
Depuis les années 70, les psychologues distinguent deux modes de pensée :
➡️ Le système 1, rapide et automatique.
➡️ Le système 2, lent et analytique.
Un test psychologique, le CRT, a été conçu exprès pour mettre ces deux systèmes en tension. Il contient des questions où la première réponse qui vient à l'esprit est fausse (donc issue du système 1), tandis qu'en prenant le temps d'y réfléchir on trouve immédiatement la bonne réponse (avec le système 2).
Eh bien une équipe de chercheur a récemment refait l'expérience du test CRT, mais cette fois en laissant la possibilité aux participants de consulter un assistant IA s'ils le désiraient.
Résultats :
1️⃣ 50% des participants demandent immédiatement à l'IA
2️⃣ Parmi eux, 87% suivent l'avis de la machine.
3️⃣ Leur degré de confiance est de 77% s'ils ont utilisé l'IA contre 65% pour ceux qui ont répondu sans l'aide de la machine.
Autrement dit, la majorité des participants n'activent ni leur système 1 ni leur système 2. Ils s'en remettent immédiatement à l'IA – une sorte de système 0, si vous voulez. Les chercheurs appellent ça le "cognitive surrender", l'abandon cognitif.
C'est d'autant plus préoccupant que les participants qui ont utilisé l'IA affichent une confiance plus importante dans leur réponse, alors même que la subtilité de la question leur a échappée.
📚 Ref : Shaw et al (2026). Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender.
Le livre de Geoffrey
After decades of gluing together software from a random set of libraries and frameworks, industry wide attacks on the software supply chain have proven this approach is unsustainable, and it's time to shift our thinking on how we write and ship software. In this session we will explore the various tools used to secure the software supply chain, and through a collection of live demos, learn how to put them to use in the real world.
Kelsey Hightower
Google, Inc.
As a curious and motivated self-learner, I gained an interest in computing at a young age, and started my IT career by opening a small consulting shop 20 years ago. From those beginnings my career progressed quickly, eventually passing through the halls of Google, Puppet Labs, New Relic and CoreOS. I am a system administrator by trade, a programmer by necessity, but a problem-solver at heart. With a passion for helping others, many successful speaking and teaching engagements under my belt, and a proven track record of getting things done and enabling others, I hope to solve the many problems facing IT culture by equipping people with the mental and computational software they need to succeed in the competitive world of technology.
Locality of Behaviour (LoB)
Carson Gross
May 29, 2020
“The primary feature for easy maintenance is locality: Locality is that characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.” – Richard Gabriel
The LoB Principle
Locality of Behaviour is the principle that:
The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code
This an attempt in the same spirit as Morris Vanilla To Do to demonstrate how you can develop a PWA with only HTML, CSS and pure Javascript.
I have aggregated all the knowledge and edge cases I’ve experienced through many PWA development and in production
Want a demo? Go over her here: demo.purejs-pwa.alethgueguen.com
The Github repo: github.com/planeth44/pure-JS-PWA
- The constraints
- Technical choices
- What the app does
- Things
- Files
- HTML forms
- Auto save
- alternate method
- Form validation
- Syncing and offline
- Update
- possible scenario
- Back-end
- Offline Multi Page, how you do that?
- Dependencies
Démo d'application PWA pure JS
I was thinking this morning about how once you understand that your technology choices have security, performance, and accessibility considerations you become a much more boring developer. Acknowledging those obligations can sort of strips the fun out of programming, but we’re better for it.
I decided to pull on that thread a little more and come up with a list of all the concerns you might have as an engineer/developer that ultimately compound to make you a boring, wet blanket of a person to be in meetings with.
- Security - Make sure you’re not opening the door for hackers.
- Privacy - Don’t leak personal information. Or don’t collect it in the first place.
- Performance - Can the software work on low-end devices? Can you deliver the large bundle over bad internet? Those are your problems.
- Inclusion/Accessibility - Are you allowing people the dignity to use your product? No? Oof. You should probably do that. Ideally because you are an ethical person, but also because it’s a legal liability.
- Scalability - If a thousand people show up in the next minute, does your software still work? You have 100 users now, but how does it work for 1000? 1 million? 1 billion?
- Maintenance - Ship a new feature? Great. Expect to spend at least 40% of cost/time to maintain a feature over its lifetime.
- Testability - Did you write the code in a way that’s easy to test to make sure bugs don’t show up in production?
- Deliverability/Distribution - How do people get or use your software?
- Adoption/Onboarding - How do customers or partners use your software? How do they get familiar?
- Documentation - Email and DMs is probably not the most efficient form on knowledge transfer.
- Ecological - Does your app burn through GPUs in Iowa? What are you doing about that?
- Financial/Cost - Servers and GPUs cost money, did you build this in such a way that it costs as little as possible to run?
- Monetizability - Good idea but does it make money or cost money?
- User feedback - What are customers or partners saying about this? Does that impact how or what you write?
- Stakeholder feedback - Like user feedback but everyone freaks out like their job depends on solving the problem that day regardless if its a good idea or bad idea.
- Organizational - How to get your co-workers onboard with the plan plays an outsized part in software engineering. Welcome to the world of office politics!
- Staffability - There’s not a lot of Haskell developers out there. Or the inverse, people over-optimize on technologies that are “easy to hire for” and now you have a billion lines of Java in your application.
- Support matrixes - For websites, of course we support major browsers and the latest 2 versions? Do we need to go back further? Weirdo browsers? Should we make native apps? Which ones? What devices/CPU architectures do we support there? Niche Linux distros? The list goes on.
- Political - Some say “all tech is political”, and I tend to agree, but ask yourself: Did you put a politics inside the code? You did, didn’t you?
- Geopolitical - Rare, but happens. See: Facebook Myanmar genocide
- Localization/Internationalization - Uh-oh, your UI doesn’t work in German or Arabic. Also all your images and icons are offensive to a particular country’s monarch. Are you ready to cross the borders? Get ready for VAT tax tables, ughck.
- SEO/Crawlability - Cool website you made, can robots get to it and index it? Now LLMs are coming and slurping up your content and traffic. Uh-oh!
- Adjacent competitors - What your competitors are doing will always play a role in engineering. Looking better than them is good, being cheaper is good too, but one rule is the most important: never be slower. See: Platform adjacency theory
- Throughput/Velocity - How fast can you and (more importantly) your team ship an idea from conception to production. What about turnaround times on bug reports?
If you ever ask a developer if an idea is possible and their brain lags out with a little loading spinner over their head, it might be this enormous pile of concerns they’re mulling over. That can be an issue, but I’d be more concerned about the developer that instantly says “Yes” to everything. And if you’re tired of developers saying “No” all the time, ask your developer about ways to put them in situations where they can say “Yes”.
This is a tiny (~1.19kB brotli'd) library that mostly mirrors the IndexedDB API, but with small improvements that make a big difference to usability.
Je construis des logiciels métiers sur-mesure pour les PME.
Ça tient à quoi tient la satisfaction du client vis-à-vis de sa consultante externe ?
C’est ma capacité en tant qu’apporteuse de solutions à comprendre comment travaille mon client, quels sont ses besoins, son environnement, pour lui apporter la solution sur mesure adaptée à son métier.
Au cours de mes missions d’ingénierie logiciel, savoir expliquer un concept technique dans le contexte du métier de mon client et me «mettre à sa place» est une des clés de cette réussite.
Cette capacité à comprendre le métier, à établir une communication fluide est tellement primordiale qu’elle a influencé ma théorie sur les conditions de succès d’un projet informatique. Vous avez envie de travailler avec moi ?
La DINSIC publie les 10 principes d’une démarche en ligne exemplaire
Diátaxis
A systematic approach to technical documentation authoring.
Diátaxis is a way of thinking about and doing documentation.
It prescribes approaches to content, architecture and form that emerge from a systematic approach to understanding the needs of documentation users.
Diátaxis identifies four distinct needs, and four corresponding forms of documentation - tutorials, how-to guides, technical reference and explanation. It places them in a systematic relationship, and proposes that documentation should itself be organised around the structures of those needs.
Diátaxis solves problems related to documentation content (what to write), style (how to write it) and architecture (how to organise it).
As well as serving the users of documentation, Diátaxis has value for documentation creators and maintainers. It is light-weight, easy to grasp and straightforward to apply. It doesn’t impose implementation constraints. It brings an active principle of quality to documentation that helps maintainers think effectively about their own work.
tutorialsandhow-to guidesare concerned with what the user does (action)referenceandexplanationare about what the user knows (cognition)
On the other hand:
tutorialsandexplanationserve the acquistion of skill (the user’s study)how-to guidesandreferenceserve the application of skill (the user’s work)
Les technologies web sont devenues matures et proposent aux développeuses et développeurs un ensemble d'API évoluées.
Je montrerai comment les mettre à profit pour livrer des applications performantes et résistantes à des conditions d’utilisation dégradées.
Je vous raconterai comment vivre et travailler à bord de mon voilier plusieurs mois par an, me permet d'expérimenter en conditions réelles ce qu'est un contexte contraint.
Je vous parlerai ensuite des questionnements qui émergent quand les apps doivent opérer sous des contraintes fortes : qu’est-ce que les designers peuvent apporter à la réflexion sur ce sujet.
Enfin, on traitera des options pour aborder cette approche avec nos clients et les convaincre.
Son site Web : https://alethgueguen.com/