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/
Observabilité des processus
A local-first, privacy-focused markdown editor. No accounts, no cloud dependency, no sync fees — just a folder of markdown files you fully own.
A local-first, privacy-focused WYSIWYG Markdown vault with full-text search, wiki-links, and a rich editor. Built with Tauri, Svelte, and Rust
Reduce noise in decision making
Plought separates setup from evaluation so you can weigh priorities, work through the tools, and review the tradeoffs before you choose an option.
TODO
- fork pour supprimer l'IA
A modular, local-first block editor engine.
Single contenteditable. Loro-CRDT.
Free, fast, and offline PDF toolkit for professionals. Edit, convert, and process PDFs entirely in your browser with no data uploads. 100% client-side processing.
The professional PDF toolkit that runs entirely in your browser. Powerful WASM engine, no server uploads, simply secure.
Une interface pour configurer Ghostty avec une apparence macOS
Je suis développeuse web depuis une grosse quinzaine d’années. Les IA génératives sont en train de me dégoûter de mon métier.
Je déteste avoir le ventre qui se tord et la voix qui se brise quand j’essaie d’expliquer à quel point je les déteste. Alors j’écris, les yeux brillants.
Je déteste l’idée d’être dans cette industrie qui, globalement, continue d’utiliser ces outils. Chaque problème qu’ils posent, pris séparément, suffit à mes yeux pour s’en passer, et pourtant mes pairs continuent de les produire, de les défendre, de les utiliser. J’en ai marre de ne plus pouvoir faire trois pas dans le monde de la tech sans croiser un gars qui m’explique que tous les problèmes de l’IA sont causés par les utilisateurs qui ne savent pas s’en servir correctement.
Je suis dégoûtée.
C’est assez nouveau, en fait. Pourtant, je suis une femme qui a étudié en école d’ingénieurs et travaillé dans diverses boîtes d’informatique pendant seize ans : des dégoûtants, j’en ai côtoyés. Des machos, des violents, des alcoolisés, des vieux et des jeunes, avec et sans cravate. Curieux, en fait, que je n’aie pas été dégoûtée plus tôt, par ces dégoûtants tellement mieux payés que moi, comme tant d’autres femmes de la tech avant moi.
Mais les IA génératives, c’est différent.
Elles détruisent tout. L’environnement. L’humanité. Et, c’est là que ça devient personnel, elles détruisent très précisément ce que j’aime dans mon métier pour mieux me noyer dans le reste.
Personnellement je refuse de me servir des IA génératives ; je mesure la chance d’être mon propre employeur et d’avoir la liberté de refuser. Tant d’autres ont expliqué ce qui ne va pas avec les IA génératives. Je ne ferais que répéter. Je vais essayer de me concentrer ici sur ce qui m’a fait aimer ce métier.
De ce métier, et dans l’absolu, j’aime principalement trois choses : créer, apprendre et transmettre. Le métier de dev a ceci de sympathique — en tout cas il avait ceci de sympathique avant 2022 — qu’il permet de varier les plaisirs en permanence avec des petites combinaisons : apprendre en créant, créer pour transmettre, et apprendre en transmettant.
Peut-on battre les modèles de Google ou Meta avec seulement 4 GPU et une disquette Zip ? C’est le pari fou de notre invité.e qui nous explique comment le "Data Design" est en train de ringardiser le scraping massif du web. 🥖 L'IA qui tient sur une disquette : La fin du gigantisme ? Dans cet épisode, on plonge dans le coeur de l'IA souveraine : pourquoi la qualité des données (tokens) prime sur la quantité, et comment les Small Language Models (SLM) vont permettre de décentraliser l'intelligence. 🚀 Ce que vous allez apprendre :
- Baguettotron : Le modèle de 320M de paramètres qui raisonne mieux que des géants.
- Data Design vs Scraping : Pourquoi "nettoyer" la donnée ne suffit plus, il faut la concevoir.
- Le secret des données synthétiques : Comment éviter le "Model Collapse" (l'appauvrissement de l'IA).
- Souveraineté : L'enjeu des bibliothèques nationales et de l'Open Data face au pillage des "Shadow Libraries".
⏳ Timestamps pour naviguer : 00:00 — Jeu d'indices : qui est la pionnière de la tech française ? 04:38 — L'arnaque du "poids ouvert" : qu'est-ce qu'une IA vraiment Open Source ? 14:41 — Data Design : pourquoi Pleias mise sur la provenance plutôt que le scraping 24:11 — Baguettotron : l'IA performante qui tient sur une disquette Zip 36:01 — Small Language Models (SLM) : battre les géants avec seulement 4 GPU 52:00 — L'avenir décentralisé : IA locale, souveraineté et modèles de raisonnement SPOILER ALERT : pour en savoir plus sur notre invitée Anastasia Stasenko , CEO Pleias : https://www.linkedin.c... 🔗 Liens et ressources : Pleias : https://pleias.fr/ Modèles & Datasets : Retrouvez "Common Corpus" sur Hugging Face.