| name | explain-diff-html |
|---|---|
| description | Use when the user asks for a rich explanation of a code change, diff, branch, or PR. Produces HTML output. |
Please make me a rich, interactive explanation of the specified code change.
It should have these sections:
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
| "use client"; | |
| /* eslint-disable @next/next/no-img-element */ | |
| import Link from "next/link"; | |
| import { useState, useEffect } from 'react'; | |
| import { | |
| AppBskyFeedDefs, | |
| AppBskyFeedPost, | |
| type AppBskyFeedGetPostThread, | |
| } from "@atproto/api"; |
| // 3D Dom viewer, copy-paste this into your console to visualise the DOM as a stack of solid blocks. | |
| // You can also minify and save it as a bookmarklet (https://www.freecodecamp.org/news/what-are-bookmarklets/) | |
| (() => { | |
| const SHOW_SIDES = false; // color sides of DOM nodes? | |
| const COLOR_SURFACE = true; // color tops of DOM nodes? | |
| const COLOR_RANDOM = false; // randomise color? | |
| const COLOR_HUE = 190; // hue in HSL (https://hslpicker.com) | |
| const MAX_ROTATION = 180; // set to 360 to rotate all the way round | |
| const THICKNESS = 20; // thickness of layers | |
| const DISTANCE = 10000; // ยฏ\\_(ใ)_/ยฏ |
| -- This function is designed to duplicate all live INSERTS/UPDATES/DELETES from one table (referred to as "source_table_name" | |
| -- to a second partitioned table (referred to as "destination_table_name"). The function should be set to trigger after insert/ | |
| -- update/delete on the source table. | |
| -- This function is designed to be leveraged for partitioned table migration through this method: | |
| -- 1) Create an empty partitioned copy of the "source_table_name". Alter primary key as necessary, as partitioned Postgres | |
| -- tables do not support unique/primary keys not included in the partition key. | |
| -- 2) Create the following function, and attach it as a trigger to "source_table_name". At this point, incoming new DML is | |
| -- being copied successfully to the partitioned table, so only historical data will need to be backfilled. | |
| -- 3) Target rows in "source_table_name" with an updated_at value BEFORE the trigger was attached, and backfill them into |
| # Recommended Celery Django settings for reliability: | |
| # (use `app.config_from_object('django.conf:settings', namespace='CELERY')` | |
| # in proj/celery.py module) | |
| from decouple import config # use python-decouple: https://github.com/HBNetwork/python-decouple | |
| # Prefer RabbitMQ over Redis for Broker, | |
| # mainly because RabbitMQ doesn't need visibility timeout. See: | |
| # https://blog.daftcode.pl/working-with-asynchronous-celery-tasks-lessons-learned-32bb7495586b | |
| # https://engineering.instawork.com/celery-eta-tasks-demystified-424b836e4e94 |
| import functools | |
| from django.conf import settings | |
| from django.db import transaction, utils | |
| def durable(func): | |
| """ | |
| Decorator to ensure that a function is not being called within an atomic block. |
| package main | |
| import ( | |
| "encoding/json" | |
| "net/http" | |
| ) | |
| func main() {} | |
| func healthcheckHandlerEncoder(w http.ResponseWriter, r *http.Request) { |
This is a compiled list of falsehoods programmers tend to believe about working with time.
Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
This is not an exhaustive list of all interfaces in Go's standard library.
I only list those I think are important.
Interfaces defined in frequently used packages (like io, fmt) are included.
Interfaces that have significant importance are also included.
All of the following information is based on go version go1.8.3 darwin/amd64.