Osmar Petry

JavaScript Modules and Bundlers

Mon, 23 Mar 2026 00:00:00 +0000

The goal here is to understand JavaScript module systems (IIFE, CommonJS, ESModules), how modern bundlers sit on top of them, and which build types to use for business apps and component libraries.

Module systems describe how code is organized and imported/exported at the language level. Bundlers and build tools consume those modules and produce optimized outputs for different environments (browser, Node, CDN, etc.).

Part 1 — Module Systems

IIFE (Immediately Invoked Function Expression)

IIFEs are the classic pattern to create a private scope and avoid polluting window, often combined with a single global namespace like App.

PixieShop Authentication Playbook — OIDC SSO Across Four Identity Providers

Sat, 21 Mar 2026 00:00:00 +0000

Scenario. PixieShop is a B2B SaaS that sells enchanted toys to retail partners. Every partner logs in through their own corporate identity provider — some use Okta, others use Microsoft Entra ID. We never see a password. FusionAuth sits in the middle as our OIDC identity broker, and Auth.js v5 handles the Next.js session on the frontend. This playbook is the single place where we document how the whole chain works, from RSA key creation to federated logout.

Backend Architectures — history, case studies & dogfooding

Mon, 01 Sep 2025 00:00:00 +0000

Summary

Know the history (monolith → services → serverless) to choose the right shape for now.
Use dogfooding to turn internal capabilities into platforms and eventually products.
Pair tech + finance on every decision so architecture choices have a clear P&L story.

Case studies (what they did → why it mattered)

Amazon: built infra & tooling for itself first (dogfood) → later externalized as AWS (new revenue, 2× monetization of the same effort).
Netflix: hybrid of microservices + serverless; serverless for bursty/edge workloads, services for core domains → speed + cost control.
Google: evolved from large coordinated monoliths to microservices as scale/teams grew → independent deploys and targeted reliability.
Uber: reused profile, payments, geo, notifications to launch Eats quickly → time-to-market by reusing platform primitives.

Decision heuristics (when to pick what)

Monolith first when the team is small, domain still moving, and you need velocity.
Split by domain (bounded contexts) when teams block each other and deploys become risky.
Serverless for event-driven, spiky, or edge tasks where operational burden must be minimal.
Always design for observability (logs/metrics/traces) and clear failure domains.

Dogfooding → productization loop

Build the capability you need (internal API/service).
Harden with SLOs, docs, dashboards.
Reuse across 2–3 internal products (prove generality).
Abstract contracts (versioning, quotas, cost model).
Externalize (SDKs, billing, support) when economics are clear.

Two-sided payoff: internal reuse lowers cost/time, externalization creates revenue.

Web Accessibility V3 — Topics cheat-sheet & decision guide

Mon, 01 Sep 2025 00:00:00 +0000

Summary

Course map covers Screen Readers, Accessible HTML, ARIA, Focus Management, and Visual Considerations, plus Debugging & team process.
Aim: ship perceivable, operable, understandable, robust experiences (POUR) with practical exercises and team-ready debugging habits.

Topics → what to do (at a glance)

Screen Readers: learn how they work, enable them, write solid alt text, and test.
Accessible HTML: prefer semantic elements and set document language; fix invalid markup.
ARIA: add only when semantics aren’t enough; know roles, states, properties, names/descriptions, and live regions.
Focus Management: full keyboard support, skip links, logical Tab order, avoid focus traps, and review shortcuts.
Visual: check color contrast, reflow/zoom, reduced motion, and prefers-color-scheme; connect performance with accessibility.
Debugging: use linters/devtools, improve team workflows, go beyond compliance, and practice with hands-on exercises.

Decision heuristics

Semantics first → ARIA last. If a native element already communicates role/state, don’t add ARIA.
Keyboard is the truth. If it’s not operable with keyboard and visible focus, it’s not accessible.
Name, role, value: can a screen reader expose them correctly? If not, fix semantics, labels, or ARIA.
Respect user prefs: prefers-reduced-motion, prefers-color-scheme, and zoom/reflow without loss.

Team workflow

Set standards (WCAG targets, browser/AT matrix).
Lint & test early (HTML validity, axe, devtools).
Exercise mindset: practice with screen readers and keyboard on real UI (modals, forms, navigation).
Go beyond checklists: optimize usability for assistive technology users, not just box-ticking.

Dev checklist

Landmark structure (header, nav, main, aside, footer).
Page language (<html lang>).
Forms: <label> + programmatic names; error text announced.
Interactive controls are native or fully re-created (role, keyboard, focus, ARIA).
Focus order and visible focus style.
Contrast meets WCAG; no information by color alone.
Motion: provide a reduced motion path; avoid parallax autoplay by default.
Respect zoom/reflow at 200–400% without horizontal scroll.

References

Web Accessibility — All Topics (Frontend Masters companion site): https://web-accessibility-v3.vercel.app/topics
GitHub repo: https://github.com/marcysutton/frontend-masters-web-accessibility-v3

[[react-forwardRef|Forwarding Ref]]
[[svg-are-the-best|SVG are the Best]]

XState — model UI behavior correctly and make it testable

Sat, 12 Jul 2025 00:00:00 +0000

The problem we’re solving

Imagine you join a company that runs an e-commerce platform. Product asks you to build a search page — the kind of page every user hits dozens of times a day. It sounds simple: a text input, a button, show results.

But then reality kicks in. The page has to handle empty queries, network failures, slow connections, retries, and race conditions where a user submits a second search before the first one finishes. A junior developer might reach for a handful of useState calls — isLoading, hasError, data, submitted — and suddenly you’re juggling four booleans that produce sixteen possible combinations. Most of those combinations are impossible, but nothing in the code prevents them. A loading spinner stays visible after an error. A success message flashes before the data arrives. Bugs creep in not because the developer made a logic error, but because the model itself was never defined.

Domain-Driven, Data-Oriented Design (DDDOD)

Sun, 01 Jun 2025 00:00:00 +0000

Overview

Bill Kennedy adapts Domain-Driven Design principles to Go by emphasising data flow and simplicity. DDDOD keeps the focus on reliable data transformations while preserving idiomatic Go patterns.

Why not pure DDD?

Traditional DDD can introduce excessive abstraction and ceremony in Go projects.
Too many layers and interfaces obscure intent, reducing maintainability.

Core pillars

Data-oriented design: prioritise data models and their transformations; ensure data can cross layers safely.
Validation & trust: embed validation logic early; fail fast to maintain integrity.
Structured layers: app → business → storage; each layer defines clear contracts and side-effects.
Domain isolation: separate bounded contexts to prevent accidental coupling and cascading failures.

Implementation tips

Use packages to reflect domains (internal/user, internal/auth); avoid grab-bag packages like common.
Expose only necessary APIs; keep implementation details private.
Guard entry points with validation and logging to catch anomalies early.
Leverage functional options or constructors to initialize services with dependencies explicitly.

References

Bill Kennedy, “Domain-Driven, Data-Oriented Design” talk and articles (Ardan Labs).
Ardan Labs Service repository as a starter kit: https://github.com/ardanlabs/service

[[ddd|Domain-Driven Design: Tackling Complexity in the Heart of Software]]

Gophers 2025 — Event Report

Tue, 20 May 2025 00:00:00 +0000

Introduction

Gophers 2025 brought the Go community together in Anita Garibaldi, Santa Catarina, for two full days of talks, panels, and hands-on workshops. Sessions ranged from organizational culture and dependency-injection strategies to Kubernetes tuning, automation, game development with Ebiten, and end-to-end observability. This report consolidates every note found in the Gophers 2025/ directory into a single English-language document. It follows the event chronologically and highlights technical takeaways, workshop content, a real-world case study, and concrete action items.

Go Serialization Options

Mon, 12 May 2025 00:00:00 +0000

Summary

Go types can expose custom wire formats through encoding/json and related packages. The main choices are MarshalText / UnmarshalText, MarshalJSON / UnmarshalJSON, or explicit helper functions. Each option trades off convenience, control, and complexity.

1. `MarshalText` / `UnmarshalText`

Implements encoding.TextMarshaler and encoding.TextUnmarshaler.

This converts values to plain text. JSON, XML, and other encoders automatically use it when a custom JSON marshaler is absent.

func (n Name) MarshalText() ([]byte, error) {
	return []byte(n.value), nil
}

func (n *Name) UnmarshalText(data []byte) error {
	n.value = string(data)
	return nil
}

2. `MarshalJSON` / `UnmarshalJSON`

Implements json.Marshaler and json.Unmarshaler.

Package Oriented Design

Mon, 12 May 2025 00:00:00 +0000

Summary

Bill Kennedy’s Package Oriented Design (POD) emphasises starting and ending architectural decisions at the package level. Each package should provide a focused solution for a domain problem to keep code composable, testable, and maintainable.

Definition

POD identifies where each package belongs and the design rules it follows. Packages act as the building blocks of Go applications, supporting composition and isolation.

Guiding philosophy

Purpose over storage: packages should provide behaviour, not just hold utilities.
Encapsulation: expose only necessary APIs and hide implementation details.
Portability: a consistent package structure makes discussion and reuse easier across projects.
Layering: organise code into purposeful layers, such as kit, application, and service, with explicit interaction rules.

Benefits

Modularity: domain-specific packages reduce unwanted coupling.
Maintainability: clear responsibilities make testing and refactoring easier.
Scalability: well-defined package boundaries support growth in complexity and team size.

Package responsibilities

Live in one place per domain, such as internal/user or internal/platform.
Provide a specific solution and avoid generic buckets like common or util.
Export only the API needed by consumers and keep implementation details private.
Name files to reflect behaviour so callers understand what the package delivers.

Layering cheat-sheet

`kit`

Shared libraries with zero dependency on application packages.

Conway’s Law — origins, literature, and team design

Tue, 15 Apr 2025 00:00:00 +0000

Reference stack

Melvin Conway, “How Do Committees Invent?” (1968).
Thoughtworks, “Applying Conway’s Law to Improve Your Software Development.”
M. Soldani et al., “A Decade of Conway’s Law: A Literature Review 2003–2012” (IEEE).
Video summary: https://youtu.be/SWrlFod8t5g.

Essence of the law

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

Architecture mirrors team communication pathways; siloed teams create siloed modules, joined at fragile seams.
“Monolithic teams do not build microservices”—system modularity depends on cross-team autonomy and shared vocabulary.
Neglecting communication design results in accidental system design, rather than deliberate architecture.

Historical context & popularization

Conway observed the phenomenon across software, military, and governmental projects in the 1960s.
Frederick Brooks amplified the idea in The Mythical Man-Month, cementing “Conway’s Law” in software folklore.
Later research confirms that org charts and interface diagrams often align, sometimes unintentionally.

Key takeaways from the literature review

Larger organizations introduce communication friction, leading to complex, tightly coupled systems.
Parkinson’s Law: management layers tend to expand, exacerbating coordination overhead.
Small, autonomous teams (“two-pizza teams”) correlate with cleaner, more modular architecture.

Review questions

How does organizational structure influence the resulting system design?

Systems reflect the communication patterns of their creators; poor cross-team collaboration manifests as brittle interfaces.

How does company size impact system complexity?

As organizations grow, coordination paths lengthen, producing sprawling systems with integration pain; keeping teams small mitigates the effect.

Practical implications

Design teams around the architecture you want (the “inverse Conway maneuver”): align squads to bounded contexts before writing code.
Optimize for communication density: co-locate domains, create shared rituals, and collapse unnecessary hierarchy.
When introducing API gateways or platform teams, ensure their communication network matches the required integrations.
Regularly map org structures to architecture diagrams; adjust teams when misalignment appears.

Next actions

Compare current team topology with service/module boundaries; plan reorg if misalignment exists.
Share the original essay and Thoughtworks article with engineering leadership to ground discussions in historical context.
Incorporate Conway’s Law checkpoints into architecture reviews (e.g., “Does a team own each interface?”).

[[DbC|Design by Contract]]
[[no-silver-bullet-1986|No Silver Bullet — Essence & Accidents]]
[[parnas-modularization-1972|Modularization Criteria — Parnas 1972]]
[[software-aging-1994|Software Aging]]

Decision-Making Traits of Great Software Engineers

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Based on 59 interviews with senior Microsoft engineers (Meyer, Zimmermann, Fritz, ICSE 2015). Identifies 53 characteristics grouped into personal qualities, decision-making, team impact, and product impact. Focus here is on decision-making skills that differentiate top engineers.

Key points

Deep knowledge of organisational context (people, priorities, constraints).
Ability to switch between big-picture vision and low-level details.
Balancing short-term deliverables with long-term maintainability.
Evaluating risks and trade-offs before committing to technical choices.
Creating shared context: ensuring stakeholders understand constraints.
Fostering psychological safety so teammates surface concerns early.
Anticipating future needs; keeping options open for future change.
Honesty and transparency in communicating limitations or unknowns.

Connections

Aligns with soft-skill emphasis: empathy, collaboration, cultural awareness.
Supports literature on leadership, team coordination, and human factors in project success.
Critiques traditional curricula (ACM/IEEE) for insufficient real-world detail.

Questions

How to cultivate these 53 traits under tight deadlines?
Which traits matter most in startups vs large enterprises?
How to measure and reward decision-making soft skills in performance reviews?
How much does organisational context enable or limit development of these traits?

Personal reflections

Excellence extends beyond technical mastery; requires self-development, empathy, systems thinking, and collaboration.
Leaders must build psychologically safe environments to encourage healthy decision-making.
Curriculum reform should focus on practical, context-aware training.
Use findings to guide career development and performance evaluation discussions.

References

Meyer, A. N., Zimmermann, T., & Fritz, T. (2015). What Makes a Great Software Engineer? ICSE Proceedings. https://www.researchgate.net/…/What-Makes-a-Great-Software-Engineer.pdf

Design by Contract (DbC)

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Bertrand Meyer introduced Design by Contract (DbC) to formalise expectations between software components. Contracts specify obligations and benefits for clients and suppliers via preconditions, postconditions, and invariants, enabling safer, more maintainable systems.

Key points

Contracts: Define preconditions (caller responsibilities), postconditions (supplier guarantees), invariants (state consistency).
Runtime checks: Contracts can be enforced during development/testing to catch violations early.
Documentation: Contracts serve as precise specs and executable documentation.
Encapsulation: Components hide implementation details while exposing contractual behaviour.
Reuse & reliability: DbC encourages reusable components with clear expectations.

Connections

Basis for Eiffel language features; influences modern assertion frameworks.
Complements unit testing and TDD by clarifying expected behaviour.
Aligns with API design best practices and microservice contracts.

Questions

How to balance DbC runtime checks with performance constraints?
How to integrate DbC in languages without native support?
When should contracts be relaxed or extended as systems evolve?

Personal reflections

Contracts clarify team communication and reduce misunderstandings.
Useful for critical systems where correctness outweighs overhead.
Combining DbC with automated tests and CI improves confidence in deployments.

References

Meyer, B. (1992). Applying “Design by Contract”. Computer, 25(10), 40-51.
Official Eiffel documentation on DbC.

[[conways-law-birth-1968|Conway’s Law — origins, literature, and team design]]
[[design-patterns|Design Pattern]]
[[ddd|Domain-Driven Design: Tackling Complexity in the Heart of Software]]
[[no-silver-bullet-1986|No Silver Bullet — Essence & Accidents]]
[[parnas-modularization-1972|Modularization Criteria — Parnas 1972]]
[[shape-up-2020|Shape Up: Stop Running in Circles and Ship Work that Matters]]
[[software-aging-1994|Software Aging]]

Modularization Criteria — Parnas 1972

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

David L. Parnas (1972) proposed information hiding as the primary criterion for modular design, using the KWIC (Key Word In Context) system to compare traditional flow-based modularization vs encapsulating design decisions. His approach yields systems that are easier to modify, maintain, and evolve.

Key points

Traditional modularization (aligned with processing steps) leads to high coupling and brittle systems.
Information hiding: modules encapsulate design decisions (data structures, algorithms, storage formats).
KWIC case study: conventional design (5 modules aligned with processing sequence) vs information-hiding design (4 modules for storage, circular shift generation, sorting, output).
Benefits: localized changes, clear responsibilities, replaceable internals without breaking clients.
Trade-off: potential performance overhead due to inter-module communication; can be mitigated via inlining and efficient call mechanisms.

Connections

Precursor to object-oriented encapsulation and modern modular design.
Supports microservices and DDD bounded context thinking.
Relates to clean architecture and low coupling principles.
Anticipates interface contracts in modern API design.

Questions

How to apply information hiding in fast-paced agile projects?
Which metrics can quantify effective information hiding?
How to balance encapsulation with performance in real-time systems?
Applicability to distributed architectures?

Personal reflections

Encapsulating design decisions prevents leakage of implementation details across layers.
KWIC example illustrates how storage strategies can remain swappable with proper abstraction.
Critique of flow-based modularization still relevant for ETL/data pipeline architectures.
Stable interfaces support DevOps pipelines and isolate testing concerns.

References

Parnas, D. L. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12), 1053-1058.
Modern commentary: https://www.refact0r.dev/blog/module-criteria

[[conways-law-birth-1968|Conway’s Law — origins, literature, and team design]]
[[DbC|Design by Contract]]
[[no-silver-bullet-1986|No Silver Bullet — Essence & Accidents]]
[[software-aging-1994|Software Aging]]

No Silver Bullet — Essence & Accidents

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Frederick P. Brooks Jr. (1986) argues there’s no single “silver bullet” that will provide an order-of-magnitude productivity boost in software engineering. Distinguishes essential difficulties (intrinsic to software) from accidental difficulties (tooling, implementation). Technological advances continue to chip away at accidental issues, but inherent complexity remains.

Key points

Essence vs accidents
Essential: inherent complexity, changing requirements, invisibility, costly change.
Accidental: tooling limitations (manual compilation, lack of IDEs) that technology can mitigate.
Central thesis: innovations (OO, AI, higher-level languages) alone won’t deliver 10x productivity across the board.
Potential breakthroughs: rapid prototyping, incremental development, empowering great designers.
Critique of techno-optimism: automating accidental tasks doesn’t fix mis-specified requirements or poor communication.

Connections

Relates to discussions on technical debt (unmanaged accidental complexity).
Anticipates agile principles (short iterations, prototyping).
Aligns with critiques of low-code/no-code as silver bullets.
Connects to cognitive complexity in distributed systems.

Questions

Where do modern frameworks (React, Kubernetes) fall in essence vs accidents?
Does generative AI (Copilot) confirm or challenge Brooks’ predictions?
Has cloud computing reduced essential complexity or just moved it around?
Do DORA metrics (deployment frequency, etc.) mostly track accidental difficulties?

Personal reflections

Essential/accidental distinction explains why microservices fix operational issues but add systemic complexity.
Emphasising “great designers” foreshadows Site Reliability Engineering and other multiplier roles.
Invisibility still critical in distributed architectures; justifies heavy investment in observability.
Incremental evolution (“UNIX philosophy”) continues to beat grand revolutions.

Detailed notes

Essential difficulties: complexity, conformity, invisibility, cost of change.
Accidental wins: high-level languages, IDEs, CI/CD automation.
Suggested strategies: buy vs build, rapid prototyping, nurture expert designers.
Predictions validated: OOP aided encapsulation but didn’t eliminate logic bugs; open source helped with accidental costs, not conflicting requirements.
Quote: “Complexity is the soul of software; there is no silver bullet.”

References

Brooks, F. P. Jr. (1986). No Silver Bullet: Essence and Accidents of Software Engineering. (Link: http://www.cs.unc.edu/techreports/86-020.pdf)
Additional commentary and analyses (ACM DL, Wikipedia, etc.).

[[conways-law-birth-1968|Conway’s Law — origins, literature, and team design]]
[[DbC|Design by Contract]]
[[parnas-modularization-1972|Modularization Criteria — Parnas 1972]]
[[shape-up-2020|Shape Up: Stop Running in Circles and Ship Work that Matters]]
[[software-aging-1994|Software Aging]]

Software Aging

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

David L. Parnas likens software aging to biological aging: over time, software becomes harder to maintain, less efficient, and more failure-prone. Maturity in software engineering requires prioritizing long-term health over first releases. Preventive practices can slow aging but cannot eliminate it.

Key points

Software aging is inevitable but manageable through disciplined engineering.
Two main accelerants:
Inability to update software as business needs change.
Accumulation of ignorance due to team turnover and poor documentation.
Aging costs: lost competitiveness, increased defects, degraded performance, higher maintenance effort.
Preventive “medicine”: design for change, thorough documentation, frequent code reviews.
Critiques the focus on initial releases and lack of systematic engineering practices.
Documentation is essential despite agile tendencies to downplay it.
Suggests planning for software “retirement” as part of lifecycle management.

Connections

Links to discussions of technical debt and legacy systems.
Resonates with sustainability narratives and maintaining long-lived open source projects.
Contrasts with agile manifesto statements about documentation.
Aligns with DevOps practices emphasizing observability and continuous improvement.

Questions

How to objectively measure software aging across domains?
Which documentation practices balance agility with sustainable knowledge?
How to adapt recommendations for small teams or short-lived projects?
Differences in aging patterns between proprietary and open source software?

Personal reflections

Aging metaphor helps analyze system trajectories, especially with high team turnover.
Highlights challenges seen in both public and private IT projects lacking systematic processes.
“Retirement plan” concept is valuable for interviewing IT managers.
Reinforces importance of documentation and review in case studies.

Detailed notes

Aging compared to humans: inevitable but mitigable via prevention and care.
Focus should shift to system health over first release success.
Aging factors recorded from various talks (timestamps included in original note).
Emphasis on design for change, documentation, code reviews.
Recognize when software becomes unreliable; apply re-modularization and documentation retrofits.
Plan for end-of-support lifecycle as part of responsible engineering.

References

Parnas, D. L. (1994). Software Aging. Proceedings of ICSE 16.
Article PDF: http://www.inf.ed.ac.uk/teaching/courses/seoc/2004_2005/resources/bullet11.pdf
Talk: https://youtu.be/fe8Mp1YOjQI

[[conways-law-birth-1968|Conway’s Law — origins, literature, and team design]]
[[DbC|Design by Contract]]
[[no-silver-bullet-1986|No Silver Bullet — Essence & Accidents]]
[[parnas-modularization-1972|Modularization Criteria — Parnas 1972]]
[[shape-up-2020|Shape Up: Stop Running in Circles and Ship Work that Matters]]

TDD Effects on Quality and Productivity

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Systematic review of 27 empirical studies (1999–2014) on Test-Driven Development (TDD). Evaluates internal code quality, external product quality, and productivity. Findings: TDD generally improves cohesion and reduces coupling; external quality gains are observed in 88% of cases; productivity results vary, showing improvements in academic settings but a decrease in industrial environments.

Key points

Internal quality: Improves in 76% of evaluated cases, showing lower coupling, reduced cyclomatic complexity, and higher cohesion (often measured via CK Metrics).
External quality: Positive impact in 88% of the scenarios, with significant defect reduction in critical systems.
Productivity: Mixed outcomes. Academic environments reported speed gains, while industrial settings reported a productivity dip.
Moderators: Prior unit testing experience and continuous integration adoption amplify benefits.
Limitations: Selection bias, uncontrolled environmental variables, self-reported productivity metrics.

Connections

Aligns with Clean Code principles and CK metrics usage.
Supports discussions on technical debt in agile processes.
Contrasts with test-last approaches in rapid prototyping.
Relates to research on developer psychology and TDD adoption.

Questions

How to tailor TDD for volatile requirements?
What is the maintenance cost of large test suites over time?
Are metrics like branch coverage sufficient to gauge TDD effectiveness?
How does TDD coexist with generative AI in testing workflows?

Personal reflections

TDD excels for complex business logic; less so for simple CRUD modules.
CK metrics help quantify internal quality gains.
Variability explains why some companies abandon TDD after superficial adoption.
Integrating TDD with BDD could boost external quality.

Detailed notes

Methodology: PRISMA-based review of 27 empirical studies.
Variables: Internal quality (CBO, LCOM, WMC, RFC), external quality (defects, MTBF, user satisfaction), productivity (delivery speed, cognitive effort).
Results: 76% of cases showed increased internal quality (coupling reduction, ~20% cohesion increase, lower cyclomatic complexity); 88% showed increased external quality (defect reduction); proficiency reached after initial productivity dip, mostly observed in academic scenarios.
Limitations: Many studies lacked controls for prior testing expertise; productivity data often self-reported; publication bias toward positive outcomes.

Example in Go

package cpf

import "testing"

func TestCPFRejectsAllZero(t *testing.T) {
	if IsValid("00000000000") {
		t.Error("All-zero CPF should be invalid")
	}
}

func TestCPFValidKnownValue(t *testing.T) {
	if !IsValid("52998224725") {
		t.Error("Valid CPF was rejected")
	}
}

func IsValid(cpf string) bool {
	if len(cpf) != 11 {
		return false
	}
	for i := 1; i < len(cpf); i++ {
		if cpf[i] != cpf {
			return true // Simplified logic for example
		}
	}
	return false
}

References

Bissi, W., Seca Neto, A. G. S., & Emer, M. C. F. P. (2016). The effects of test driven development on internal quality, external quality and productivity: A systematic review. Information and Software Technology. https://www.sciencedirect.com/science/article/abs/pii/S0950584916300222
Additional supporting documents (ResearchGate, CK Metrics literature).

Gophers Workshop — Deploy-First Go Architecture
Design & Analysis of Algorithms — Course Overview
Assembly Study Plan
BDD
Code Smells and Maintainability
Enterprise UI Development — Testing, Standards, and Ego Control
Testing Concepts Notes

Teach Yourself Programming in Ten Years

Tue, 15 Apr 2025 00:00:00 +0000

Abstract

Peter Norvig critiques promises of learning programming in weeks. Drawing on research in chess, music, and sports, he argues true mastery requires about ten years of deliberate practice—progressive challenges, feedback, and continual improvement. There are no shortcuts: success comes from sustained effort and critical self-analysis.

Key points

Questions the abundance of “Learn X in 24 Hours/21 Days” books.
Excellence in any complex field typically demands ~10 years of deliberate practice (citing K. Anders Ericsson’s work).
Historical examples (Mozart, Beatles) show their peak came only after years of intense practice.
No magical formulas; commitment to long-term learning is essential.
Practical advice: explore multiple languages, seek challenges, learn from peers, blend theory with real projects.
Books alone are insufficient; hands-on experience is irreplaceable.

Connections

Ties to deliberate practice theory and Malcolm Gladwell’s “10,000 hours” popularisation.
Informs discussions on computing education and depth vs superficial knowledge.
Supports lifelong learning and career development perspectives in tech.

Questions

How to balance theory and deliberate practice?
Does the “ten-year” model apply uniformly across computing domains?
How to maintain motivation through multi-year learning journeys?
Which strategies accelerate progress without sacrificing depth?

Personal reflections

Reinforces patience and persistence when building programming expertise.
Relevant to today’s culture of immediacy—reminds us depth takes time.
Agrees that combining study, deliberate practice, and real projects yields steady growth.
Encourages valuing the learning process rather than chasing quick wins.

Detailed notes

Abundance of quick-learning resources doesn’t reflect real mastery requirements.
Deliberate practice: constant challenge, error analysis, improvement.
Role of mentors, community, and diverse language exposure.
Suggested languages: Python, Scheme, JavaScript, Alice, Squeak, Blockly (depending on learner profile).
“Ten years” is illustrative; the key is sustained, deliberate work.
Original essay: https://norvig.com/21-days.html

JavaScript Sets, Maps, and Hashing

Sun, 09 Feb 2025 00:00:00 +0000

TL;DR

Notes captured on 2025-02-09 during Deveficiente algorithms study.
Set = unique values with O(1) add/remove; Map = key-value store with O(1) lookups.
Hashing is reference-based for objects; custom equality needs manual hashing/serialization.
Useful for caching and deduplication; V8 resolves collisions with internal linked lists/trees.
C# exposes GetHashCode; in JS you must implement equivalent behaviour explicitly.

Sets

Store unique values; duplicates are ignored.
Backed by hash tables in engines like V8.
Typical operations (add, delete, has) run in O(1) on average.

const set = new Set();
set.add("value1");
set.add("value2");
console.log(set.has("value1")); // true
console.log(set.size); // 2

Maps

Store key-value pairs; keys can be any data type.
Also implemented with hashing for O(1) lookups.

const map = new Map();
const key = { id: 1 };
map.set(key, "object");
console.log(map.get(key)); // 'object'

Hashing behaviour

Objects/arrays are compared by reference. Two objects with identical structure are not equal unless they share the same reference.
For custom hash keys (similar to C# GetHashCode), stringify values or build hashing utilities.

function hashObject(obj) {
 return JSON.stringify(obj);
}
const cache = new Map();
const obj = { id: 1, name: "test" };
cache.set(hashObject(obj), "cached");

Cache patterns

const cache = new Map();

function getData(key) {
 if (cache.has(key)) {
 return cache.get(key);
 }
 const value = fetchFromSource(key);
 cache.set(key, value);
 return value;
}

Internal details (V8)

Hash collisions handled via linked lists or adaptive structures (e.g., small arrays, balanced trees).
Sparse arrays may convert to hash tables internally for memory efficiency.

Set vs Map recap

Set: unique values.
Map: key-value pairs, versatile for caching, memoization.

References

MDN: Set, Map.
V8 blog on hash tables and inline caching.

[[javascript-closures-and-curries|Closures and Curries]]
[[react-forwardRef|Forwarding Ref]]

ADR — Architecture Decision Records

Wed, 15 Jan 2025 00:00:00 +0000

ADRs (Architecture Decision Records) are essential documents in software engineering that capture important architectural choices and the context behind them. In an Obsidian vault, ADRs integrate naturally into project documentation.

Why use ADRs?

In long-running projects — such as framework migrations or service changes in Go or Java — decisions change constantly. Without recording why a tool was chosen over another, the team (or even yourself) may forget the reasoning months later, losing the context that justified the choice.

Agile Software Development

Wed, 15 Jan 2025 00:00:00 +0000

Agile is a set of values and principles for software development that emphasizes flexibility, collaboration, and iterative delivery. Rather than following a rigid plan, Agile teams adapt to changing requirements and deliver working software frequently.

What is Agile?

Agile is not a single methodology but rather a philosophy that encompasses various frameworks and practices. The core idea is to break down large projects into smaller, manageable pieces that can be delivered incrementally.

Behavior-Driven Development (BDD)

Wed, 15 Jan 2025 00:00:00 +0000

What Is BDD

BDD bridges the gap between business stakeholders and developers by expressing requirements as executable specifications. Instead of writing tests after the fact, you describe the expected behavior of the system in plain language, then automate those descriptions.

The core loop: Discovery (what should the system do?) → Formulation (write it in Gherkin) → Automation (implement step definitions).

BDD vs TDD

TDD focuses on unit-level correctness (“does this function return the right value?”). BDD focuses on system-level behavior (“does this feature work from the user’s perspective?”). In practice they complement each other — use TDD for internal logic, BDD for acceptance and integration tests.

Closures and Curries

Wed, 15 Jan 2025 00:00:00 +0000

Closures and currying are both important concepts in JavaScript, especially for functional programming.

Closure

A closure is a function that has access to its outer scope even after the outer function has returned. It “closes over” its outer scope, hence the name. Here’s an example:

function outerFunction(x) {
 return function innerFunction(y) {
 return x + y;
 };
}
const add5 = outerFunction(5);
console.log(add5(3)); // 8

In the above example, **innerFunction** has access to **x** even after **outerFunction** has returned. This allows us to keep state across multiple invocations of the inner function. We can use closures to store a function with a first parameter, you can see an example here:

Design Patterns

Wed, 15 Jan 2025 00:00:00 +0000

Presentation Intent

Prepare the presentation with a clear script of intentions.

Explain how to read the book and how, by recognizing similar patterns, you create connections between them and discover different perspectives on the same problem. In some cases, this leads to other ways—or better ways—to apply a different pattern.

Another pattern can sometimes feel very similar to the one you are reading. The point is to think beyond the current chapter and compare intent, structure, and trade-offs.

Domain-Driven Design: Tackling Complexity in the Heart of Software

Wed, 15 Jan 2025 00:00:00 +0000

Domain-Driven Design (DDD) is a software design approach that focuses on modeling complex systems based on the real-world domains or concepts they represent. The aim is to tackle complexity in the heart of software by aligning the development process with the business domain, using a common language, and creating models that capture the behavior and relationships of the system. DDD emphasizes the importance of designing software around the concepts and processes of the business domain, rather than just technical implementation. It encourages communication and collaboration between the development team and business stakeholders, and promotes the use of models as the primary driver for design decisions. The end result is a software solution that better reflects the needs and requirements of the business domain, and is more maintainable, scalable and adaptable over time.

Mapped Types and Generics

Wed, 15 Jan 2025 00:00:00 +0000

Mapped types and generics are two of TypeScript’s most powerful tools for writing reusable, type-safe utilities without duplicating type definitions.

A generic lets you write a function or type that works over any type while still preserving type information — think of it as a type-level parameter. A mapped type iterates over the keys of an existing type and transforms each one, letting you derive new types mechanically from existing shapes rather than rewriting them by hand.

Optimizing React with Memoization

Wed, 15 Jan 2025 00:00:00 +0000

Introduction

It’s important to understand the component lifecycle and when to re-render. Some tips to optimize React include:

Use useMemo or memo to memoize expensive calculations or component render.
Use useCallback to memoize callback functions.
Use React.PureComponent instead of React.Component for pure components.
Use shouldComponentUpdate lifecycle method to avoid unnecessary re-renders.
Avoid using the state for non-essential data that does not affect the render.
Avoid using too many inline functions and use memoized callback functions instead. It is important to note that the most important aspect of optimization is to understand the performance bottlenecks in your application and address them accordingly.

useMemo

This is a hook that is used to memoize a component’s expensive calculations. It helps to reduce the number of re-renders by only recalculating the value when one of its dependencies has changed. It takes two arguments, the first being a calculation function and the second being an array of dependencies. If the dependencies change, the calculation function will be re-executed, otherwise, the previously calculated value is returned, example:

Prototype

Wed, 15 Jan 2025 00:00:00 +0000

Every object in JavaScript has an internal link to another object called its prototype. When you access a property that doesn’t exist on an object, the engine walks up this chain — prototype by prototype — until it finds the property or reaches null. This is the prototype chain, and it is the mechanism behind all inheritance in JavaScript.

Understanding prototypes is essential because class syntax in ES6 is just syntactic sugar over this system. Under the hood, extends sets up the same prototype chain. Knowing the raw model helps debug unexpected property lookups, instanceof checks, and performance issues around deep prototype chains.

React ForwardRef

Wed, 15 Jan 2025 00:00:00 +0000

By default, React does not let a parent component access the DOM node of a child component. forwardRef breaks that boundary explicitly — the child opts in to exposing its DOM node (or instance) to whoever holds the ref.

The typical need is imperative control from a parent: focusing an input inside a design-system <Input> wrapper, scrolling a <List> to a specific row, or triggering animations on a child element. Without forwardRef, the parent would need to own the DOM directly, which defeats the purpose of encapsulation.

React.Suspense

Wed, 15 Jan 2025 00:00:00 +0000

React.Suspense is a boundary component that lets you declaratively specify a fallback UI while its children are “suspended” — waiting for code to load or, in frameworks like Next.js/Remix, for async data to resolve. It decouples the loading concern from the component that needs the data, keeping each piece focused on its own responsibility.

Why use Suspense

Suspense lets you declaratively handle loading states for code-splitting and async data (with frameworks that support it). It improves first-load performance and keeps your UI logic focused on states that matter.

Recursion

Wed, 15 Jan 2025 00:00:00 +0000

let countDownFrom = (num) => {
 if (num === 0) return;
 console.log(num);
 countDownFrom(num - 1);
};

countDownFrom(10);

// Should output
// 10
// 9
// 8
// ...

function call themselves - Screenshot from Fun Fun Function

let categories = [
 { id: "animals", parent: null },
 { id: "mammals", parent: "animals" },
 { id: "cats", parent: "mammals" },
 { id: "dogs", parent: "mammals" },
 { id: "chihuahua", parent: "dogs" },
 { id: "labrador", parent: "dogs" },
 { id: "persian", parent: "cats" },
 { id: "siamese", parent: "cats" },
];

let makeTree = (categories, parent) => {
 let node = {};
 categories
 .filter((c) => c.parent === parent)
 .forEach((c) => (node[c.id] = makeTree(categories, c.id)));
 return node;
};

console.log(JSON.stringify(makeTree(categories, null), null, 2));

makeTree(categories, null) - Screenshot from Fun Fun Function

Recursion is a technique in programming where a function calls itself repeatedly until a specific condition is met. This allows solving complex problems by breaking them down into smaller, easier to solve sub-problems.

Shape Up: Stop Running in Circles and Ship Work that Matters

Wed, 15 Jan 2025 00:00:00 +0000

Summary

In December 2020 I read several books and papers: The Mythical Man-Month, Design by Contract, Programming with Abstract Data Types, Shape Up, and Domain-Driven Design. Their ideas map directly to problems and solutions I encountered building apps in recent years. The largest recurring gap in real projects is the beginning—how we shape and refine the work—more than the middle or the end. Shape Up gives a concrete way to close that gap in modern teams.

SVG Are the Best

Wed, 15 Jan 2025 00:00:00 +0000

SVG and icon fonts can solve similar problems, especially for icons. However, icon fonts must be downloaded correctly and mapped to the expected glyphs. When that fails, users may see empty squares or broken characters. SVG does not have that problem because the graphic itself is rendered directly.

SVG vs. Font Icons

Both approaches can be used for icons, but SVG is usually the better choice.

Why SVG is better

It does not depend on a font being loaded correctly
It can be styled and animated with CSS
It scales well across screen sizes
It works well for diagrams, illustrations, and UI icons
It supports filters and visual effects
It is accessible when used correctly
It exists as structured markup in the DOM
It is code, so it can be versioned, reviewed, and edited easily

SVG Benefits

1. Interactive and stylable with CSS

SVG elements can be targeted directly with CSS. You can change properties such as fill, stroke, opacity, transform, and more.

TensorFlow

Wed, 15 Jan 2025 00:00:00 +0000

Imagine you work at an online clothing store. Every day, thousands of product photos arrive and someone needs to tag each one: is it a t-shirt? A sneaker? A bag? Doing this by hand is painfully slow, so you decide to teach a computer to do it for you. That’s exactly the kind of problem Fashion MNIST was designed to solve — and it’s a perfect first project to understand how neural networks learn to see.

This Object Inside Call, Apply and Bind

Wed, 15 Jan 2025 00:00:00 +0000

JavaScript has four rules that determine what this refers to inside a function: implicit binding, explicit binding (.call, .apply, .bind), new binding, and window binding. Understanding these rules is essential because this behaves differently depending on how and where a function is called — not where it is defined.

At AutoLot, the car dealership platform, the team kept running into bugs where this was undefined or pointed to window instead of the expected object. Once they mapped each scenario to one of the four binding rules, those bugs disappeared.

Typescript Overwrite Types

Wed, 15 Jan 2025 00:00:00 +0000

Summary

This is a simple example of how to overwrite types from a library. When you do not want to use Pick or Omit, this strategy can be a good option.

Example

declare module "@maas-components/button" {
 export interface ButtonProps {
 /**
 * The content of the button.
 */
 children?: React.ReactNode;

 /**
 * The color of the component. It supports those theme colors
 * that make sense for this component.
 */
 color?: "inherit" | "primary" | "secondary" | "danger" | "success";

 /**
 * If `true`, the button will be disabled.
 */
 disabled?: boolean;

 /**
 * If `true`, no elevation is used.
 */
 disableElevation?: boolean;

 /**
 * If `true`, the keyboard focus ripple will be disabled.
 */
 disableFocusRipple?: boolean;

 /**
 * Element placed after the children.
 */
 endIcon?: React.ReactNode;

 /**
 * If `true`, the button will take up the full width of its container.
 */
 fullWidth?: boolean;

 /**
 * The URL to link to when the button is clicked.
 * If defined, an `a` element will be used as the root node.
 */
 href?: string;

 /**
 * The size of the button.
 * `small` is equivalent to the dense button styling.
 */
 size?: "small" | "medium" | "large";

 /**
 * Element placed before the children.
 */
 startIcon?: React.ReactNode;

 /**
 * The variant to use.
 */
 variant?: "text" | "outlined" | "contained";

 /**
 * Can be set to circle, square, or omitted.
 */
 shape?: "circle" | "square";

 /**
 * The styles in className.
 */
 className?: string;

 type?: "submit";
 onClick?: React.MouseEventHandler<HTMLButtonElement>;
 }

 // eslint-disable-next-line react/prefer-stateless-function
 declare const Button: React.FC<ButtonProps>;

 export default Button;
}

[[typescript-mapped-types-and-generics|Mapped Types and Generics]]

useRef

Wed, 15 Jan 2025 00:00:00 +0000

useRef gives you a mutable container — { current: value } — that persists for the full lifetime of the component without triggering re-renders when changed. This makes it the right tool for two distinct jobs: holding a reference to a DOM node for imperative operations, and storing any mutable value that your component needs to remember across renders but that should not drive the UI.

The key mental model: useState is for values that should be shown; useRef is for values that should be remembered.

Master’s Article Summaries

Wed, 04 Sep 2024 00:00:00 +0000

TL;DR

Replay attacks remain the easiest ASV spoofing vector; DL-RAD, autoencoders + Siamese networks, and CQCC features significantly improve detection.
ASVspoof 2021 pushes detection into real-world, noisy settings requiring domain generalisation.
Remote sensing (NEON/NIST) mirrors the need for multi-source data fusion—hyperspectral, LiDAR, RGB—for ecological insights.

SPIED articles

Ren et al. — Replay attack detection via loudspeaker distortion (DL-RAD).
ASVspoof 2021 — Spoofed/deepfake speech detection in the wild.
NIST DSE — Plant identification with airborne remote sensing.
Adiban et al. — Autoencoder + Siamese countermeasures on ASVspoof 2019.

Context

Consolidated notes from 4 September 2024 research sprint.
Focus: voice authentication security (spoofing/deepfake) and ecological remote sensing.
Supporting docs: ZIP archive with slides/text; online share for extended summaries.

1. Replay Attack Detection Based on Distortion by Loudspeaker

Source: Ren et al., Multimedia Tools and Applications, 2019. DOI: 10.1007/s11042-018-6834-3.
TL;DR: DL-RAD detects replay attacks by analysing loudspeaker-induced distortions (low-frequency attenuation, harmonic energy).
Highlights: Harmonic Energy Ratio, Low Spectral Variance. Achieves >98% detection accuracy.
Application: voice authentication systems (mobile, banking). Focus on dependable feature extraction.
Reflection: Consider how speaker hardware signatures can serve as anti-spoof signals.

2. ASVspoof 2021: Deepfake Speech Detection in the Wild

Source: ASVspoof 2021 challenge; TASLP 2023 paper (DOI: 10.1109/TASLP.2023.3285283).
TL;DR: Evaluates spoofed/deepfake detection in noisy, uncontrolled environments; introduces large-scale dataset.
Highlights: Variance across capture devices, environmental noise; combination of spectrogram analysis and deep models.
Application: deploy robust detectors for real-world ASV systems, banking, call centers.
Reflection: emphasises the need for adaptive models and domain generalization.

3. NIST DSE Plant Identification with Remote Sensing

Source: NIST publication on airborne remote sensing data challenge.
TL;DR: Integrates hyperspectral, LiDAR, RGB data to segment tree crowns, align field data, classify species.
Highlights: data fusion, scaling ecological monitoring, addressing heterogeneous resolutions.
Application: environmental monitoring, conservation, precision agriculture.
Reflection: parallels with multi-modal data integration in other domains (e.g., security sensors).

4. Replay Spoofing Countermeasure Using Autoencoder & Siamese Networks (ASVspoof 2019)

Source: Adiban et al., Computer Speech & Language, 2020. DOI: 10.1016/j.csl.2020.101105.
TL;DR: Combines autoencoders (denoising) with Siamese networks (similarity) to detect replay attacks.
Highlights: CQCC features, improved EER by 10.73%, t-DCF drop of 0.2344.
Application: mobile authentication, payment systems, secure access.
Reflection: underscores the power of hybrid feature + metric-learning approaches.

Supporting Docs

Comparative notes across TXT/PPTX/Google Docs for detailed methodology.
Extended definitions (CQCC, EER, t-DCF) stored in local dictionary.
Presentations (March 25) outline challenge evolutions and future work.

Next steps

Investigate combined defenses against multi-modal spoofing (synthetic + replay).
Explore edge deployment viability for real-time detection.
Compare ecological data pipelines with security workflows for cross-domain insights.

Testing Concepts Notes

Fri, 15 Jan 2021 00:00:00 +0000

BDD

BDD (Behavior Driven Development) is a method of testing where you use “Given” for the scenario, “When” for the environment of the action, and “Then” for the action.

Imagine AutoLot, a car dealership chain building an online vehicle marketplace. A product manager, a developer, and a QA engineer sit together and write this scenario in plain English:

Given a customer browsing the SUV category
When the customer clicks "Schedule Test Drive" on a 2024 Honda CR-V
Then the test drive request should appear as "pending" in the customer's dashboard

This is BDD in practice — the three roles agree on the expected behavior before any code is written. The npm package jest-cucumber lets you map these Gherkin-style scenarios directly to Jest tests.

Testing Library vs Enzyme

Fri, 15 Jan 2021 00:00:00 +0000

Introduction

Testing Library is built around a simple philosophy: the more your tests resemble the way your software is used, the more confidence they can give you. Its three core principles are: tests only break when your app breaks (not when implementation details change), you interact with your app the same way as your users, and built-in selectors find elements the way users do to help you write inclusive code.

Mon, 01 Jan 0001 00:00:00 +0000

Osmar Petry

Senior Software Engineer

Summary

Luxembourgish-Brazilian Senior Software Engineer with 10+ years building and scaling web and mobile products across EU and US distributed teams. Full-stack delivery across TypeScript and Python: product interfaces in React, Vue and Next.js, backend services with Node.js, FastAPI and Temporal, and the testing, CI/CD and observability practices that keep them reliable in production.

Core Skills

TypeScript, JavaScript, Python, React, Next.js, Vue, Nuxt, Node.js, FastAPI, Pydantic, Temporal, REST APIs, PostgreSQL, Supabase, GraphQL, RAG, Pinecone, Observability, Distributed Tracing, Unit Testing, Jest, Testing Library, Cypress, Playwright, CI/CD, Development and Build Tools, Redux, Storybook, React Native, AWS, GCP, Firebase, Drizzle ORM, Micro Frontends, HTML, CSS, Java

breadcrumb

Mon, 01 Jan 0001 00:00:00 +0000

company-logos

Mon, 01 Jan 0001 00:00:00 +0000

The whole strip, as it appears on the home page.

hero

Mon, 01 Jan 0001 00:00:00 +0000

navbar

Mon, 01 Jan 0001 00:00:00 +0000

Takes no arguments; the links come from [[menus.main]] in hugo.toml.

post-card

Mon, 01 Jan 0001 00:00:00 +0000

post-row

Mon, 01 Jan 0001 00:00:00 +0000

posts-filter

Mon, 01 Jan 0001 00:00:00 +0000

Each chip is a link to a tag page, so the filter needs no JavaScript.

project-card

Mon, 01 Jan 0001 00:00:00 +0000

project-row

Mon, 01 Jan 0001 00:00:00 +0000

Projects.

Mon, 01 Jan 0001 00:00:00 +0000

Selected builds, experiments, and technical assessments across product, frontend, backend, and AI work.

prose

Mon, 01 Jan 0001 00:00:00 +0000

Obsidian wikilinks resolve here. A missing target renders as a marker instead of a dead link.

section-heading

Mon, 01 Jan 0001 00:00:00 +0000

slide-card

Mon, 01 Jan 0001 00:00:00 +0000

slide-row

Mon, 01 Jan 0001 00:00:00 +0000

Slides.

Mon, 01 Jan 0001 00:00:00 +0000

Presentation decks from talks, workshops, and university seminars I have given.

tier-section

Mon, 01 Jan 0001 00:00:00 +0000

Composes project cards, the text-only list and the CTA. Used by the home preview and the projects page.

Osmar Petry

JavaScript Modules and Bundlers

Part 1 — Module Systems

IIFE (Immediately Invoked Function Expression)

PixieShop Authentication Playbook — OIDC SSO Across Four Identity Providers

Backend Architectures — history, case studies & dogfooding

Summary

Case studies (what they did → why it mattered)

Decision heuristics (when to pick what)

Dogfooding → productization loop

Web Accessibility V3 — Topics cheat-sheet & decision guide

Summary

Topics → what to do (at a glance)

Decision heuristics

Team workflow

Dev checklist

References

Related Notes

XState — model UI behavior correctly and make it testable

The problem we’re solving

Domain-Driven, Data-Oriented Design (DDDOD)

Overview

Why not pure DDD?

Core pillars

Implementation tips

References

Related Notes

Gophers 2025 — Event Report

Introduction

Go Serialization Options

Summary

1. MarshalText / UnmarshalText

2. MarshalJSON / UnmarshalJSON

Package Oriented Design

Summary

Definition

Guiding philosophy

Benefits

Package responsibilities

Layering cheat-sheet

kit

Conway’s Law — origins, literature, and team design

Reference stack

Essence of the law

Historical context & popularization

Key takeaways from the literature review

Review questions

Practical implications

Next actions

Related Notes

Decision-Making Traits of Great Software Engineers

Abstract

Key points

Connections

Questions

Personal reflections

References

Design by Contract (DbC)

Abstract

Key points

Connections

Questions

Personal reflections

References

Related Notes

Modularization Criteria — Parnas 1972

Abstract

Key points

Connections

Questions

Personal reflections

References

Related Notes

No Silver Bullet — Essence & Accidents

Abstract

Key points

Connections

Questions

Personal reflections

Detailed notes

1. `MarshalText` / `UnmarshalText`

2. `MarshalJSON` / `UnmarshalJSON`

`kit`