public-notes

There's a lot of truth here. But also. But also, LLMs are incredibly powerful and capable tools at discovering and finding what the architecture of things is. They have amazing abilities to analyze huge code bases & to build documents and diagrams to map out the system. They can answer all manners of questions, to let us probe in. I'm looking for good links here. I know I have run across some good stuff before. But uhh I guess this piece that I just found introduces the idea well enough. https://blog.promptlayer.com/llm-architecture-diagrams-a-pra... And you can see an example in the ever excellent @simonw's review of prompts in copilot. At the end, they briefly look at testing, and it's a huge part of the code base. They ask Gemini for a summary and it spits out a beautiful massive document on how copilot testing works! https://simonwill

I use GitHub Issues threads for this and it works amazingly well. Any task I'm working on has a GitHub issue - in a public repo for my open source work, or a private repo for other tasks (including personal research). As I figure things out, I add comments. These might have copy pasted fragments of code, links to things I found useful, quoted chunks of text, screenshots or references to other issues. I often end up with dozens of comments on an issue, all from me. They provide a detailed record of my process and also mean that if I get interrupted or switch to something else I can quickly pick up where I left off. Here's a public example of one of my more involved research threads: https://github.com/simonw/public-notes/issues/1 I also create a new issue every day to plan the work I intend to get done and keep random notes in. I wrote abo

I've been using GitHub Issues as a coding journal for a few years now and found it to work incredibly well. I work on most of my projects in public repositories and often end up posting hundreds of issues with thousands of accumulated comments across them all. I also have private repos which I use just for issue threads for coding journal mode entries that I'm not ready to share. Occasionally I'll take one of those private issues and make it public later on, for example this one: https://github.com/simonw/public-notes/issues/1

I've been trying to develop the habit of reading the documentation from cover to cover of any tool that I've been using for more than a year or so. I find that reading all of the documentation for a tool you've just started using isn't as valuable: if you haven't gained any experience with it yet, a lot of what you read will fail to stick. Once you have a few months (or years) of experience under your belt doing a thorough review of the documentation can massively increase your abilities with the tool. Here are some notes I made when I finally spent the time to read through every page of the Jinja documentation for example: https://github.com/simonw/public-notes/issues/4

I've been trying to figure out options for 100% robust protection against CSRF for late 2022 (without using csrftokens in requests, which are tried and tested but are a little bit cludgy to build and use). It's proving surprisingly difficult to research. Here are my notes so far: https://github.com/simonw/public-notes/issues/2 SameSite=Lax is almost but not quite the answer I'm looking for, for a couple of reasons: - It doesn't protect against attacks from subdomains, since they can trigger requests that use existing Lax cookies. This is a problem because I can never be sure that a future decision won't be made to CNAME helpdesk.mysite.com over to some third party vendor who might themselves have security holes that enable XSS attacks to run against my domain - SameSite cookie support is at 95.75% global usage. That's not 100% yet. Where