About
--TODO -
-diff --git a/output/about.html b/output/about.html deleted file mode 100644 index 526f01b..0000000 --- a/output/about.html +++ /dev/null @@ -1,240 +0,0 @@ - - - -
- - - --TODO -
-At times, I find myself being able to digest material more quickly and efficiently, and so I thought to myself as to what the probable cause of this was. The answer transpired to be the inculcating of reading in my daily routine. As humans, we are constantly surrounded with information, some are noisy, some are useful. We can choose to filter out noisy information by limiting exposure of their avenues, however the topic I wanted to briefly touch upon is what are the (cognitive and non-cognitive) benefits of increasing the intake of useful information through the medium of reading?
The brain is a muscle, in order to keep any muscle strong and healthy, it needs stimulation and attention. Thus, reading is an excellent way of ensuring the brain is fit and healthy.
A well written novel or informative book can go a long way in making you forget about the worries of the world.
Reading will always fill your head with new information.
A plethora of genres can keep anyone entertained!
Being exposed to different writing styles allows you to be influenced to obtaining your own unique writing style.
diff --git a/output/blogs/2025/08/hilberts.hotel.html b/output/blogs/2025/08/hilberts.hotel.html index 2ef7546..174a4c6 100644 --- a/output/blogs/2025/08/hilberts.hotel.html +++ b/output/blogs/2025/08/hilberts.hotel.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +I saw a few websites that used marginal notes on the right side of the screen like this one, so I decided to try and implement this feature in this wesbite. In my mind I thought of using an external pre-configured CSS that I can just insert and ta-da it would work.
diff --git a/output/blogs/2025/08/third-time.html b/output/blogs/2025/08/third-time.html index a368dae..c521970 100644 --- a/output/blogs/2025/08/third-time.html +++ b/output/blogs/2025/08/third-time.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +Useful for people who don't like the constrained working limit of 25 minutes for instance.
diff --git a/output/blogs/2025/08/wacom-with-arch.html b/output/blogs/2025/08/wacom-with-arch.html index 94303e6..d9acad8 100644 --- a/output/blogs/2025/08/wacom-with-arch.html +++ b/output/blogs/2025/08/wacom-with-arch.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +I purchased a One by Wacom tablet almost 2 years ago now and it works flawlessly in both Windows and MacOS and even in most Linux distros with some configuration.
diff --git a/output/blogs/2025/08/weekly-review-week-ending-august-10-2025.html b/output/blogs/2025/08/weekly-review-week-ending-august-10-2025.html index 58ef8c4..057ed5a 100644 --- a/output/blogs/2025/08/weekly-review-week-ending-august-10-2025.html +++ b/output/blogs/2025/08/weekly-review-week-ending-august-10-2025.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +
Mostly continuing reading from the book clean code, also setup the ankii cards and this website. The amount of leetcode problems I solved could improve however.
I seem to be spending less time working on technical crafts, primarily due to so many other commitments. Making it a goal to remove distractions and focus more on reading, writing and executing.
-
This Zettelkasten method is growing in popularity for taking notes. Ever felt as though there's too much pieces of information but you don't know how to deal with it? This method solves exactly that problem and more. Think of it as forming a second brain, where you can jot down ideas and information whilst simultaneously being able to connect them together.
@@ -246,7 +246,7 @@ There are many personal knowledge management systems' (PKMS) out there that allo -
In this section you will find posts that are not as structured as the ones found in here. Mainly these will deal with findings, research, assorted writings and random bits and blobs.
diff --git a/output/blogs/blogs-list.html b/output/blogs/blogs-list.html index c898323..ce07059 100644 --- a/output/blogs/blogs-list.html +++ b/output/blogs/blogs-list.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +See the categories: Categories
-> LinkedIn: LinkedIn
diff --git a/output/index.html b/output/index.html index c7d578f..20d2f89 100644 --- a/output/index.html +++ b/output/index.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +
This is a website built using Emacs Org-mode and published using org-publish. The very first iteration of this website used the Angular framework, only after a while I realised (as every Emacs lover does) that I want to make this an Emacs-centric project
org-publishorg-publish
This website is heavily inspired by some people who have decided to use org-publish as a way to convert org files into html. I came across a few that took the plunge and decided to migrate from platforms like Wordpress and instead opted for a more transparent, text-based workflow.
http://localhost:8000/<
Feel free to reach out on GitHub: https://github.com/zainezq
diff --git a/output/posts.html b/output/posts.html deleted file mode 100644 index b6ead60..0000000 --- a/output/posts.html +++ /dev/null @@ -1,251 +0,0 @@ - - - - - - - -Link to Chapter 2
-Referenced Items:
diff --git a/output/posts/clean-code/clean-code-chapter-2.html b/output/posts/clean-code/clean-code-chapter-2.html index 389c686..94297cb 100644 --- a/output/posts/clean-code/clean-code-chapter-2.html +++ b/output/posts/clean-code/clean-code-chapter-2.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +Link to Chapter 1 | Link to Chapter 3
-
Names should reveal intent, there is no revelation in naming an integer d, intending it stands for days. Instead, you should use the following names:
d<
Don't postfix the word 'list' to the name 'accounts' unless it's actually a list. This is because the reader will assume the data type of accountsList is indeed a list, instead choose a name like accountsGroup.
While it is possible to name by being disinformative, it is also possible to name being non informative. Consider:
@@ -302,18 +302,18 @@ Furthermore, noise words are redundant. We should never use the wordvaria
This is quite straightforward. Do not use a name like genymdhms to refer to generation date, year, month, day, hour, minute,
and second. Instead use generationTimeStamp.
In modern IDE's, it is still quite difficult to search for single-lettered variables. The writer states a personal preference of using single-letter names only as local variables and inside short methods. The following principle is given:
@@ -323,42 +323,42 @@ In modern IDE's, it is still quite difficult to search for single-lettered varia
Don't prefix variables with letters like m_ as was done in the past. Do not type encode as well, an example of this is: PhoneNumber phoneString; we can see the reader being misled into thinking the phone number is a String.
Clarity is king, don't use a name for a variable that only you know what it stands for. For example: using the letter r as the lower-cased version of the url with the host and scheme removed. That's being smart, not professional.
Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb
Methods should have verb or verb phrase names.
Do not use names that are only understandable to people whom you share jokes etc with. Furthermore, do not use colloquialism and slang in names.
@@ -368,17 +368,17 @@ Do not use names that are only understandable to people whom you share jokes etcIf you have multiple choices for naming a concept, use one and stick with it. For instance if your options are fetch, get and retrieve, use one and stick with it throughout.
Where possible use solution domain names, as the people that are going to be reading the code are programmers. Therefore, do not shy away from using CS terms, algorithm names, math names and so forth.
@@ -388,17 +388,17 @@ However when it is not possible to use solution domain names (in other words, whEnclose names with well-named classes, functions, or namespaces. When all else fails, then prefix with something that provides more context.
Shorter names are better than longer ones, generally. This is so long as the context and intent is clear. Don't add redundant or irrelevant additions to the name in the for the sake of 'context'.
diff --git a/output/posts/clean-code/clean-code-chapter-3.html b/output/posts/clean-code/clean-code-chapter-3.html index 467066e..895eed7 100644 --- a/output/posts/clean-code/clean-code-chapter-3.html +++ b/output/posts/clean-code/clean-code-chapter-3.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +Link to Chapter 2 | Link to Chapter 4
-Functions should be extremely short—ideally just a few lines, so they remain easy to understand and maintain.
@@ -269,9 +269,9 @@ Large functions hide complexity and mix abstraction levels, making errors and duA function should do exactly one conceptual task, and all its statements should exist at the same abstraction level.
@@ -293,9 +293,9 @@ Functions that “do one thing” cannot be logically split into sections such aSwitch statements naturally violate “do one thing” by handling multiple cases; they also grow in size over time.
@@ -350,9 +350,9 @@ Example:A function’s name should clearly state its purpose. Long, descriptive names beat short, cryptic ones.
@@ -374,9 +374,9 @@ IDE refactoring tools make renaming safe, encouraging experimentation.
The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn’t be used anyway.
write
A function should do only what its name promises. Hidden state changes are misleading and dangerous.
@@ -426,9 +426,9 @@ Functions that modify state and return information often cause confusion and shoError handling is a single responsibility—separate it from normal logic to keep both paths clear.
diff --git a/output/posts/clean-code/clean-code-chapter-4.html b/output/posts/clean-code/clean-code-chapter-4.html index f1c79e9..50ee8df 100644 --- a/output/posts/clean-code/clean-code-chapter-4.html +++ b/output/posts/clean-code/clean-code-chapter-4.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +Link to Chapter 3 | Link to Chapter 5
-Comments are a necessary evil—they exist because code fails to express intent clearly.
@@ -281,9 +281,9 @@ Strive to write code that explains itself; comments should be minimised. Truth is always in the code, not in the comments.Don’t use comments to excuse messy, unclear code. Clean the code instead.
@@ -304,16 +304,16 @@ Clear, expressive code with few comments > cluttered code with many comments.Only write them when unavoidable. Such as in the following instances:
Sometimes required for copyright/licensing.
@@ -323,9 +323,9 @@ Keep them short; refer to standard licenses rather than embedding full legal texExplain return values, formats, or patterns.
@@ -343,9 +343,9 @@ Prefer naming/structuring code to make such comments unnecessary.Describe why a certain approach was chosen.
@@ -371,9 +371,9 @@ Helps future maintainers understand reasoning behind code.Translate obscure values into readable terms.
@@ -383,9 +383,9 @@ Useful when working with unchangeable APIs/libraries, but risky if incorrect.Alert others about performance, thread-safety, or side effects.
@@ -399,9 +399,9 @@ For example, in code you can say:Mark incomplete work or planned improvements.
@@ -411,9 +411,9 @@ Should be reviewed regularly; not an excuse for bad code.Highlight the importance of seemingly small details.
@@ -423,9 +423,9 @@ Highlight the importance of seemingly small details.Public APIs should have clear documentation.
@@ -436,9 +436,9 @@ Javadocs can also mislead. Keep them accurate and up-to-date.Replace explanatory comments with expressive variable or function names.
@@ -460,9 +460,9 @@ Refactor code to remove comment redundancy.
Avoid decorative banners like // Actions ///////////////////////, they add clutter.
Comments on closing braces (} // while) are unnecessary for small, well structured functions.
@@ -488,9 +488,9 @@ Prefer short, clear functions over brace markers.
Don’t add personal tags like /* Added by Rick */, use version control for authorship history.
Never keep old code commented out; delete it and rely on version control history.
@@ -521,9 +521,9 @@ Commented-out code adds clutter and confuses future maintainers.Avoid HTML markup inside code comments, it makes them harder to read in the editor.
@@ -533,9 +533,9 @@ Let documentation tools (like Javadoc) handle formatting.Comments should describe nearby code only, not unrelated parts of the system.
@@ -545,9 +545,9 @@ Avoid embedding global/system details that the function can’t control.Avoid long, unnecessary historical or technical explanations.
@@ -557,9 +557,9 @@ Keep only relevant context (e.g., “RFC 2045” reference is fine, not the fullEnsure the relationship between comment and code is clear.
@@ -577,9 +577,9 @@ Don’t make readers guess what part of the code the comment refers to.Short, single purpose functions with good names don’t need header comments.
@@ -589,9 +589,9 @@ Let the function name explain the purpose.Javadocs are useful for public APIs, but excessive formality in internal code is just noise.
diff --git a/output/posts/clean-code/clean-code-chapter-5.html b/output/posts/clean-code/clean-code-chapter-5.html index 497d94d..ecec9ab 100644 --- a/output/posts/clean-code/clean-code-chapter-5.html +++ b/output/posts/clean-code/clean-code-chapter-5.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +Link to Chapter 4 | Link to Chapter 6
-Keep lines short. Most professional code naturally stays within ~45 characters, with ~80 as an upper bound. Lines beyond 100–120 characters are generally careless.
@@ -391,9 +391,9 @@ Example limit guideline:Use spaces to separate low-precedence operators (e.g., +, -, =) and improve readability.
@@ -416,9 +416,9 @@ Separate arguments with spaces after commas to show distinct parameters.Avoid aligning variable declarations or assignments in columns, it draws the eye to the wrong place.
@@ -446,9 +446,9 @@ Example (preferred unaligned):Indent according to scope hierarchy:
@@ -478,9 +478,9 @@ Avoid collapsing scopes onto one line, always use braces and proper indenting.Avoid dummy bodies in loops (e.g., empty while or for loops).
@@ -497,9 +497,9 @@ If unavoidable, place semicolon on its own indented line to make it visible.Teams must agree on a single formatting style for consistency.
@@ -513,9 +513,9 @@ Consistent formatting builds trust and reduces mental load for readers.Short, clear methods with consistent spacing and indentation.
diff --git a/output/posts/posts-intro.html b/output/posts/posts-intro.html index 245f36c..fd9ac9b 100644 --- a/output/posts/posts-intro.html +++ b/output/posts/posts-intro.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +
In this section you will find posts related to both technical and non-technical topics. As Einstein said: “If you can’t explain it simply you don’t understand it well enough”, thus the goal with these posts is to develop the skill of being able to deliver habitual high quality explanations as well as reinforcing the topic(s) learnt.
See the categories: Categories
-Last updated:
@@ -235,9 +235,9 @@ This page will highlight thebuild-script.el used to generate this
The script is as follows, at the start I have some metadata relating to the file, followed by package management,then the declaration of variables/functions and finally the org-publish-project-alist which handles nearly all of the project generation instructions.
As the project is hosted on Github, I have created a small script that is able to push changes to the remote repository, which Cloudflare will automatically detect and rebuild the website:
diff --git a/output/sitemap.html b/output/sitemap.html index 9e326c0..2f731c0 100644 --- a/output/sitemap.html +++ b/output/sitemap.html @@ -3,7 +3,7 @@ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> - +