Testing the new notes plugin #
2023/08/16 #
-
-
Another notes test... #
-
I quietly announced the website's new Notes feature on Twitter earlier. So what it is?
I've noticed recently that
It's not just me, readers of the newsletter commented about it recently too. It had crossed my mind but the feedback is really useful. Thanks @HackHackHack!
The notes feature is intended as a sort of working space where it's as easy to add content as the linkblog, but without the contraint of having to associate a link to a post item.
The other big difference is that notes are chronologically ordered rather than reverse chronologically ordered. The idea being that as you read through them you get a view on what I was thinking about as I went through my day.
That's in contrast to the linkblog which lists the last link posted at the top of the page. In a sense though both linkblogs and notes are reverse chronological at the date level. They both display the very last day at the top of the page. However they differ in ordering at the item level. Notes are chrono, links are reverse chrono at the item level. That probably makes it sound very complicated, but it's quite obvious once you start reading them.
I expect what might happen as I use the notes feature, that linkblog links get shorter, and I'm able to write down thoughts more easily. That will hopefully lead to more blog posts.
Let's wait and see though, it could also just turn out to be extra overhead, and not worth the effort. #
-
There are all sorts of very subtle things to consider, that I'm discovering as I write.
For example, how do I name the markdown files now that there isn't a url donain, which I use in linkblog link filenames.
Also should posts have titles? Probably not. One of the things that is nice about linkblog links is that you don't need to think about titles. It's suprising how much friction titles introduce. #
-
One of the things at the back of my mind is the issues I've been facing with the number of files in the repo. There are so many files that my code editor is not able to process changes, often getting stuck, which causes no end of problems. It also takes 10 times longer to post items than it should. At times that ammounts to hours when it really should take minutes.
I'm finding the ease of posting notes very useful. I've already posted 3 notes! And I think the posting process could be improved further too. #
-
What are notes titles like?
Just testing what a title looks like in a note. I expect it will look weird because of the bullets on each item. In fact the bullets are likely going to make some of the other posts look odd too.I'll find out tomorrow when today's notes get merged. I setup the same workflow as for the linkblog. Every evening the latest notes get merged into the repo main branch via an automatically created PR, and the site then gets rebuilt. That saves on build minutes, but it also avoids issues with RSS feed generation. That can get tricky when you make edits. #
-
I've added an RSS feed for new notes that get added. It's listed on the feeds page.
The cool thing about my static site generator is that it's at the point now where adding new features is quite easy. Once I had developed the main feature, adding archive pages, a tagcloud page and an RSS feed was as easy as copying a few markdown templates and updating some frontmatter variables.
Also if any of you were subscribed to the feeds suscription list opml then you wouldn't even have had to update your RSS reader. I actually changed the urls of some of the existing feeds. They changed when I rewrite all my RSS generation code a few weeks back. In had redirects setup so notmally speaking there shouldn't have been any breakages. Sorry if there were though. Kind if unnavoidable.
I'd be interested to hear from anyboby that is subscribed to the opml file, as unlikely as it might be, because unfortunetly very few readers support this excellent feature. #
-
Improving Github Actions build times
Since I keep running out of Github build minutes I was thinking about ways to optimise the build. Looking at the github action logs, the obvious place that can be improved is getting nodejs installed and setup. The entire build/deploy/backup workflow takes approx 7 minutes. Installing nodejs takes around 3 minutes, and because I run seperate jobs for build, deploy and backup, I actually end up installing nodejs twice.My first thought was that maybe there was a way to create a custom runner. i.e. instead of running the stock ubuntu image, create an image (docker?) with nodejs and perhaps all the modules I use in the static site generator, then use that to run the build. After doing about 30 minutes of googling it seems that's only possible if you are self hosting your own runners. I might be wrong about this, I'll beed to do some more research. Currently I'm stuck using hosted Github runners.
I noticed while searching that there are some caching actions that enable you to cache build artifacts between runs. The most popular of which appears to be cache. I'm already using setup-node which uses the cache action. There appear to be some caching options I could try, but doesn't seem like caching will improve things much because as far as I can tell it's already downloading a pre built nodejs version. I could be wrong.
Ideally I want the build to be under a couple of minutes. The actual website build of 17000 markdown files only takes around 45 seconds, so it's a bit ridiculous that the whole build and deploy takes 7 minutes. There has to be a way to optimise. #