Invert: study failure, then avoid it

One of the philosophies I keep coming back to — preached relentlessly by Charlie Munger (Warren Buffett’s longtime partner at Berkshire Hathaway, who shares the same defensive instinct) — is deceptively simple:

Don’t ask “how do I succeed?” Ask “how do I fail?” — then don’t do that.

Instead of chasing the elusive recipe for success, you catalogue the failure patterns: the recurring ways things blow up. Then you build your life, your code, your decisions to steer clear of them. Munger calls this inversion — “all I want to know is where I’m going to die, so I’ll never go there.”

Munger borrowed the phrase “invert, always invert” from the 19th-century mathematician Carl Jacobi. It sounds like a cute reframing, but it’s a genuinely different way to think.

Why inversion works

• Failures are fewer and more legible than successes. There are a thousand ways to build a great company and only a handful of ways to reliably kill one (run out of cash, lose trust, over-leverage). The failure set is smaller and easier to memorize.
• Avoiding stupidity beats seeking brilliance. Buffett’s edge isn’t a string of genius bets — it’s decades of not doing the dumb thing when everyone else did. You don’t have to be clever if you’re consistently not foolish.
• It’s defensive, and defense compounds. Survive long enough and avoid the catastrophic mistakes, and time does the rest of the work for you.

How I apply it

Whenever I’m about to make a decision, I run the inversion:

1. List the failure modes. “What are all the ways this could go badly?”
2. Rank them by damage. Some failures are recoverable; some are terminal. Pay attention to the terminal ones first.
3. Engineer them out. Design the decision so the catastrophic paths are simply unavailable, not just unlikely.

In engineering this is second nature — it’s literally what a pre-mortem or a failure-mode analysis is. You imagine the system has already crashed and work backwards to the cause. The Buffett insight is that the same move works for careers, relationships, and money, not just distributed systems.

The one-line takeaway

You don’t need a map of every road to success. You need a map of the cliffs — and the discipline to not drive off them.

Next in the series: more borrowed wisdom, one mental model at a time.

• Like Python, it is dynamically typed — you don’t declare types, and a variable can hold a string now and a number later.
• Like Java, the syntax is C-style — curly braces for blocks, semicolons at the end of statements, for loops with the classic three-part header.

This post collects the handful of things worth knowing up front.

Primitive types

Unlike some languages, JavaScript doesn’t split numbers into int, float, double, etc. — there is just one number type that covers integers and floating-point alike. In total JavaScript has 7 primitive types:

A couple of things worth noting:

• number includes special values NaN (not-a-number) and Infinity.
• bigint is for integers larger than number can safely hold — note the n suffix.

You check a value’s type with the typeof operator. A few worth remembering:

typeof 42           // "number"
typeof "hello"      // "string"
typeof true         // "boolean"
typeof undefined    // "undefined"
typeof null         // "object"   <-- historical bug
typeof {}           // "object"
typeof []           // "object"
typeof function(){} // "function"

Two gotchas to note: typeof null returns "object" (a long-standing bug in the language), and arrays also report "object".

For arrays specifically, use Array.isArray(obj). Your instinct might be to reach for typeof, but there’s a gotcha — both arrays and plain objects report "object", so typeof can’t tell them apart:

typeof []   // "object"
typeof {}   // "object"

Array.isArray([])   // true
Array.isArray({})   // false

Math utilities

The built-in Math object has the usual helpers. Math.min and Math.max return the smallest/largest of their arguments, and Infinity is handy as a starting “very large” value (for example when finding a minimum):

Math.min(3, 1, 2);   // 1
Math.max(3, 1, 2);   // 3

let smallest = Infinity;
for (const x of [5, 2, 8]) {
    smallest = Math.min(smallest, x);
}
// smallest === 2

Always use ===, never ==

This is the single most important habit to build. The honest answer is that most modern JavaScript developers rarely use ==.

Historically, == was added to make JavaScript more forgiving in the early days of the web. It does type coercion before comparing, so it converts the operands to a common type first:

"5" == 5      // true
1 == true     // true
0 == false    // true

The idea was that developers wouldn’t have to manually convert types all the time. For example, a value coming from an HTML form is always a string:

let age = "25"; // from an HTML form

if (age == 25) {
    console.log("same");   // this prints
}

The problem is that these coercion rules are surprising and error-prone. === (strict equality) compares value and type with no coercion:

"5" === 5     // false
1 === true    // false
0 === false   // false

Rule of thumb: always use === and !==. Forget == exists.

Declaring variables: const and let

Prefer const for anything that won’t be reassigned (think final in Java), and let when you genuinely need to reassign. Avoid the old var.

const name = "Seroze";   // cannot be reassigned
let count = 0;           // can be reassigned
count = count + 1;

Watch out: if you assign to a variable without declaring it with let/const/var, JavaScript silently creates a global variable instead of erroring. This is a historical quirk and a real source of bugs.

I got bitten by this in a binary search — I used lo and hi without declaring them, so they leaked into the global scope and the code did all sorts of garbage:

function search(arr, target) {
    lo = 0;              // ❌ no let/const — becomes a global!
    hi = arr.length - 1;
    while (lo <= hi) {
        // ...
    }
}

The fix is just to declare them: let lo = 0, hi = arr.length - 1;. (Running in strict mode — "use strict"; — turns this silent footgun into an actual error, which is why modules and classes enable it by default.)

For loops

The classic C-style loop is exactly what you’d expect:

for (let i = 0; i < 10; i++) {
    console.log(i);
}

Arrays

Arrays are JavaScript’s lists. Use .length to get the number of elements:

const arr = [10, 20, 30];
console.log(arr.length);   // 3

for (let i = 0; i < arr.length; i++) {
    console.log(arr[i]);
}

A few array basics worth learning early: push() / pop() (add/remove at the end), shift() / unshift() (front), slice(), indexOf(), and the higher-order ones like map(), filter(), and forEach().

Creating an array of size n

Use the Array(n) constructor together with .fill() to get an array of a fixed size with a default value:

const zeros = new Array(5).fill(0);     // [0, 0, 0, 0, 0]
const ones  = new Array(3).fill(1);     // [1, 1, 1]

If you need each element computed from its index, use Array.from():

// [0, 1, 2, 3, 4]
const seq = Array.from({ length: 5 }, (_, i) => i);

// 2D array (3x3 grid of zeros) — note: build each row separately
const grid = Array.from({ length: 3 }, () => new Array(3).fill(0));

Heads up: don’t write new Array(3).fill(new Array(3).fill(0)) for a 2D grid — every row would be the same array reference, so changing one row changes all of them. Use Array.from as shown above.

Checking if an element is in an array

Use includes() — it returns a boolean and is the cleanest way to check membership:

const arr = [10, 20, 30];

arr.includes(20);   // true
arr.includes(99);   // false

If you also need the position of the element, use indexOf(). It returns the index, or -1 if the element isn’t present:

arr.indexOf(20);    // 1
arr.indexOf(99);    // -1

if (arr.indexOf(20) !== -1) {
    console.log("found it");
}

Note: indexOf() returns only the first matching index, even if the value appears multiple times in the array.

[5, 7, 5, 9].indexOf(5);   // 0, not 2 — only the first match

(If you need the last one, use lastIndexOf().)

Sorting: always pass a comparator

By default sort() converts elements to strings and sorts lexicographically. This produces nonsense for numbers:

const nums = [1, 2, 10, 5];

nums.sort();

console.log(nums);   // [1, 10, 2, 5]  ❌

10 comes before 2 because the string "10" is less than "2".

Always pass a custom comparator (a lambda) when sorting numbers. The comparator returns a negative number if a should come first, zero if equal, positive if b should come first.

const nums = [1, 2, 10, 5];

nums.sort((a, b) => a - b);   // ascending
console.log(nums);            // [1, 2, 5, 10]  ✅

nums.sort((a, b) => b - a);   // descending
console.log(nums);            // [10, 5, 2, 1]

Yes, the string-by-default behaviour is garbage — but this is how JavaScript works, so just build the habit of always passing a comparator.

Comparator vs key functions (vs Python)

There’s a subtle difference here if you’re coming from Python. JavaScript follows the Java convention — sort() takes a comparator (a, b) that answers “which of these two comes first?”. Python takes a key function that answers “what value should I sort this element by?”.

# Python — key style
arr.sort(key=lambda obj: obj.x)

// JavaScript — comparator style
arr.sort((a, b) => a.x - b.x);

A common mistake is to pass a Python-style key to JS: arr.sort(o => o.x). That silently breaks, because JS calls it as fn(a, b), not fn(a). To sort by a key fn, wrap it in a comparator: arr.sort((a, b) => fn(a) - fn(b)).

String utility methods

Strings come with a bunch of built-in helpers. Get familiar with them — you’ll reach for these constantly:

const s = "hello world";

s.charAt(0);       // "h"
s.slice(0, 5);     // "hello"
s.toUpperCase();   // "HELLO WORLD"
s.toLowerCase();   // "hello world"
s.indexOf("world") // 6
s.includes("lo")   // true
s.split(" ");      // ["hello", "world"]
s.trim();          // removes leading/trailing whitespace

Note that .length works on strings too (s.length is 11).

Strings in JavaScript are immutable — you can’t change a character in place. Assigning to an index simply does nothing:

let s = "hello";
s[0] = "H";
console.log(s);   // "hello" — unchanged

If you need to edit a string, convert it to a character array first, mutate the array, then join it back:

let s = "hello";
const chars = s.split("");   // ["h", "e", "l", "l", "o"]
chars[0] = "H";
s = chars.join("");          // "Hello"
console.log(s);              // "Hello"

The key trick is const chars = s.split("") — since strings are immutable, this is the standard way to get a mutable char array you can index into and edit. It comes up constantly in string problems, so keep it handy.

And to go back the other way, join the array into a string:

return chars.join("");   // convert char array back to a String

Sets

A Set stores unique values. Use add() to insert, has() to check membership, delete() to remove, and .size for the count:

const seen = new Set();
seen.add(1); seen.add(1); seen.add(2);
console.log(seen.has(1), seen.size);   // true 2

The ... spread / rest operator

... is one of the most useful pieces of modern JS syntax. It does two opposite-looking things depending on where it appears. (It’s roughly analogous to Python’s *args / *list unpacking.)

Spread — “unpack” into individual items

It expands an array (or any iterable) into its individual elements. This is exactly what fn(...args) does in the cancellable example above:

fn(...args);   // if args = [2, 3], this calls fn(2, 3)

Other common uses:

const a = [1, 2, 3];
const b = [...a, 4, 5];        // [1, 2, 3, 4, 5]  — copy + extend
Math.max(...a);                // 3                — array -> arguments

const o1 = { x: 1 };
const o2 = { ...o1, y: 2 };    // { x: 1, y: 2 }   — works on objects too

It’s also the idiomatic way to make a shallow copy: const copy = [...arr].

Note that spread is only a shallow copy — nested objects/arrays are still shared by reference. For a true deep copy, use the built-in structuredClone():

const original = { a: 1, nested: { b: 2 } };

const shallow = { ...original };
shallow.nested.b = 99;
console.log(original.nested.b);   // 99  — nested object was shared ❌

const deep = structuredClone(original);
deep.nested.b = 42;
console.log(original.nested.b);   // 99  — original untouched ✅

This is the JS equivalent of Python’s copy.deepcopy() (versus the shallow copy.copy()).

Rest — “collect” the leftovers into one array

In a function’s parameter list (or in destructuring), ... does the reverse — it gathers multiple values into a single array:

function sum(...nums) {         // nums is a real array
    return nums.reduce((acc, x) => acc + x, 0);
}
sum(1, 2, 3);                   // 6

const [first, ...others] = [10, 20, 30];
// first = 10, others = [20, 30]

Rule of thumb: ... in a call or literal spreads (unpacks); ... in a parameter list or destructuring target collects (rest).

Closures

A closure is a function that “remembers” the variables from the scope where it was created, even after that outer function has finished running. The inner variable stays alive as long as the returned function holds a reference to it.

function create() {
    let value = 5;

    return () => {
        value *= 2;
        console.log(value);
    };
}

const fn = create();

fn();   // 10
fn();   // 20
fn();   // 40

Even though create() has already returned, its value isn’t garbage-collected — the returned arrow function keeps it alive and mutates it across calls. This is the basis for things like counters, memoization, and private state.

Analogy in Python: the exact same thing works, but reassigning the captured variable needs the nonlocal keyword:

def create():
    value = 5
    def fn():
        nonlocal value
        value *= 2
        print(value)
    return fn

Analogy in Java: Java has closures via lambdas/anonymous classes, but the captured local variable must be effectively final — you cannot reassign it. To get mutable state like above you’d capture a field or a one-element array (int[] value = {5};).

Arrow functions and this

Arrow functions aren’t just shorter syntax for function — they differ in one crucial way: an arrow function does not have its own this. It captures this lexically, from the scope where it was defined. A regular function, by contrast, gets its this rebound depending on how it’s called.

This wrinkle is the source of a classic pre-ES6 workaround. Look at this code:

const person = {
    name: "Alice",

    greet() {
        const self = this;

        function fn() {
            console.log(self.name);
        }

        fn();
    }
};

person.greet();   // "Alice"

Why the self = this maneuver? Inside greet(), this correctly refers to person (because it was called as person.greet()). But fn is a plain function, not a method — so when it’s invoked as a bare fn(), JavaScript rebinds its this to undefined (in strict mode) or the global object (in sloppy mode). It is not person. So this.name inside fn would blow up or print undefined.

The old fix: capture the outer this into an ordinary variable (self, often called that or _this) while you still have the right value, then close over that variable from the inner function. Closures behave predictably; this doesn’t. So you sidestep this entirely.

Arrow functions make this trick obsolete. Because an arrow function inherits this from its surrounding scope, you can drop self completely:

const person = {
    name: "Alice",

    greet() {
        const fn = () => {
            console.log(this.name);   // `this` is still `person`
        };

        fn();
    }
};

person.greet();   // "Alice"

The arrow function doesn’t get its own this, so this inside it is the same this as in greet — which is person. No self, no bind, no surprises. This is exactly why you’ll see arrows used for callbacks (setTimeout, .map, event handlers, promises) — they keep this pointing at whatever the enclosing method’s this was.

One consequence of the same rule: never use an arrow function as a method when you need this to be the object. greet: () => this.name would capture this from the module/global scope, not person. Use the greet() { ... } shorthand (or a regular function) for methods, and arrows for the callbacks inside them.

Analogy in Python: Python never had this footgun because methods take an explicit self parameter — the binding is in the signature, not in how you call the function. A nested function in Python simply closes over self like any other variable:

class Person:
    def __init__(self):
        self.name = "Alice"

    def greet(self):
        def fn():
            print(self.name)   # plain closure over `self`
        fn()

The JavaScript const self = this line is essentially a manual re-creation of what Python gives you for free. This connects to [[blog-python-analogies]] — JS’s this is the implicit, call-site-dependent version of Python’s explicit self.

Generators

A generator is a function that can pause and resume, producing a sequence of values lazily — much like Python’s generators. You declare one with function* and emit values with yield. Calling the generator returns an iterator, and each .next() runs until the next yield.

Here’s an infinite Fibonacci generator:

function* fibonacci() {
    let [a, b] = [0, 1];
    while (true) {
        yield a;
        [a, b] = [b, a + b];
    }
}

const gen = fibonacci();
console.log(gen.next().value);   // 0
console.log(gen.next().value);   // 1
console.log(gen.next().value);   // 1
console.log(gen.next().value);   // 2
console.log(gen.next().value);   // 3

Because it’s lazy, an infinite generator is fine — you just take as many values as you need. For example, the first 10 Fibonacci numbers:

function firstN(gen, n) {
    const out = [];
    for (const x of gen) {
        out.push(x);
        if (out.length === n) break;
    }
    return out;
}

console.log(firstN(fibonacci(), 10));
// [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]

Objects

In JavaScript you don’t need an explicit class declaration to make an object. An object is just a bag of key-value pairs — essentially a hashmap with string (or symbol) keys. You write one with braces, and you can read, add, or delete keys at will:

const user = {
    name: "Alice",
    age: 30,
};

console.log(user.name);     // "Alice"  — dot access
console.log(user["age"]);   // 30        — bracket access, like a hashmap
user.email = "a@x.com";     // add a key on the fly
delete user.age;            // remove one

This is the same mental model as a Python dict — except the .key dot syntax is first-class, and the keys are unordered string properties rather than arbitrary hashable objects.

Functions are special objects. A function in JS is an object that happens to be callable — which means you can hang arbitrary properties off it, exactly like any other object:

function hello() {
    console.log("hello");
}

console.log(typeof hello);   // "function"

hello.myProperty = 42;
console.log(hello.myProperty);   // 42

That last bit is perfectly valid JavaScript. The function still runs as a function, but it also carries the myProperty field. This is why things like memoization caches or static-style counters are sometimes stashed directly on the function object.

Where do prototype and class fit? Because objects are just hashmaps, JavaScript originally had no real classes — shared behaviour was wired up through the prototype chain. You can think of a prototype as roughly the equivalent of an interface (or shared base) in Java: it’s the object that supplies the methods every instance inherits. Modern JavaScript adds the class keyword, which gives you familiar class syntax — but under the hood it’s still just prototypes and objects:

class Animal {
    constructor(name) {
        this.name = name;
    }
    speak() {
        console.log(`${this.name} makes a sound`);
    }
}

const a = new Animal("Rex");
a.speak();   // "Rex makes a sound"

Analogy in Python: a plain JS object maps cleanly onto a Python dict, and the class keyword onto a Python class. The difference is that Python keeps “dict” and “class instance” as distinct concepts, whereas in JavaScript a class instance is still an object/hashmap underneath — the line between data and type is much blurrier.

Extending built-ins with .prototype

In JavaScript you can add new methods to a built-in class (like Array) by attaching them to its prototype. Every array then has access to your method:

Array.prototype.second = function () {
    return this[1];
};

const arr = [10, 20, 30];
console.log(arr.second());   // 20

This is real monkey-patching — you’re modifying the built-in type itself.

Note: you cannot do this directly in Python. Python forbids patching built-in types like list (list.second = ... raises a TypeError). To get similar behaviour there you’d have to subclass list:

class MyList(list):
    def second(self):
        return self[1]

A word of caution: monkey-patching built-ins is powerful but considered risky — it affects every array in your program and can clash with future language features or other libraries. Use it sparingly.

setTimeout and clearTimeout

setTimeout(fn, t) schedules fn to run once after t milliseconds. It returns a timer id that you can pass to clearTimeout(id) to cancel the call before it fires.

A classic LeetCode problem (Cancellable Function) makes this concrete: schedule a function, but hand back a cancel() that stops it if called in time.

var cancellable = function (fn, args, t) {
    const timerId = setTimeout(() => { fn(...args); }, t);

    // calling this before `t` ms have passed cancels the scheduled fn
    return function () {
        clearTimeout(timerId);
    };
};

How it plays out: if the returned cancel() runs before t, clearTimeout removes the pending call and fn never executes. If t elapses first, fn runs and the later clearTimeout is a harmless no-op.

const fn = (x) => x * 5;
const args = [2], t = 20, cancelTimeMs = 50;

const cancel = cancellable(fn, args, t);   // fn fires at t = 20ms
setTimeout(cancel, cancelTimeMs);          // cancel at 50ms — too late, fn already ran
// fn(2) returns 10

Here cancelTimeMs (50) is greater than t (20), so fn fires first and the cancel does nothing. If cancelTimeMs were less than t, the call would be cancelled and fn would never run.

If the calling and execution flow is still confusing, here’s another way to frame it:

• You’re supposed to execute fn after a delay of t, and also return a cancel function.
• If cancel is called, it should stop the pending timeout for fn.
• So if cancel is called after fn has already executed, nothing happens. But if it’s called before, we clear the timeout so fn never runs at all.

The implementation recipe is simple: put a setTimeout (which will resolve into executing fn) just before returning the cancel function, and put a clearTimeout inside cancel.

setInterval and clearInterval

Where setTimeout fires once, setInterval(fn, t) calls fn repeatedly every t milliseconds. It also returns a timer id, which you cancel with clearInterval(id) to stop the repeats:

let count = 0;
const id = setInterval(() => {
    count++;
    console.log(count);
}, 1000);          // logs 1, 2, 3, ... every second

// later, to stop it:
clearInterval(id);

The event loop: microtasks vs macrotasks

JavaScript is single-threaded, and async callbacks are scheduled onto two different queues:

• Microtask queue — Promise callbacks (.then, await), queueMicrotask.
• Macrotask queue — setTimeout, setInterval, I/O events.

The event loop’s rule is simple but easy to get wrong:

1. Run all microtasks (draining the queue completely).
2. Run one macrotask.
3. Repeat.

Crucially, the entire microtask queue is emptied before the next macrotask runs — so a setTimeout(fn, 0) still waits behind every pending Promise callback. Consider:

console.log(1);

setTimeout(() => {
    console.log(2);
}, 0);

Promise.resolve()
    .then(() => { console.log(3); })
    .then(() => { console.log(4); });

console.log(5);

This prints 1, 5, 3, 4, 2:

• 1 and 5 are synchronous — they run first, top to bottom.
• 3 and 4 are microtasks (Promise callbacks) — they drain next, in order.
• 2 is a macrotask (setTimeout) — even with a 0ms delay, it runs last, after the microtask queue is empty.

(Python’s asyncio has a comparable distinction between ready callbacks and scheduled-later ones, though the exact ordering rules differ.)

valueOf() and toString() — custom conversion

JavaScript objects can control how they behave when converted to a number or a string. This is something I ran into while solving LeetCode.

• valueOf() is called when JavaScript needs a numeric value from an object (for example, with the + operator).
• toString() is called when it needs a string representation (for example, inside String(...)).

class Box {
    constructor(x) {
        this.x = x;
    }
    valueOf()  { return this.x; }
    toString() { return `Box(${this.x})`; }
}

const a = new Box(3);
const b = new Box(7);

console.log(a + b);        // 10   -> a.valueOf() + b.valueOf()
console.log(String(a));    // "Box(3)" -> a.toString()

The LeetCode Array Wrapper problem uses both at once:

var ArrayWrapper = function (nums) {
    this.nums = nums;
};

ArrayWrapper.prototype.valueOf = function () {
    return this.nums.reduce((sum, x) => sum + x, 0);
};

ArrayWrapper.prototype.toString = function () {
    return `[${this.nums.join(',')}]`;
};

const obj1 = new ArrayWrapper([1, 2]);
const obj2 = new ArrayWrapper([3, 4]);

obj1 + obj2;     // 10        -> obj1.valueOf() + obj2.valueOf()
String(obj1);    // "[1,2]"   -> obj1.toString()

This lets operators like + and functions like String() work naturally with your own classes — a feature without a direct equivalent in Python, Java, or Go.

Takeaways

• Dynamic typing like Python, C-style syntax like Java.
• Always use === (and !==); ignore ==.
• Use const by default, let when you must reassign.
• Learn the array basics and the common string methods — they cover most day-to-day work.
• Always pass a comparator to sort() for numbers — the default sorts as strings.
• Generators (function* / yield) give you lazy sequences.
• You can monkey-patch built-ins via .prototype, but do it sparingly.
• Custom classes can hook into + and String() via valueOf() and toString().
• ... spreads in calls/literals and collects (rest) in parameter lists.

The document skeleton

Every HTML page starts with the same boilerplate. It’s worth typing this out by hand a few times until it sticks:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>My Page</title>
  </head>
  <body>
    <h1>Hello, world</h1>
    <p>This is my first page.</p>
  </body>
</html>

A few things I had to remind myself of:

• <!DOCTYPE html> tells the browser to use standards mode. Without it you get “quirks mode” and old, inconsistent rendering.
• <head> holds metadata — things the user doesn’t see directly (title, charset, links to CSS).
• <body> is the visible content.
• lang="en" and charset="UTF-8" matter for accessibility and correct character rendering.

Semantic elements

Instead of wrapping everything in <div>, HTML5 gives you tags that describe meaning. This helps screen readers, SEO, and your own sanity:

<header>Site title and nav</header>
<nav>Links</nav>
<main>
  <article>
    <h2>A blog post</h2>
    <section>...</section>
  </article>
  <aside>Sidebar</aside>
</main>
<footer>Copyright</footer>

Rule of thumb I’m trying to follow: reach for a semantic tag first, and only fall back to <div> when nothing else fits.

Text basics

<h1>–<h6>   <!-- headings, in order of importance -->
<p>          <!-- paragraph -->
<strong>     <!-- important (bold) -->
<em>         <!-- emphasis (italic) -->
<br />       <!-- line break -->
<hr />       <!-- thematic break -->

One thing that bit me: headings should follow a logical order (h1 → h2 → h3), not be chosen for their size. Sizing is a CSS concern.

Links and images

<a href="https://example.com">A link</a>
<a href="/about">An internal link</a>

<img src="cat.jpg" alt="A sleepy cat" />

alt text isn’t optional in my book — it’s what screen readers announce and what shows when the image fails to load.

Lists

<ul>
  <li>Unordered item</li>
</ul>

<ol>
  <li>Ordered item</li>
</ol>

What’s next

Next I want to dig into forms (<input>, <label>, validation) and how HTML connects to CSS for layout. I’ll post those notes as I go.

The real situation that led me here

I was relearning HTML, and my files lived on my Linux box — that’s where I was editing test1.html and friends. But I was actually working from my macOS machine. I wanted to preview the pages in my Mac’s browser without copying files back and forth.

The fix was simple:

1. On the Linux box, in the directory holding the HTML files, I started a tiny web server:

   cd ~/html-practice          # the folder with test1.html
   python3 -m http.server 8000
   

2. On my Mac, I set up port forwarding so my Mac’s localhost:8000 points at the Linux box’s 8000:

   ssh -L 8000:localhost:8000 user@linux-host
   

3. Then in my Mac’s browser I typed:

   http://localhost:8000/test1.html
   

   …and the actual HTML page rendered. The browser is on my Mac, but the file and the server are on the Linux box, with everything flowing through the SSH tunnel. Very cool.

Gotcha I hit: python3 -m http.server only serves files in the directory it was launched from. If I started it in my home folder but test1.html lived in ~/html-practice/, the server couldn’t see it and I got a 404. Always cd into the folder with your files before starting http.server (or pass --directory).

The one-liner

ssh -L 8000:localhost:8000 youruser@linux-machine

After running this, opening http://localhost:8000 in my laptop’s browser actually reaches a service listening on port 8000 of the remote linux-machine. The traffic rides inside the encrypted SSH connection.

Reading the -L flag

-L means local port forwarding. The argument has three parts separated by colons:

-L  [local_port] : [target_host] : [target_port]
        8000      :   localhost   :    8000

• 8000 (first) — the port to open on my laptop (the SSH client side).
• localhost — the host to connect to, as seen from the remote machine. This is the key subtlety: localhost here is the remote box’s own loopback, not my laptop’s.
• 8000 (second) — the port on that target host.

So “take connections to localhost:8000 on my laptop, send them through the SSH tunnel, and on the far end connect to localhost:8000.”

Why localhost refers to the remote machine

This trips people up. The target_host:target_port part is resolved from the remote machine’s perspective, because that’s where the tunnel exits. You can forward to other hosts the remote can reach, too:

# Reach a database that only the remote machine can see
ssh -L 5432:db.internal:5432 youruser@linux-machine

Here db.internal is resolved by linux-machine, not by my laptop. This is how you tunnel to internal services behind a bastion host.

Local vs remote forwarding

There are two directions, and mixing them up is the classic mistake:

# -L: I want to reach the remote's port 8000 from my laptop
ssh -L 8000:localhost:8000 youruser@linux-machine

# -R: I want the remote to reach my laptop's port 3000
ssh -R 3000:localhost:3000 youruser@linux-machine

Handy extra flags

# -N : don't run a remote command, just hold the tunnel open
# -f : background the SSH process after connecting
ssh -N -f -L 8000:localhost:8000 youruser@linux-machine

-N -f is what I use when I just want the tunnel and don’t need an interactive shell.

# Bind the local end to all interfaces, not just loopback
# (lets other machines on my LAN use the tunnel too)
ssh -L 0.0.0.0:8000:localhost:8000 youruser@linux-machine

Tearing it down

If you backgrounded it with -f, find and kill it:

# Find the tunnel
ps aux | grep "ssh -N"

# or, if you forwarded a known port
lsof -i :8000
kill <pid>

For a foreground tunnel, just Ctrl-C (or type ~. to drop an SSH session).

Common gotchas

• “Connection refused” on the remote side usually means nothing is actually listening on the target port on the remote machine. SSH the box and check with ss -tlnp.
• Port already in use locally — pick a different local port: -L 8001:localhost:8000.
• Service binds to 0.0.0.0 vs 127.0.0.1 — if the remote service only listens on 127.0.0.1, forwarding to localhost works fine. That’s the common case.

A single ssh -L line is one of those tools that feels like magic the first time it clicks — encrypted, no extra software, and it works through anything that lets SSH out.

The core idea

Every backtracking problem can be modeled as a tree where:

• Each node is a partial state (decisions made so far).
• Each edge is a single choice extending that state.
• Leaves are either valid complete solutions or dead ends.

Backtracking = exhaustive search with early termination. You explore the tree depth-first, and whenever a partial state can’t lead to any valid solution, you prune the branch and backtrack to the parent.

The universal template:

void backtrack(State& state, Choices& available) {
    if (is_solution(state)) {
        record(state);
        return;
    }

    for (Choice c : available) {
        if (!is_valid(state, c)) continue;   // prune

        apply(state, c);                      // choose
        backtrack(state, available);          // explore
        undo(state, c);                       // unchoose
    }
}

The critical discipline: every apply must be mirrored by an undo. If you forget to undo, choices from one branch bleed into siblings.

Problem 1 — Subsets (power set)

Generate all subsets of [1, 2, 3, ..., n].

At each index i, make a binary choice: include a[i] or skip it.

vector<vector<int>> result;

void backtrack(vector<int>& a, int i, vector<int>& current) {
    result.push_back(current);           // every prefix is a valid subset

    for (int j = i; j < a.size(); j++) {
        current.push_back(a[j]);         // choose a[j]
        backtrack(a, j + 1, current);   // explore subsets starting after j
        current.pop_back();              // unchoose a[j]
    }
}

vector<vector<int>> subsets(vector<int>& a) {
    vector<int> current;
    backtrack(a, 0, current);
    return result;
}

The loop iterates j from i forward (not from 0) to avoid counting the same subset twice in different orderings. There are \(2^n\) subsets, so time is \(O(2^n \cdot n)\) (copying each subset takes \(O(n)\)).

Problem 2 — Permutations

Generate all permutations of n distinct integers.

The trick: swap element i into position start, recurse on [start+1, n), then swap back.

vector<vector<int>> result;

void backtrack(vector<int>& a, int start) {
    if (start == a.size()) {
        result.push_back(a);
        return;
    }

    for (int i = start; i < a.size(); i++) {
        swap(a[start], a[i]);            // place a[i] at position start
        backtrack(a, start + 1);
        swap(a[start], a[i]);            // restore
    }
}

vector<vector<int>> permutations(vector<int> a) {
    backtrack(a, 0);
    return result;
}

There are \(n!\) permutations, so time is \(O(n! \cdot n)\).

Permutations with duplicates: sort first, then skip if a[i] == a[start] and i != start (same value was already placed at this position).

void backtrack(vector<int>& a, int start) {
    if (start == a.size()) { result.push_back(a); return; }

    unordered_set<int> seen;
    for (int i = start; i < a.size(); i++) {
        if (seen.count(a[i])) continue;   // same value placed here before
        seen.insert(a[i]);
        swap(a[start], a[i]);
        backtrack(a, start + 1);
        swap(a[start], a[i]);
    }
}

Problem 3 — Combination Sum

Given candidates (distinct positive integers) and a target, find all combinations that sum to target. You may use each number unlimited times.

The pruning key: sort first, then break early when candidates[j] > remaining.

vector<vector<int>> result;

void backtrack(vector<int>& cands, int start, int remaining, vector<int>& current) {
    if (remaining == 0) {
        result.push_back(current);
        return;
    }

    for (int i = start; i < cands.size(); i++) {
        if (cands[i] > remaining) break;   // sorted — no point continuing

        current.push_back(cands[i]);
        backtrack(cands, i, remaining - cands[i], current);  // i, not i+1 (reuse allowed)
        current.pop_back();
    }
}

vector<vector<int>> combinationSum(vector<int>& candidates, int target) {
    sort(candidates.begin(), candidates.end());
    vector<int> current;
    backtrack(candidates, 0, target, current);
    return result;
}

For Combination Sum II (each element used once, may have duplicates): pass i+1 and skip cands[i] == cands[i-1] at the same recursion depth.

for (int i = start; i < cands.size(); i++) {
    if (i > start && cands[i] == cands[i-1]) continue;  // skip same value at same level
    if (cands[i] > remaining) break;
    current.push_back(cands[i]);
    backtrack(cands, i + 1, remaining - cands[i], current);
    current.pop_back();
}

Problem 4 — N-Queens

Place n queens on an n×n board such that no two attack each other.

Constraint: no two queens share a column, row, or diagonal. Since we place one queen per row, rows are automatically distinct. Track forbidden columns and diagonals.

int n;
vector<vector<string>> result;

// col[c] = queen in column c
// diag1[r-c+n] = queen on major diagonal (r-c constant)
// diag2[r+c]   = queen on minor diagonal (r+c constant)
vector<bool> col, diag1, diag2;

void backtrack(int row, vector<string>& board) {
    if (row == n) {
        result.push_back(board);
        return;
    }

    for (int c = 0; c < n; c++) {
        if (col[c] || diag1[row - c + n] || diag2[row + c]) continue;

        board[row][c] = 'Q';
        col[c] = diag1[row - c + n] = diag2[row + c] = true;

        backtrack(row + 1, board);

        board[row][c] = '.';
        col[c] = diag1[row - c + n] = diag2[row + c] = false;
    }
}

vector<vector<string>> solveNQueens(int _n) {
    n = _n;
    col.assign(n, false);
    diag1.assign(2 * n, false);
    diag2.assign(2 * n, false);
    vector<string> board(n, string(n, '.'));
    backtrack(0, board);
    return result;
}

The diagonal indexing is the key insight:

• Major diagonal: r - c is constant. Shift by n to avoid negatives: r - c + n.
• Minor diagonal: r + c is constant.

This gives \(O(1)\) conflict checks instead of scanning the board each time.

Problem 5 — Word Search on a grid

Given a 2D character grid and a word, determine whether the word exists as a connected path (horizontal/vertical, no cell reused).

int rows, cols;
vector<vector<char>> grid;
string word;

bool backtrack(int r, int c, int idx) {
    if (idx == word.size()) return true;
    if (r < 0 || r >= rows || c < 0 || c >= cols) return false;
    if (grid[r][c] != word[idx]) return false;

    char tmp = grid[r][c];
    grid[r][c] = '#';   // mark visited

    bool found = backtrack(r+1, c, idx+1)
              || backtrack(r-1, c, idx+1)
              || backtrack(r, c+1, idx+1)
              || backtrack(r, c-1, idx+1);

    grid[r][c] = tmp;   // restore
    return found;
}

bool exist(vector<vector<char>>& g, string w) {
    grid = g; word = w;
    rows = g.size(); cols = g[0].size();
    for (int r = 0; r < rows; r++)
        for (int c = 0; c < cols; c++)
            if (backtrack(r, c, 0)) return true;
    return false;
}

In-place mutation with restore (grid[r][c] = '#' then restore) avoids a separate visited array. This is a common trick in grid backtracking.

Worst case: \(O(m \cdot n \cdot 4^L)\) where \(L\) is word length — but in practice pruning cuts this heavily.

Problem 6 — Sudoku Solver

Fill a 9×9 grid so each row, column, and 3×3 box contains digits 1–9 exactly once.

bool used_row[9][10] = {}, used_col[9][10] = {}, used_box[9][10] = {};

int box(int r, int c) { return (r / 3) * 3 + c / 3; }

bool solve(vector<vector<char>>& board, int pos) {
    while (pos < 81 && board[pos/9][pos%9] != '.') pos++;
    if (pos == 81) return true;

    int r = pos / 9, c = pos % 9;
    for (int d = 1; d <= 9; d++) {
        if (used_row[r][d] || used_col[c][d] || used_box[box(r,c)][d]) continue;

        board[r][c] = '0' + d;
        used_row[r][d] = used_col[c][d] = used_box[box(r,c)][d] = true;

        if (solve(board, pos + 1)) return true;

        board[r][c] = '.';
        used_row[r][d] = used_col[c][d] = used_box[box(r,c)][d] = false;
    }
    return false;
}

void solveSudoku(vector<vector<char>>& board) {
    // initialize constraint sets from pre-filled cells
    for (int r = 0; r < 9; r++)
        for (int c = 0; c < 9; c++)
            if (board[r][c] != '.') {
                int d = board[r][c] - '0';
                used_row[r][d] = used_col[c][d] = used_box[box(r,c)][d] = true;
            }
    solve(board, 0);
}

Pre-computing used_row/col/box makes each candidate check \(O(1)\). Without this, you’d scan the row/column/box for each digit — much slower.

Problem 7 — Letter Combinations of a Phone Number

You’re given a sequence of digit presses on an old T9 phone keypad (digits 2–9). Each digit maps to 2–4 letters. Return every possible string that could have been typed.

2 → abc    3 → def    4 → ghi    5 → jkl
6 → mno    7 → pqrs   8 → tuv    9 → wxyz

Pressing 2 then 3 can produce any of: ad, ae, af, bd, be, bf, cd, ce, cf.

This is a clean illustration of the backtracking template — the state is the combination being built, and the choices at each position are the letters mapped to that digit.

class Solution:
    def letterCombinations(self, digits: str) -> List[str]:
        choices = {
            "2": "abc", "3": "def", "4": "ghi", "5": "jkl",
            "6": "mno", "7": "pqrs", "8": "tuv", "9": "wxyz"
        }

        n = len(digits)
        ret = []

        def solve(pos, cur):
            if pos >= n:
                ret.append(''.join(cur))
                return

            for ch in choices[digits[pos]]:
                cur.append(ch)      # choose
                solve(pos + 1, cur) # explore
                cur.pop()           # unchoose

        solve(0, [])
        return ret

The decision tree has depth n (one level per digit) and branching factor 3 or 4 (letters per key). Total leaves = total combinations = product of letters per digit, so time is \(O(4^n \cdot n)\) in the worst case (all 9s and 7s, which map to 4 letters).

What makes this a good first backtracking problem: there is no pruning needed — every path from root to leaf is valid. It isolates the choose/explore/unchoose rhythm without the distraction of constraint checking.

Problem 8 — Generate Parentheses

Given n pairs of parentheses, generate every string of length 2n that is a valid bracket sequence. For n = 3 there are 5 such strings: ((())), (()()), (())(), ()(()), ()()().

The string has 2n positions. At each position you choose ( or ). The trick is knowing when ) is legal — you need to track how many unmatched opens you have so far (cur):

• You can always add (, which increments cur.
• You can only add ) when cur > 0 (there’s an open bracket to close).
• At position 2n, the string is valid iff cur == 0 (all brackets matched).

class Solution:
    def generateParenthesis(self, n: int) -> List[str]:
        ret = []

        def solve(pos, res, cur):
            if pos >= 2 * n:
                if cur == 0:          # all brackets matched
                    ret.append(''.join(res))
                return

            for ch in '()':
                if ch == '(':
                    res.append(ch)
                    solve(pos + 1, res, cur + 1)  # one more unmatched open
                    res.pop()
                elif ch == ')' and cur > 0:       # prune: can't close what isn't open
                    res.append(ch)
                    solve(pos + 1, res, cur - 1)
                    res.pop()

        solve(0, [], 0)
        return ret

The pruning cur > 0 is what prevents invalid sequences — it cuts every branch that would produce a ) with nothing to close. This eliminates the need to validate at the leaf.

Compare this to Letter Combinations (Problem 7): there, every path was valid and we only checked at the leaf. Here, the constraint (cur > 0) is checked mid-path, halving the branches at each ) decision.

Time complexity: \(O(4^n / \sqrt{n})\) — the number of valid sequences is the \(n\)-th Catalan number \(C_n = \frac{1}{n+1}\binom{2n}{n}\), which grows as \(O(4^n / n^{3/2})\). Each sequence takes \(O(n)\) to copy, giving the total.

Recognizing when to prune

Backtracking without pruning is just brute force. The speedup comes entirely from cutting branches early. Ask:

• Can this partial state ever reach a valid solution? If not, return immediately.
• Is the current cost/sum already beyond the target? Break (especially if candidates are sorted).
• Is a constraint already violated? Skip before recursing.

Patterns summary

The mental checklist:

1. What is the partial state?
2. What are the choices at each step?
3. What makes a choice invalid (prune)?
4. What makes the state complete (record)?
5. Does undo fully restore the state?

Creating a project with gradle init

gradle init is an interactive wizard that scaffolds a new project. Run it in an empty directory:

mkdir my-app && cd my-app
gradle init

It will ask:

Select type of project to generate:
  1: basic
  2: application       ← pick this for a runnable app
  3: library
  4: Gradle plugin

Select implementation language:
  1: Java

Select build script DSL:
  1: Kotlin             ← build.gradle.kts
  2: Groovy             ← build.gradle

Project name: my-app
Source package: com.example

After finishing, you get:

my-app/
├── gradlew                        # Gradle wrapper script (Linux/Mac)
├── gradlew.bat                    # Gradle wrapper script (Windows)
├── gradle/
│   └── wrapper/
│       ├── gradle-wrapper.jar     # wrapper bootstrap binary
│       └── gradle-wrapper.properties  # which Gradle version to use
├── settings.gradle.kts            # project name, subproject list
├── build.gradle.kts               # dependencies, plugins, build config
└── src/
    ├── main/java/com/example/
    │   └── App.java
    └── test/java/com/example/
        └── AppTest.java

The source directory convention

Gradle follows the Maven standard layout. The package name becomes a nested directory path under src/main/java/ and src/test/java/. For a package com.ridesharing:

src/
├── main/
│   └── java/
│       └── com/
│           └── ridesharing/
│               ├── Main.java
│               ├── Driver.java
│               └── Trip.java
└── test/
    └── java/
        └── com/
            └── ridesharing/
                ├── MainTest.java
                ├── DriverTest.java
                └── TripTest.java

The test package mirrors the main package exactly. This is convention, not enforced — but it means test classes get package-private access to the classes they test without needing everything to be public.

When Gradle compiles, src/main/java goes to build/classes/java/main/ and src/test/java goes to build/classes/java/test/. The test classpath includes both so tests can import production classes.

The build file

build.gradle.kts (Kotlin DSL) for a Java application looks like this:

plugins {
    java                         // compiles Java source
    application                  // adds 'run' task and creates a distribution
}

repositories {
    mavenCentral()               // where to download dependencies from
}

dependencies {
    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
}

application {
    mainClass = "com.example.App"  // entry point for ./gradlew run
}

tasks.test {
    useJUnitPlatform()           // tell Gradle to use JUnit 5 runner
}

settings.gradle.kts just names the project and lists subprojects (for single-project builds, it’s minimal):

rootProject.name = "my-app"

Key commands

All commands use ./gradlew (the wrapper) rather than gradle directly — more on why below.

./gradlew tasks

Lists every available task and a short description. Good starting point when you’re unfamiliar with a project.

./gradlew tasks

./gradlew build

The main command. It:

1. Compiles src/main/java → build/classes/java/main/
2. Compiles src/test/java → build/classes/java/test/
3. Runs all tests
4. Packages everything into a JAR at build/libs/my-app.jar

If any test fails, the build fails.

./gradlew build

./gradlew run

Compiles (if needed) and runs the class specified in application.mainClass.

./gradlew run

Pass arguments via --args:

./gradlew run --args="hello world"

./gradlew test

Compiles and runs tests only. After it finishes, a human-readable HTML report is generated at:

build/reports/tests/test/index.html

./gradlew test

# Run a specific test class
./gradlew test --tests "com.example.AppTest"

# Run a specific test method
./gradlew test --tests "com.example.AppTest.shouldReturnTrue"

./gradlew clean

Deletes the build/ directory. Use this when you want a completely fresh build — useful when you suspect stale compiled classes are causing weird behavior.

./gradlew clean build   # clean then build in one shot

./gradlew jar

Builds just the JAR without running tests.

./gradlew jar
# output: build/libs/my-app.jar

What happens during a build — the three phases

Gradle processes every build in exactly three phases, in order:

1. Initialization — Gradle reads settings.gradle.kts to find which projects exist and sets up the project hierarchy.

2. Configuration — Gradle evaluates every build.gradle.kts file. This does NOT run tasks yet — it just builds a graph of all tasks and their dependencies. This is why you can print tasks without actually compiling anything.

3. Execution — Gradle looks at which tasks you asked for, resolves the dependency graph (e.g., test depends on compileTestJava which depends on compileJava), and executes them in the correct order.

This separation is important: code at the top level of build.gradle.kts runs at configuration time (phase 2), not at execution time. Mistakes here cause slow configuration or broken task graphs.

Incremental builds and the build cache

Gradle tracks the inputs and outputs of every task. If nothing changed since the last run, it skips the task and prints UP-TO-DATE.

> Task :compileJava UP-TO-DATE
> Task :processResources UP-TO-DATE
> Task :classes UP-TO-DATE
> Task :test UP-TO-DATE

This makes repeated builds very fast. ./gradlew clean throws this away — only do it when something is genuinely wrong, not as a habit.

Dependencies — implementation vs api vs testImplementation

dependencies {
    implementation("com.google.guava:guava:32.0.0")
        // available in your main code, NOT exposed to callers of your library

    api("com.fasterxml.jackson.core:jackson-databind:2.15.0")
        // available in main code AND exposed to callers (for libraries only)

    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
        // available only in test source set

    runtimeOnly("org.slf4j:slf4j-simple:2.0.0")
        // only on classpath at runtime, not at compile time
}

For application projects (not libraries), use implementation for everything — api only matters when other projects depend on your project as a library.

The Gradle Wrapper — gradlew vs gradle

The wrapper is the recommended way to run Gradle. Instead of using a globally installed gradle command, you use ./gradlew — a small script that downloads and caches the exact Gradle version specified in gradle/wrapper/gradle-wrapper.properties.

# gradle/wrapper/gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-8.7-bin.zip

Why use the wrapper instead of global Gradle?

Reproducibility — everyone on the team uses the exact same Gradle version. “Works on my machine” build failures caused by version mismatches disappear.

No installation required — a new team member clones the repo and runs ./gradlew build. They don’t need to install anything. The wrapper downloads the right Gradle version automatically on first run.

CI/CD friendly — your CI pipeline just runs ./gradlew build. No setup step to install a specific Gradle version. No drift between what CI uses and what developers use.

Upgrading is explicit and tracked — to upgrade Gradle, run:

./gradlew wrapper --gradle-version 8.8

This updates gradle-wrapper.properties, which you commit to version control. Every developer and CI job gets the upgrade automatically on next pull. There’s a clear history of when and why the version changed.

Commit the wrapper, not the distribution — commit gradlew, gradlew.bat, gradle/wrapper/gradle-wrapper.jar, and gradle/wrapper/gradle-wrapper.properties. Do not commit the downloaded Gradle distribution itself (it lives in ~/.gradle/wrapper/dists/).

Multi-project builds

Large projects split into subprojects (modules). The root settings.gradle.kts declares them:

rootProject.name = "my-app"
include("core", "api", "web")

Each subproject has its own build.gradle.kts. A subproject can depend on another:

// web/build.gradle.kts
dependencies {
    implementation(project(":core"))
    implementation(project(":api"))
}

Build a specific subproject:

./gradlew :web:build
./gradlew :core:test

Quick reference

The rule on gradlew vs gradle: always use ./gradlew. Never rely on a globally installed gradle for project builds — it defeats the purpose of the wrapper.

Comparable vs Comparator

Java has two ways to define ordering:

Comparable<T> — the object defines its own natural ordering by implementing compareTo. One ordering per class, baked in.

class Student implements Comparable<Student> {
    String name;
    int age;

    @Override
    public int compareTo(Student other) {
        return Integer.compare(this.age, other.age); // natural order: by age
    }
}

List<Student> list = ...;
Collections.sort(list); // uses compareTo

Comparator<T> — an external object defines an ordering. You can have as many as you want, and you don’t need to touch the class.

Comparator<Student> byName = (a, b) -> a.name.compareTo(b.name);
list.sort(byName);

Use Comparable for the one obvious natural ordering (e.g., integers by value, strings lexicographically). Use Comparator for everything else — alternate orderings, anonymous sorts, and when you don’t own the class.

The compare contract

compare(a, b) must return:

• negative — a should come before b
• zero — a and b are equal in ordering
• positive — b should come before a

The one rule to remember: the first argument to Integer.compare(x, y) is what you want out first.

// ascending: small values first
(a, b) -> Integer.compare(a, b)

// descending: large values first
(a, b) -> Integer.compare(b, a)

Avoid a - b subtraction — it overflows when values are large or negative. Always use Integer.compare or Double.compare.

Comparator factory methods

Since Java 8, Comparator has static factory methods that let you build comparators without writing the comparison logic manually.

Comparator.comparing

// Sort students by name
Comparator<Student> byName = Comparator.comparing(s -> s.name);

// With method reference (cleaner)
Comparator<Student> byName = Comparator.comparing(Student::getName);

comparingInt, comparingDouble, comparingLong

Prefer these over comparing when the key is a primitive — they avoid boxing.

Comparator<Student> byAge = Comparator.comparingInt(Student::getAge);

Chaining with thenComparing

Sort by a primary key, break ties with a secondary key.

// Sort by age ascending, then by name ascending for same age
Comparator<Student> cmp = Comparator
    .comparingInt(Student::getAge)
    .thenComparing(Student::getName);

list.sort(cmp);

You can chain as many levels as needed:

Comparator<Employee> cmp = Comparator
    .comparingInt(Employee::getDepartment)
    .thenComparingInt(Employee::getSalary)
    .thenComparing(Employee::getName);

Reversing order with reversed()

// Descending by age
Comparator<Student> byAgeDesc = Comparator
    .comparingInt(Student::getAge)
    .reversed();

// Descending primary, ascending secondary
Comparator<Student> cmp = Comparator
    .comparingInt(Student::getAge).reversed()
    .thenComparing(Student::getName);       // name still ascending

Be careful about where you call reversed() — it reverses everything chained before it, not just the last key.

// Reverses BOTH keys
Comparator<Student> cmp = Comparator
    .comparingInt(Student::getAge)
    .thenComparing(Student::getName)
    .reversed();

// Reverses ONLY age, name stays ascending
Comparator<Student> cmp = Comparator
    .comparingInt(Student::getAge).reversed()
    .thenComparing(Student::getName);

For mixed directions (ascending primary, descending secondary) without reversed(), write the secondary comparator manually:

Comparator<Student> cmp = Comparator
    .comparingInt(Student::getAge)                              // age ascending
    .thenComparing((a, b) -> b.getName().compareTo(a.getName())); // name descending

Handling nulls

Comparator.nullsFirst and Comparator.nullsLast wrap another comparator and push null values to the front or back.

// Nulls sort to the front, non-nulls sort by name
Comparator<Student> cmp = Comparator.nullsFirst(
    Comparator.comparing(Student::getName)
);

// Nulls sort to the back
Comparator<Student> cmp = Comparator.nullsLast(
    Comparator.comparing(Student::getName)
);

Where Comparator is used

List.sort and Collections.sort:

list.sort(Comparator.comparingInt(Student::getAge));
Collections.sort(list, Comparator.comparing(Student::getName));

Arrays.sort (object arrays only — int[] doesn’t accept a comparator):

Student[] arr = ...;
Arrays.sort(arr, Comparator.comparingInt(Student::getAge));

PriorityQueue constructor:

// Min by age
PriorityQueue<Student> pq = new PriorityQueue<>(
    Comparator.comparingInt(Student::getAge)
);

// Max by age
PriorityQueue<Student> pq = new PriorityQueue<>(
    Comparator.comparingInt(Student::getAge).reversed()
);

TreeMap and TreeSet constructor:

// TreeSet ordered by name
TreeSet<Student> ts = new TreeSet<>(Comparator.comparing(Student::getName));

// TreeMap ordered by key length
TreeMap<String, Integer> tm = new TreeMap<>(
    Comparator.comparingInt(String::length).thenComparing(Comparator.naturalOrder())
);

Storing and reusing comparators

Comparators are objects — you can store them in variables, pass them around, and compose them.

class StudentComparators {
    static final Comparator<Student> BY_AGE = Comparator.comparingInt(Student::getAge);
    static final Comparator<Student> BY_NAME = Comparator.comparing(Student::getName);
    static final Comparator<Student> BY_AGE_THEN_NAME = BY_AGE.thenComparing(BY_NAME);
}

list.sort(StudentComparators.BY_AGE_THEN_NAME);
pq = new PriorityQueue<>(StudentComparators.BY_AGE);

Quick reference

The one rule: Integer.compare(X, Y) means X comes before Y. Put the value you want out first as the first argument.

What is a Stream?

A Stream<T> is a sequence of elements that supports a pipeline of operations. The key properties:

• Not a data structure — it doesn’t store elements. It pulls them from a source (collection, array, generator).
• Lazy — intermediate operations are not executed until a terminal operation is called.
• Single-use — once consumed, a stream cannot be reused.

A pipeline has three parts:

source → intermediate operations (lazy) → terminal operation (triggers execution)

Creating streams

// From a collection
List<String> names = List.of("Alice", "Bob", "Charlie");
Stream<String> s = names.stream();

// From an array
int[] arr = {1, 2, 3};
IntStream s = Arrays.stream(arr);

// From values directly
Stream<String> s = Stream.of("a", "b", "c");

// Infinite stream — generate
Stream<Double> randoms = Stream.generate(Math::random);

// Infinite stream — iterate (like a for loop)
Stream<Integer> naturals = Stream.iterate(0, n -> n + 1); // 0, 1, 2, 3, ...

// Finite iterate (Java 9+)
Stream<Integer> first10 = Stream.iterate(0, n -> n < 10, n -> n + 1);

Intermediate operations

These are lazy — they return a new stream and don’t execute until a terminal operation is called.

filter — keep elements matching a predicate

List<Integer> evens = numbers.stream()
    .filter(n -> n % 2 == 0)
    .collect(Collectors.toList());

map — transform each element

List<String> upperNames = names.stream()
    .map(String::toUpperCase)
    .collect(Collectors.toList());

// Map to a different type
List<Integer> lengths = names.stream()
    .map(String::length)
    .collect(Collectors.toList());

flatMap — flatten a stream of streams

Use when each element maps to multiple elements. map would give you a Stream<List<T>>; flatMap flattens it to Stream<T>.

List<List<Integer>> nested = List.of(List.of(1, 2), List.of(3, 4), List.of(5));

// map gives Stream<List<Integer>> — not what we want
// flatMap gives Stream<Integer>
List<Integer> flat = nested.stream()
    .flatMap(Collection::stream)
    .collect(Collectors.toList());
// [1, 2, 3, 4, 5]

Another common use — splitting strings into words:

List<String> sentences = List.of("hello world", "foo bar");
List<String> words = sentences.stream()
    .flatMap(s -> Arrays.stream(s.split(" ")))
    .collect(Collectors.toList());
// ["hello", "world", "foo", "bar"]

sorted — sort elements

// Natural order
list.stream().sorted()

// Custom comparator
list.stream().sorted(Comparator.comparingInt(Student::getAge))

// Descending
list.stream().sorted(Comparator.comparingInt(Student::getAge).reversed())

distinct — remove duplicates

List<Integer> unique = List.of(1, 2, 2, 3, 3, 3).stream()
    .distinct()
    .collect(Collectors.toList());
// [1, 2, 3]

limit and skip

// First 5 elements
stream.limit(5)

// Skip first 5, take the rest
stream.skip(5)

// Pagination: page 2, size 10
stream.skip(10).limit(10)

peek — inspect elements without consuming the stream

Useful for debugging. Does not alter the stream.

list.stream()
    .filter(n -> n > 0)
    .peek(n -> System.out.println("after filter: " + n))
    .map(n -> n * 2)
    .collect(Collectors.toList());

Terminal operations

These trigger the pipeline to execute and produce a result. After calling one, the stream is consumed.

collect — gather results into a collection

The most common terminal operation. Takes a Collector — covered in the next section.

List<String> list = stream.collect(Collectors.toList());
Set<String> set = stream.collect(Collectors.toSet());

forEach — consume each element

names.stream().forEach(System.out::println);

Note: forEach does not guarantee order on parallel streams. Use forEachOrdered if order matters.

count

long count = names.stream().filter(n -> n.startsWith("A")).count();

findFirst and findAny

Both return an Optional<T>. findFirst returns the first element in encounter order; findAny may return any element (faster on parallel streams).

Optional<String> first = names.stream()
    .filter(n -> n.length() > 3)
    .findFirst();

first.ifPresent(System.out::println);
String val = first.orElse("none");

anyMatch, allMatch, noneMatch

Short-circuit — stop as soon as the answer is known.

boolean hasAdult = students.stream().anyMatch(s -> s.getAge() >= 18);
boolean allAdults = students.stream().allMatch(s -> s.getAge() >= 18);
boolean noneMinor = students.stream().noneMatch(s -> s.getAge() < 18);

min and max

Return Optional<T>.

Optional<Student> youngest = students.stream()
    .min(Comparator.comparingInt(Student::getAge));

Optional<Integer> maxVal = numbers.stream().max(Integer::compare);

reduce — fold elements into a single value

// Sum
int sum = numbers.stream().reduce(0, Integer::sum);

// Product
int product = numbers.stream().reduce(1, (a, b) -> a * b);

// Without identity — returns Optional
Optional<Integer> max = numbers.stream().reduce(Integer::max);

Collectors

Collectors is a utility class with factory methods for common collection strategies.

toList, toSet, toUnmodifiableList

List<String> list = stream.collect(Collectors.toList());
Set<String> set  = stream.collect(Collectors.toSet());
List<String> immutable = stream.collect(Collectors.toUnmodifiableList());

toMap

// Map from name to age
Map<String, Integer> nameToAge = students.stream()
    .collect(Collectors.toMap(Student::getName, Student::getAge));

// Handle duplicate keys with a merge function
Map<String, Integer> nameToAge = students.stream()
    .collect(Collectors.toMap(
        Student::getName,
        Student::getAge,
        (existing, newVal) -> existing  // keep existing on collision
    ));

groupingBy — group elements by a classifier

// Group students by department
Map<String, List<Student>> byDept = students.stream()
    .collect(Collectors.groupingBy(Student::getDepartment));

// Group and count
Map<String, Long> countByDept = students.stream()
    .collect(Collectors.groupingBy(
        Student::getDepartment,
        Collectors.counting()
    ));

// Group and collect only names
Map<String, List<String>> namesByDept = students.stream()
    .collect(Collectors.groupingBy(
        Student::getDepartment,
        Collectors.mapping(Student::getName, Collectors.toList())
    ));

partitioningBy — split into two groups (true/false)

Map<Boolean, List<Student>> partition = students.stream()
    .collect(Collectors.partitioningBy(s -> s.getAge() >= 18));

List<Student> adults = partition.get(true);
List<Student> minors = partition.get(false);

joining — concatenate strings

String result = names.stream().collect(Collectors.joining());
// "AliceBobCharlie"

String result = names.stream().collect(Collectors.joining(", "));
// "Alice, Bob, Charlie"

String result = names.stream().collect(Collectors.joining(", ", "[", "]"));
// "[Alice, Bob, Charlie]"

counting, summingInt, averagingInt

long count = stream.collect(Collectors.counting());
int total  = stream.collect(Collectors.summingInt(Student::getAge));
double avg = stream.collect(Collectors.averagingInt(Student::getAge));

Primitive streams

For int, long, and double, use IntStream, LongStream, DoubleStream to avoid boxing overhead. They have extra methods like sum(), average(), range().

// Sum of 1 to 100
int sum = IntStream.rangeClosed(1, 100).sum();

// Average age
OptionalDouble avg = students.stream()
    .mapToInt(Student::getAge)
    .average();

// Box back to Stream<Integer> if needed
Stream<Integer> boxed = IntStream.range(0, 10).boxed();

Common patterns

Filter then transform:

List<String> result = students.stream()
    .filter(s -> s.getAge() > 20)
    .map(Student::getName)
    .sorted()
    .collect(Collectors.toList());

Frequency map (word count):

Map<String, Long> freq = words.stream()
    .collect(Collectors.groupingBy(w -> w, Collectors.counting()));

Flatten and deduplicate:

Set<String> allTags = posts.stream()
    .flatMap(p -> p.getTags().stream())
    .collect(Collectors.toSet());

Top N elements:

List<Student> top3 = students.stream()
    .sorted(Comparator.comparingInt(Student::getScore).reversed())
    .limit(3)
    .collect(Collectors.toList());

Check if a value exists and get it:

students.stream()
    .filter(s -> s.getName().equals("Alice"))
    .findFirst()
    .ifPresent(s -> System.out.println(s.getAge()));

Parallel streams

Call .parallelStream() instead of .stream() to split work across threads. Useful for CPU-bound operations on large collections.

long count = bigList.parallelStream()
    .filter(expensiveOperation)
    .count();

Caveats:

• Not always faster — parallelism has overhead. Benchmark before using.
• Order is not guaranteed unless you use forEachOrdered or sorted.
• Avoid stateful lambdas (e.g., modifying a shared variable) — they cause race conditions.

Quick reference

Creating a new project with uv

uv is a fast Python package manager (written in Rust by Astral, the team behind Ruff). It replaces pip, venv, pip-tools, and partly poetry with a single tool.

Install uv:

curl -LsSf https://astral.sh/uv/install.sh | sh
# or
pip install uv

Create a new project:

uv init my-project
cd my-project

This scaffolds:

my-project/
├── pyproject.toml       # project metadata and dependencies
├── README.md
├── .python-version      # pins the Python version for this project
├── .gitignore
└── src/
    └── my_project/
        └── __init__.py

uv init also creates a virtual environment at .venv/ automatically on first use.

Typical project structure

For anything beyond a one-file script, use the src layout:

my-project/
├── pyproject.toml
├── README.md
├── .gitignore
├── .python-version
├── src/
│   └── my_project/          # your package (underscores, not hyphens)
│       ├── __init__.py
│       ├── main.py
│       ├── models/
│       │   ├── __init__.py
│       │   └── user.py
│       └── services/
│           ├── __init__.py
│           └── auth.py
└── tests/
    ├── conftest.py           # shared fixtures
    ├── test_main.py
    ├── models/
    │   └── test_user.py
    └── services/
        └── test_auth.py

Why src/ layout? Without it, import my_project in tests would find the local directory instead of the installed package — which can hide import errors that only show up in production. The src/ layout forces the package to be installed before it can be imported.

Test files mirror the source structure — same as Java/Gradle. src/my_project/models/user.py → tests/models/test_user.py. Pytest discovers test files by looking for files named test_*.py or *_test.py.

Python naming conventions

These follow PEP 8, the official Python style guide.

Google’s Python conventions

Google’s Python Style Guide builds on PEP 8 but adds a few opinions of its own. These are the ones worth internalizing:

Naming, the Google way

Google spells out the casing rules explicitly. They line up with PEP 8 above, but the guide phrases them as a table you can memorize:

Google explicitly avoids __double_leading_underscore for “private” attributes — they prefer a single underscore, because name mangling is rarely worth the friction.

Things Google is opinionated about

• No single-character names except for counters/iterators (i, j), e in except clauses, and f for file handles. Avoid l, O, I — they look like 1 and 0.
• No “dunder” naming for your own modules — names like __author__ are discouraged.
• Prefer descriptive names over abbreviations. error_count, not err_cnt.
• CapWords for class names even when they’re acronyms — HttpServer, not HTTPServer.
• Module names match the file name — keep them short and lower_with_under.
• Use one statement per line, and keep lines ≤ 80 chars (PEP 8 allows 79; Google says 80).

Docstrings

Google has a distinctive docstring style — sectioned with Args:, Returns:, Raises::

def fetch_user(user_id: int, *, retries: int = 3) -> User:
    """Fetches a user by ID.

    Args:
        user_id: The unique identifier of the user.
        retries: Number of times to retry on failure.

    Returns:
        The User object matching the given ID.

    Raises:
        UserNotFoundError: If no user exists with that ID.
    """

This is the “Google style” you’ll see picked up by tools like Sphinx’s Napoleon extension. The alternative is NumPy or reST style — pick one and stay consistent across the project.

pyproject.toml — the modern config file

pyproject.toml is the single file for project metadata, dependencies, and tool config. It replaces setup.py, setup.cfg, and requirements.txt for most purposes.

[project]
name = "my-project"
version = "0.1.0"
description = "A short description"
requires-python = ">=3.11"
dependencies = [
    "requests>=2.31.0",
    "pydantic>=2.0",
]

[project.optional-dependencies]
dev = [
    "pytest>=8.0",
    "pytest-cov",
    "ruff",
]

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[tool.pytest.ini_options]
testpaths = ["tests"]

Virtual environments — why they matter

A virtual environment is an isolated Python installation for your project. Without one, every project on your machine shares the same global packages — version conflicts are inevitable.

# Create a venv manually
python -m venv .venv

# Activate it (Linux/Mac)
source .venv/bin/activate

# Activate it (Windows)
.venv\Scripts\activate

# You're now in the venv — pip install goes here, not system-wide
(my-project) $ pip install requests

uv manages the venv for you automatically — you rarely need to activate it manually.

Managing dependencies with uv

Add a dependency

uv add requests          # adds to [project.dependencies] in pyproject.toml
uv add pytest --dev      # adds to dev dependencies
uv add "pydantic>=2.0"   # with version constraint

uv add also updates uv.lock — the lockfile that pins every dependency’s exact version.

Install all dependencies (e.g. after cloning a repo)

uv sync                  # installs everything in pyproject.toml
uv sync --dev            # includes dev dependencies too

Remove a dependency

uv remove requests

Run a command inside the project environment

uv run python src/my_project/main.py
uv run pytest

uv run automatically uses the project’s venv without needing to activate it first.

Show installed packages

uv pip list

Managing dependencies with pip (the fallback)

If you’re not using uv, the traditional approach uses pip and a requirements.txt file.