commit 9f104f1063038c5a2ce952f47e87509f47df2d2c parent b209fad43feaf095c4e1aefa49a3ff362f3ac807 Author: ling0x <ling0x@users.noreply.github.com> Date: Mon, 8 Jun 2026 02:45:01 +0100 refactor: git command Diffstat:
27 files changed, 20 insertions(+), 340 deletions(-)
diff --git a/async_programming/index.md b/async_programming/index.md @@ -1,92 +0,0 @@ -# Async Programming - -Concurrent programming is the practice of performing multiple tasks during -overlapping periods of time. It’s not the same as parallelism; in concurrency, -different sequences of operations progress independently, though not necessarily -simultaneously. This concept is quite advanced in programming, as it often -involves managing [threads](/operating_systems/thread.md), locks, and -avoiding pitfalls like race conditions and -[deadlocks](https://tokio.rs/tokio/tutorial/shared-state#holding-a-mutexguard-across-an-await)—making -concurrent code challenging to implement correctly. By structuring programs as -independent processes that cooperate in a defined manner, developers can achieve -more flexible and efficient designs. While these designs aren’t always parallel, -the concurrency approach provides significant benefits in scalability and -responsiveness. - -### Question: Whats the difference between concurrency and parallelism? - -First, start to understand why we want to make a distinction between parallel -and concurrent in the first place! - -> The why has everything to do with resource utilization and efficiency. - -> Efficiency is the (often measurable) ability to avoid wasting materials, -> energy, effort, money, and time in doing something or in producing a desired -> result. - -> Parallelism is increasing the resources we use to solve a task. It has nothing -> to do with efficiency. - -> Concurrency has everything to do with efficiency and resource utilization. -> Concurrency can never make one single task go faster. It can only help us -> utilize our resources better and thereby finish a set of tasks faster. - -(Asynchronous Programming in Rust) - -### Question: Whats the difference between async programming and concurrent programming? - -[Async programming](/async_programming/async_futures.md) is a way to -implement concurrency without relying on OS threads, while concurrent -programming is the broader idea of making a program do multiple things at once -or appear to do so. In the Rust async book, concurrent programming includes -thread-based models, but async programming keeps concurrency inside the program -and uses an async runtime plus explicit yielding with await instead of -OS-managed thread scheduling. - -#### Core difference: - -The Rust async book says concurrent programming means a program does multiple -things at the same time, or at least appears to. It also notes that threads are -one form of concurrent programming, where each thread is written sequentially -and the operating system runs those threads concurrently. - -By contrast, async programming moves that coordination into your program rather -than the operating system. In Rust, an async runtime manages tasks, and tasks -give up control explicitly when they hit .await, which lets other tasks make -progress. - -#### A simple way to think about it is this: - -Concurrent programming asks, “How can multiple things make progress?” - -Async programming answers, “We’ll do that inside one runtime, using lightweight -tasks and await.” - -### Question: So does async programming avoid using threads? - -Not exactly. Async programming does not require one OS thread per task, but it -can still use threads underneath. In Rust, the async model lets many lightweight -tasks run without creating extra threads for each task, while the runtime may -still use a small number of threads behind the scenes to drive those tasks. -[rust-book](https://rust-book.cs.brown.edu/ch17-02-concurrency-with-async.html), -[rust-lang](https://rust-lang.github.io/async-book/01_getting_started/02_why_async.html) - -What async avoids What async mainly avoids is the “one task = one thread” model. -The Rust async material explains that you can run concurrent async work without -spawning extra operating-system threads for each small job, which is why async -can handle far more tasks with lower CPU and memory overhead. - -What may still use threads An async runtime often does use threads internally. -The Rust book notes that, in practice, an async runtime might rely on -operating-system threads under the hood even though your async code is written -in terms of tasks and await, not manually managed threads. - -#### Simple way to think about it A good shorthand is: - -- Threads are one way to get concurrency. - -- Async is another way to structure concurrency, usually with many tasks - multiplexed onto a small number of threads. - -So the precise answer is: async programming does not mean “no threads at all”; -it usually means “not one thread per unit of work.” diff --git a/commands/git.md b/commands/git.md @@ -0,0 +1,20 @@ +# Git + +Undo last 2 already pushed commits: + +``` +git revert HEAD HEAD~1 +``` + +(If the commits have already been pushed to a shared remote, use git revert +instead — it creates new "undo" commits rather than rewriting history, which +avoids causing problems for collaborators. ) + +And the push it back to repo: + +``` +git push origin <branch-name> --force-with-lease +``` + +(This rewrites remote history and can break things for anyone who has already +pulled those commits — avoid on shared branches.) diff --git a/commands/index.md b/commands/index.md @@ -1,2 +0,0 @@ -# Commands - diff --git a/compiler/index.md b/compiler/index.md @@ -1,36 +0,0 @@ -# Compiler - -# Compiler Internals - -This folder contains documentation about Rust compiler internals and low-level -programming concepts. - -## Topics - -### The Compiler - -- [The Compiler](compiler.md) - Overview of how a compiler works - -### Token Processing - -- [Compiler Tokens](compiler_tokens.md) - Understanding lexxing and parsing - stages - -### Low-Level Mechanics - -- [Lifetime.md](lifetime.md) - Variable lifetimes and borrowing rules -- [Non-Lexical Lifetimes](non_lexical_lifetimes.md) - NLL and borrow checker - improvements -- [VTable.md](vtable.md) - Virtual function tables and dynamic dispatch -- [Dynamic Libraries](dynamic_libraries.md) - Shared objects, runtime loading, - and FFI with C libraries - -### Macros & Procedural Macros - -- [define_dal_transactions! Macro](define_dal_transactions_macro.md) - Trait - generation for database access layer operations - -### Advanced Topics - -- [Dynamic Dispatch](dynamic_dispatch.md) - Runtime polymorphism and trait - objects diff --git a/engineering_practice/index.md b/engineering_practice/index.md @@ -1,2 +0,0 @@ -# Engineering Practice - diff --git a/food/index.md b/food/index.md @@ -1,2 +0,0 @@ -# Food & Nutrition - diff --git a/index.md b/index.md @@ -1,63 +0,0 @@ -# Ling's Notebook - -Personal study notes for software engineering topics with Rust and TypeScript. - -[](https://github.com/ling0x/notes/actions/workflows/deploy-pages.yaml) - -[Also backed up on codeberg](https://codeberg.org/ling0x/notes) - -## Software Engineering - -- [Compiler](compiler/) - -- [Async Programming](async_programming/) - -- [System Design](system_design/) - -- [Machine Learning](machine_learning/) - -- [Memory Safety](memory_safety/) - -- [Networking](networking/) - -- [Observability](observability/) - -- [Operating Systems](operating_systems/) - -- [Refactoring](refactoring/) - -- [System Administration](system_administration/) - -- [Test Driven Development](test_driven_development/) - -- [Web Development](web_development/) - -- [Engineering Practice](engineering_practice/) - -- [Useful Commands](commands/) - -## Broader Knowledge - -- [Linear Algebra](linear_algebra/) - -- [Quantum Mechanics](quantum_mechanics/) - -- [Personal Development](personal_development/) - -- [References](references/) - -- [Food Recipes](food/) - -## Coding Exercises - -- [Spinlock](exercises/spinlock/) - -- [Tokio Tutorial](exercises/tokio-tutorial/) - -- [Channels](exercises/channels/) - -- [My Vec](exercises/my_vec/) - -- [Actors](exercises/actors/) - -- [Design Patterns in Rust](exercises/design_patterns_in_rust/) diff --git a/linear_algebra/index.md b/linear_algebra/index.md @@ -1,5 +0,0 @@ -# Linear Algebra - -1. Vectors - - [Vectors](linear_algebra/vectors/vectors.md) - - [Dot Product](linear_algebra/vectors/dot_product.md) diff --git a/linear_algebra/vectors/index.md b/linear_algebra/vectors/index.md @@ -1,6 +0,0 @@ -# Vectors - -- Vectors -- Dot Product -- Cross Product -- Lines and Planes diff --git a/machine_learning/index.md b/machine_learning/index.md @@ -1,2 +0,0 @@ -# Machine Learning - diff --git a/memory_safety/index.md b/memory_safety/index.md @@ -1,14 +0,0 @@ -# Memory Safety - -Notes on Rust's memory safety model, covering ownership, borrowing, and -concurrency primitives. - -## Topics - -- **Ownership & Borrowing** — borrowing rules, non-lexical lifetimes, shared and - exclusive references, interior mutability -- **Smart Pointers** — `Box`, `Arc`, and the `Drop` trait -- **Concurrency** — `Mutex`, `RwLock`, atomics, spinlocks, `Send`/`Sync` traits, - and synchronization/concurrency primitives -- **Memory Model** — stack vs. heap, segfaults, iterator invalidation -- **Practical Patterns** — connection pooling, PostgreSQL connections diff --git a/networking/index.md b/networking/index.md @@ -1,2 +0,0 @@ -# Networking - diff --git a/observability/index.md b/observability/index.md @@ -1,2 +0,0 @@ -# Observability - diff --git a/operating_systems/index.md b/operating_systems/index.md @@ -1,20 +0,0 @@ -# Operating Systems - -## OS-level view - -A [mutex (mutual exclusion lock)](/memory_safety/mutex.md) is a synchronization -primitive that ensures only one thread at a time enters a critical section that -uses some shared data. - -If a thread tries to lock a mutex that is already locked, the OS (or runtime) -either makes it spin briefly or puts it to sleep and queues it until the mutex -is unlocked. - -The OS uses low-level tools (like Linux futex on an integer in memory) plus -atomics and memory fences to implement this reliably across cores. - -- [System Call(syscall)](/operating_systems/system_call.md) -- [User Space and Kernel Space](/operating_systems/user_space_and_kernel_space.md) -- [Thread](/operating_systems/thread.md) -- [PostgreSQL Connection](/operating_systems/postgres/postgresql_connection.md) -- [Connection Pool](/operating_systems/postgres/connection_pool.md) diff --git a/operating_systems/postgres/index.md b/operating_systems/postgres/index.md @@ -1,5 +0,0 @@ -# Postgres - -- [PostgreSQL Connection](/operating_systems/postgres/postgresql_connection.md) -- [Connection Pool](/operating_systems/postgres/connection_pool.md) -- [Postgres Binaries](/operating_systems/postgres/postgres_binaries.md) diff --git a/personal_development/index.md b/personal_development/index.md @@ -1,3 +0,0 @@ -# Personal Development - -Knowledge about Personal Development diff --git a/quantum_mechanics/index.md b/quantum_mechanics/index.md @@ -1,2 +0,0 @@ -# Quantum Mechanics - diff --git a/refactoring/index.md b/refactoring/index.md @@ -1,2 +0,0 @@ -# Refactoring - diff --git a/references/index.md b/references/index.md @@ -1,3 +0,0 @@ -# References - -Educational content diff --git a/system_administration/index.md b/system_administration/index.md @@ -1,2 +0,0 @@ -# System Administration - diff --git a/system_design/case_study/index.md b/system_design/case_study/index.md @@ -1,2 +0,0 @@ -# Case Studies - diff --git a/system_design/design_patterns/index.md b/system_design/design_patterns/index.md @@ -1,2 +0,0 @@ -# Design patterns - diff --git a/system_design/index.md b/system_design/index.md @@ -1,7 +0,0 @@ -# System Design - -- [PostgreSQL transactions and ACID](postgresql_transactions_acid.md) -- [Design patterns](design_patterns/) -- [Single server](single_server.md) -- [Server scaling](server_scaling.md) -- [Server authoritative design](server_authoritative_design.md) diff --git a/system_design/state_management/index.md b/system_design/state_management/index.md @@ -1,58 +0,0 @@ -# State Management - -## Vanilla TypeScript Core State Management Patterns - -The foundational approach is a typed observable store — a generic `Store<T>` -class that holds state, exposes `getState()`, and notifies subscribers via -`setState()`. TypeScript generics enforce that only valid keys/shapes can be -set. Three main patterns build on this: - -- [Observable Store](observer_pattern.md) - — a central class with `subscribe/setState`, good for simple-to-medium apps - -- [Action/Reducer](action_reducer_pattern.md) - — Redux-style discriminated union actions processed by a pure `reducer` - function; TypeScript's exhaustive checking ensures no action is missed - -- [Proxy-based reactivity](proxy_based_reactivity.md) - — intercepts property assignments to auto-trigger re-renders, mimicking - Vue/MobX without a library - -- [Path-based (DeepState)](path_based_state.md) - - Best for bested state trees - -- [Persistent State](persistent_state.md) - - Best for cross-session state - - Best practices: always define a state interface, use `Partial<T>` for updates, - prefer immutable spreads, and normalise collections as `{ byId, allIds }`. - -### Difference between observer, singleton channel and BroadcastChannel - -1. Observer — one object talking to its own watchers - -2. [Singleton Channel](singleton_channels.md) - — any part of your app talking to any other part, within the same tab - -3. [BroadcastChannel](broadcastchannel_api.md) - — any tab talking to any other tab in the same browser - -In practice, you'd often use all three together: a `BroadcastChannel` receives a -cross-tab message → publishes onto a singleton `Channel<T>` → individual -components subscribed via the Observer pattern react to the update. - -## TypeScript-Specific Best Practices - -- Always define a state interface — never use any for your state shape - -- Use `Partial<T>` for updates — so you only pass the fields you're changing - -- Prefer immutable updates — spread operators `({ ...state, ...updates })` - instead of mutating directly - -- Normalize entity collections — store arrays as - `{ byId: Record<id, T>, allIds: - id[] }` for O(1) lookups - -- Use `localStorage` with version migrations — persist state but include a - `_version` field so you can safely migrate old data diff --git a/test_driven_development/index.md b/test_driven_development/index.md @@ -1,2 +0,0 @@ -# Test Driven Development - diff --git a/web_development/index.md b/web_development/index.md @@ -1,2 +0,0 @@ -# Web Development - diff --git a/whiteboards/index.md b/whiteboards/index.md @@ -1,2 +0,0 @@ -# Whiteboards -