> Workflow

 > Notes

Home

Metadata:

The first post of the blog proper. A rundown on the purpose of this subdirectory.
- Initially published on 10-14-2024.


Introductory Post

Prior to this writing, this website was divided into primary sections of content: Writings and Projects. Writings involve discussions of existing within this natural world; my experiences as an individual within social and environmental contexts. Projects involve discussions pertaining to the creation of systems while being a Computer Scientist.

This new Notes section seeks to fuse these two categories and then some. Much of what will be placed here will act as scaffolding for a given item to be published within one of the original two sections. In these cases, each post likely will represent a step of progress in completing a specific writing or project.

The term "notes" should inform the laissez-faire approach that will be taken in deciding the type of content that will be published here. This will ultimately act as a personal repository of information, some information of which may or may not be useful to an external agent. Similar to a blog, but without the vie of maximizing engagement and monetary gain. Many call this general form a digital garden.

A digital garden is basically a combination of an online notebook and a personal wikipedia. It’s your personal collection of ideas. - Danielle Messler


Workflow

In the past month, work has been put into the back-end of this website to help make my life a bit more productive and structured. The first step taken on this route is the deployment of an instance of NextCloud. The instructions on how to do this are pretty straight forward; documentation is not lacking on NextCloud's front. My project diverges by hosting the instance on a separate server and navigating Apache2's documentation to allow access to this instance from my website.

Indeed, this document is currently being written within this instance of NextCloud through the Notes app. This app uses a rich-text editor to allow a user to write their notes which is then saved within the database represented as markdown.

The code produced for this website has been self-produced; no libraries or content management systems were used to expedite the process of development. (This excludes the NextCloud instance, of course, which is hidden from public use.) This provides a good amount of experience in terms of handling the core technologies. My About page notes this as well, which then follows up by imploring that the reader not assume this to be rigidness on my part; learning a new language or framework is trivial.

The current process of publishing content within the writings or projects directories is very flexible. This is due to a lack of reliance on external libraries and content management systems. My experience in HTML, CSS, and JavaScript gives me flexibility to form the page in a manner that pleases me. There are infinite paths of customization available to me. I have noticed reproducible patterns of implementation within my web pages that can be abstracted such that I need not be worried about fumbling the markup syntax to produce invalid structure.

From NextCloud Notes to alanmckay.blog/notes

I've written how a different markup language can decrease error and expedite the development processes for the front-end of a website. This can be read in the discussion of Developing DRY Forms. Here, Embedded Ruby (ERB) is compared to HAML (HTML Abstraction Markup Language), where a preference of HAML is made due to its feature of abstracting away the need of closing tags as a means to make code easier to digest at a glance. The same sentiment can be held whilst comparing HTML to markdown.

This first entry in the notes section of this website is proof that I've made the bridge from markdown to HTML. Specifically, the bridge has been built to convert markdown into HTML that conforms to how I template HTML on my web pages. This space is surprisingly underdeveloped when it comes to PHP implementation. The tool I've ultimately chosen is phpLeague's CommonMark, which has required a lot of exploration of the code-base to figure out how to produce HTML structures that suit my needs. This is a space that has little documentation, which I intend to rectify by presenting my notes in accomplishing this goal.