Since JavaScript is the programming language I use the most, it made sense to use JavaScript to build both the frontend and backend.
On the backend, I had to come up with a database schema design, API documentation, identifying potential cron jobs, queues, third-party libraries to integrate, and a robust authentication flow. For the choice of the database, the consideration centered around three key factors; my current skill set and learning capacity, how well it integrates with Node, and flexibility to accommodate evolving product requirements.

Building Ziner: Overview

Back in 2023, I set out to build at least one somewhat complex fullstack project to brush up my skills. What I came up with was Ziner; a centralized platform of features and integrations designed to help creators boost their workflows.
Taking the occassional freelance route, I realized that I found it hard to centralize and keep track of my workflows, i.e, client management, projects, tasks, invoices, rate cards, ...etc. What this meant was using different tools I had to use different tools and connecting them in a way that works for me. SO I decided to build a platform of consolidated tools I can use.
Deciding the architecture for both the frontend and backend has been quite tricky. From the choice of stack, database schema design, the need for cron jobs, and potential third-party negotiations.

Figuring out Cron Jobs

For the frontend part of this project, the goal was to build a scalable, performant, and maintainable web app while shipping fast. Some things I had to consider to ensure a somewhat smooth sailing were project structure, testing, performance optimizations, maintainability and tooling.
<h3>Project structure</h3>
Project structure is a foundational aspect when starting out any project. As the app needs grow, it becomes less feasible to cram things or repeat logic in multiple places. A better approach I took was employing modularity by keeping shared components as reusable as possible. Along with separating unrelated logic, it became easier to navigate as the codebase grows.
For this project, I adopted a feature-based architecture.
<pre><code> /src
 +components
 +features # Feature-specific UI &#x26; logic
 +ui # Shared UI components
 +services # API interactions
 +store # State management (Vuex)
 +layouts # Layout components
 +utils # Helper functions, enums and static data
 +directives # Vue directives
 +plugins # Vue plugins
 +router # Vue router file and any router-specific logic
 +directives # Vue directives
 +assets # Static files (fonts, icons, images and minified js files)
 +styles # Directory for global styles grouped further based on their related functions
 +views # For all pages/views
</code></pre>
For the choice of stack, I used Vue 2. That meant forfeiting SSR benefits and finding a way around SEO management. Since Vue 2 doesn’t have built-in TypeScript support like Vue 3, Zod was used for runtime validation. But in a future rewrite, integrating with TypeScript is definitely a must.
<h3>State management</h3>
For smaller Vue projects, managing state can be done locally or by passing data as props to child or sibling components. As the project grew larger, I needed a way to share data across unrelated components without falling into the "prop-drilling" trap. Vuex was a good choice due to its robust API, minimal boilerplate, and compatiblity with Vue 2.
To avoid the complexity of keeping all store logic in a single file, a better approach was to break the Vuex store into multiple store modules. The outcome is small, independent modules combinined into a single large store. Vuex exposes to us a "module" API whose value is an object of multiple store modules. This helps with file management and easy lookup.
<h3>API handling</h3>
For API integrations, the goal was to have something simple with sufficient error handling mechanisms. I created a custom global plugin that enabled the axios instance to be called from anywhere in the application, and with interceptor methods for request/response handling, particularly error handling. This plugin also eliminates unnecessary re-fetching by keeping retries to a maximum count and caching responses where necessary.
<h3>Testing</h3>
<ul>
<li>Cypress for testing workflows</li>
<li>Vitetest for unit tests</li>
</ul>
<h3>Tooling</h3>
To ship features quickly, I optimized for a good developer experience by integrating tools to keep the codebase clean and efficient
<ul>
<li>ESLint + Prettier – for auto-formatting and consistent code styling</li>
<li>Husky – to run checks before commits and catch broken code</li>
<li>Storybook – to test UI components in isolation before pushing to production</li>
<li>GitHub Actions – for testing automation, linting, and deployments</li>
</ul>
<h3>App Observability</h3>
<ul>
<li>Future plans to integrate Sentry for error tracking in production</li>
</ul>
<h3>Performance optimizations</h3>
With this project, I wanted to avoid common performance pifalls and ensure faster load times. For performance optimizations, a few things I did were:
<ul>
<li>Lazy load heavy components at the route or component level, e.g, lazy loading the main dashboard entry component on the route level</li>
</ul>
<pre><code> component: () => import("@/views/Dashboard.vue")
</code></pre>
<ul>
<li>Image optimization: some effective approaches I took include:
<ul>
<li>deferring loading images on the marketing pages until they're about to enter the viewport,</li>
<li>compressing images with Cloudinary before serving</li>
</ul>
<ul>
<li>applying native loading attributes where necessary</li>
</ul>
</li>
</ul>
<ul>
<li>Debounce expensive operations (search filters and some API requests).</li>
<li>Paginate data to avoid fetching large datasets at once.</li>
</ul>
<ul>
<li>Using performance monitoring tools like Lighthouse to measure core web vitals</li>
</ul>
<h3>Post-launch Improvements</h3>
<ul>
<li>Gather user feedback for new features.</li>
<li>More performance optimizations</li>
</ul>

Building Ziner: Frontend

As you know by now, Ziner offers tasks management with multiple ways to organize tasks. With this feature, an interesting problem I had to solve was finding a way to fetch and group tasks by their respective labels. For example, on the frontend, if a user created multiple tasks with the following labels: school, work, content, and wanted to organize these tasks by labels.
Several questions arise, like, how does that get handled? Ideally, where should the data sorting happen? On the frontend or backend? What are the tradeoffs in doing it on either side? I am a huge believer in shifting the burden of data manipulation to the backend, particularly for large datasets because a lot of databases are built to optimize large-scale data operations.
For a smaller number of records, sorting or filtering operations on the frontend works but as the data grows, we need to offset the heavy-lifting to the backend. At a certain level of scale, it becomes performant to handle heavy processing and data shaping on the backend. On the backend, we can filter, sort or group before paginating and returning it to the frontend.
As mentioned in the previous posts, my database of choice is MongoDB. At the start of developement, I went through so many iterations schema-wise, that it made sense for me to switch to a database that offered flexibility. Things like dynamic schemas, zero downtime when I needed to update a schema, and even nested data structures are supported in MongoDB, ensuring developement runs without enforcing a rigid schema upfront. Having previously worked with only traditional SQL databases, this was a delight.
MongoDB offers a way to run complex operations in multiple stages using its aggregation feature. This works by employing a set of helper methods to run operations on a collection,like advanced filtering or grouping. Typically useful for generating reports, trying to fetch data from records across multiple collections or in my case, fetching advanced grouped data.
For this particular problem, I want to apply an aggregration pipeline to query, filter, alter and finally group the tasks collection. We are going to split the pipeline into several stages working with the following algorithm:
For first stage of the pipeline, we employ the $match stage. What this stage helps us do is filter the collection by specific conditions. In this case, we want to filter out all tasks that don't belong to that specific user, returning only the documents where the userId in each task document matches the user id belonging to that specific user. This looks like:
<pre><code> const samplePipeline = [
 { $match: { userId: new ObjectId('userIdHere') } },
 ]
</code></pre>
For the second stage of the pipeline, the goal is: for each document in the collection, ensure the tagIds field:
<ul>
<li>remains unchanged if it exists and has non-empty/null values</li>
<li>has its value replaced with [null] if the field is missing, has a null value or is an empty array</li>
</ul>
The algorithm would look like:
<ol>
<li>Check if the tagIds field is null or empty. If true, move to step 3</li>
<li>Check if the tagIds field is an array:
<ul>
<li>if true and array length is greater than 0, leave it unchanged</li>
<li>if array is empty, move to step 3</li>
</ul>
</li>
<li>Set the value of the tagIds to null if empty, missing or has a nullable value</li>
</ol>
...
<pre><code> [
 ...previous stage above
 {
 $addFields: {
 tagIds: {
 $cond: {
 if: { $gt: [{ $size: { $ifNull: ["$tagIds", []] } }, 0] },
 then: "$tagIds",
 else: [null],
 },
 },
 },
 },
 ]
</code></pre>
...
Next, we unwind the result of the first stage into a new path tagIds (any other name can be used). The $unwind stage basically deconstructs the array from the first stage and outputs a document for each element in the array. We also want to ensure each document with null values for its tagIds field gets returned as well.
<pre><code> [
 ...previous stages above
 {
 $unwind: {
 path: "$tagIds",
 preserveNullAndEmptyArrays: true
 },
 },
 ]
</code></pre>
For the third phase, we're going to make use of $lookup. The goal is to find matching tags from the tags collection based on the value of the tagIds field in the tasks collection. Then, we store all matched tags inside an array field called tagDetails. If a document has an empty array for its tagIds field, we simply return an empty array.
The "from" field references the tags collection, the "localField" match the "tagIds" field in tasks, the ""foreignField"" is used to compare the ids in the "tags" collection
to lookup details for each tag from the Tag collection, and finally, we store the results in a new field "tagDetails".
Query
<pre><code> [
 ...previous stage above 
 {
 $lookup: {
 from: "tags",
 localField: "tagIds", 
 foreignField: "_id",
 as: "tagDetails",
 },
 },
 ]
</code></pre>
Sample result
<pre><code> { 
 "_id": 1, 
 "name": "Task A", 
 "tagIds": [ObjectId("abc123")], 
 "tagDetails": [ { "_id": ObjectId("abc123"), "name": "Urgent" } ] // or an empty array
 }
</code></pre>
Next, we unwind the result of the previous stage. This step creates separate documents for each array of multiple tags per task document. If a task document has an empty value for its tagDetails array, it preserves the document using "preserveNullAndEmptyArrays: true." and returns a null value instead.
The final step involves taking all the advanced operations done during the previous stages and grouping the results by the tag name. If $tagDetails.name exists, it becomes the _id (grouping key), if the value is null, then we falls under the label "No tags". Basically, all tasks with the same tag name get grouped together and those without a tag name get grouped under the "No tags" group. A "tasks" array is created to hold all tasks under each label while the "$push" adds each task into its respective group along with any other important meta data.
<pre><code> [
 ...previous stage above,
 {
 $group: {
 _id: { $ifNull: ["$tagDetails.name", "No tags"] },
 tasks: {
 $push: {
 _id: "$_id",
 name: "$name",
 description: "$description",
 priority: "$priority",
 projectId: "$projectId",
 deadline: "$deadline",
 isCompleted: "$isCompleted",
 },
 },
 },
 }
 ]
</code></pre>
The result of this aggregration pipeline is a list of documents in this format:
<pre><code> "_id": "tag name here",
 "tasks": [
 {
 "_id": "67dc3bd20852171c33af9eb2",
 "name": "Test task",
 "description": "Test description",
 "priority": "Test priority",
 "deadline": "Test deadline",
 "isCompleted": false
 },
 ]
</code></pre>
For Ziner, I have some more use cases for employing MongoDB aggregration, e.g, advanced reporting, attempting the equivalent of SQL joins...etc.
<h3>Some helpful notes</h3>
<ol>
<li><a href="https://www.mongodb.com/resources/products/capabilities/aggregation">What is Aggregration in MongoDB?</a>,</li>
<li><a href="https://www.mongodb.com/docs/manual/reference/operator/aggregation/unwind/">Aggregration Docs</a></li>
</ol>

Building Ziner: Using MongoDB Aggregration Pipeline Feature

Back in 2023, I realized that whenever I had to work on a freelance project, I struggled to maintain an organized database of things I needed to enjoy a more streamlined workflow. Typically, for a new project, I had to use at least two separate platforms to track all the important elements—clients, projects, rate cards, emails, tasks, meetings, and invoices—and manually connect them in a way that helped with easy retrieval. Continuous context-switching between several platforms required a lot of manual synchronization.
Well, I found this fragmented approach inefficient, and as an engineer, I was ultimately inspired to build something that helped solve this problem of mine.
What I came up with was <a href="https://ziner.cc">Ziner</a>; a centralized platform of features and integrations for freelance workflows. Built on a Node.js backend with Vue as the web framework of choice, Ziner helps to establish relationships between these disconnected entities—clients, projects, tasks, communications, rate cards, and invoices.
Live [and still a work-in progress], Ziner offers the following features:
<ul>
<li>Invoice management</li>
<li>Client management</li>
<li>Project management</li>
<li>Project reminders and time tracking</li>
<li>Project and tasks reminders</li>
<li>Calendar and meeting management</li>
<li>Reports</li>
<li>Revenue and milestone tracking:</li>
<li>Sharing accomplishments via social media (X &#x26; LinkedIn) or directly with potential clients</li>
<li>Integrations (Calendar &#x26; Emails for now)</li>
</ul>
...
What began as a personal workflow optimization has evolved into a fun, whimsical project I was extremely excited to work on. And so, the purpose of this blog post is to have a public diary of some sorts, where I document the technical decisions, implementation details, and lessons I picked up while working on this project.
<h2>subpages</h2>
<ul>
<li><a href="./frontend-architcture.md">Building the frontend</a></li>
</ul>
<ul>
<li><a href="./mongodb-aggregation.md">Using MongoDB Aggregration feature</a></li>
</ul>

Building Ziner

** This post is a work-in-progress. Same with the code implementation.**
<a href="https://github.com/Uzoamaka126/lox-js">Link to Github</a>
To build a programming language that feels natural and intuitive, certain things have to be taken into consideration, including working around abstractions. I'm 100 pages into Robert Nystrom's book, Crafting Interpreters, where he offers really good insight on interpreters, compilers and language implementation as a whole. It's quite detailed and a great exercise to get into if you are interested in learning how programming languages work.
Lox, the language used in this book, is a small-scale, dynamically-typed scripting language with a syntax similar to C. The book is split into two parts: implementing Java and C interpreters. Since my knowledge of either language is close to nil at best, I opted to build this interpreter with JavaScript.
<h4>Intro</h4>
When we run a program, even one as simple as "Hello world!", the execution process is divided into several phases. Each phase operates like a pipeline; returning a different representation of the source code before passing it to the next phase, until the representation is (or close to) machine code.
In typical language processing, the final phase generates machine code, a low-level set of instructions, far less readable for humans, but a virtual or real-time CPU can execute. With this interpreter, some phases are skipped in favour of a simpler process; scanning, parsing and evaluating the code. The scanner takes the source code as a series of characters, and outputs a sequence of tokens. The parser then constructs a tree-like structure from these tokens, using grammar rules to ensure validity of the tokens.
An interesting aspect highlighted in the book is the concept of a shared intermediate representation (IR) for reusability. Basically, an IR is a data structure used further down the line to represent and optimize source code without being too tightly coupled with the source or destination language. The reusability function of shared IRs means that support can exist for the translation of multiple languages without having to write a new data structure for each one after parsing has occurred.
Built as a tree-walk interpreter, the Lox interpreter walks (or traverses) an Abstract Syntax Tree (AST), returned when the parser processes the scanned tokens.
<h4>Error handling</h4>
Error handling is high up on the list of things to consider when building a good programming language. A good error handling mechanism goes a long way. In the event of an error, it's not just enough to indicate that an error has occurred, users of the language also need additional context like what line the error occurred, what type of error...etc
The code contains a separate error class that can be referenced externally to handle all errors. The error class extends the standard built-in JavaScript Error class, and has its own custom functionality; a private boolean variable for tracking the occurrence of an error and a static method for reporting errors. When called, the report method logs the error line and message to the terminal before internally updating the private boolean variable to true.
<pre><code>LoxError.js
 class LoxError extends Error {
 static hadError = false;

 constructor(token, message) {
 super(`${token.line}: '${token.lexeme}' ${message}`)
 this.name = 'LoxError: '
 }

 static setError(boolValue) {
 this.hadError = boolValue;
 }

 static report(line, where = "", message = "") {
 console.log('\x1b[34m%s\x1b[0m', "[line " + line + "] Error" + where + ": " + message);
 this.setError(true);
 }
}
</code></pre>
<h4>Tokens</h4>
The process of identifying and classifying lexemes is called lexical analysis or tokenization. [Lexemes are distinctly different from characters. Characters make up the source code while lexemes consist of one or more characters representing a single token]. During the lexical analysis phase, characters are grouped into several categories like, single characters, new lines, whitespaces, keywords, identifiers, comments, ...etc. Typically, white spaces and comments get ignored or discarded, while characters that are unrecognizable by the scanner get returned as an error.
To represent and group various lexemes, we are going to create a Token class to group and output the desired token and an enum that houses a list of all the various ways lexemes can be grouped.
*See full list of enum <a href="https://github.com/Uzoamaka126/lox-js/blob/main/src/TokenType.js">here</a>
<pre><code>Token.js

class Token {
 static type; // enum
 static lexemme; //string
 static literal; // object
 static line; // number

 constructor(type, lexeme, literal, line) {
 this.type = type;
 this.lexemme = lexeme;
 this.literal = literal;
 this.line = line;
 }

 toString() {
 return this.type + " " + this.lexemme + " " + this.literal;
 }
}
</code></pre>
<h4>Writing the scanner</h4>
We are going to create a scanner class with the following: a string variable to hold the raw source code, a default empty array to hold the result tokens, two integer variables, "start" and "current" to keep track of the starting and current points in the loop. On each iteration, we take the current character, group it with its relative lexeme and emit a token based on that grouping. The goal of the scanning phase is to return a different representation as tokens.
<pre><code>Scanner.js
 class Scanner {
 #SOURCE = ""; // raw source code as a string
 #TOKENS = []; // a default empty list to add generated tokens to
 #start = 0; // points to the first character being scanned
 #current = 0; // points to the character in the current iteration
 #line = 1; // tracks what source line "current" character is on 

 constructor(source = "") {
 this.#SOURCE = source;
 }

 ...
 }
</code></pre>
The Scanner class contains a "scanTokens" method, which calls a different private method "scanToken" during iteration. Inside the "scanTokens" method block, once the loop ends, we append a final "end-of-file" token to help make the parser cleaner and then we return a list of tokens.
<pre><code>Scanner.js
 ...
 scanTokens() {
 while(!this.isAtEnd()) {
 this.#start = this.#current;
 this.#scanToken();
 }

 this.#TOKENS.push(new Token(TOKEN_TYPE.EOF, "", null, this.#line));
 return this.#TOKENS;
 }

 isAtEnd() {
 return this.#current >= this.#SOURCE.length;
 }
</code></pre>
On each iteration, the private "scanToken" method checks to see what token type the current character falls under. If the character doesn't fit into any of the existing groups, we can report an error without interrupting the loop. We make use of two helper methods; 1) an "advance" method that consumes the next character in the source string and returns it 2) an "addToken" method that grabs the text of the current lexeme, outputs a new token from it before pushing to the tokens array we created earlier.
Inside the default block, we check for digits and alphanumeric values to group them accordingly or we handle unrecognized characters by calling the error class we created earlier.
<pre><code>Scanner.js
 #scanToken() {
 const c = this.#advance();

 switch (c) {
 // single character
 case "(": this.#addToken(TOKEN_TYPE.LEFT_PAREN); break;
 case ")": this.#addToken(TOKEN_TYPE.RIGHT_PAREN); break;
 case "{": this.#addToken(TOKEN_TYPE.LEFT_BRACE); break;
 case "}": this.#addToken(TOKEN_TYPE.RIGHT_BRACE); break;
 case ",": this.#addToken(TOKEN_TYPE.COMMA); break;
 case ".": this.#addToken(TOKEN_TYPE.DOT); break;
 case "-": this.#addToken(TOKEN_TYPE.MINUS); break;
 case "+": this.#addToken(TOKEN_TYPE.PLUS); break;
 case ";": this.#addToken(TOKEN_TYPE.SEMICOLON); break;
 case "*": this.#addToken(TOKEN_TYPE.STAR); break;

 // second character
 case "!": this.#addToken(this.#match("=") ? TOKEN_TYPE.BANG_EQUAL : TOKEN_TYPE.BANG); break;
 case "=": this.#addToken(this.#match("=") ? TOKEN_TYPE.EQUAL_EQUAL : TOKEN_TYPE.EQUAL); break;
 case "&#x3C;": this.#addToken(this.#match("=") ? TOKEN_TYPE.LESS_EQUAL : TOKEN_TYPE.LESS); break;
 case ">": this.#addToken(this.#match("=") ? TOKEN_TYPE.GREATER_EQUAL : TOKEN_TYPE.GREATER); break;

 case "/": 
 if (this.#match("/")) {
 while (this.#peek() != '\n' &#x26;&#x26; !this.isAtEnd()) this.#advance();
 } else {
 this.#addToken(TOKEN_TYPE.SLASH);
 }
 break;

 case " ": 
 case "\r": 
 case "\t": 
 break;
 
 case "\n": 
 this.#line++;
 break;
 
 case '""': 
 this.#string();
 break;

 default:
 if (this.#isDigit(c)) {
 this.#number();
 } else if (this.#isAlpha(c)) {
 this.#identifier();
 } else {
 LoxError.report(this.#line, "", "Unexpected character.")
 }
 break;
 }
 }

 #advance() {
 this.#current++;
 return this.#SOURCE.charAt(this.#current - 1);
 }

 #match(expected = "") {
 if (this.isAtEnd()) return false;
 
 if (this.#SOURCE.charAt(this.#current) != expected) return false;

 this.#current++;
 return true;
 }
</code></pre>
<h4>Writing the parser</h4>
Parsers make use of grammar production rules to convert a sequence of tokens into a different representation: a Parse Tree or an Abstract Syntax Tree (AST). To create new representations, we make use of formal grammars instead of regular grammars.
Formal grammars specify production rules that describe how to form valid strings in a language. These rules define things like the structure of expressions, statements and program constructs, allowing the language to be parsed and understood by an interpreter or compiler. They also closely resemble regular expressions.
For example: given grammar G, where G = {(S,A) (a,b) (S → aAb, A → aAb | ϵ)}, generate an equal number of "a's and b's", with the production rules P defined below:
<pre><code> 𝑆 → aAb
 A → aAb | ϵ

 S is the start symbol.
</code></pre>
Starting with 'S', we apply the production rule S → aAb once, then recursively apply A → aAb, exactly n-1 times. To maintain a balance, on every iteration, we add a single "a" at the start and "b" at the end of the string. Then finally, we apply the rule A → ϵ (where ϵ = an empty string) to terminate the recursion. This gives us the result below:
<pre><code> S → aAb
 → aaAbb (where A → aAb )
 → aaaAbbb
 → aaabbb (where A → ϵ)
 → a³b³
</code></pre>
Our parser is going to make use of the grammar below to translate the rules to code:
<pre><code> expression → literal | unary | binary | grouping ;
 literal → NUMBER | STRING | "true" | "false" | "nil" ;
 grouping → "(" expression ")" ;
 unary → ( "-" | "!" ) expression ;
 binary → expression operator expression ;
 operator → "==" | "!=" | "&#x3C;" | "&#x3C;=" | ">" | ">=" | "+" | "-" | "*" | "/" ;
</code></pre>
When parsing, certain things have to be taken into consideration, like the validity of the sequence of tokens or precedence of the grammar rules being applied. This means we have to determine the order the operators are evaluated, especially if an input has multiple operators. Operators with higher precedence will get evaluated before their lower counterparts.
For example, the expression 6 / 3 - 1 * 4 gets parsed as (- (/ 6 3) (* 1 4))
We're going to create a Parser class with a parse method that kickstarts the entire parsing operation. Our Parser class uses an array to store the list of tokens received and an integer variable, "current" to track the next token to be parsed. For each grammar rule defined above, we are going to create an equivalent method that outputs a different expression before calling the next method.
We use the "recursive descent" parsing technique to translate our grammar rules into code. Also called a "top-down" technique, this technique parses from the outermost grammar rule, moves to nested subexpressions before finally moving to the bottom part of the tree. It is able to do this by recursively calling itself until the entire process is done.
<pre><code>class Parser {
 current = 0;
 tokens = [];

 constructor(tokens = []) {
 // validation
 if (!Array.isArray(tokens)) {
 throw new TypeError('Tokens must be an array');
 }
 this.tokens = tokens;
 }

 parse() {
 try {
 return this.expression() 
 } catch (error) {
 return null
 }
 }
 ...
}
</code></pre>
I've also created a class to help with traversing and printing the expression tree. In the AstPrinter class, we try to mimic a similar functionality to the visitor pattern implementation in Java. We use a base Expr class which other expression sub-classes inherit from, mimic the visitor pattern through the accept method, and finally creating an AstPrinter class that invokes methods defined on the other sub-classes. See the example below:
<pre><code>// Base expression class
class Expr {
 accept(visitor) {
 throw new Error("accept() not implemented");
 }
}

class Binary extends Expr {
 constructor(left, operator, right) {
 super();
 this.left = left;
 this.operator = operator;
 this.right = right;
 }

 accept(visitor) {
 return visitor.visitBinaryExpr(this);
 }
}

class Literal extends Expr {
 constructor(value) {
 super();
 this.value = value;
 }

 accept(visitor) {
 return visitor.visitLiteralExpr(this);
 }
}

</code></pre>
The rest of the code can be found <a href="https://github.com/Uzoamaka126/lox-js/blob/main/src/AstPrinter.js">here</a>.
<h4>Error reporting for the parser</h4>
While parsers take in a valid sequence of tokens, there might be instances where invalid tokens get passed in. When this happens, our parser should be able to detect and notify the user without interrupting the system. We use an error method to handle this:
<pre><code> error(token, message) {
 // LoxError.error(token, message);

 if (token.type === TOKEN_TYPE.EOF) {
 throw new SyntaxError(`Invalid or unexpected token, at end, ${message}`);
 } else {
 throw new SyntaxError(`Invalid or unexpected token ${token.lexemme}, at line ${token.line}, ${message}`);
 }
}
</code></pre>
*The LoxError.error part is intentionally commented out. In a future refactor, the system will make use of the central error reporting class to report all errors.
<h4>Wiring up the interpreter</h4>
<h3>Notes</h3>
Here are some resources I found helpful:
<ol>
<li><a href="https://pgrandinetti.github.io/compilers/page/what-is-a-programming-language-parser/">What is a Programming Language Parser?</a>,</li>
<li><a href="https://en.wikipedia.org/wiki/Separation_of_concerns">Separation of concerns</a></li>
<li><a href="https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools">Compilers, Principles, Techniques, and Tools</a></li>
<li><a href="https://www.youtube.com/watch?v=U8SXIlCTLuk">YT video on Grammars</a></li>
<li><a href="https://en.wikipedia.org/wiki/Control-flow_graph#:~:text=In%20computer%20science%2C%20a%20control,matrices%20for%20flow%20analysis%20before">Control Flow Graph</a></li>
</ol>

Building a Lox interpreter with JavaScript; An exercise from Robert Nystrom's Crafting Interpreters

A linked list is a dynamic linear structure that typically holds one or more nodes where at least one node has a value and a pointer to the address of the next existing node. Implementing a doubly linked list can be slightly more complex than a singly list because the former is bi-directional while the latter is uni-directional. This means that, in a doubly linked list, each node has two pointers; one to the address of the previous existing node and the other to the next node. There are several operations that can generally be done on a linked list but in this post, the focus will be on inserting a new node at the end of a list, deleting a node from the end of a list and traversing a list to find a node.
As someone who primarily writes JavaScript, I found implenting a linked list in JavaScript easier since it supports OOP -- quite useful for creating and keeping track of state during implementation.
Since C is a procedural oriented language and does not support OOP, replicating concepts like encapsulation and inheritance is not quite straightforward. [While C does have object-like structures, the behaviours of these structures are completely different from your standard object].
Let's look at an implementation of a doubly linked list in JavaScript with classes
<pre><code> // initialize a node class
 class Node {
 constructor(value) {
 this.value = value;
 this.prev = null;
 this.next = null;
 }
 }

 // use a class to encapsulate and keep track of various states
 class DoublyLinkedList {
 constructor() {
 this.head = null; // starting node
 this.tail = null; // end node
 this.length = 0; // initial length state
 }

 // removal from the end of list
 pop() {
 if (!this.head) return undefined;

 const nodeToBeDeleted = this.tail;

 if (this.length === 1) {
 this.head = null;
 } else {
 const prev = nodeToBeDeleted.prev;
 prev.next = null;
 this.tail = prev;
 }
 this.length--;
 return nodeToBeDeleted;
 }

 // insertion at the end
 push(val) {
 const newNode = new Node(val); // create a new node

 if (!this.head) {
 this.head = newNode;
 this.head.prev = null;
 this.head.next = null;
 this.tail = this.head;
 } else {
 const currentTail = this.tail;
 this.tail.next = newNode;
 newNode.prev = currentTail;
 newNode.next = null;
 this.tail = newNode;
 }
 this.length++;
 return this;
 }

 // traversing the list to find a specific node
 find(val) {
 if (!this.head) return undefined;

 let temp = this.head;

 while (temp.next !== null) {
 temp = temp.next;

 if (temp === val) {
 return temp;
 }
 }

 return undefined;
 }
 }

 const newList = new DoublyLinkedList();

 newList.push(11);
 newList.push(12);
 newList.push(13);
 newList.push(14);
 newList.pop();
 newList.find(12);

 console.log({ newList });
</code></pre>
Let's try to implement a doubly linked list of integers and some of its operations in C
<h4>Inserting a node at the end of the list</h4>
To insert a node at the end of a list in C, first, we allocate memory for a new node, then take the pointer of the last node which points to null and point it to the new node being inserted. An example code below:
<pre><code> int insertAtEnd(struct Node** head, int data) {
 struct Node* newNode = (struct Node*)malloc(sizeof(struct Node));

 newNode->value = data;
 newNode->next = NULL;

 if (*head == NULL) {
 newNode->prev = NULL;
 *head = newNode;
 return;
 } 

 struct Node* temp = *head; 

 while (temp->next != NULL) {
 temp = temp->next;
 temp->next = newNode;
 newNode->prev = temp;

 return;
 }
 }
</code></pre>
A rough visual example would look like this:
<pre><code> &#x3C;!-- Before insertion -->
 &#x3C;-11 ->&#x3C;- 12 ->&#x3C;- 13 ->&#x3C;- 14 ->&#x3C;- null (tail node)

 &#x3C;!-- After insertion: node 15 -->
 &#x3C;-11 ->&#x3C;- 12 ->&#x3C;- 13 ->&#x3C;- 14 ->&#x3C;- 15 ->&#x3C;- null (tail node)
</code></pre>
<h4>Deleting a node at the end of a list</h4>
Deleting a node on a doubly linked list can be done at any point on the list but in the implementation below, we're going to delete a node from the end of the list (pop)
<pre><code> int deleteFromEnd(struct Node** head, struct Node* nodeToDelete) {
 if (*head == NULL) { // list is empty
 return;
 }
 
 if (*head == nodeToDelete) { // target node is the head node
 *head = nodeToDelete->next;
 return;
 }

 if (nodeToDelete->next != NULL) {
 nodeToDelete->next->prev = nodeToDelete->prev;
 }

 if (nodeToDelete->prev != NULL) {
 nodeToDelete->prev->next = nodeToDelete->next;
 }

 // then free the memory for the node to be deleted
 free(nodeToDelete);
 }
</code></pre>
<h4>Traversing a doubly list to find a target node</h4>
Since a doubly linked list contains one or more nodes linked to each other in two opposite direction, we can traverse a doubly linked list by taking the head node, assigning it to a temporary variable "temp", then, in a loop, keep reassigning the next node as the new value of the temp variable until all nodes on the list have been visited. We know when all the nodes have been visited when the value of temp->next becomes NULL and then the loop ends.
Let's look at an implementation in C that traverses a list to find a target node
<pre><code> int traverseAndFind(struct Node** head, struct Node* nodeToFind) {
 if (*head == NULL) { // only one node on the list
 return;
 }

 if (*head == nodeToFind) { // target node is placed at the beginning of the list
 return nodeToFind;
 }

 struct Node* temp = *head; 

 while (temp->next != NULL) {
 temp = temp->next;
 printf("%d --->",temp->value);

 if (temp == nodeToFind) {
 return temp.data; // return value of target node
 }

 return 0;
 }
 }
</code></pre>
<h4>Testing out the code</h4>
To test out the code, we're going to initialize a node variable with struct, which is another way for us to group related information.
<pre><code> struct Node {
 int value;
 struct Node *prev; // a pointer to the previous node/address
 struct Node *next; // a pointer to the next node
 }

 void printList(struct Node* node) {
 struct Node* last;

 while (node != NULL) {
 printf("%d->", node->value);

 last = node;
 node = node->next;
 }

 if (node == NULL) {
 printf("NULL\n");
 }
 }

 int main() {
 // initialize an empty node
 struct Node* head = NULL;
 
 insertAtEnd(&#x26;head, 11);
 insertAtEnd(&#x26;head, 12);
 insertAtEnd(&#x26;head, 13);
 insertAtEnd(&#x26;head, 14);

 traverseAndFind(&#x26;head, 12);
 deleteFromEnd(&#x26;head, 12);

 printList(head);
 }
</code></pre>
That's all, folks!
<h3>Notes</h3>
Here are some resources I found helpful on linked lists, C structs or C data types:
<ol>
<li><a href="https://www.w3schools.com/c/c_structs.php">W3Schools: C Structs</a>,</li>
<li><a href="https://www.reddit.com/r/C_Programming/comments/3rxl9o/question_why_are_structs_not_objects/">Reddit: Why are structs not objects?</a>,</li>
<li><a href="https://softwareengineering.stackexchange.com/questions/113533/why-is-c-not-considered-an-object-oriented-language">Why is C not considered an 'object-oriented' language?</a></li>
</ol>

Implementing a Doubly Linked List in C

I'm currently learning C. As someone who primarily writes JavaScript, I find the concept of pointers, malloc, and heap allocation quite confusing. Mostly because 1) these concept don't exist in JavaScript -- not on the surface at least 2) JavaScript has an in-built garbage collector, which helps with memory management (<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management">MDN</a>).
In low-level languages like C, memory allocation and management are manual; when a variable is declared, and assigned a value, memory has to be manually allocated for it. In high-level languages like JavaScript, memory allocation happens automatically, so we don't have to worry so much about memory management.
A huge part of programming in C revolves around finding ways to efficiently pass variables between functions, memory allocation and management. Using a pointer is an efficient way to do this because they allow data structures and variables to get passed between functions. Simply put, pointers are variables that take the memory addresses of other variables and store them as a value. Usually called a pointer variable, pointers point to the address of a variable in memory and are initialized using the "*" symbol. The type of a pointer variable usually correlates with the data type of the value [in memory] they are pointing to.
<h3>Things to note</h3>
When you declare two variables in the manner below:
<pre><code> int *x, y
</code></pre>
what this means is that there is a one pointer decalaration of type int and one actual variable.
<ul>
<li>
the * star operator decorates the variable and not the variable type
</li>
<li>
so int *x, y; -> one pointer decalaration of type int and one actual variable;
</li>
<li>
int *x, y
</li>
<li>
x = &#x26;y;
</li>
<li>
Let's assume you have a house class with some members like square feet, color, design...etc and then you create a new house object off the house class.
</li>
</ul>
When the new house object gets created and stored in memory, you might want to access its content; maybe check to see the color or design of the house. To do this, rather than use a copy of the house, you can use a pointer to the location of the house in memory to directly access the content of the house (or its value)
<ul>
<li>pointers allow us to pass variables by value instead of reference</li>
<li>pointers allow for proper resource management since it cuts down the work of creating copies of variables and instead provides direct access to the variable values</li>
<li>pointers do not hold any actual values or variable types. They hold the address of the the values in question. They point to the location in memory where the values are stored</li>
</ul>
<pre><code> // a character or a collection of strings variable declaration
 char sampleCharVar[] = "Hello world!";

 // prefixing "&#x26;" to a variable returns the memory address where the actual value of the variable is stored
 // and 
 char* samplePointerVar = &#x26;sampleCharVar;

 // prints out the memory address of the sampleCharVar 
 printf("%p\n", samplePointerVar);

</code></pre>
In the example above, we declare a variable "sampleCharVar" to hold a string of characters, "Hello world!" and this gets stored in memory. To retrieve the memory address of the variable, we use an ampersand symbol (&#x26;), also called a dereferencing operator.
<h4>The need for pointers in C</h4>
We use pointers to store addressess instead of using a value
// using pointers instead of variables or copies of the variables
// being able to pass the variables/data between functions in a different way
// if we make a change in one function, the effect can take place in a different function
<pre><code>int k;
</code></pre>
-->
<h4>Where and how to use them in C?</h4>

Pointers in C

I'm currently working on a creative website built with Pug and Webpack that's being served via Express. In this post, I'll layout how to setup a new project with these tools in a series of steps.
Link to boilerplate repo: https://github.com/Uzoamaka126/express-pug-webpack-boilerplate
<h3>Steps</h3>
<ol>
<li>Create a github repository for your new project (optional)</li>
<li>Initialize your project</li>
<li>Install dependencies</li>
<li>Install dev dependencies</li>
<li>Create your Webpack config files</li>
<li>Setup other files</li>
<li>Setup scripts in your package.json to run your build and development commands</li>
<li>Test that your setup works</li>
</ol>
<h3>Create a github repository</h3>
Go to <a href="https://github.com">Github</a> to create a new repository for your project. This is a completely optional step if you use a different version control service, you are playing around or running this in an online playground. After creating the repository, open your terminal and run the git clone (remote-url) command to clone the repository locally.
<h3>Initialization</h3>
Next, we run the "npm init" command to create the package.json file which helps scaffold the node packages our project relies on to run. Any package we install shows up on this file with its installed version number. This file also stores meta data and contains the scripts we'll need to run the project -- in this case, we're going to need a build script for production and a dev script for development.
<h3>Install dependencies</h3>
Dependencies are packages our projects rely on to run in production or users will need to install when they run our app. In your terminal, run the following to install the dependency packages
<pre><code> npm install express pug node-sass
</code></pre>
<h3>Install dev dependencies</h3>
We use dev dependencies during development, so the following packages below need to be installed as dev dependencies. In your terminal, run the following command and add the package name after it. You can run the installs individually or at the same time by writing them in one straight line.
<pre><code>/* 
 @babel/core, dotenv, errorhandler, nodemon, webpack, webpack-cli, 
 webpack-dev-server, webpack-merge, postcss-loader, sass, sass-loader, 
 mini-css-extract-plugin, file-loader, css-loader, babel-loader, concurrently, 
 clean-webpack-plugin, copy-webpack-plugin
*/
</code></pre>
Individually
<pre><code> npm install &#x3C;package-name>
</code></pre>
or simultaneously
<pre><code> npm install @babel/core dotenv errorhandler ...
</code></pre>
Yes, they are quite a lot but since we are not working with a build tool that abstracts the work of bundling packages, we are going to do it manually using webpack and babel. Libraries/frameworks like <a href="https://nuxt.com/">Nuxt</a>, <a href="https://vuejs.org/">Vue</a> or <a href="https://react.dev/">React</a>, provide the option of having Webpack and Babel baked in, package bundling abstracted away, and ready to use out of the box.
This project uses scss in place of css, so we are adding the following package loaders below to help with ...
<pre><code> postcss-loader css-loader sass sass-laoder mini-css-extract-plugin
</code></pre>
If you plan on using regular css, you can skip the installation of the above packages.
<h3>Create Webpack config files</h3>
We're going to create three different webpack config files. One for the source config, one for development and the other for production. The output of the build files are going to be put in a public directory that gets rebuilt every time the build command runs
Source config (webpack.config.js)
<pre><code> const path = require('path');
 const webpack = require('webpack');
 const { CleanWebpackPlugin } = require('clean-webpack-plugin');
 const CopyWebpackPlugin = require('copy-webpack-plugin');
 const MiniCssExtractPlugin = require('mini-css-extract-plugin');

 const IS_DEVELOPMENT = process.env.NODE_ENV === 'dev';

 const sourceDir = path.join(__dirname, 'src');
 const sharedDir = path.join(__dirname, 'shared');
 const stylesDir = path.join(__dirname, 'styles'); // skip if you are using vanilla css
 const modulesDir = 'node_modules';

 module.exports = {
 entry: [
 path.join(sourceDir, 'index.js'),
 path.join(stylesDir, 'index.scss')
 ],

 resolve: {
 modules: [sourceDir, sharedDir, stylesDir, modulesDir]
 },

 plugins: [
 new webpack.DefinePlugin({
 IS_DEVELOPMENT
 }),

 new CopyWebpackPlugin({
 patterns: [
 { from: './shared', to: '' }
 ]
 }),

 new MiniCssExtractPlugin({
 filename: '[name].css',
 chunkFilename: '[id].css'
 }),

 new CleanWebpackPlugin()
 ],

 module: {
 rules: [
 {
 test: /\.js$/,
 use: { loader: 'babel-loader' }
 },

 {
 test: /\.scss$/,
 exclude: /node_modules/,
 use: [
 {
 loader: MiniCssExtractPlugin.loader,
 options: { publicPath: '' }
 },
 { loader: 'css-loader' },
 { loader: 'postcss-loader' },
 { loader: 'sass-loader' }
 ]
 }
 ]
 },
}

</code></pre>
Build config file extended from the source config file (webpack.config.build.js)
<pre><code> const path = require('path')
 const { merge } = require('webpack-merge')
 const config = require('./webpack.config')

 module.exports = merge(config, {
 mode: 'production',

 output: {
 path: path.join(__dirname, 'public')
 }
 })
</code></pre>
Dev config file extended from the source config file (webpack.config.development.js)
<pre><code> const { merge } = require('webpack-merge')
 const path = require('path')
 const config = require('./webpack.config')

 module.exports = merge(config, {
 mode: 'development',

 devtool: 'inline-source-map',

 devServer: {
 static: {
 directory: path.join(__dirname, 'public'),
 },
 devMiddleware: {
 writeToDisk: true,
 },
 },

 
 output: {
 path: path.resolve(__dirname, 'public')
 }
 })
</code></pre>
<h4>Setup other files</h4>
Create an app.js file in your root directory. This is going to be the entry file for your express server. This file contains setup for things like serving your pages on the server side, global error handling and logging, passing the data you need to your pages and listening for changes.
app.js
<pre><code> require('dotenv').config();

 const logger = require('morgan')
 const express = require('express');
 const errorhandler = require('errorhandler');
 const app = express();
 const port = process.env.PORT || 3000;
 const path = require('path');

 // meta data for pages
 const meta = {
 title: "",
 image: {
 "url": "",
 "alt": ""
 }
 }

 app.use(logger('dev'));
 app.use(errorhandler());
 app.use(express.static(path.join(__dirname, 'public'))); // Serves the static file returned by the build

 // functions to use within your pug components
 app.use(function (req, res, next) {
 res.locals.Link = function(link) {
 if (link &#x26;&#x26; link === "Home") {
 return "/"
 }

 if (link &#x26;&#x26; typeof link === 'string') {
 return `/${link.toLowerCase()}`
 }
 };

 next();
 })

 app.set('views', path.join(__dirname, 'views'));
 app.set('view engine', 'pug');

 app.get("/", function (req, res) {
 res.render('pages/home', { meta: { ...meta, title: "Home" } });
 })

 app.get("/about", function (req, res) {
 res.render('pages/about', { meta: { ...meta, title: "About us" } });
 })

 app.get("/features", function (req, res) {
 res.render('pages/features', { meta: { ...meta, title: "Our Features" } });
 })

 app.get("/features/:id", function (req, res) { 
 const id = req.params.id;

 res.render('pages/single-feature', { 
 id,
 meta: { ...meta, title: `Page ${id}`}
 });
 })

 app.listen(port, function() {
 console.log(`Example app listening at http://localhost:${port}`);
 })
</code></pre>
Next, we're going to create the directories and files we need with the following steps:
<ol>
<li>In the root directory, create a server**, shared, views and client directory respectively.</li>
<li>In the views directory, create two separate directories; pages and partials. The pages directory is going to house all our page views. The partials directory is going to contain reusable components like layouts, loaders..etc</li>
<li>In the views directory, create an index.pug file. This is going to be our base file from which every other page view file is going to extend from.</li>
<li>Next, in the views/pages directory, create your .pug files. Ideally, this should be page views files that are going to be served by the express server. Inline with the boilerplate, we're going to create 4 different .pug files: home.pug, about.pug, features.pug, single-feature.pug. These are placeholder pages and can always be removed as needed.</li>
<li>Finally, copy and paste the following content below into their respective files</li>
</ol>
Note: unlike regular HTML, Pug will throw an error if there is an invalid or inconsistent indentation. Try to follow a consistent indentation pattern to avoid these errors.
index.pug
[In this file, multiple CSS files can be added to the head block. If you are using CSS pre-processor like SCSS, you'll need a compiled CSS file (this is our main.css file below)]
<pre><code> block variables

 doctype html
 html(lang="en") 
 head
 meta(charset="UTF-8")
 meta(name="viewport" content="width=device-width, initial-scale=1.0")

 base(href="/")

 title=meta.title

 meta(name="description" content=meta.description)

 link(rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png")
 link(rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png")
 link(rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png")
 link(rel="manifest" href="/site.webmanifest")

 link(href="main.css" rel="stylesheet")

 meta(property="og:type" content="website")
 meta(property="og:title" content=meta.title)
 meta(property="og:description" content=meta.description)
 meta(property="og:image" content=meta.image ? meta.image.url : '')

 meta(name="twitter:card" content="summary_large_image")
 meta(name="twitter:title" content=meta.title)
 meta(name="twitter:description" content=meta.description)
 meta(name="twitter:image" content=meta.image ? meta.image.url : '')

 body
 include ./partials/nav

 .content#content(data-template=template)
 block content
</code></pre>
home.pug
<pre><code> extends ../index.pug 

 block variables
 - var template = 'home' 

 block content
 .wrapper 
 | This is the home page
</code></pre>
about.pug
<pre><code> extends ../index.pug 

 block variables
 - var template = 'about' 

 block content
 div This is the about page
</code></pre>
features.pug
<pre><code> extends ../index.pug 

 block variables
 - var template = 'features' 

 block content
 .wrapper 
 | This is the features page
</code></pre>
single-feature.pug
<pre><code> extends ../index.pug 

 block variables
 - var template = 'single-feature' 

 block content
 .wrapper 
 | This is the single feature details page. The params id is #{id}
</code></pre>
<h3>Setup build and dev scripts in package.json</h3>
Now, that we've set up these directories and files, we can setup our dev and build scripts that enables us to run our app in either dev or production mode. Inside your package.json file, go to the scripts object and paste the following
package.json
<pre><code> "scripts": {
 "server:build": "node app.js",
 "server:dev": "nodemon app.js",
 "client:build": "webpack --progress --config webpack.config.build.js",
 "client:dev": "webpack serve --progress --config webpack.config.development.js",
 "start": "concurrently --kill-others \"npm run server:dev\" \"npm run client:dev\""
 },
</code></pre>
We're using the <a href="https://www.npmjs.com/package/concurrently">concurrently</a> package to run multiple commands concurrently (no pun intended).
Run the npm run start command to test run the app. You should see something in your terminal like this below
<pre><code> [0] [nodemon] starting `node app.js`
 [0] Example app listening at http://localhost:3000
</code></pre>
<h3>Test app</h3>
Open the development link in your browser to confirm that your app is running. You should see a bare-bones page with 3 different navigation links; Home, About and Features.
<h3>Notes</h3>
Here are some resources you might find helpful
<ul>
<li><a href="https://expressjs.com/en/guide/using-template-engines.html">Using template engines with Express</a></li>
<li><a href="https://pugjs.org/api/express.html">Express Integration with Pug</a></li>
<li><a href="https://pugjs.org/api/getting-started.html">Getting started with Pug</a></li>
<li><a href="https://nodesource.com/blog/an-absolute-beginners-guide-to-using-npm/">An Absolute Beginner's Guide to Using npm</a></li>
<li><a href="https://webpack.js.org/configuration/dev-server/">Webpack DevServer</a></li>
</ul>

Setup a new project with Pug, Webpack and Express

*putting this up as a blog post so it's easily accessible to me whenever I need it. This isn't a perfect solution but it worked for me.
I'm currently building a <a href="https://calm-custard-ddb033.netlify.app/login">freelance management tool</a> that's reasonably tailored to my (on the side) freelancing needs and I ran into a minor issue a few days ago. I had a list of items to iterate over. Each item had several keys, one of which was a "name" key with string values. Some string values had at least one whitespace, while others had whitespaces and at least one special character.
On every iteration, the idea was to create a new key, called "path" with a string value by taking the value of the "name" key, call the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/trim">String.prototype.trim()</a> method on it, then call the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/join">Array.prototype.join()</a> method on the returned array to produce a different string value as seen in the example below:
<pre><code class="language-JS">&#x3C;script>
 // initial array
 const items = [
 ...
 { name: 'App Integrations', iconName: 'grid' },
 ....
 ]
 // after iteration and transformation becomes
 const transformedArr = [
 ...
 { name: 'App Integrations', iconName: 'grid', path: 'app-integrations' },
 ....
 ]
&#x3C;/script>

</code></pre>
This is a non-issue if each string value is guaranteed to contain only one whitespace but in the event of dynamic multiple whitespaces or at least one or more special characters, things can get tricky easily. While the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/trim">String.prototype.trim()</a> method is very useful for trimming out white spaces, it doesn't extend to special characters. One hack is to trim the string value first before calling the .split() method, and finally, the .join(*operator) method. There might be some drawbacks to this approach regarding the performance but I'm not very familiar with that.
<pre><code class="language-JS">&#x3C;script>
 // helper function to be run on every iteration
 function transformPath(name) {
 if (!name) return "";

 const regexPattern = /\s\W*/;

 return name?.trim()?.split(regexPattern)?.join("-")?.toLowerCase();
 }

 // result
 const transformedArr = [
 ...
 { name: 'App Integrations', iconName: 'grid', path: 'app-integrations' },
 { name: 'Billings &#x26; Plans', iconName: 'money', path: 'billings-plans' },
 ....
 ]
&#x3C;/script>

</code></pre>
Another hack is calling the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace">String.protoype.replace()</a> method on the string value. This method takes in two parameters, a string or a <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp">RegExp</a>, a value to replace the string with and returns a new string. We'll pass in a regex value as the first parameter and an empty string as the second parameter. Call the split method on this new string, passing in a second regex expression which matches special characters; in regex, /W matches all non-word characters. Call the <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/join">Array.prototype.join()</a> method on the returned array. You can choose to further transform the returned string to lower case characters.
<pre><code class="language-JS">&#x3C;script>
 // helper function to be run on every iteration
 function transformPath(name) {
 return name.replace(/(\s)*/g, '').split(/\W/g)?.join("-")?.toLowerCase();
 }

 // result
 const transformedArr = [
 ...
 { name: 'App Integrations', iconName: 'grid', path: 'app-integrations' },
 { name: 'Billings &#x26; Plans', iconName: 'money', path: 'billings-plans' },
 ....
 ]
&#x3C;/script>

</code></pre>
As I mentioned earlier, there might be some performance or even readability issues with these solutions but they work (even if temporaily). Maybe, I'll come back someday to update this article if I find a more performant approach or an approach with less overkill.
<h3>Notes</h3>
Leaving some notes below, as usual. Here are some resources for this issue that I've found helpful:
<ul>
<li><a href="https://regex101.com/r/nK3zB3/1">Regex101</a>,</li>
<li><a href="https://regexr.com/">Regexr</a>,</li>
<li><a href="https://bobbyhadz.com/blog/javascript-split-string-special-characters#:~:text=To%20split%20a%20string%20by,an%20array%20containing%20the%20results.">Bobby Hadz</a>,</li>
</ul>

Experimenting with various ways to alter a string

Forms are a core part of the web, and that’s not going away anytime soon. It’s practically a way to collect information on the web that may be utilized elsewhere. Given how vital forms are to the web, I've set out to learn about them as much as possible. In this article, I look at form actions, its default behavior, and potential bugs we might run into if we ignore such behaviours.
HTML supplies us with a form tag that allows us to use forms on the web. This tag works as a container for input elements, which are form elements by extension. If certain default actions in a form are left unchecked, they can create minor issues. An example is a recent bug I ran into that nicely captured what occurs when you ignore some of the default behaviors on a form. I had wrapped two different check input components in a form element tag with a button that had a "Next" CTA. The expected behaviour was that when a check component is selected and the button is clicked, the current selection value is set, and the user is sent to the next page. However, when the button was clicked, a page reload occurred that resulted in the current selection being cleared. This bug prevented me from getting past the current page, so I tried debugging the issue. Turns out that the reason for the page reload on click was because the form action attribute wasn't set, and as a result, a page reload occurs every time the form is submitted.
The form action attribute captures the action that will be executed when a form is submitted. When we submit a form, we usually transfer the data collected on the form to a server. A form's action is triggered for execution when its button or input element with a type="submit" attribute is clicked or the enter key is pressed after the value of its last element has been set. Usually, the expected behaviour of a form's submit event is to run the value of the provided action attribute. So, in the absence of an action, most browsers will point the form to the current URL loaded in the browser, and a page reload occurs. Because I didn't set the action attribute on the form which enclosed the check components, the bug that I described earlier occurred.
A helpful way of bypassing this behaviour is to listen for the submit event on the form and then call the .preventDefault() method. This method cancels an event from taking place, if possible. When used on a form, it cancels the default action that happens when a form's submit event is triggered. Of course, depending on the frontend framework in use, there are various approaches to this. In vanilla JavaScript, one approach is to use an addEventListener inside a script - as shown in the code example below - to listen for the submit event on the form.
<pre><code class="language-HTML">
&#x3C;form id="form">
 &#x3C;input value="name" >
 &#x3C;input value="submit" type="submit">
&#x3C;/form>

</code></pre>
<pre><code class="language-JS">&#x3C;script>
 document.getElementById("form").addEventListener("submit", function(event){
 event.preventDefault();
 });
&#x3C;/script>

</code></pre>
Frontend frameworks like Vue provide a <a href="https://vuejs.org/guide/essentials/event-handling.html">v-on</a> directive on the form to listen for events. The directives can be called as inline or method handlers. The examples below show ways to add the .preventDefault method as an inline or a method handler
As an inline handler
<pre><code class="language-HTML">
&#x3C;!-- the .prevent means that submit event will no longer reload the page -->
&#x3C;form @submit.prevent>&#x3C;/form>

</code></pre>
As a method handler
<pre><code class="language-HTML">&#x3C;!-- Template -->
&#x3C;form id="form" @submit="handleSubmit">
 &#x3C;input value="name" >
 &#x3C;input value="submit" type="submit">
&#x3C;/form>

</code></pre>
<pre><code class="language-JS">// Script
methods: {
 handleSubmit(event) {
 event.preventDefault();
 }
}

</code></pre>
<h3>Notes</h3>
Here are some resources on form behaviours and event propagation:
<a href="https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attributes-for-form-submission">HTML Spec Docs</a>,
<a href="https://www.freecodecamp.org/news/a-simplified-explanation-of-event-propagation-in-javascript-f9de7961a06e/">FreecodeCamp</a>,
<a href="https://vuejs.org/guide/essentials/event-handling.html">Vue</a>,
<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form">MDN</a>

Form Actions

A not-too-tricky UI challenge at work had me scouring the internet for CSS tips around scrollbars on Apple devices. I had a dropdown feature with
a scrollbar that rendered a list of items. The scrollbar was visible on a Windows system but not on a Mac or an iPhone. This was a UX problem because users thought the dropdown only contained no more than 4 items when viewed on a Mac or an iPhone. Turns out that iOS has a default behaviour where scrollbars are not visible until a user starts scrolling.
A helpful way of changing this default behaviour is by customizing your own scrollbar. In 2018, the W3C org released <a href="https://www.w3.org/TR/2018/WD-css-scrollbars-1-20180925">a way</a> to customise the apperance of scrollbars using CSS. It's a non-standard method of styling, so, it makes use of the <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/WebKit_Extensions">::-webkit</a> vendor prefix to overwrite the default apperance/behaviour of scrollbars. It's also good to note that only webkit browsers support these prefixes. (The official docs page of Mozilla Developers puts out this warning at the top of each prefix.)
Writing a custom scrollbar for iOs devices only involves a few lines of code and needs no JavaScript. There are several pseudo-elements that can be used to customize a scrollbar on a webkit browser. To be able to use these pseudo-elements, they must be prefixed with "-webkit-". Some of these pseudo-elements we are going to make use of are:
<pre><code>
 ::-webkit-scrollbar {/* targets the entire scrollbar container */}
 ::-webkit-scrollbar-button {/* targets the buttons positioned at the top and bottom of the scrollbar */}
 ::-webkit-scrollbar-track {/* targets the space below the progress bar. Think of it as a layer on top of the base scrollbar */}
 ::-webkit-scrollbar-track-piece {/* not covered area by the scrollbar-thumb */}
 ::-webkit-scrollbar-thumb {/* targets the draggable area of the scrollbar */}
 ::-webkit-scrollbar-corner {/* targets the bottom part of the scrollbar, where both horizontal and vertical scrollbars meet */}
 ::-webkit-resizer {/* targets the draggable resizing handle that appears at the bottom corner of some elements */}

</code></pre>
The code below puts some of these elements to use in order to create a custom scrollbar:
<pre><code>
 .parent {
 height: 200px;
 width: 300px;
 border: 1px solid #ddd;
 width: 25vw;
 background: #eee;
 overflow-y: scroll
 }
 .parent::-webkit-scrollbar {
 background-color: #fff;
 width: 10px;
 }

 .parent::-webkit-scrollbar-track {
 background-color: #fff;
 }

 .parent::-webkit-scrollbar-thumb {
 background-color: #babac0;
 border: 4px solid #fff;
 border-radius: 16px;
 }

 .parent::-webkit-scrollbar-button {
 display:none
 }
 .child{
 min-height: 100vh
 }
</code></pre>
In the code above, the property, .parent::-webkit-scrollbar sets the total width of the entire (vertical) scrollbar while the height automatically adjusts to the height of its parent container.
.parent::-webkit-scrollbar-track sets our scrollbar background color to white.
.parent::-webkit-scrollbar-thumb sets the background color, border radius and border of the movable/scrolling indicator. The border radius is set to 5px for rounded edges instead of default flat edges.
.parent::-webkit-scrollbar-button is set to display: none because I don't want the top and bottom buttons visible.
The screenshot below is what the output looks like. Also, this is a blown up shot of the code pen result. You can find the Codepen <a href="https://codepen.io/uzoamaka126/pen/dyVxmVy">here</a>
<img src="/code_screenshot.png" alt="a screenshot of the output of the code above">
That's all, folks!
If you want to read more on custom scrollbars and their pseudo-elements used to style them, I have attached some links below.
<h3>Notes</h3>
Here are some resources I found helpful on Webkit scrollbars:
<ol>
<li><a href="https://www.webkit.org/blog/363/styling-scrollbars/">Dave Hyatt's styling scrollbars</a>,</li>
<li><a href="https://www.digitalocean.com/community/tutorials/css-scrollbars">Digital Ocean's CSS scrollbars</a>,</li>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-scrollbar">Mozilla Docs</a></li>
<li><a href="https://css-tricks.com/custom-scrollbars-in-webkit/">CSS Tricks</a></li>
</ol>
Also, you can check <a href="https://caniuse.com/?search=scrollbar">caniuse</a> to look up browsers that currently support scrollbar styling.

Scrollbars and iOS

Hello there, and welcome to 2022!
It's the first month of the new year, which means that the term new year, new me is still in full swing. So, I've joined the swing by taking on a new challenge at work: working on an existing codebase that uses TypeScript + Vue. My knowledge of TypeScript is minimal - almost nonexistent - and going back to the basics has been fun so far.
Going back to the basics involves trying to understand the conceptual aspects of TypeScript and type systems in general. What is a type system? What are typings? Why is it useful? What do people mean when they say a language is static, duck, or strongly typed?
<h3>Typing</h3>
Assigning a data type to a value or variable.
<h3>Type checking</h3>
Type checking ensures that functions and variables operate within the limit of their constraints. It helps us answer questions like "Does this align with the defined constraints of this value I am trying to use?". It also acts as a way to help us write better programs by stating our intentions with every line of code.
<h3>Type systems</h3>
Type systems are categorized as static, dynamic, structural, nominal, strongly, or weakly typed.
<h3>Static vs Dynamic types</h3>
Static or dynamic typing is based on whether type checking is done at runtime or compile time. What this means is when I write a code in a language that is statically typed, I need to define the types in my code because type checking is done at run time. Examples of statically typed languages are TypeScript, Java, C#, C++;
For dynamic type systems, type checking is carried out at compile time. Not defining types on the go does not prevent the code from running because type checking is done when the language is being compiled (at compile time). Examples of dynamically typed languages are JavaScript, PHP, Python. Although, some languages present the option of taking a static typing route by providing us with optional annotations.
The simple function addTwoNums below is an example of a typed function that takes two parameters - both numbers - and returns the sum of the parameters, also a number. Type checking ensures that only the defined type for each parameter is allowed to be passed in as an argument and nothing else. If I pass in a string instead of a number, TypeScript flags it instantly. Type checking also ensures that the return value of my function is also a number. Not a string, not an object, or an array but a number.
<pre><code>
 function addTwoNums(a: number, b: number) {
 return a + b // this is also going to be a number
 }

</code></pre>
<h3>Structural vs Nominal</h3>
As the name implies, a nominal typing system is typing based on naming. In this category of type systems, the equivalence of types are decided by the name of the types. In a structural typed system, typing is decided based on the structure of the types.
<h3>Strongly vs weak typed</h3>
These particular categories have very loose definitions. This means there is no general or universally accepted definition of a strongly or weakly typed language. Although, I found an excerpt below from Wikipedia on strongly typed systems:
<blockquote>
The more type restrictions that are imposed by the compiler, the more strongly typed a programming language is. Strongly-typed languages often require the programmer to make explicit conversions in contexts where an implicit conversion would cause no harm. Pascal's type system has been described as "too strong" because, for example, the size of an array or string is part of its type, making some programming tasks difficult. Haskell is also strongly typed but its types are automatically inferred so that explicit conversions are often unnecessary.
</blockquote>
<h3>Notes</h3>
Here are some resources I found helpful when starting out with TypeScript:
<ul>
<li><a href="https://en.wikipedia.org/wiki/Type_system">Wikipedia</a>, <a href="https://en.cppreference.com/w/cpp/language/implicit_conversion">CPPreference</a>, <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-scrollbar">Mozilla Docs</a>,</li>
<li><a href="https://css-tricks.com/custom-scrollbars-in-webkit/">CSS Tricks</a>, <a href="https://www.cs.princeton.edu/courses/archive/spring12/cos320/typing.pdf">Princeton - typing</a>,</li>
<li><a href="https://en.wikipedia.org/wiki/Nominal_type_system">Wikipedia - Nominal Type System</a></li>
<li><a href="https://en.wikipedia.org/wiki/Structural_type_system">Wikipedia - Structural Type System</a></li>
</ul>

Getting Started with Typescript

Game of Life

Writing CSS is hard. It’s one thing a lot of us can agree on. There are a lot of things to grapple with and as a codebase grows, it becomes harder to maintain. A common problem with this is overrides, i.e when the properties of a CSS class that is defined somewhere in a file get replaced by the properties of another CSS class defined somewhere else with the same [class] name - either on the same or a different file.
When setting up a new codebase, one of the challenges I face is choosing a maintainable CSS structure. It has to be a structure that is easy to understand, follow, test, and debug. Oh, it also has to be easily searchable. There is always the temptation to veer off the current CSS structure on a codebase and write something quick that solves the problem, especially with time-bound features. Taking the time to map out a list of things to consider as I build has saved me a considerable amount of time and debugging energy.
In this post, I will share some tips for writing consistent and clean CSS that I have picked up along the way.
<h3>Identify base selectors</h3>
Base selectors target HTML elements in their tag form, e.g, p, a, h1, h2, body…etc. Once I identify the base selectors, I do a conventional CSS reset which helps to manage browser inconsistencies. (Not all browsers share the same default styles, so it makes sense to do a reset to enable us to start on a clean slate). Next, I set the default styles for these elements. For me, this also includes setting styles for the typography.
<h3>Identify and create a base layout</h3>
CSS layouts get mixed up sometimes with components. Although they both share a similar function of grouping related things, I see layout as more of a container that houses components to give pages a specific shape. There are several ways to imagine a layout based on the page’s design. After defining the layout, I move on to naming.
<h3>Naming conventions</h3>
Naming in programming is difficult and one of the most important things we have to do as we build software applications. Naming allows us to recognize features with similar functions and group them accordingly. It also allows for the separation of concerns.
There are several CSS naming conventions like this and <a href="https://groups.google.com/g/sass-lang/c/F9MnjqSCaPs/m/H6R7rGR7E-cJ">this</a> The BEM (Block, Element, Modifier) convention is one that I find useful for naming classes, especially when working with components. It also provides structure and is easy to understand.
<ul>
<li>The block in the BEM is for components that are abstracted at their base level. Think of it as something that can act as a standalone, i.e a button, header, or modal.</li>
<li>The element is dependent on the block. It has no meaning without the block (parent), e.g, the links in a navbar</li>
<li>The modifier is used to change the state of either the block or element, such as its appearance or behaviour.</li>
<li>For BEM naming, I prefer to use a double hyphen to separate the block and the modifier, an underscore to separate the block and element. For a class that combines all three, I use an underscore to separate the block and element, and then, double hyphen to separate the element and modifier. Just like the example below:</li>
</ul>
<pre><code class="language-css">/**** block acting as a standalone ***/
 .header {
 border: none;
 padding: 15px 30px;
 text-align: center;
 font-size: 16px;
 cursor: pointer;
 min-height: 50px;
 }
 /* block and a modifier combined */
 .header--lg {
 min-height: 80px;
 }
 /* block, element and modifier combined */
 .header__item--lg {
 font-size: 20px;
 }

</code></pre>
<h3>Thinking in components</h3>
Thinking in components when writing CSS helps me identify patterns that can be abstracted. That is, it shows me parts of my CSS code that have been repeated and if I have to write a particular style more than once, it makes sense to bundle that repetition into a single class and reuse that class in different instances. This helps with reusability and less bulky code.
When thinking in components, naming classes is very key. I usually want to name classes in a way that is intuitive and reusable. For example, having a component class name like <code>.homepage-nav</code> is limiting and doesn’t describe the full functionality of the component. Renaming the above component to something like a <code>.nav</code> shifts it to a general component that is applicable in a different context.
Also, if I use CSS pre-processors, like LESS or SASS, I keep components in their separate files. For example, a <code>button</code> component is written in its <code>button.scss</code> file. This helps me to easily navigate my codebase, especially during debugging.
<h3>The <code>!important</code> property</h3>
I limit the use of this property to when I am 100% sure that I don’t want a property to be overwritten in a codebase. I try to minimize how often I use the property, especially when creating components that need to be overwritten at some point by modifiers.
<h3>Spacing</h3>
For readability purposes, I always add new CSS rules on a new line even if they are comma-separated.
<pre><code class="language-css">.content,
.content-edit {
 
}

/**** vs ***/
.content, .content-edit { 
 
}
</code></pre>
<h3>Comments</h3>
I use comments to specify the beginning and end of similar CSS rules. Helps for better navigation.
<pre><code class="language-css">/************ Button ***********/
.btn {
 …
}
/************ Button ***********/
</code></pre>
<h3>Conclusion</h3>
Writing good CSS is hard and requires us to be intentional about a lot of things. Having documented rules help teams working on or getting acquainted with a codebase navigate the codebase better. Rules can be flexible but always make sure that they are easily understood by stakeholders.
<h3>Notes</h3>
<ol>
<li>Here are some resourcesI found helpful: <a href="https://anotheruiguy.gitbooks.io/sassintherealworld_book-i/content/aLittleUnderTheHood/naming.html">[1]</a>, <a href="https://groups.google.com/g/sass-lang/c/F9MnjqSCaPs/m/H6R7rGR7E-cJ">[2]</a>, <a href="http://getbem.com/introduction/">[3]</a></li>
</ol>

Writing good CSS is hard

There are several ways to imagine a layout. For a site like https://www.google.com/gmail/, I can define the layouts in two different ways: a layout with a header, sidebar, content, and footer or a layout with a header, sidebar, grid, an additional sidebar, and footer.
<a href="https://www.flickr.com/photos/beaurogers/31833779864/in/photolist-Qv3rFw-34mt9F-a9Cmfy-5Ha3Zi-9msKdv-o3hgjr-hWpUte-4WMsJ1-KUQ8N-deshUb-vssBD-6CQci6-8AFCiD-zsJWT-nNfsgB-dPDwZJ-bn9JGn-5HtSXY-6CUhAL-a4UTXB-ugPum-KUPSo-fBLNm-6CUmpy-4WMsc9-8a7D3T-83KJev-6CQ2bK-nNusHJ-a78rQH-nw3NvT-7aq2qf-8wwBso-3nNceh-ugSKP-4mh4kh-bbeeqH-a7biME-q3PtTf-brFpgb-cg38zw-bXMZc-nJPELD-f58Lmo-bXMYG-bz8AAi-bxNtNT-bXMYi-bXMY6-bXMYv"><img src="/assets/images/shiprock.jpg" alt="An old rock in the desert" title="Shiprock, New Mexico by Beau Rogers"></a>{:target="_blank"}
#<img src="https://gist.github.com/Uzoamaka126/433c8def32d7bb9af0b59df22221f4e8" alt="Sample CSS" title="Github Gist">
Writing software for games often provides us with the perfect window to think about people - and objects - in terms of attributes and behaviors

Jigsaw Puzzle Game

For over two years, I avoided the work of setting up, and maintaining a technical blog outside of public publishing platforms like Medium, Hashnode and co.
So, when I decided that I was ready to do the work, I did a little bit of research to see the easiest way for me to setup a blog.
The things I considered were access, maintainability, setup, easy customization, and ownership. It's safe to say that Hugo meets all of my demands hugely. Hugo enables me to have access to my work through the use of terminal commands and markdowns. It works via a command-line interface only, which means that it has no graphical interface for users to interact with using a mouse.
Maintainability is easy for me because all my posts are written in markdown and I can update them whenever I want. When it comes to setup, using Hugo can be a bit tricky if you are not used to working with markdowns, but luckily, Hugo provides directions on how to get started via its documentation <a href="https://gohugo.io/documentation/">here</a>. Also, Hugo has options for you to deploy your site, using selected platforms like Azure, Netlify, AWS Amplify, GitHub..etc. You can find the overview of the deployment/hosting options Hugo integrates with <a href="https://gohugo.io/hosting-and-deployment/">here</a>.
Let's get started on setting up Hugo
First, we want to do a global install. I use a macOS, so the command line I ran is <code>brew install hugo</code>. If you use a different OS or are looking for an alternative install, you can find instructions <a href="https://gohugo.io/getting-started/installing/">here</a>. After installation, double-check that Hugo is installed globally on your system by running the command <code>hugo version</code> to see the version installed on your system. To create a new Hugo project, <code>cd</code> into a new directory, and run the command <code>hugo new site &#x3C;site-name-here></code> in that directory. This generates a new Hugo site for you in your selected directory.
<h4>Selecting a theme</h4>
While themes are not mandatory when using Hugo, they help beautify your site. You can choose to build your theme or pick one from the list of already built themes out there. There are over a hundred Hugo themes that offer different layouts from websites to blogs. You can go through them on <a href="https://themes.gohugo.io/themes">this site</a>.
I chose a theme called Terminal because I found the layout uncommon. The original background for the theme was dark but I was able to customize it [with a separate custom CSS file] to a light theme for readability. To get a custom theme, select a theme on the site by clicking on the theme. Each theme comes with instructions on how to setup but a common way to set it up is to do a <code>git init</code> in your project's directory and then, install the theme as a git submodule.
Once the theme has been installed and previewed, you can then create a new Hugo markdown file by running the command <code>hugo new posts/&#x3C;new-file-name>.md</code>. The <code>new</code> keyword is self-descriptive and indicates that a new markdown file (.md) should be created. The posts path tells Hugo that this new file should be stored in the posts directory.
<h4>Drafts</h4>
When a new markdown content file is created, it has a draft flag which is automatically set to true until a user is ready to publish the file as a post. The flag tells Hugo that the file is in draft mode, and so, is not ready to be published yet. Once we are ready to publish, we set the draft flag to false and run the <code>hugo -D</code> command to build. The output of the build will be stored in a new <code>./public/</code> directory
<h4>Hosting &#x26; Storage</h4>
I think it's great to mention that with Hugo, there isn't any need for a database, in the traditional sense. Content is stored and served in static files.
For hosting, as I mentioned earlier, Hugo integrates with several hosting providers. You can go through the list <a href="https://themes.gohugo.io/themes">here</a> and make a choice. I initially deployed my site with <a href="https://netlify.com/">Netlify</a> - before moving it to my domain site - because it offers easy deployment with the click of a button. (I sound like I am in a commercial. Lol, I know).
That's it! Also, I plan on using Hugo to manage my blog until I come across a better alternative that meets my blog needs.

Setting Up Hugo for My Blog

I’m Uzoamaka, a full-stack developer based in Lagos, Nigeria. I’ve taken a shot at tech in different forms throughout my life; learning about networking in secondary school, graduating with a Bachelor’s degree in Computer Science, attempting to start a career in data science after graduation before moving to build websites for clients.
Then, I decided to write code full time as a full-stack web developer, which has allowed me to play with different software technologies and learn new concepts. It helps my brain not to feel bored now and then.
This is going to act as a sort of diary where I dump my experiences with tools and concepts that I come across as I learn.
This is the reason for choosing to have the What I learnt today phrase as the main title for this site because it resonates with my random style of learning.
<h3>Inspiration</h3>
<a href="https://www.stefanjudis.com/">Stefan Judis</a>, and <a href="https://welearncode.com/">Ali Spittel's</a> blogs.
<h3>Stack</h3>
My stack currently includes HTML, CSS, SVGs, JavaScript (React, Vue &#x26; Node/Express), PostgreSQL, and MongoDB. I also played with AWS, Docker
and Kubernetes when I did the Udacity Nanodegree Cloud Developer program.
This is a long journey for me and I hope to come out on the other side way better than I started.
You can always say Hi 👋 on <a href="https://github.com/Uzoamaka126/">GitHub</a>