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.

Recently completed Factorio: Space Age with my weekend gaming group . This is a group who have been playing games together for many years, and we tend to rotate through various games.

While on Nauvis, two of our group kept biters in check, while one worked on the main factory parts and I often worked on resources. Once we were ready to expand to space, we each took a planet to be in charge of. I was in charge of Vulcanus which we tried to setup reasonably quickly, due to a few achievements we were also trying to go for this run.

For quite a while, nearly every Saturday, I have a core group that plays games together. Two of the core games that brought us together are Natural Selection (2002) and Guild Wars (2005) though our regular weekend gaming didn’t start till sometime later after that. I am uncertain when we started doing regular gaming together since we previously used IRC for collaboration, but our shared calendar’s oldest entry is 2018-11-25.

One of the challenges of the group, is our distributed timezones with one in the United States, one in Canada, one in the United Kingdom, and one in Japan. Our current game time is pinned to one member’s daughter’s bed time. This mostly works due to our UK member being fine with an all nighter.