SerpAPI (which seems like a good product from my singular use), has a really confusing pricing page:

What is a Legal US Shield? And why do I have to pay for it? Does the free plan not include it either?

From their docs:

We are committed to maintaining legal and ethical web scraping practices and providing our customers with peace of mind. This is one reason that for all plans from the production plan and upwards we offer our Legal US Shield. Although web scraping is legal in the US, we provide this coverage in case there were ever any issues to arise. Our Legal US Shield would cover any legal questions regarding only the scraping and parsing of data, not the use of said data. We continue to offer this protection to ease any concerns our customers may have in regards to web scraping.

But really, why does this not apply to the free plans? Seems weird.

const vm = require('vm')
const context = { a: async () => console.log('aaa') }
const code = `await a(); console.log('bbb')`;
new Promise(resolve => { 
	context.console = console; 
	context.resolve = resolve; 
	vm.runInContext(
		`(async () => { ${code}; console.log('pre resolve'); resolve() })()`, 
		vm.createContext(context))
}).then(res => console.log('res', res)).catch(e => console.log('error', e))

I spent all of last year reading all of Robert Caro's books. I started with the Power Broker, and while I would have been happy to just finish that, I finished it ahead of schedule and had time to plough my way through the rest of his Lyndon Johnson books. It took me all year - I finished the last book during the first week of January, 2025. Coincidentally, 2025 is the 50th year anniversary of the Power Broker, so I got to go to a New York Historical Society exhibit where the masters process was laid bare.

While the entire exhibit was awe inspiring, some things stood out:

• Caro had a log of how many words he wrote every day. Even this prolific writer seemed to have a reasonable number of "0 (lazy)" entries in that book.
• He writes in cursive first to slow down his thinking. He talks about how one of his editors said "don't think with your fingers". This hits home for me in a world with AI, where we are unbound not just from thinking upfront about our code, but can outsource that thinking entirely to the speed of GPUs - but what is the cost to quality? A recent plane ride where I wrote code for ~10 hours without any internet, and any distractions really makes me think that it's not always useful or better to have an agent do work for us.
• On the destruction of East Tremont: "What is the cost of (one) generation of human suffering"?

All this inspired me to give myself a birthday gift - a hardcover copy of the Power Broker signed by Caro (completing my collection of all his books). A little bonus fact I discovered when picking up the book is that he is supposedly done with the last LBJ book, and it's off at the editors!!

I've been on an India trip recently with my friends from New York, and one thing that has stuck out to me is what happens when you become a country known for scamming tourists and generally being untrustworthy. Being someone from this country means that I feel a pang of guilt and annoyance when people make these assumptions, but the reality is that people do get scammed often. Heck, even the government, charges tourists almost 10x the amount to enter national monuments - a state sponsored scam.

Anyway, the real cost of this lack of trust is borne by everyone else in society and we can no longer have nice things. This happened in a couple of instances:

• A friend didn't trust the quality of cashmere sold at a shop and was fairly loud about it. The shopowner came out and tried to defend the quality of his goods.
• When we went to the Taj Mahal, the guide told us not to trust the shops right outside the monument since they're mostly fakes. Ironically, the guide himself seemed to have an inordinate amount of pride from being part of the family that built the Taj Mahal (do I even believe this?), but when he took us to his shop later, it was hard to remove the seed of doubt that he'd planted about the remained of the shops.

This post feels like a fairly naive characterization of the way of the world, but it hurts my heart a little bit to see somebody who works with integrity but has to bear the cost of a society that has had it's integrity eroded away.

When you work on code that does something useful, there will always come a time when you have to serialize this data. And your serialization is never right the first time - there will be breaking changes.

Often, this serialization will happen by writing this data to a database. This mode of serialization is relatively easy to handle from a backwards compatibility perspective since you own all the data and can backfill away any inconsistencies at your leisure. Most importantly, the code that handles your backwards incompatibilities can eventually die.

Think now of serializing your data to a file. Perhaps you want the user to be able to download their data. The second you enable this capability, even in the smallest way, you are forever bound to handling that data well, or if you choose to ignore it, being okay with weird data inconsistencies and bugs that will plague your existence. You have to start writing migrations that will live forever, you will start making strange stylistic decisions about your code (for example, let’s not change this string, but introduce a new mapping from this string to another string) - in short, your code is now unkillable because a small part of its past lives in the serialized data exported one day.

The AQI in New York has been bad this weekend, and the gloomy weather it brought with it has got the gears in my head spinning with weighty topics. One in particular has come up around sincerity. I recently watched an exposition of why Lord of the Rings holds up so well even today, and the word "sincerity" rang loudly and clearly throughout the video. Even though the moral calculus of characters in LOTR is relatively straightforward (good and evil are clearly demarcated), they point out that characters in LOTR are sincere. Sam is sincere, Frodo is sincere, Gandalf is sincere. This sincerity shines through in other movies I love, most notably, Top Gun: Maverick (which also makes a fleeting appearance in the video).

At the other extreme, it's a lack of sincerity that rubs me the wrong way with the majority of Twitter grindset content.

recently i started telling candidates right in the first interview that greptile offers no work-life-balance, typical workdays start at 9am and end at 11pm, often later, and we work saturdays, sometimes also sundays. i emphasize the environment is high stress, and there is no...

I can't quite put my finger on why this doesn't feel sincere - the most compelling explanation I've heard is: this would be a fine way to work with people who accept this deal, except there's no real reason to post about it unless the core of the reason you're doing it is to gain platitudes from the Twitter masses (that mostly backfired). To play devil's advocate, if you did want to adopt this strategy, but were unsure about it, maybe you post on Twitter to get advice? I still think that's a terrible idea if you really want advice on whether this is a good thing to do, but mysterious are the ways of the founder.

This should really be a living document, but here's a start:

• The tool to make rounded corners is a fillet
• Use the point tool liberally, especially if you want to avoid the constraint on the center point
• Associate sketches with parts
• You can drag the anchor in the transform tool to move things with respect to a different origin.

I've seen a lot of love recently for local first apps, and a lot of really exciting tools to build out local first apps. One thing I don't see discussed enough is that when your app is local first, you have to work without an internet connection, and keep working sensibly once the connection is back online. This means you have to think about:

• Data migrations and rolling them out. Migrations become slow to roll out and necessary to get right since people could have data stored for a long time after you ship a change.
• Client versions and version upgrades. Shipping a bad client has a huge cost.

This is an incoherent rant. Read at your own risk.

You show up for your Schengen visa appointment on a Tuesday morning - you've taken two hours off work. Your roommate learned about the Schengen agreement for the first time today, it's been seared into your brain since you were 10. The security guard refuses to let someone else in - they don't have an appointment but were told to come back by an employee. They slow the queue down, but you can't help but empathize with them. Travel, after all, frees the mind.

You, the black and brown sheep, are herded into a room with your brethren. The workers - your people, now working for the colonizers - cheerful. The room is understaffed, slow and filled with anxiety. Wait two hours for your turn - the token number is CRAP-71, which matches your mood. Get called up front, spend 20 minutes going through documents, to be told, finally, that you are missing 1 piece of paper - an employment verification letter. Never mind the pay stubs you do have, and immigration proof that you still work at this company.

You leave, and come back 3 days later. Go through the same process, now with all documents in hand. Two hours later, you're free (or so you think).

Two weeks later - you get a call. "We messed up taking your fingerprints, so can you, please, come back, again?" It's a Friday morning, so you actually can go right away. You fill out a new application on a website that can best be described as retro, print it out at a nearby Fedex, and make your way over.

You're supposed to meet C and get the process expedited, but as you enter you see him busy with something. C is spending his time pinning 8 individual QR codes, carefully, onto a board. It's a Finnish visa board. C cannot do this job alone - so two people stand behind him and watch. A third person (who was originally assigned this job), sees this from a distance, and her insecurities about not doing her job well come out in her words.

Anyway, 20 minutes later, the QR codes are put up on the board, and you can get your fingerprints taken. Your token today is CRAP-85. You get the white glove treatment (only 30 minutes, instead of 2 hours) much to the chagrin of every other person there. This is a zero-sum game though, in this room, so you take your advantage. You submit your fingerprints for the second time, and the clock starts, once again, waiting for a response from the embassy. Will they let you into their country?

As part of my most recent reading strategy I've been reading a lot of biographies. I finished the Power Broker in early April, and started reading Isaacson's biography about Elon Musk more recently. I'd heard excellent reviews about the latter, but halfway through it, I'm sorely disappointed.

What strikes you when reading the Power Broker is the depth of research, the coherence of story and the intensity of feeling that Robert Caro has managed to put into words. None of these exist with the Musk biography. Chapters are short, out of chronological order and feel woefully under written and under researched. For example:

(Chapter 35: Marrying Talulah)
... It's actually funnier than I made it sound ...

Why not just make it sound.. funnier? I'm not saying it's easy, but its definitely something I'd have expected of Isaacson.

(Chapter 6: Canada: 1989)
... most jobs paid $5 an hour. But there was one that paid $18 an hour, (... describes job).

Did he take the job? We never find out. Presumably yes, based on the description, but it was ambiguous enough while reading it that it stood out to me.

Setting aside individual nits, the biggest disappointment is how uninteresting the story feels (despite how interesting the story actually is). When I read Jobs, I was much more motivated to find out what happens next. Here, it's as though I'm reading through an extended Wikipedia entry.

Admittedly, I am only halfway through the book, but I am skeptical that the style of writing changes significantly in the latter half of the book. Perhaps this is too harsh of a review, and my biography fatigue might be partly to blame for it, but there's definitely something missing in this book.

I haven't published anything for about 6 weeks. There are a numer of reasons for this: In March I went on a trip across the US and was "one with nature" as my brother-in-law put it. Zion was incredibly beautiful, but the days of driving and hiking didn't lend themselves well to writing.

Once I was back, I was laser-focused on finishing the Power Broker. I had to return the book by April 11th to the library, and I finished a week ahead of schedule! It is one of the greatest books I've ever read, and has changed the way I view a number of things: government, agency, power and people.

The following two weeks I was really trying to get Tailor out. My weekly goals for the last 6 weeks have inevitably included "Get Tailor Out!!" in no uncertain terms, but while I've been making consistent progress, finishing a project with complex UI is so hard.

I realized I hadn't written in 6 weeks, and so this is just a recap of why. When I asked Tom Macwright what kept him writing for so long, he said his recap posts helped a lot with consistency. This is my attempt at taking good advice.

The focus of this reading strategy is "How Big Things Get Done" - both on an individual and an organizational level. Like with my previous reading strategy, the first rule was to come up with a simple list of questions to answer:

• How hard vs. smart did people who got big things done work?
• Were most of them innately smart, or was there something else? What subsets of traits did a lot of them share?
• How did they interact with other people?
• Did they go wide or deep?
• What were values they had? What values did they share?
• What were key organizational principles to getting people to work together on large projects?
• How large/ unrealistic were the visions of big projects when they started? Did they have to tone it down, or did they just achieve it?
• What were key reasons large projects failed?

This is a fairly broad category and I don't expect to get definitive answers to everything here. Again, as before, I have a curriculum of books. This being a fairly wide topic, the books are also fairly wide (and a bit random), but the benefit of that is I've already read quite a few of them (marked with ✓)

• How Big Things Get Done
• The NASA paper on why Apollo was a success
• The Art of Doing Science and Engineering (reread You and Your Research) ✓
• Read technical plans for {insert major project here}
• Biographies/ history of people who got "big things done"
• • A Mind At Play (Claude Shannon) ✓
  • Elon Musk biography
  • Creativity Inc. ✓
  • The Power Broker
  • Read Founders (on Paypal founders)?
  • Jon Von Neumann ?
  • Masters of Doom ✓
  • Jobs ?

I like reading a lot of physical books, but I also would like to remember important details from said books. My default strategy for remembering things is to pipe them into Readwise and then Anki where I can make sure interesting pieces of information stay in my head. Unfortunately this is hard for physical books, and sometimes I want to put these pictures into Obsidian when writing recaps about what I learnt from a book. Google Photos makes this unreasonably hard (perhaps because they want to keep all your data). Every downloaded file is 10MiB which is way beyond what I need for an image with a bunch of text in it.

Here's a tiny bash script to take the zip file Google gives you and output a bunch of tiny images:

unzip Photos-001.zip -d photos -x '*.MP4'
cd photos2
parallel 'magick "{}" -auto-orient -resize "800x800>" -quality 75 -define jpeg:dct-method=float "{}.jpg"' ::: *.HEIC
rm *.HEIC

Make sure you have GNU Parallel, ImageMagick and libheic installed. If you run into issues, ask me ChatGPT.

When working in Typescript I miss the exhaustive match statements I've gotten used to in Rust. They're super useful when dealing with Enums and expansive types that you want to make sure you cover all cases for. When working on Cannon I have an enum defined for a language. Along the way I discovered a couple of nifty tricks for exhaustive case matching in Typescript. The simple way is to have an exhaustive object:

enum Language {
	Python = 'python',
	Java = 'java'
}

type LanguageMap<T> = { [language: Language]: T}

const a: LanguageMap<number> = {
	[Langauge.Python]: 0,
}

If you have an unreasonable affinity for switch statements like I do, you can do this instead:

enum Language {
	Python = 'python',
	Java = 'java'
}

export function assertUnreachable(_: never): never;
export function assertUnreachable(_: Language) {
  throw new Error('Unreachable');
}

function a(l: Language): number {
	switch(l) {
		case Language.Python:
			return 0;
		default:
			assertUnreachable(l);
	}
}

which I think is really nifty. Credit to this StackOverflow answer!

It's always been easy for me to "get through" reading. You simply skim through the page, absorb a part of the material, and fumble your way around deep understanding, instead substituting it with words that sound like intelligence.

This is obviously a terrible strategy for deeply understanding anything, and many things have recently taught me that. One example was going through Reflections on Trusting Trust recently. Ken Thompson talks about quines early on, saying:

If you have never done this, I urge you to try it on your own.

Past me would have skimmed through for an answer, but now I opened up a terminal. The best I could come up with myself after 20 minutes was

with open('main.py') as f:
	print(''.join(f.readlines()))

On researching quines after this, I discovered that I had "cheated" by reading the file. When going through this I finally understood how one could produce a quine in Python: the key was understanding that repr prints the string with quotes. Writing partially from memory now:

data = ";print('data = ' + repr(data) + data)";print('data = ' + repr(data) + data)

Anytime you do something off the beaten path in the world of software, you have one of two choices:

• reverse engineer the base concept from a couple of RFCs and a reference implementation
• find a couple of libraries that do exactly what you want, but are poorly documented

As a concrete example, I was trying to figure out how you connect to the Astro LSP locally. I started off by reading the LSP specification, but quickly got bogged down by details around how to give requests. I learn best with experimentation, so I moved on to finding a library I could use to connect to LSPs locally. I found ts-lsp-client and pylspclient, both of which are sparsely documented. The VSCode reference implementation looked way too complex. And then I realized both those libraries had tests, and the tests had a working way to connect to those LSPs!

My original goal was to connect to the Astro LSP, so sticking to the pattern above, it's time to take a deep dive into the Astro LSP test suite.

If you're an Obsidian power user, you've likely hit a wall pretty quickly with what raw Dataview queries can give you. Or you're just annoyed with how much new syntax you have to learn just to get your data out in anything but the simplest manner. If that resonates with you, and you already know javascript, I'd strongly recommend only using DataViewJS for all your queries. It's no harder than writing the queries in their custom DSL, and you can massage both the query and the view output however you like.

Some tips when working with DataView JS in Obsidian:

• dv.current() gives you the current page as represented by DataView.
• console.logs go to the Obsidian dev console (accessible with Cmd + Option + I on a Mac).
• You can access lists or tasks on the page using pageData.file.lists or pageData.file.tasks
• Inline Dataview fields show up on the list element as properties. For example, if you have a list like this - This is a log #~"some tag" [property::value], you can access property using pageData.file.lists[0].property.

The rest of it is just scripting and iterating.

A year ago I started tracking my TODOs much more systematically using the Getting Things Done system in Obsidian. It only clicked for me when I hand rolled my own version on top of Obsidian, using default tools or Notion never felt low effort and easy.

I’ve been relatively consistent with keeping track of my tasks and working on dashboards, but now that a year has finished, I have a much better sense of what works and doesn’t work for me within the system.

• Be ruthless in pruning your dashboard to exactly what you can do in a week (hint: it’s not as much as you think).
• It’s more important for me to track things I don’t want to do but have to (not always, but as a rough heuristic). My default mode is to execute on things I want to do, so I don’t need a dashboard of tasks motivating me here. I’m going to take this a step further in 2024 by really trying to make my dashboard very sparse so I can focus only on the big rocks I’m excited about.
• Have many ways to record and reflect. I have a handwritten journal, random notes I scrawl on project pages and a per day notes section. Variety makes me record more.
• Really try to do some version of a weekly review. Even if you lack the mental energy to clean up the dashboard that week, write down the vibes of the week in your weekly review. The stuff unrecorded in your notes but that lives in your memory is really powerful, and you can’t really remember those when looking back at a week months later.
• Make it easy to add new projects and be liberal with creating them (even if a lot of them are marked “someday”).

I wanted to write a full review of a lot of books I read this year, but I ran out of time. So instead, here's a quick little rating scale out of 5 🥔s. It's also in the rough order I read them this year. If anything is below 3 🥔s, definitely just read a summary. 3/4 is up to your judgement, please read every 5 🥔.

I've been working on a new DevTools experience I'm calling Tailor. I was inspired by Tailscan and wanted to understand how I'd build a clone of it as a starting point.

• The most annoying interaction problem I faced was when/ how to activate and deactivate DevTools. Tailscan does this super well, you have a button to activate/ deactivate DevTools. When you click on an element the toolbar remains but the hover behaviour is disabled. When you click anywhere outside the toolbar again you reactivate the hover behavior.
• Make the toolbar follow the cursor for a more natural feeling placement instead of making it relative to the element you place.
• When you add and remove mouseover listeners for document inside a React component, make sure you wrap the callback function you pass in inside a useCallback. Otherwise React creates new functions each time the component re-renders and you won't properly remove the event listeners.
• pointer-events: none is your best friend for the overlay/ toolbar UI you build.
• css-box-model is a great package to do math for you.

I need a place where I just want to dump tiny logs with low pressure to edit things - tiny DevLogs for different things I'm working on. Then I saw Tom Macwright's Micro section and I was inspired to start my own.

I wanted to call it "DumpTrucks" and format it as a truck, but that felt like a worse and worse idea as I tried to bring it to life. "DevLogs" doesn't capture everything I want these to be, this is more for just dev stuff. So I settled on the vanilla "logs" - lmk if you have better ideas!

I recently spent a lot of time getting feedback on different things:

• I got a lot of feedback on Advent of Distributed Systems from HackerNews and HackManhattan.
• My friend gave me really great feedback on my review for Atlas Shrugged which made it go from unreadable to ok.
• Guzey gave me some feedback on my blog after I emailed asking for it.

I'm not used to asking for feedback generally, and I didn't know how uncomfortable it made me feel until I started doing it more - but the outcome is (maybe obviously) positive!