I remember a time when there were whole libraries dedicated to clipboard management.

Turns out in browsers released after ~2020 you can do it with one line:

navigator.clipboard.writeText(text).then(console.log).catch(console.error);

Some caveats:

• this only works in a secure context (which mostly means either “a site served over HTTPS” or localhost).
• the user needs to have interacted with the page before you can actually call the method.
• this was only added to certain browsers in 2020, so it's new enough that it might cause problems if your constituents have older devices or don't update often.

Usually when I do this I'm implementing something like a “copy to clipboard” button:

<span id='copy-target'>This text is going into a clipboard</span>
<button onclick='copyToClipboard("copy-target")'>Copy</button>
<script>
    const copyToClipboard = (target) => {
        const element = document.getElementById(target);
        const value = element?.innerText
        if (value) {
            navigator.clipboard.writeText(value).then(console.log).catch(console.error);
        }
    }
</script>

I was working on a custom element today that replaces a textarea with CodeMirror in the UI while still updating the textarea in the background so that it can be submitted in a form. I ran across a wild footgun in custom elements.

StackOverflow eventually provided the solution. There's a solution on stack overflow, but Danny Engleman wrote up a more thorough explanation.

When you're creating a custom element you do most of your setup in a method called connectedCallback. Here you can read the content of the custom element, replace it with different elements, set up callback handlers, etc.

Or so I thought.

You can read the attributes of the node just fine, but if you try to read its contents you'll find they aren't there. The reason is that the connectedCallback fires when the opening tag of the custom element is parsed, so the contents aren't in the DOM yet.

The solution is breathtakingly simple and silly: call setTimeout to defer initialization until after the DOM has been fully parsed.

export class MyCustomElement extends HTMLElement {
  initialize () {
    // Fancy custom element stuff goes here; you can safely access
    // `this.innerHTML` and stuff.
  }

  connectedCallback() {
    // Be sure to use an arrow function here or 'this' will be
    // messed up in `initialize.
    setTimeout(() => this.initialize(), 0)
  }
}

I've known for a while that uv can run Python scripts that declare inline dependencies.

I learned today that you can also use uv to manage those dependencies.

If you have a file foo.py:

#!/usr/bin/env -S uv run

print("your code here")

you can run uv add --script foo.py numpy and it becomes:

#!/usr/bin/env -S uv run
# /// script
# requires-python = ">=3.12"
# dependencies = [
#     "numpy",
# ]
# ///

print("your code here")

This is obviously nice if, like me, you have trouble remembering the exact syntax for declaring the inline dependencies, but it also means uv does things like dependency resolution so you don't have to manage your script's dependencies by hand.

You can add --script to:

• uv add and uv remove to add and remove dependencies
• uv lock and uv sync to create and synchronize with the script's lock file
• uv tree to print the script's transitive dependencies
• uv export to export the script's dependencies to another format, such as requirements.txt

(via epistasis on HN)

Semantic versioning is difficult. Not everyone has the same idea of what “breaking change” means, and depending on your language and tooling “breaking” changes can sneak in despite your best efforts.

One possible mitigation is to record when you resolved your dependencies and ignore anything published after that date. It's crude, and relies on package dependencies not monkeying with stuff that's already been published, but it's easy to understand and you can do it with uv.

It's documented here.

Put a date in your pyproject.toml file and subsequent invocations of uv will ignore anything published after the cutoff:

[tool.uv]
exclude-newer = "2023-10-16T00:00:00Z"

You can also use it in the “inline metadata” format for scripting! From the uv docs:

# /// script
# dependencies = [
#   "requests",
# ]
# [tool.uv]
# exclude-newer = "2023-10-16T00:00:00Z"
# ///

import requests

print(requests.__version__)

This use case seems particularly valuable: if I write a quick script I probably care more about it not breaking than I care about it getting updated dependencies. It's nice that uv offers a way to keep code running rather than forcing me to update it or throw it out.

I had to update a Django service to use S3 instead of local file storage recently. Here's how I set up Minio (a self-hostable S3-compatible data store) for local development.

I use Docker Compose (well, Finch Compose, but same difference) to run local versions of Postgres and S3.

Here's the docker-compose.yaml file for Minio:

services:
  minio:
    image: minio/minio
    ports:
      - "64040:9000" # API port
      - "64041:9001" # Web dashboard port
    volumes:
      - minio_data:/data
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin
    command: server /data --console-address ":9001"

volumes:
  minio_data:

Note that:

• We're setting a default username and password for local development. Obviously use proper secrets management for a more serious environment.
• We're re-mapping the service's ports to a random high port since other services sometimes try to bind 9000 or 9001.

Once you've docker compose up'd this, you can log in to the admin console at localhost:64041 and create your development bucket and access keys.

In your application you'll need to configure:

• An S3 url:
  • use http://127.0.0.1:64040 for running natively or
  • http://minio:9000 if you're in a different Docker Compose container
• An S3 region: use us-east-1
• An S3 bucket name: use whatever you created via the admin
• An access key and secret key: use the keys you created via the admin

This should also work for developing against S3 compatible services like:

• Backblaze B2
• Cloudflare R2
• Digital Ocean Spaces
• Oracle Cloud
• Scaleway Object Storage

etc.

I was checking out the Model Context Protocol, a spec from Anthropic that lets you expose external programs to an LLM, and discovered that you can extend the Claude desktop app in this way. There are a bunch of enterprisey tools (and you can write your own, more interesting stuff), but out-of-the box you can enable URL-fetching, which lets you grab and process arbitrary information with Claude.

To enable the plugin,

1. Install the Claude desktop app.
2. Enable MCP under “Settings” > “Developer” > “Edit Config”
3. Add details about the MCP plugins you want in the indicated file.

For fetch, you'd add:

{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
        "args": [
          "mcp-server-fetch"
        ]
    }
  }
}

Anthropic has more docs on using MCP plugins from the desktop app, and a list of built-in plugins that you can set up with minimal effort.

I think there are some exciting possibilities here! I don't think it should be too hard to give the model access to reference material, searchable history—basically retrieval augmented generation but for small, bespoke uses that wouldn't warrant the effort of custom-building an RAG system.

Of course, you're sending all of that off to Anthropic, so it would be particularly interesting to find a system that can do this with a self-hosted LLM, where the privacy and power concerns aren't as severe.

On a recent project I found myself needing one classic form-and-template style page in an otherwise API-driven project. I could, of course, just do it with a regular view function, but I had a bunch of authentication and suchlike set up for DRF APIViews.

Turns out it's actually pretty easy to make an APIView kick it oldschool!

from rest_framework.parsers import FormParser
from rest_framework.renderers import TemplateHTMLRenderer
from rest_framework.response import Response
from rest_framework.views import APIView


class OldSchoolView(APIView):
    parser_classes = [FormParser]
    renderer_classes = [TemplateHTMLRenderer]
    template_name = "path/to/a/template.html"

    def get(self, request):
        context = {}
        # do regular view stuff here
        return Response(context)

    def post(self, request):
        formdata = request.data.dict()
        # do regular view stuff here
        return Response()  # or redirect; whatever's appropriate

The indicated template gets rendered with the context you pass to the Response.

I think you could write a view that simultaneously supports HTML and JSON with content negotiation, but it ended up being more trouble that it was worth in my case.