Now that just made it into debian trixie , it has become easier to install it everywhere. I have recently been updating some of my dev environment, and have started using it with my existing salt configuration to make it easier while testing.

On my phone and tablet, I typically use safari as a default, always in private mode, and I use Vivaldi for a few sites I want to keep a persistent session. I will periodically do a “Close all Tabs” for my browser and save links to something like Raindrop. On my desktop I currently use Vivaldi mostly like normal, though I do miss Firefox Multi-Account Containers for separating things. Somewhat inspired by Firefox Multi-Account Containers , I have long brainstormed about some browser ideas, even if they’re not super original.

If we understand what files git rebase creates, then we can manually create our own rebase plan.

# Lets check out a branch to work with
git checkout origin/main demo-branch
# and kick off a rebase against root
git rebase -i --root

I have never had a beer. I have never had a glass of wine. I will often joke that as an computer science major, I was busy studying and never attended parties so I just never started. At first, it was not not any kind of specific decision and I have no religious reason for abstaining, I just never started. Over time I made a more conscious decision that I did not have a compelling reason to start and just never did.

I have been using salt for quite a while (oldest commit in my personal salt states repo is 2010), but have usually taken the old approach to distributing modules. By setting the file_roots you can automatically sync all your modules with the saltutil.sync_all command.

file_roots:
  base:
    - /srv/salt
    - /srv/salt-kafka
    - /srv/salt-forgejo

With our file_roots defined, our plugin repo looks like this

tree /srv/salt-kafka
├── LICENSE
├── README.md
└── _engines
    └── kafka_consumer.py

This is useful, but for maintainability, I finally sat down to look at how to package things up more properly.

As part of my Markdown Virtual Table project, when running the development runserver , I occasionally want to run some code when we update a file.

There are two signals that we can use for this, that are not well documented in Django itself:

from django.utils.autoreload import autoreload_started, file_changed

These are mostly used internally with the development runserver.

autoreload_started

The first half of this is used to register our file watches. We can find some of these examples in Django itself.

I have been continuing with my virtual table implementation, though taking a short break to do some more integration on the Django side.

I have an ideas site that I use as a kind of wiki to keep track of various ideas.

# the default model I'm using from my virtual table integration
class FrontmatterModel(models.Model):
    inode = models.PositiveIntegerField(primary_key=True, editable=False)
    path = models.FilePathField(unique=True, editable=False)
    slug = models.SlugField()

    content = models.TextField()
    excerpt = models.TextField(blank=True)

    metadata = models.JSONField()

    class Meta:
        abstract = True

# Custom model for my idea object itself
# These also exist in the `metadata` json frontmatter, but putting them here
# makes them nicer to deal with from Django
class Idea(FrontmatterModel):
    title = models.CharField(max_length=128)

    status = models.ForeignKey(Status, on_delete=models.SET_NULL, null=True, db_column="dir")

    homepage = models.URLField(blank=True)
    repository = models.URLField(blank=True)
    focus = models.BooleanField(default=False)
    date = models.DateTimeField(default=timezone.now)

    class Meta:
        required_db_vendor = "markdowndb"
        managed = False

The model ultimately gets sent to the virtual table backend with a statement that looks like this

I have been continuing my earlier virtual table prototype and it is slowly coming along. I uploaded a version to codeberg while I was debugging python packaging. I do not have it quite working right, but I think I will be using setuptools-rust for now (pr ).

This post is partly to help document what I have discovered over time so will not be complete code examples in every case. In the future I will be uploading the project to Codeberg and later to PyPi.

Most of my rust code is likely not great, so would appreciate a mentor!

I wanted to have some drag and drop web components that I could use with my django apps. I am planning on using them in another of my many todo/scheduling prototypes. Basing heavily on the api docs for drag and drop, I start with some basic components.

I start with my <drag-source> component that I will use to wrap anything I want draggable.

class DragSource extends HTMLElement {
  constructor() {
    super();
    // I use a random ID here to make something quick/simple but in a real version
    // I should probably only set this if not already set.
    this.id = Math.random();
  }

  dragStart(e) {
    e.dataTransfer.setData("text/plain", e.target.id);
    e.dataTransfer.dropEffect = "move";
    setTimeout(() => {
      e.target.classList.add("hide");
    }, 0);
  }

  dragEnd(e) {
    e.target.classList.remove("hide");
  }

  connectedCallback() {
    this.addEventListener("dragstart", this.dragStart);
    this.addEventListener("dragend", this.dragEnd);
  }
}
customElements.define("drag-source", DragSource);

Next, I create a container that I will use to drop onto.

Sqlite has support for virtual tables which can be used for external datasources. There is an example csv data source that allows you to query a csv file as if it was a regular table.

.load ./csv
CREATE VIRTUAL TABLE temp.csv USING csv(filename=FILENAME);
SELECT * FROM csv;

I do not really want to write C for this, but I found the rusqlite project which allows writing a loadable_extension that provides virtual tables. Using their vtablog example (slightly modified) I was able to test from sqlite with a rust module.