The static site generator for my personal website. It was something I wrote in an evening. The code[0] isn’t the best but it’s been easy to extend as needed.

It basically takes a couple json files for configuration, and some markdown.

[0]: https://git.sr.ht/~zacbrown/zsitegen

Another anecdote - I hate slack. Indifferent to teams, but loathe slack.

I’m curious what materially changed beyond Slack complaining.

Microsoft has long bundled Lync/Skype-for-Business with Office 365. Hell it did that, I’m pretty sure, before Slack even existed.

skype for business didn't really take off as much as team now. Team spread like a cancer like nothing else before.

So if they had bundled a shitty software that would have been more OK than then bundling a software that people want to use more?

Fair enough - also lol at people downvoting. It was an honest question.

Is there a brief blurb about how this differs from Obsidian? Just curious mostly.

- Eidos has an Airtable-like table, but Obsidian does not. - Eidos and Obsidian are both file-based. - Eidos is based on SQLite, and Obsidian is based on Markdown.

Well. This sounds like it will be exciting to upgrade to.

Having watched this first hand, you won’t be treated the same. Maybe that’s a good thing, but people will assume you get to do whatever you want which, generally, shouldn’t be true.

It sets a strange precedent sometimes too if not well communicated and managed.

This blog post felt unsatisfying. I’m not sure I’ve talked to anyone in the last decade about distributed systems where:

- CAP came up

- all parties immediately agreed that CA was impossible

I still think it’s a useful model for forcing people to think about their failure modes though. Systems, largely, tend to fall into either CP or AP or be horrendously expensive.

You have to choose your trade offs.

I wish the author had expounded a little further on better options. I’ll read the paper linked, but there’d be more punch with more inline content.

Two options from my own experience:

- Allocate a regular time to read the papers/articles. Accept that the list may forever grow. Bonus points if you tag the content going in so that you can prioritize a tag/topic to make progress in a space you like.

- Expire out old content you aren’t going to get to. I triage my list periodically, sorted by oldest. If I don’t remember adding it or don’t feel interested based on a skim of title and intro, it gets deleted.

I pulled these from how I treat feature/bug backlogs at work. If it’s older than 90 days since any activity and a feature - delete. If it’s a bug, it gets archived (in case of repro steps needed).

I empathize with this. I’m similar to your son - no amount of practice ever made me faster or “more prepared”.

I’ve learned to accept it and manage expectations with people.

One thing I discovered about myself was for many things I have a “gut feel” that I trust unquestioningly. I might not be able to explain why something is wrong/right, but I know it is. Given a bit of time, I can explain it sufficiently and convincingly.

I’ve never had the gift of quick answers with explanations. I’m okay with that.

The time I the most Rust was the couple of years before Rust's async/await settled. I worked on what is now a large code base that processes a lot of data quickly.

It was multi-threaded but no async/await. When I tried to start converting things over, it was really painful. I have no idea where it landed, but I remember coming away from it thinking that I'd prefer to just not deal with the async code in its current state.

I mostly write Go now and haven't had to think about this. Sounds like it's still painful.