Mustafa's zettelkasten 📔
Search
Search
Search
Dark mode
Light mode
Explorer
a.technical
references
GoLang - useful resources
setting up neovim
100% is the wrong reliability target
abstraction
ACID
Acing System Design Interviews
active record pattern
adapter design pattern
amdahl's law
analyzing business domains
article - complexity in software design
availability and reliability
behavioural design patterns
benefits of code consistency
benefits of general-purpose modules
Benefits of Ports & Adapters Pattern
benefits of well-written code comments
benefits of well-written comments
better together or better apart
blog - Transactional Outbox Pattern
bounded context ownership boundaries
bounded context physical boundaries
bounded context vs subdomains
bounded contexts context map
bounded contexts in real life
builder design pattern
building boundaries with bounded context
business problem discovery
CAP Theorem
capture more design information with code comments
causes of complexity
chain of responsibility design pattern
change amplification
choosing names
classitis
code comments might be worthless
code reading
code repetition
cognitive load
command design pattern
comments get out of date
common distributed system patterns
Communication and Coordination
communication for software projects
comparing subdomains
comparing subdomains competitive advantage
comparing subdomains complexity
comparing subdomains solution strategy
comparing subdomains volatility
complexity
complexity in software design
complexity is incremental
conjoined methods
consistency
consistency in databases
contention in distributed systems
converting business domain to a model
core subdomain
corrupting data by distributed transaction
corrupting data by implicit distributed transaction
corrupting data by lack of transactional behaviour
costs of hexagonal architecture pattern
creational design patterns
Customer Reliability Engineering
database dirty reads
database durability
database durability techniques
database engineering
database internals
database isolation levels
database lost updates
database non-repeatable reads
database phantom reads
database read phenomenas
database transaction
DDD - bounded context
DDD - domain abstraction
DDD - domain activities
DDD - domain objects
DDD - hexagonal architecture
decorator design pattern
deep modules
dependancy inversion
dependencies
design it twice
design patterns
designing reactive distributed systems
developer excuses not to write code
DevOps Vs SRE
different layer different abstraction
discovering domain knowledge
dispatcher
distributed systems
distributed systems - async communication
distributed systems - Back Pressure Pattern
distributed systems - communication styles
distributed systems - CQRS
Distributed Systems - Design Patterns for Event-Driven Architecture
distributed systems - Event Carried State Transfer
distributed systems - event sourcing
distributed systems - outbox pattern
distributed systems - saga pattern
Docker Basics
Docker Security
domain driven design
Domain Driven Design a Practical Guide
domain knowledge discovery
dual write problem
effective modeling
encapsulation
error budget
event-based communication
eventual consistency
examples of code consistency
exceptions reasons
facade design pattern
factory design pattern
fighting against complexity
file storage vs object storage
functional programming
general purpose module
general purpose module 1
general purpose modules vs special purpose modules
general-purpose and special-purpose code separation
generic subdomain
Go Lang
Go Lang - doc.go
Go Lang - Functional Option Pattern
Go lang - Modules
Go Lang - Rules of A Go Package
Go Lang - Variadic Functions
GoLang - constants
GoLang - Idiomatic Naming Conventions
GoLang - primitive types
gunther's universal law
Hexagonal Architecture & CQRS
Hexagonal Architecture Actor
Hexagonal Architecture Adapter
Hexagonal Architecture and DDD anti-corruption layer
Hexagonal Architecture Application, Core or System
Hexagonal Architecture Elements
Hexagonal Architecture Explained
hexagonal architecture glossary
Hexagonal Architecture Interactor
Hexagonal Architecture Interface
Hexagonal Architecture Port
Hexagonal Architecture vs Clean Architecture
higher-level comments
higher-order functions
homelab - grafana dashboards to collect personal metrics
homeLab - index
homelab - install k3s on ubuntu
homelab - running private docker registry
horizontal scaling
How Hexagonal Architecture is Related to DDD
how information hiding reduces complexity
how module abstraction can go wrong
how much to invest in strategic programming
how much to invest in strategic programming?
how SLOs help balance operational and project work
how SLOs help build features faster
how SLOs help businesses make decisions
how to avoid database phantom reads
how to ensure code consistency
how to prevent information leakage
how to set SLOs for SLIs
how to write better code comments
how to write better comments - don't repeat the code
how to write better comments - pick conventions
how transaction script pattern can lead to data corruption
i don't have time to write comments
implementation code comments
in-sync replica set
Index
information hiding
information hiding and information leakage
information leakage
information leakage types
inheritance
interface comments
interface segregation
iterator design pattern
kafka
kafka common terms
kafka consumer group
kafka high water mark
kafka in-sync replicas
kafka topic partitions
kafka use cases
kafka workflow as a pub-sub
kafka workflow as a queue
keep the code comments near the code
key characteristics of distributed systems
Kubernetes
Kubernetes - pods - arguments and commands
Kubernetes - configMaps
Kubernetes - env variables
Kubernetes - Master vs Worker Nodes
Kubernetes - Node Selectors
Kubernetes - replication controller and replicaSets
Kubernetes - Resource Requirements
Kubernetes - secrets
Kubernetes - security contexts
Kubernetes - Service Accounts
Kubernetes - Taints and Tolerations
Kubernetes Architecture
Kubernetes Cluster
Kubernetes Commands
Kubernetes Components
Kubernetes Configuration
Kubernetes deployments
Kubernetes Namespaces
Kubernetes Node
Kubernetes Pod
Kubernetes scheduler
Kubernetes YAML Definition Files
laws of scalability
lddd - analyzing business domains
lddd - bounded context ownership boundaries
lddd - bounded context physical boundaries
lddd - bounded context shared kernel
lddd - bounded context vs subdomains
lddd - bounded contexts context map
lddd - bounded contexts in real life
lddd - building boundaries with bounded context
lddd - business problem discovery
lddd - communication
lddd - comparing subdomains
lddd - converting business domain to a model
lddd - discovering domain knowledge
lddd - effective modeling
lddd - Identifying Subdomain Boundaries
lddd - implementing simple business logic
lddd - inconsistent models
lddd - integrating bounded context with cooperation pattern
lddd - integrating bounded context with customer-supplier pattern
lddd - integrating bounded context with separate-ways or duplication
lddd - integrating bounded contexts
lddd - integrating bounded contexts with anticorruption layer
lddd - integrating bounded contexts with conformist pattern
lddd - integrating bounded contexts with open-host service
lddd - integrating bounded contexts with partnership
lddd - knowledge discovery
lddd - managing domain complexity
lddd - model boundaries
lddd - modeling the business domain
lddd - scope of a bounded context
lddd - semantic domains
lddd - size of a bounded context
lddd - subdomains as coherent use cases
lddd - tackling complex business logic
lddd - ubiquitous language refined
lddd - what is a bounded context?
lddd - what is a model
lddd - who are the domain experts
Learning Domain Driven Design
linear scalability
liskove substation
low-level comments
managing domain complexity
message queueing
Microservice Patterns
mindmap - A Philosophy Of Software Design - POSD
mindmap - learning domain driven design
model boundaries
modifying existing code
modular design
module abstraction
module depth
module division and complexity
module implementation
module interface
modules should be deep
my technical toolbox
names should be consistent
names should be precise
object oriented design
Object-oriented programming
obscurity
observability
observer design pattern
open-closed
Outbox Pattern vs Two-Phase Commit
partition tolerance
pass-through methods
pass-through variables
philosophy of software design
PHP
PHP - ArrayObject
PHP - attributes
PHP - class constant
PHP - readonly
platform engineering
Pod YAML Definition
polymorphism
POSD - modifying existing code
procedural programming
programming paradigms
prototype design pattern
publish-subscribe
pull complexity downwards
pure functions
questions to find the right balance between general and special purpose approach
reactive distributed systems
reactive principles
read committed isolation level
read uncommitted isolation level
repeatable read isolation level
Resiliency
running docker mysql localy
scalability
scalability vs performance
scope of a bounded context
separation of concerns
serializable isolation level
shallow modules
single responsibility
singleton design pattern
Site Reliability Engineering
size of a bounded context
SLAs
SLIs
SLOs
snapshot isolation level
software design red flags
SOLID
special purpose module
splitting and joining methods
state design pattern
strategic programming
strategic programming investment types
strategic vs tactical programming
strategy design pattern
strong consistency
structural design patterns
supporting subdomain
symptoms of complexity
tactical programming
tactical tornado
targeting reliability
template method design pattern
temporal decomposition
the effect of coherency delay
the happiness test
the kano model
the myth of good code is self-documented
the reactive manifesto
things that can make the code more obvious
things that make the code less obvious
Tmux
transaction script pattern
transactional outbox pattern
types of code comments
types of distributed systems architectures
types of subdomains
TypeScript
TypeScript - Enum
TypeScript - Numbers
TypeScript - Type Annotations and Type Inference
TypeScript - Types and Type System
ubiquitous language
unknown unknowns
use different git email based on repository path
using the ubiquitous language
vertical scaling
visitor design pattern
what is a bounded context
what is a domain
what is a messaging system
what is a subdomain
what is new in PHP 8.0
what is new in PHP 8.1
what is new in PHP 8.2
when is interface duplication okay
when is interface duplication okay?
when to bring modules together
Why Code Comments Is More Important Than You Think
why conventions is important
why do you need a read-only database transaction
why do you need a read-only database transaction?
why exception adds complexity
why pass-through methods are bad
why reactive architecture
why to write code comments
write code comments first
write code comments for better abstraction
your code can be more obvious
zooKeeper
b.PKM
references
avoid cramming in writing
books are teachers
how to take smart notes
A System For Writing
avoid multitasking
become an expert writer by practicing
building a seconded brain
building notes bottom-up
compare PKB notes
fleeting notes
folgezettel
get laser-focused
good workflow properties
how to add new permanent notes
how to avoid confirmation bias when taking notes
how to take a fleeting note
how to take reference note
HTNS - let the work carry you forward
HTNS - nobody ever starts from scratch
HTSN - Everything You Need To Do
HTSN - Everything You Need To Know
HTSN - Steps To Successful Writing
HTSN - Writing a Paper step-by-step
HTSN - writing is the only thing that matters
improve thinking by making permanent notes
improve understanding with literature notes
index notes
knowledge building blocks
knowledge workers
literature notes
literature notes vs reference notes
Luhmann's ZettelKasten
make a career one note at a time
new fleeting note workflow
Niklas Luhmann
note taking mistakes
On Writing Well
PARA
permanent notes
PKM - Index
project notes
Rapid Logging
reduce the number of decisions
reference notes
reference notes vs fleeting notes
taking notes and quotes from content to your PKM
understand what you read
What is PKM
what makes a fleeting note a permanent one
Why Having a Knowledge Base Is Important
why there was no much interest in zettelkasten at the beginning
why to take notes
workflow simplicity is essential
Writing To Learn
zettelkasten
zettelkasten as a workflow
zettelkasten as an object
zettelkasten cross-reference links
zettelkasten is organized bottom-up
zettelkasten method explained
zettelkasten note categories
Home
❯
a.technical
❯
my technical toolbox
my technical toolbox
Feb 02, 2025
1 min read
tools
Index
PHP
TypeScript
Go Lang
kafka
Graph View
Backlinks
No backlinks found