Tamsin Ordway

Worth putting a question to the HQ side too, since "never arrives" cuts both ways.

If there is DDoS scrubbing, a transit provider filter, or an upstream ACL sitting in front of that firewall, traffic can be dropped before it ever reaches the interface you're capturing on - and your capture would look exactly like it does now. Ask whoever provides HQ transit whether that source prefix, or the whole consumer ISP range it lives in, is currently being filtered, scrubbed or rate limited.

It's a five minute question, and it's the only theory on this page that explains "nothing in the capture" without involving the client's ISP at all. Rule it out before you send the customer down the road of arguing with their provider.

That explains both symptoms at once. I had the export sitting in actions.ts and assumed it was being ignored rather than rejected.

If you find yourself doing the const dance twenty times, lift it into one place:

function withEmail(u: User): (User & { email: string }) | null {
  return u.email ? (u as User & { email: string }) : null
}

One cast, in one file, reviewed once, and everything downstream is honest about what it has.

Same reason if (this.x) never survives into a callback in class code, which is where most people meet this. Destructuring the fields you need at the top of the method makes an entire category of this disappear.

If the column list is fixed you can go further and build one statement with 100 value tuples: one subrequest and one parse instead of 100 prepared bindings. Mind the SQLite bound parameter ceiling of 999 while you do it: with three columns that is 333 rows a statement, with six it is 166.

Rule of thumb that has never once failed me: pool max should be single digits on a shared vCPU. People set 100 because it sounds generous. It is the opposite of generous, it is handing 100 concurrent queries to a machine that can execute two.

Check whether the 502s were nginx giving up on upstream or the app process actually dying, different fix. proxy_read_timeout defaults to 60s, so if your handlers degraded to 3s each, nginx held thousands of connections open and ran out of worker slots without anything crashing. Your logs and dmesg will settle it in a minute.

Export your history every few months regardless of what you decide. I lost about two years of data when a service shut down its consumer app with a couple of months of notice and the export tool was slow and partial. A folder of files on your own disk costs nothing and is the only version of your data nobody can change the terms on.

Agreed in the general case, and I would still keep it where the path arrives as a runtime string you want checked against the shape: feature flag keys, translation keys, that sort of thing. That is the one place it earns its cost, and it is also the place where capping the depth is painless.

Not a dead end, but you need a depth counter. The compiler is not confused, it hit its instantiation budget, and it has no way to know your object bottoms out.

type Prev = [never, 0, 1, 2, 3, 4, 5, 6]

type Path<T, D extends number = 4> =
  [D] extends [never] ? never
  : T extends readonly unknown[] ? never
  : T extends object
    ? { [K in keyof T & string]:
          T[K] extends object ? K | `${K}.${Path<T[K], Prev[D]>}` : K
      }[keyof T & string]
    : never

The thing to internalise is that depth is not the real cost, the cross product is. Nine top keys with seven children each with six each with five is roughly 1,890 distinct string literals, and every one of them is a template literal instantiation the checker has to materialise. Add a level and you multiply, not add.

Capping at 4 means anything deeper falls back to never for the tail, which in practice you handle by accepting string past that depth. Nobody has ever complained about not getting autocomplete at level six.

Practical constraint that fixed this for me: one page per lecture, no exceptions. When the page is nearly full you have to decide what actually matters, which is the work you are currently avoiding by writing everything down.

drizzle-kit and D1 work well together and it is not either/or. drizzle-kit generate writes plain SQL into your migrations folder and wrangler applies it, you keep typed queries and the migration is still a file a human can read in review. That readability matters more than it sounds when someone has to approve a schema change at 6pm on a Thursday.

Keep the overloads and split the implementation into three private functions with honest signatures, then have the public one dispatch. The any shrinks to about four lines of dispatch that you can read in one glance.

And the crash loop case is the worst case, because the thing you most want to read is the thing being overwritten fastest by its own restarts.

For the two categories, the split that has worked for us is: expected and user actionable failures are values, unexpected failures are exceptions. Duplicate email returns an object with a field level message that the form renders through the action state, and the database being down throws and is caught by an error boundary that shows a try again screen. The rule of thumb is whether the user can do something about it, because if they can, it is part of your data model, and if they cannot, it belongs to the boundary.

Separate landmine: AllowedOrigins: ["*"] is silently ignored by browsers on any request sent with credentials. If anything in this flow ever carries a cookie you will get a preflight failure that looks identical to what you have now and no config change will fix it until you list the origin explicitly.

Trace found it in about four minutes. One generated API types file, 11 seconds on its own, and a second one at 6. Both are codegen output that nothing needed to deeply check.

Worth doing the export test before you commit rather than after two years of notes. Write ten pages, export them all, and see what you actually get out.

Nebo is the one I ended up paying for, specifically because the recognition is the best I have used and it converts a page to typed text in one gesture, then exports to Word, HTML or markdown. That solves your search and portability problems at once, because you are not searching handwriting, you are searching text. What it is not is a good place to keep a thousand notes - the organisation is weak compared with a real notes app. I write in it and file the converted text elsewhere.

No argument with that version. Might help, plausible mechanism, unproven at the level of any individual person is exactly where I would put it too. My objection is only to the number of years being quoted as if it were a dosage.

The tell is what happens to the beautiful second set. If you never open it again, it was never notes, it was a craft project. Mine were a craft project and I was quite good at it.

Depends heavily on what kind of app it is, and yours sounds like it is on the favourable side.

Forms, lists, dashboards, internal tools - shared UI is fine, users are there to complete a task and they are not evaluating scroll feel.

Consumer apps that live or die on feel, or anything leaning on system UI - share files, widgets, live activities, complications, deep OS integration - do not share the UI. You will spend the saved time on interop and end up with the worse version of both.

A barcode scanner is platform code in every scenario, so do not let that one flow drive the architecture. Write it twice, it is a small screen.

Things that have run for years on my Pi 3s without complaint: network-wide DNS filtering, a print and scan server so the ancient printer becomes wireless, an ADS-B receiver feeding flight data with a cheap USB dongle, and a Syncthing node that keeps a copy of the family photos in a different room. All of those are I/O light and RAM light, which is exactly what a 1GB board wants. The Pi 2 I would use as the sacrificial test box you break things on.

Politely disagreeing with the enthusiasm, having bought one of the cheap ones first. £34 marketplace "migraine relief band," gel-filled, freezer, straps round the head.

It helped, genuinely - and so does a wet flannel from the fridge, which is free, and so does a bag of peas. Cold on the head during an attack is comforting and nobody needs to sell you a device for it. What I paid for was the branding and a strap.

So before spending three figures, work out whether you want a cold compress or actual neuromodulation. They're marketed identically and they're not remotely the same category of thing.

I wasted most of a year and a lot of money on a class that was a level below where I actually was, because I was too shy to take the placement test seriously and I liked feeling competent. Sit the placement test honestly, take the harder room, be the worst person in it. That is the single most expensive mistake I made and it was entirely self-inflicted.