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

Trouvé depuis : https://alethgueguen.com/slides/2025_JUG/web_natif_hors_ligne.html#36

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 ?

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.

• tutorials and how-to guides are concerned with what the user does (action)
• reference and explanation are about what the user knows (cognition)

On the other hand:

• tutorials and explanation serve the acquistion of skill (the user’s study)
• how-to guides and reference serve the application of skill (the user’s work)

Observabilité des processus

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

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.

La DINSIC publie les 10 principes d’une démarche en ligne exemplaire

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/

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”.