api-playground VS til

GitLab team member here.

Maybe you can re-use the script I shared in this comment [0] to query the GitLab REST API to generate an index. I'm a fan of using the API programmatically, and tend to avoid git checkout/grep/etc. inside CI/CD pipelines (works too, everyone is free to choose their way).

Yet again, I love API challenges, so I've created a new script which parses a defined markdown footer for Tags and Due date, and generates an ordered index by due date. I did not know which format you are using, so I made up my own, see the MR description [1] and docs [2].

The script lives in [3] and is a mix of fetching files, parsing content with regex, and generating the index + creating a commit to upload automatically.

A demo overview is shown in [4] with the generated index.md, ordered by due date and linking the files by parsed heading title, file paths, and tags.

Hope it helps, feel free to repurpose, or ping me for questions on the GitLab community forum [5]. My Python code is a little rusty, I am slowly adopting all the 3.x design patterns after many years with 2.x.

I might follow your idea with notes and custom footer parsing. That's a really nifty idea, and helps solve my own chaos :-)

[0] https://news.ycombinator.com/item?id=32155848

[1] https://gitlab.com/dnsmichi/api-playground/-/merge_requests/...

[2] https://gitlab.com/dnsmichi/api-playground/-/tree/main/pytho...

[3] https://gitlab.com/dnsmichi/api-playground/-/tree/main/pytho...

[4] https://gitlab.com/dnsmichi/api-playground/-/tree/main/demo/...

[5] https://forum.gitlab.com/u/dnsmichi/summary

Some people create single note for each code example, like for example this TIL a repo https://github.com/jbranchaud/til`

That's more like it. This backs up the decision to add a B-Tree index for the created_at column in production. As I mentioned at the beginning of the post, adding an index like this in any production setting, but especially for a table of this size, it is important to do so concurrently and to monitor your app's health metrics during the process.

State machines are hierarchical. They can be made up of simple and composite states. Composite states have sub-states nested within them.

In all the time that I've been building and maintaining Rails apps, I've somehow never noticed that ActiveRecord attributes backed by columns with default values are nil on create.

Dump them in a github repo (like this)