Automatic Publication Lists for Zola

New name, new tricks, new templates. Same old list.

Reading time: about 6 minutes (1237 words).
Banner

It's been a while since I last ranted about publication lists, so let's go ahead and see if we can't re-solve this non-issue in a different context. The papers section of this blog has always been manually updated. Back in the Hakyll days there was an attempt to rectify this, but it caused no end of frustration. Gutenberg's system didn't really allow for an automated process either, so the whole idea had been shelved indefinitely.

Accessing partially recursive data structures in Elm

A comment on commenting systems, implementation discussion for your discussions on implementations.

Reading time: about 11 minutes (2295 words).
Banner

So you've read over the Recursive Type Aliases hints in the Elm compiler documentation and that all seems straightforward. Mainly because it is, but unfortunately simple examples like this are seldom actually useful when you need to actually do something.

In my last post, I talked about generating a nested structure of comments and any replies pulled from a database at the backend of oration, so that this data could be exposed via an API in JSON format. Now, I'd like to continue the conversation at the frontend—hopefully answering the question: how do we invoke a recursive type and do some work with one?

Nesting Structures from Flat Indexes

I don't always use recursion; but when I do, I don't always use recursion.

Reading time: about 4 minutes (961 words).
Banner

SQL databases are still one of the best ways of storing relational data, but sometimes you hit a wall transferring your representation to or from a table based layout.

Say we have a table full of Foos, where some Foos may have other Foo parents. This can easily be represented in a table with some unique primary key id, a secondary key parent, which joins to the parent's id, and whatever data Foo may hold. Retrieving this table into a rust data structure, we'd find ourselves with something like Vec<Foo>, where Foo is defined as

struct Foo {
    id: i32,
    parent: Option<i32>,
    data: String,
}

This isn't really the best way to represent these data though, what you really want is more akin to

struct Bar {
    id: i32,
    data: String,
    children: Vec<Bar>,
}