Last year, I switched to vscode and as part of that, have become interested in how the language server protocol works. As part of my worklog project, I’ve been building various tools and scripts around hugo to manage my notes and day to day tasks, and building a language server to handle some of the formatting tasks may be an interesting way to implement some of the required functionality.

This week I gave a presentation at LINE Developer Meetup #47 in Fukuoka entitled Automating deployments from GitHub using SaltStack .

Partly inspired by apps such as NotePlan or the friends project, I’m intrigued by the idea of using Markdown as a database. The popularity of static site generators such as hugo and jekyll already forgo using a database by having the main content as a Markdown document with metadata contained in yaml frontmatter. My own worklog experiment is built op top of jekyll with some scripts to parse out the frontmatter. I suppose the biggest worry would be dealing with merge conflicts depending on if something like iCloud sync was used or building on top of git

I’m still debating replacing Jekyll with something else but I’m not super enthusiastic about writing a blog system. One frustration with many software packages is when it does almost everything you want except for a small bit. Typically your only recourse is to build the entire thing from scratch. Though I’m not very fond of Liquid templates since I’m more used to Django Templates , I think the biggest issue I have with Jekyll is some of the special cases particularly with posts being special collections but regular pages are unable to take advantage of tags without workarounds. I suppose any frustrations regarding atom feeds I could probably solve by building the feed myself using vanilla Jekyll like I used to do.

In general, I’ve been mostly happy with Jekyll , it handles most of my basic requirements but whenever it comes to doing more customizing various index pages or generating some automatic indexes, the GitHub Pages version gets a little more annoying to work with. I could easily self-host which would allow me more flexibility to automatically generate more parts or hook in additional plugins, but if I were to self host, then I’m not necessarily limited to Jekyll. I could check out something like Pelican or Lektor or perhaps roll my own. I quite like the simplicity of writing blog posts in plain markdown with Jekyll, it’s just all the other customization that gets a bit annoying.

Taking advantage of cron and the rmtrash tool from homebrew, I often setup several simple cron entries to automatically move old files to Trash

@hourly        find ~/Downloads -mindepth 1 -maxdepth 1 -mtime +7d -exec /usr/local/bin/rmtrash '{}' \;

Currently I’m using Ansible at work, but I would MUCH rather be using Salt . A discussion on the Salt mailing list reminded me of this again, so I thought I would write down a few notes regarding why I would rather be using Salt (and why I not-so-secretly use Salt for development)

Why have both roles and playbooks?

Roles and Playbooks are somewhat similar, and feel like they have some overlap in usage, so at times it can be quite frustrating to have things that are so similar but different.

One app I’ve been really enjoying recently is Numerous . It’s quite nice for tracking a lot of different stats. For example, checking the weather in Fukuoka

Or checking how many lessons I have due in WaniKani

Or checking to see if the USD/JPY conversion is in my favor or not.

After reading a post on the WaniKani forums about using Google docs for graphing study data, I decided to play around with some charts for myself

Review Queue

Progress