![[Home]](/img/sr_logo.jpg){kind=logo}
[2023-07-13 16:33]
Tags: BlogPublished OddmuseWiki MyCommentary EmacsStuff OddmuseWiki SocialOutreach PublishingOnline Linux notes
Kensanata's post where he talks about troubleshooting some issues with oddmuse made me realise that there are still a tonne of things that I am still neglecting to think about with respect to 'running a wiki' or even a VPS. Like, the considerations of a system-admin and really understanding the framework running this site. Maybe not a good thing to admit, but I do not even have this wiki on a backup system yet.
I will admit, this post was initially different and was about thoughts of jumping back into a static html website, despite my earlier grand announcement at 2023-07-08 A summary of my journey to Oddmuse. At the end of the day, a static site is just html, and there is no engine or framework to worry about. Well, the html pages could in theory be generated by a framework of choice - but one need not dive into the guts of the framework itself.
In the course of thinking, I've re-realised this is a journey and one cannot necessarily connect all the dots in a linear fashion. The important thing is to (stay) be curious and not shy away from challenges. A re-read of kensanata's post indicated made me think that I should pay attention to the commands, comments and logs that he is kind enough to share, and use that as a starting point to enhance my own understanding. As James Clear mentions in his book Atomic Habits, one should aim to improve incrementally, and consistently in manageable chunks - nothing is 'impossible' to learn with some effort. A re-read of my own post reminded me of the reasons I enjoy the idea of an unstructured website and wiki, and so - the journey continues.. here.
I realised that I could edit static sites like those of Hugo on the go - by editing the source markdown file itself using applications like Working Copy on iOS, and having a CI/CD mechanism in place to re-render the static site. Well, it is still not the same as a wiki - but hey, it is probably better than the web editing interface of Oddmuse.
However, what if one would 'like' to dive into the guts of a framework if ever required? While looking at adopting a software or choosing a framework - it is worth considering the languages that one is interested in learning and comfortable with. This becomes even more relevant in the self-hosting route. The next step to look at is the contrast between opportunity and exposure.
For example, Python is a language that I do use almost everyday, and one that I could certainly get better at, and efforts would see results beyond personal satifaction, i.e. career growth. There are great starter options like Makesite for the purpose of a simple blog. Learning Golang would not be entirely useless considering that any serious or new machine learning algorithm would be re-written in a more performant C or Go at some point. On the other hand, using Perl, and configuring Apache are things that I typically never get to do at work. However, choosing this does not mean that the knowledge gained would never be of use.
A supporting example for the indirect benefits is that the little exposure that I did gain while experimentally setting up a LAMP stack on a Linode VPS, along with other services like an IRC bouncer, RSS feed reading service and so on were a tremendous help when I had to on one occassion setup an Apache server with a reverse proxy to a Shiny (R) server, at work. This extends into the cascading benefits of an increased comfort with the command line, remote servers, reading application logs and so on (aided to no small extent with Emacs).
Though I would struggle at the moment to explain the exact technical background or the nuances of configuring an Apache server, a cognizance at a higher level is knowledge that can be built upon at an opportune moment - and is still better than starting from scratch. I mean something like: the main idea of Apache is that it is is a reliable webserver application which is used to serve 'content'; it can be programmed to perform a bunch of operations - like running a script before loading a page from a particular URL, or serving a CGI script, and this extends to hooking into a load balancer and more. An Apache stack as a part of a LAMP stack with a basic firewall can be setup on a VPS fairly quickly, and many documents exist with the steps on the likes of Digital Ocean and Linode. Once a single site and working configuration is up - it becomes easy to use that and create a new site. There are other options to Apache, like Nginx, and the latter is indicated to be more performant in the cases of managing processes with child workers. Caddy is another recent entrant in the web server suite.
The above, while being a gross simplification, is better than starting at 'WTH is Apache?'. For example, there is some value in taking in pointers from kensanata's article about troubleshooting a process in general, and gradually learn what words like 'CGI script' and 'Mojolicious' mean; instead of being intimidated. It would be even better to document it.
In my current field of MLOps - a topic or role that could be defined differently in organisations depending on a variety of factors - the above tidbits of knowledge and exposure tend to be useful in solving problems and also have a strange tendency to 'fit' into place when you encounter it in some architecture diagram. Knowledge tends to explode a bit more when it is connected to more knowledge - as opposed to going too deep in one particular direction alone. A wider exposure facilitates connections. A note taking system, and a wiki facilitate revisiting these connections.
All this being said, I am now wondering about the dangers of 'a little knowledge'. As a self-taught programmer - it is easy to simplify things down to a point that they miss important nuances, and then ride on that (close to) forever. To avoid this, one should be aware of what does not know, which may not always be the case. I think this is where a community or a mentor can really help. Therefore, it is really important to have atleast an (evolving) sense of, if not a some principles to review the impact of technical debt. Mental models as a concept talks about MentalModels which might help in this regard. Even so, the practical application of this strategy appears to be a very 'dynamic' activity, one that is based on a constant cognizance and evaluation; perhaps a dance of sorts; especially considering that it is impossible to know 'everything'.