For the thing which I greatly feared is come upon me, and that which I was afraid of is come unto me.

Job 3:25, The Bible

I knew it has brewing for a while, but I never thought it would actually come. This whole time I thought I would be able to make an escape from it before it happened, but boy was I wrong and completely blindsided.

Like I said, e don happen¹ 😔.

Earlier this month, I was laid off from my job. I went through various stages through this period — sadness, fear, uncertainty. But one feeling I haven't felt — regret. I wouldn't change a thing if I could.

I enjoyed the job I had. I worked as a software engineer and I love to code. I liked the coworkers I worked with. I had a good time. And before you say "AI took my job", it wasn't that. I would say it was a subjective decision from the company; it's not always your fault.

I'm not the type of person whose life revolves around his job. I believe life is way bigger than that and to think of life in that way is to belittle yourself. I still get to code on my own and as long as that can't be taken from me, I'm happy.

This whole period of unemployment has taught me one thing: family and friends would forever be more important that a paycheck. And that's what a job is at the end, a paycheck. It's not fulfillment. It's not a form of "family". It's a paycheck. And that's okay.

For me, I will be okay. With all the emotions I went through, one that came right from the same day it happened, was relief. I leave everything in God's hands. I know there's a greater future ahead of me. Right now, I'm using the time off to connect with family and friends and just rest. After all, that is what Jesus came to do, give me rest.

For all who are going through the same thing in this recession, I want to encourage you. The storm would soon end and the sun will shine again. Don't lose hope, no matter what you are experiencing right now. The promised land comes after the wilderness.

One thing that I can remember from my late father is, "For a seed to grow, it must first die". And this is my period of "death" — death to my pride in my occupation, and life to a new world of opportunities.

Keep your head above the water; tomorrow is a new day.

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

Alan Kay, the father of OOP

My adapter needs a service
To adapt to any purpose,
And that service kinda functions
As a helper at the junction
Between builders; the conception
Is to model raised exceptions,
Causing tension, also leaving me in dread —
My mind's crowded with code objects in my head. 😵‍💫 😖

Object-oriented programming (OOP) is talked about so much in the software development space. It's a tried-and-true method of creating applications, and many developers swear by it. But what is OOP?

According to Alan Kay, the inventor of OOP, the whole idea was based on biology. Kay (who majored in biology in college) likened objects to biological cells; each cell has its own "data" (DNA) and "logic", and they communicate via chemical "messages". No single cell is in charge of the whole body; the complexity changes from their interactions.

I agree completely with Alan Kay in theory; I only disagree in application. Alan Kay (and a lot of developers) believe that this can be accomplished with a programming language (like his language, Smalltalk). I believe that it's all a mindset and programming languages are only tools we can use to implement OOP.

I'm not saying the programming language does not matter; I'm just saying that the language is not responsible for making your code object-oriented — the developer is.

In other words, there is no silver bullet in software¹, but there's misplaced effort.

Misplaced effort

The abuse of OOP reminds me of the abuse of declarative programming languages by developers who are used to imperative programming languages.

I used to work as a software engineer in in-flight entertainment, and our language of choice for the UI was QML. QML is a declarative language, which means you have to describe what you want to achieve as opposed to listing the step-by-step instructions on how to achieve it.

However, what I noticed with amateur QML developers² is that they would use the language imperatively as opposed to declaratively.

For example, let's say we wanted to animate a side panel in and out of the UI using QML. We could write it declaratively like this:

import QtQuick

Item {
    width: 400
    height: 400

    Rectangle {
        id: sidePanel
        width: 200
        height: parent.height
        color: "#2c3e50"
        state: "hidden" // DECLARATIVE: Start by being "hidden"

        states: [
            State {
                name: "visible"

                PropertyChanges {
                    target: sidePanel
                    x: 0
                }
            },
            State {
                name: "hidden"

                PropertyChanges {
                    target: sidePanel
                    x: -sidePanel.width
                }
            }
        ]

        // DECLARATIVE: Transition from "hidden" to "visible" (and vice versa) is handled automagically
        transitions: Transition {
            from: "hidden"
            to: "visible"
            reversible: true

            NumberAnimation {
                property: "x"
                duration: 500
                easing.type: Easing.OutQuint
            }
        }
    }

    MouseArea {
        anchors.fill: parent
        onClicked: sidePanel.state = (sidePanel.state === "visible" ? "hidden" : "visible");
    }
}

Notice since the code is set up declaratively, animating the side panel is a matter of switching its state from "hidden" to "visible". The intent is very obvious.

However, we could go against the QML "declarative" philosophy and write it imperatively, like this:

import QtQuick

Rectangle {
    id: badPanel
    width: 200
    height: 400
    x: -200
    color: "red"

    PropertyAnimation {
        id: slideIn
        target: badPanel
        property: "x"
        to: 0
        duration: 500
    }

    PropertyAnimation {
        id: slideOut
        target: badPanel
        property: "x"
        to: -200
        duration: 500
    }

    MouseArea {
        anchors.fill: parent
        onClicked: {
            // IMPERATIVE: Manually checking values and firing commands
            if (badPanel.x < 0) {
                slideIn.start();
            } else {
                // Now you have to write a second animation for sliding out!
                slideOut.start();
            }
        }
    }
}

Here, the developer has to explicitly check values and start the animations.

Both snippets of code work, but only one embodies the principles of declarative programming.

As I've illustrated, QML, a declarative language, can still be written in an imperative way. The language does not prevent it completely — it only makes it awkward and more difficult to do incorrectly (i.e. the imperative way)³.

OOP is great...

I use OOP (a lot 🙈) because it works:

• It keeps my code maintainable. It's nice to reason each class/module etc. as an "object" that is independent of all other objects. Then I get to route messages between them like a patchbay.
• In my experience, OOP works better for software that is developed for people that don't know how to code (i.e. the masses). This is because we all intuitively think in objects, and mapping human problems to objects (i.e. modelling the domain) becomes easier. In that way, OOP democratized computer programs.
• OOP helps me to reason about architecture better, for both my own code and others.
• There is no other way to make large GUI applications. Well, at least for now.⁴

...but OOP is not always the answer

Just because I use OOP, it doesn't mean I shun other paradigms. There are times that I write code procedurally and there are times that I write code using functional programming principles. Use the right philosophy for the right task. It's perfectly legal to mix and match to your taste.

Experienced game developers seem to hate OOP, and I get it. In game programming, performance and speed is very important, so I can understand people taking a more data-oriented approach (also known as Data-Oriented Design or DOD). This is sometimes more efficient, because the programmer writes code with knowledge of the low-level architecture and workings of the computer, and therefore could optimize better. However, a lot of software development doesn't require this. In those cases, OOP may suffice.

The bottom line

OOP is not a programming language; it's a mindset.

We should use programming languages to teach the principles of OOP (and other paradigms) as opposed to relying on them to govern us. The more we understand the philosophy (by reading about it and writing code), the more effectively we can apply it in our favor and most importantly, correctly.

Here are a lists of blog posts I've enjoyed reading recently on the web 🕸️:

• Doing the thing is doing the thing by zerosleeps
• What I actually want to say in tech interviews by Nelson
• Qt Widgets to Qt Quick, An Application Journey Part 1 by the Qt company
• The cults of TDD and GenAI by Drew DeVault
• Emmet for HTML by Asif Ansari
• Frontend is easy to be messed up and we need to organize it by Upon The Sky
• I like when apps are "finished" by Cassidy Williams
• Hell is other people's markup by HTMHell
• Don't forget how far you've come by Mark Pitblado
• Why I write in public by Andre Franca
• Quality: The Concept2 RowErg by Jason Fried from HEY
• Design Principles by Adactio

I asked ChatGPT:

Humans code better than machines, yes or no? Its response

Chase the vision, not the money; the money will end up following you.

Tony Hsieh, Zappos CEO

Inventory tracking by the books is such a pain;
For every sale I make, I have to calculate the gain.
But apps like Record Rack have saved the day, it's such a hack;
It solved my tracking issues and have shown me where I lack.
Even on vacation, I can keep up with my business,
Track goods with precision and know my profit any instant!

Record Rack is the first "big" project I've ever worked on. It would be the first application tailored towards solving actual (paying) customer needs. Before then, I just coded for a hobby and to solve my own problems. The Record Rack project would change all of that.

In this post, I'd like to talk about Record Rack: its purpose, its history, and its evolution.

The problem

Meet Jane Doe.

Jane owns a retail shop in Nigeria. She sells rice, beans, noodles, can tomatoes, pasta, flour, oil, garri, and a lot of other raw ingredients you would find in your kitchen.

From Monday to Saturday, Jane would drive to her shop to monitor all operations that took place. She paid a staff of 5 to sell goods, attend to customers and ensure that the items she had in stock were well accounted for.

As the years went by, the shop only got bigger and more profitable. She tried to open multiple shops in various locations but had to close them down because of theft from her very own staff in those shops. She had seemingly reached an impasse.

And though her business seemed to be at its peak since she's started, it was plagued with unspoken problems:

• All transactions were written on paper, making transactions error-prone and slow. Customers also had to wait long times, leading to some leaving for other nearby shops.
• Receipts were written by hand by her staff, making each transaction take longer. The copy of receipts were done by literal carbon copy.
• At the end of the day, all money made and stock sold (or purchased by the business) had to be balanced. Balancing the accounts involved counting the stock to make sure the quantity is correct and ensuring the money made equals the money documented. Since this was done at the end of the day, workers had to leave late on days where miscalculations happened or a lot of money was made¹.
• Jane was unaware when stock items were low or sold out, making it harder to satisfy customers reliably.
• Jane had no way to measure what stock items sold well or which ones she made the most profit from without measuring it herself from the books.
• Jane had to rely on staff to report the right numbers.
• If any of the books used for taking records was lost, there was no backup.
• Debtors and creditors were loosely tracked in a book. Looking up old records was hard.
• Recurring customers were not tracked. If they were, the business can decide to offer discounts.

Record Rack to the rescue!

Out of all the pain mentioned above, Record Rack wore its cape and offered to save the day 🦸!

From hearing all these issues faced by Jane, my business partner and I rose to the challenge. We were laser-focused on making a software that could solve Jane's problems and the many local retailers that face similar issues.

This ultimately led to the creation of Record Rack.

Record Rack is an inventory management software made with the pain of the Nigerian retail entrepreneur in mind:

• It tracked all the stock items sold and purchased.
• Jane was kept up-to-date on all inventory changes and transactions through a mobile app we provided; she no longer was required to visit her shop to monitor operations.
• Sale transactions were much faster and all receipts were printed by the software. Jane's revenue increased.
• It tracked other income (i.e. income that was not made from stock items).
• It tracked all business expenses.
• It notified the user when a product was low in stock or sold out.
• It allowed users to edit created transactions (useful for customers who needed changes).
• It tracked debtors and creditors, along with each payment made, the deadline for payment and how much was left to pay.
• It supported subunits, allowing users to track goods with multiple units. For example, a carton of noodles can be sold by the sachet instead of the full carton.
• Recurring customers could be tracked and therefore rewarded.
• It used a simple interface. This was important in getting her staff up to speed quickly.

If business is all about relieving pain 🤕, Record Rack was definitely the Tylenol 💊.

Gallery

The official Record Rack logo:

Background used in the main Record Rack application:

Notifications showing items low in stock:

Newer version of the notifications showing items low in stock in red:

"Manage debtors/creditors" window:

"Manage users" window:

Multiple sale and purchase windows:

Multiple sale windows:

First summary page:

Revised summary page:

Old "User Privileges" window:

Revised "User privileges" page:

Add a note to a new sale entry:

The notification widget:

Windows load independent of others:

Highlighted terms for quick search:

Alternate summary page:

Another alternate summary page:

Another alternate summary page:

Show detailed quantity breakdown using the subunits:

List of sale entries for the day:

Miscellaneous details about the project

• Date started: September 2013
• Initial release date: ~ March 2014
• Stable release date: ~ May 2014
• Customers: 1
• Used between: 2014 - 2022
• Released as a desktop app and a mobile app

Tech stack used

• SQLite (later changed to MySQL)
• Qt C++

Record Rack Epsilon

After I left Nigeria, I worked in in-flight entertainment² for a couple years and I decided to work on a new version of Record Rack. This version was created to:

• Address all the bugs of the previous version.
  • There was a lot of rounding errors, since I stored floating point numbers for subunit quantities. (I know, rookie mistake 🙈).
  • There were random crashes.
  • Some days, the application wouldn't record some quantity changes.
• Make the look-and-feel of the application more modern.
• Update the UI code to use QML instead of C++, since QML was better for rapid application development.
• Write better code. The last version's code was monstrous!³.

Unfortunately, this version was canned, but it did teach me a lot about C++/QML development and separating UI and logic.

Gallery

Testing Chart.js (excuse my French in the image 🙈):

Same screen with a more defined sidebar (excuse my French in the image 🙈):

Our company name and logo, Gecko Solutions:

Login screen:

Login screen with access granted dialog:

Login screen with access denied dialog:

Login screen with access granted message (revised design):

Login screen with access denied message (revised design):

Stock page with a product list:

Dashboard page:

New stock item page (though it says "New Sales Entry" 🙈):

New sales home page:

New sales entry page:

Stock page with extended sidebar:

Stock page with collapsed sidebar (ignore the Spider-Man background 🙈):

Old login screen vs new login screen (ignore the Spider-Man background 🙈):

Old access denied screen vs new access denied screen (ignore the Spider-Man background 🙈):

Old access granted screen vs new access granted screen (ignore the Spider-Man background 🙈):

Old login screen vs new login screen (ignore the Spider-Man background 🙈):

Old main screen vs new main screen (ignore the Spider-Man background 🙈):

Old "New Sales Entry" page vs new "New Sales Entry" page with prompt:

Old "New Sales Entry" page vs new "New Sales Entry" page without prompt:

Old stock page vs new stock page:

Old main screen vs new dashboard page:

Login page (again):

Sales home page:

Sign up page:

Sign up page with picture selected:

Stock grid view:

Old stock page:

Miscellaneous details about the project

• Date started: ~ November 2015
• Date ended: ~ November 2018
• Release date: Never released
• Created as a desktop app
• Eventually abandoned

Tech stack used

• MySQL
• Qt C++
• QML
• Chart.js

Record Rack Paper: Yet another version

I stopped Record Rack Epsilon because I got distracted. Plus, it lacked some solid UI patterns like the first version. The first Record Rack used the widgets library from Qt, making the look and feel more consistent. Epsilon used QML, which encouraged you to code the UI yourself from scratch at the time.

Building Epsilon from scratch was kinda hard. Mind you, at the time I knew nothing about typography, colors, spacing, nothing! My shortcomings were revealed in my final design. (Check the Epsilon gallery above.)

So for this version, I chose to use Material Design by Google instead. With the help of a QML library I found on GitHub (called Fluid), I decided to start Record Rack (again) from scratch. This time, I would use more of my experience and all the best practices I've learned over the years.

This was definitely my best attempt, compared to previous years.

Gallery

Unfortunately, I don't have any pictures of this lying around. If I could get it to compile again, I'll update this section.⁴

Miscellaneous details about the project

• Date started: ~ January 2019
• Date ended: ~ November 2020
• Release date: Never released
• Created as a desktop app (to be ported to mobile)
• Eventually abandoned

Tech stack used

• MySQL
• Qt C++
• QML
• Fluid QML (for Material Design components)

Record Rack: To infinity, and beyond!

On October 2025, my college colleague and I decided to give it one more go. We observed that the market is still vacant in Nigeria, and since we've done it before, we believe we could do it again. However, this time, we are much more knowledgeable in our crafts (we both code) and the market needs. My colleague also has connections to some of the businesses that would be interested, so we decided to get back to the Rack!

Over the course of the year, I'll update you on how things are going. Right now, we are still ironing out bugs and features, but we plan to release soon. By the time we release, I would blog more about how that is going. The main focus is to make a product and get it out there as soon as possible so we can get user feedback quickly and iterate.

Gallery

List of products:

"New Sale Entry" page:

"New Sale Entry" page with cart items:

"Stock" home page:

List of income entries:

"Reports" page:

"Stock Reports" page:

Miscellaneous details about the project

• Date started: October 2025
• Release date: To be determined
• Created as a PWA (supported by all platforms a browser can run on)

Tech stack used

• PostgreSQL
• uWSGI
• Nginx
• Vultr
• Flask (Python)
• HTML
• CSS
• JavaScript
• Chart.js

The bottom line

In summary, Record Rack is dead; long live Record Rack! 👑

3 Let nothing be done through strife or vainglory; but in lowliness of mind let each esteem other better than themselves.

4 Look not every man on his own things, but every man also on the things of others.

Philippians 2:3-4, The Bible

They run from you because you drool for cash;
They know that that's your one and only task;
They wish you understood all of their pain;
They know you have no interest in their gain.

I just recently finished reading a book called Company of One and it got me thinking about everything I've learned about business over the years.

Here's a list of points that come to mind.

You need a passion for pain.

It may sound ironic, but it's true. In business, you have to be obsessed with the problem. Through that obsession, you can find solutions for your customers and your customers will be willing to compensate you.

The keyword here is pain. I use that word very intentionally. Whatever your customer is facing has to be equivalent to body pain. And just like we are when we have body pain, we are desperate to alleviate it, even if it costs us a fortune¹.

You need to satisfy at least one customer.

One customer. That is all you need at first. If you can make one customer happy, 2 is a piece of cake, then 3, and so on.

It's very similar to the gospel.

I know this may sound like a stretch, but the gospel has the same format:

1. As a Christian, understand the God-man problem. God wants to fellowship with us, but sin provides a barrier. Therefore, God sent his only begotten Son to save humanity.
2. Go about looking for those in need of help.
3. Offer the solution to a person in need. The solution is the good news (i.e. the gospel) of Jesus Christ dying to save us. This is evangelism.
4. Ask the person if he/she believes. If so, he/she is instantly saved by Jesus. This is an agreement between the person and Jesus that Jesus will give him/her everlasting life.
5. Keep a relationship with the person to ensure he/she is growing in Christ.
6. The new convert repeats the cycle.

Compare this to the business format:

1. Understand the problem.
2. Understand the demographics that need help.
3. Offer a solution (i.e. product or service) to your customers.
4. Enter into a contractual agreement with your customers.
5. Keep up with the customer to make sure the solution still works.
6. If the customer is happy enough, he/she would most likely let others know about your solution.

Both formats start with empathy. Understand the customer's pain, then develop a passion that would lead to the solution.

It's similar to marriage.

Once again, there are similarities with business and marriage:

1. Understand the problem. This involves understanding the shortcomings of your to-be spouse.
2. Understand who else might be involved (like children) that you may have to also help.
3. Offer the solution i.e. marriage.
4. Enter into a contractual agreement with your spouse i.e. marriage.
5. Ensure your spouse is well taken of.
6. If both are happy, the relationship would last until death.

Learning the "Company-of-One method" is helpful in the workplace.

You don't have to be an entrepreneur to apply the principles of the book Company of One. You can do it even at your workplace. It's more of a mindset. With that mindset, your thinking aligns more with the goals and vision of the corporation you work at.

Bottom line

The foundation of business is simple and is not very different from patterns we already engage in. It is up to business owners to recognize the similarities and apply any principle that works with their customers.

When you understand things, there's no more magic.

Tim Burners-Lee, inventor of the world wide web

In my last post, I spoke about how web content is made with HTML and how to write your first lines of HTML code. I also mentioned that HTML is modeled after real-life documents.

In this post, I'd like to go a little deeper on HTML being a document model.

The purpose of the web

The original purpose of the web was to share scientific papers, reports and documentation among researchers over the internet¹. In order for its creator, Tim Burners-Lee, to do that, he created HTML, a language used to create digital documents on the web.

This decision comes with a couple downsides (for instance, it's harder to make web applications than it is to make web documents etc.), but it has a couple advantages, the main one being that anyone who understood documents could learn HTML fairly quickly, as it was just a digital representation of a document.

So how do HTML documents map to real-life documents?

The document parallels

Let's go through each of the individual parts of a document and see how that connects to HTML.

The document itself

Of course, what makes a document is what is in the document, but a document's content has to be written on something. In our world today, that medium is paper.

In HTML, the "paper" that we write upon is the root element called <html>. Therefore, all proper HTML documents start with <html>:

<html></html>

The document head

The document head usually has some information that may be unrelated to the document itself but gives more information about the document.

A perfect example of this is a letter with the address at the top. The address is not needed to understand the letter, but it is helpful in getting the document to where it needs to be, and provides more information for those who are interested.

This parallel exists in HTML as the <head> element. As explained in the last paragraph, the <head> element contains metadata (or "data about data"). It usually appears at the (...you guessed it...) head of the document i.e. the top:

<html>
    <head></head>
</html>

When the HTML page is rendered by the browser, information in the head is not shown to the site visitor at all and is not really considered to be useful to visitor. I see it as a literal head; no one can read the thoughts inside your head².

The only data that could possibly be seen from the <head> element is the <title>. Adding a title to <head> makes the title appear in the browser's tab title area:

<html>
    <head>
        <title>My Webpage</title>
    </head>
</html>

The document body

Next is your document's content. What do you want to tell the world? This is where the <body> element comes in:

<html>
    <head>
        <title>My Webpage</title>
    </head>
    <body></body>
</html>

Everything in the <body> is visible to the site visitor³.

Here is where you could divide your document into the header, the main content, and the footer:

<html>
    <head>
        <title>My Webpage</title>
    </head>
    <body>
        <header></header>
        <main></main>
        <footer></footer>
    </body>
</html>

Note that this structure depends on what the document is. For example, if there is nothing to present in the <footer>, you could leave it out.

The document header

In HTML, <header> is different from <head>. One major distinction is that <header>s are always visible (unless you explicitly hide them) while the <head> is never visible.

The <header> represents what is at the top of your document and is also relevant to the document. An example of elements that may be created under the <header> are navigation bars (i.e. <nav>) and the top heading of the document (i.e. <h1>).

The <nav> element helps you to navigate the document; it contains links (or anchors i.e. <a>) for you to quickly access different parts of the document (or possibly link you to another document entirely). They also act as a table of contents revealing topics covered by the document.

The <h1> element is the heading of your document, giving a short title to the content. Unlike <title>, <h1> is shown on the page, usually at the top.

Updating our document⁴:

<html>
    <head>
        <title>My Webpage</title>
    </head>
    <body>
        <header>
            <nav>
                <ul>
                    <li><a href="#">Home</a></li>
                    <li><a href="#">About</a></li>
                    <li><a href="#">Contact</a></li>
                </ul>
            </nav>
            <h1>Welcome to my site</h1>
        </header>
        <main></main>
        <footer></footer>
    </body>
</html>

The document's main content

The document's main content comes right after the header. This contains the "meat and potatoes" of the site. This portion in HTML contains paragraphs (i.e. <p>), subheadings (i.e. <h2>, <h3> etc), bold text (i.e. <strong>), italicized text (i.e. <em>), highlighted text (i.e. <mark>) and another other tool used in writing to present information.

Adding this to our document:

<html>
    <head>
        <title>My Webpage</title>
    </head>
    <body>
        <header>
            <nav>
                <ul>
                    <li><a href="#">Home</a></li>
                    <li><a href="#">About</a></li>
                    <li><a href="#">Contact</a></li>
                </ul>
            </nav>
            <h1>Welcome to my site</h1>
        </header>
        <main>
            <p>This is where I start to <strong>talk</strong> about what <em>I</em> want <mark>to talk about</mark>.

            <h2>More things I would like to say</h2>
            <p>This is another topic.</p>

            <h2>Even more things I would like to say</h2>
            <p>This is another topic, again.</p>
        </main>
        <footer></footer>
    </body>
</html>

The document footer

This is where you leave the last parts of your documents like links, copyright notices, privacy policies and other information that is not immediately relevant, but relevant nonetheless.

<html>
    <head>
        <title>My Webpage</title>
    </head>
    <body>
        <header>
            <nav>
                <ul>
                    <li><a href="#">Home</a></li>
                    <li><a href="#">About</a></li>
                    <li><a href="#">Contact</a></li>
                </ul>
            </nav>
            <h1>Welcome to my site</h1>
        </header>
        <main>
            <p>This is where I start to <strong>talk</strong> about what <em>I</em> want <mark>to talk about</mark>.

            <h2>More things I would like to say</h2>
            <p>This is another topic.</p>

            <h2>Even more things I would like to say</h2>
            <p>This is another topic, again.</p>
        </main>
        <footer>
            <h2>Welcome again to my site</h2>
            <p>Don't let the door hit you on the way out.</p>
            <p>&copy; My site forever</p>

            <h3>Other Links</h3>
            <ul>
                <li><a href="#">Photos</a></li>
                <li><a href="#">Videos</a></li>
                <li><a href="#">Marketplace</a></li>
            </ul>
        </footer>
    </body>
</html>

Bottom line

I hope this post gave you more of an idea of what I mean by "HTML is a document model"⁵. It mimics documents in so many ways. Understanding this drops the barrier to entry of web programming.

The web is more a social creation than a technical one. I designed it for a social effect — to help people work together — and not as a technical toy.

Tim Burners-Lee, creator of the world wide web

HTML (Hypertext Markup Language) is to the world wide web as English is to Americans; it is not only the language with which we communicate, but also a very part of the culture. Mozilla defines HTML as the most basic building block of the web. All user-facing content in the world wide web is written in HTML, from games to web applications to videoconferencing.

In this article, we'll be exploring how we can make web content from HTML.

What is HTML all about?

HTML is a language for writing web pages. The web pages written in HTML can be displayed by web browsers. The content that you are viewing on this page right now was written in HTML. That is why the browser can render it and you can view it.

The web pages you write with HTML model how documents are written in the real world.

We'll come back to this later.

Let's write code!

Now, I know what you are thinking: "I am not a coder. I have never even read a line of code in my life." Fear not lad — the title of this article was not clickbait! Just follow my instructions.

Let's start with a program that displays the text "Hello, World". In the editor on the left below, type the text Hello, World and watch it appear on the right:

If you see Hello, world appear on the right, then congratulations, you have just written your first line of code 🎉!

Let's spice things up a little bit. In the editor on the left below, change the text from Hello, world to <h1>Hello, world</h1>:

Hello, world

If everything was done right, you should see Hello, world displayed in large font on the right. Good job 🎊🙌!

What just happened?

You wrote HTML code! Hello, world is not standard HTML code, but it's understood by the browser. Why? Because HTML is a markup language. Markup languages are coding systems that use symbols to control structure and formatting. In other words, they are used to enhance text. If no symbols are added, the text is displayed unaltered.

However, in the second code drill, you wrapped Hello, world with h1 tags, which are <h1>, the opening tag, and </h1>, the closing tag. These symbols signal to the browser that the wrapped text is a heading, specifically the topmost heading. This is why the text grew in size, as you would expect of any heading in any document.

HTML as a document model

HTML was created to model documents: it has headings, paragraphs, navigation (which mirrors "table of contents" of a document), lists, sections, headers, footers and all the stuff you'd usually see in a document. In fact, I would go as far as saying the web is just a network of documents. When you visit a website, you receive a document. When you send an email, you send a document. And so on and so forth.

This document model is what makes HTML simpler than most languages. If you understand how to write documents, you are already halfway familiar with writing HTML.

For instance, look at this document:

The equivalent in HTML:

<html>
    <head>
        <title>The Impact of Technology on Society</title>
    </head>
    <body>
        <header>
            <h1>The Impact of Technology on Society</h1>
            <p>Exploring how technological advances shape our daily lives, economy, and future.</p>
        </header>
        <nav>
            <ul>
                <li><a href="#intro">Introduction</a></li>
                <li><a href="#impact">Impact on Society</a></li>
                <li><a href="#future">Future Trends</a></li>
            </ul>
        </nav>
        <section id="intro">
            <h2>Introduction</h2>
            <p>Technology has drastically transformed the way we live, work, and interact. From the rise of the internet to the proliferation of smartphones, its influence is pervasive in every facet of modern life.</p>
        </section>
        <section id="impact">
            <h2>Impact on Society</h2>
            <p>Technological advancements have affected various sectors of society, from communication to healthcare, education, and business.</p>
            <div class="content-section">
                <h3>Communication</h3>
                <p>With the advent of social media and instant messaging apps, communication has become faster and more accessible, bridging gaps across the world.</p>
            </div>
            <div class="content-section">
                <h3>Healthcare</h3>
                <p>Medical technology has improved diagnostic accuracy, treatment options, and patient care. Wearable devices now track health data, providing real-time information to both doctors and patients.</p>
            </div>
            <div class="content-section">
                <h3>Business</h3>
                <p>Technology has streamlined business operations, making processes more efficient and cost-effective. E-commerce, digital marketing, and cloud computing are just a few examples of how tech influences business today.</p>
            </div>
        </section>
        <section id="future">
            <h2>Future Trends</h2>
            <p>The future of technology holds exciting possibilities, from artificial intelligence to quantum computing. Innovations are expected to continue reshaping industries and creating new opportunities for growth and change.</p>
            <ol>
                <li>Artificial Intelligence (AI)</li>
                <li>Virtual Reality (VR)</li>
                <li>Blockchain Technology</li>
                <li>Internet of Things (IoT)</li>
            </ol>
        </section>
        <footer>
            <p>&copy; 2025 Technology Insights, All rights reserved.</p>
        </footer>
    </body>
</html>

As you can see, HTML models real-life documents.

Bottom line

Congratulations, you are a web coder 🕸️ — welcome to the club! Now if you were thrilled with the lesson, you may have a secret passion for writing websites. You can feed your desire at multiple sites that offer free tutorials:

• Free Code Camp
• W3 Schools

And let it be known I'll beat a motherf*cker to death
You'll get a knife stuck in your head so you don't f*cking forget

Pat Stay, battle rapper

Today I was listening to some of my favorite songs and I started remembering some of the bars that have remained in my brain longer than I expected.

Ladies and gentlemen, let me give a list of the bars from some of my favorite artists that are burnt into my brain¹. 🔥🧠

On blind criticism 🙈

Eminem raps in his song, If I Get Locked Up²:

You critics try to criticize but couldn't visualize individuals' lives through a criminal's eyes

Other than the amazing rhythm, this is a deep, honest line. It's easy to criticize people, but do we try to see their lives through their own eyes? Before we judge, we should look at both sides of the coin 🪙.

On world imbalance 🌎

Childish Gambino sings these lyrics in his song, To Be Hunted:

To be happy
Really means that someone else ain't
And balance ain't a one-food take
Everything is give and take

I heard this song again today and that is what inspired this whole post. This hits hard. We forget that if there is rich, there is poor; if there is full, there is hungry; if there is happiness, there is sadness too. We can't have it all, but we should not overlook our privileges.

On childlike creativity 👶

In Kanye West song Power, he raps:

I just needed time alone, with my own thoughts
Got treasures in my mind, but couldn't open up my own vault
My childlike creativity, purity and honesty, is honestly
Being crowded by these grown thoughts

These bars are some of the realest lines I've ever heard from a rapper! To be honest, it's pretty much a summary of my life.

"Time alone" for me has always been a benefit, because that is when I'm at my most creative. And when I finally get that "vault" open, it's curtains! That's when the childlike creativity comes out, but then my "grown thoughts" join the party to bully the poor baby.

On dreams and aspirations 💤

In his song See Me Now, Kanye raps:

Here's something you could use as an analogy
My life is like a child's illusions become reality

I think of this a lot. I've reached points in my life that I never thought I'd be in and I'm grateful. Some of these things I could only dream of as a kid. I know there is still plenty of room to grow, and I definitely don't have it all, but I'm content.

Bottom line

Music is one thing, but adding sense to go along with it is always worthy of praise. Stay tuned, I would drop more posts on this if anymore come to my mind.

The web is a continuum, not a platform.

Alex Russell, Google Chrome team

A couple weeks ago, I started a brand new web project I call Record Rack. It's an inventory application that I'm working on with an old college mate specifically targeted for the African market. Maybe, I'll talk more about the story of Record Rack in a later post.

Over the course of writing the code today, I was going over rules I've picked up along the way from all the web projects I've worked on¹. Here's what I came up with:

• Don't modify CSS through the style property in JavaScript. To change a style, add or remove the class names of an element instead.

  // Don't do this:
  const button = document.getElementById("button");
  button.style.display = "none";
  
  // Do this:
  const button = document.getElementById("button");
  button.classList.add("hidden");
  

  That way, CSS-specific code can stay in your CSS file:

  .hidden {
      display: none;
  }
  

• Use containers to contain data. This may seem obvious but I never knew what containers did in CSS, until I started building interfaces on the web. Containers help to keep elements contained in a certain area of the screen. A common use is to keep text in the center. You can do this simply with a little CSS:

  .container {
      max-width: 800px; /* Keeps contents contained */
      margin-inline: auto; /* Centers the container */
  }
  

• Use SVG spritesheets. This does not get enough attention. SVGs (or Scalable Vector Graphics) are the future of vector graphics. And they have a lot of benefits like being scalable to any size without deterioration in image quality, being lightweight (they are pretty much XML files), and being customizable or extended with CSS and JavaScript. An SVG spritesheet is a collection of SVG sprites (mostly icons) all in one file. This is better than using hardcoded SVGs in your HTML files because SVG spritesheets are cached (like CSS and JavaScript are). This prevents them from being downloaded each time your refresh your page. If you want a simple tool to create SVG spritesheets, look no further than a tool I created a while ago, ssm². Once your spritesheet is created, you can use a sprite like this:

  <svg class="menu icon">
      <use href="/static/icons/sprites.svg#menu></use>
  </svg>
  

• Use HTML and CSS for your UI. You don't need any JavaScript. This ensures faster loading and rendering.

• Use IDs for elements that appear once, and classes for elements that appear more than once. This simple principle helped me get rid of BEM in my CSS and I'm a happier man now 😄.

• Use buttons to respond to clicks and anchors for taking visitors to another page. Sounds simple, but some people interchange the two. Swapping them could disrupt the accessibility of the webpage.

• Use rem and hsl() when you can. rem is a size unit in CSS that's based off the default font size (usually at 16 pixels). Using this unit helps to keep spacing between elements proportional to the font size and more uniform. Using hsl() makes it easier to differentiate colors. I've written extensively on it in a previous post.

• Create deploy scripts. Because ain't nobody want to have to type a thousand commands just to update your website. And no one definitely has time to build anything either.

• Use dev tools for debugging and fine tuning an interface. Dev tools is your best friend in the web dev, I can't stress this enough.

• Use @container over @media whenever possible. CSS containers are more local than media queries; it only cares about its own size rather than the size of the whole page. This makes them easier to work with and more flexible since you can rearrange the container's elements at different screen sizes.

• Test for responsiveness early. Make sure your layouts work well. Also, work on the desktop interface first as it is usually the more complex. Mobile is generally simpler and straightforward, making it easier to collapse the desktop into the mobile screen size once complete.

• Use flexbox over grids. Flexbox is good for one-dimensional layouts (i.e. layouts the stretch in only one direction like rows and columns) while grid is good for two-dimensional layouts. In my experience, most of my layouts have been one-dimensional, and mastering flexbox has made it easy to build interfaces faster.

• Set up a cache buster. There's nothing worse than pushing up your changes to the server, only to refresh your page and not see any of your changes³. The cache is the one to blame for this, but cache busting fixes it. I wrote my own cache buster script that creates a hash and appends it to the end of all cacheable resources (like CSS files, JavaScript files, images, SVG spritesheets etc.). That way, when I want changes to happen on the browser, I just bust the cache and refresh the page. I run it like this:

  $ python -m app.cachebuster mmhq.me
  

  Then voila! My updates show immediately after I refresh the browser.

• The cascade is your friend, use it! I'm talking about the CSS cascade, or the "C" in "CSS"⁴. The better you get familiar with it, the less likely you would end up breaking your code.

• Semantics matter. That's the key to SEO and accessibility. It all starts with choosing the right HTML elements to use on the page. And by avoiding JavaScript frameworks, I can skip the extra steps required and get them for free with semantic HTML.

Bottom line

Well, that's all folks! I'm heading back to go wiggle my fingers some more for this web project. Cheers 🍻!

He sendeth forth his commandment upon earth: his word runneth very swiftly.

Psalms 147:15, The Bible

I'm born again like Matt Murdock — 
Transformed when I use Bash;
Performing signs and miracles,
My fingers flinging fast 👨‍💻.

Bash and the terminal are two of the best things to happen to computing. I can talk to the soul of the computer with just the tips of my fingers — talk about sheer power! It's the OG ChatGPT 😉.

In this blog post, I'd like to talk about Bash¹ shortcuts that save me typing time.

Shell shortcuts

Rename a file using brace expansion ({}):

$ mv imaginary-playmate{,-rene-and-angela}.mp3
mv imaginary-playmate.mp3 imaginary-playmate-rene-and-angela.mp3

Run previous command with sudo using history expansion (!):

$ rm -rf /   # Delete folder without proper permission
Permission denied.
$ sudo !!   # Run last command with "sudo"
sudo rm -rf /

Run last command with a specific prefix:

$ ssh user@mmhq.me   # SSH to server

# Run a couple commands on server ...
# ...

$ !ssh   # Return to server
ssh user@mmhq.me

Print last command (so you know what it is before you run it):

$ !make:p   # print last "make" command without running it
make VERBOSE=1

# Press the "Up" key and hit "Enter" to run the command.

Copy folder and all its contents:

$ cp ~/Music/songs/ /run/media/flashdrive/   # Try to copy folders with the "-r" flag missing, fails
cp: -r not specified; omitting directory '/home/efe/Music/songs/'
$ cp -r !*   # Copy folder with the right flag, succeeds
cp -r ~/Music/songs/ /run/media/flashdrive/

Run a very long command; use the printed result in another command:

$ ls -1rth ~/Music/songs/*.mp3 | tail -1   # Print last added song in folder
/home/efe/Music/songs/imaginary-playmate.mp3
$ mid3v2 -l $(!!)   # Check ID3 metadata tag in MP3 file
mid3v2 -l $(ls -1rth ~/Music/songs/*.mp3 | tail -1)

Use last argument of last command:

$ cp blog/posts/.template.md blog/posts/something-exciting-i-have-to-say.md   # Create new blog post by copying template file
$ vim !$   # Open Markdown file in vim
vim blog/posts/something-exciting-i-have-to-say.md

Check the error status of the last command to know if I should run it again:

$ yay -Syu   # Run updates on my computer
$ echo $?   # Print last error code; prints "0" if successful and any other number if not
0

Switch directories without typing the directory names:

$ cd ~/Downloads   # Switch to "Downloads" directory
$ cd ~/Documents   # Switch to "Documents" directory
$ cd -   # Switch back to "Downloads" directory
$ cd   # Switch to home directory

Run a recently run command:

$ history | grep rm   # Check history for all "rm" commands
1094 rm -rf blog/posts/talk-a-lot.md
1096 rm -rf /tmp/cache
1099 rm -rf blog/posts/talk-some-more.md
$ !1096   # Run second-to-last command
rm -rf /tmp/cache

Keyboard shortcuts

• Ctrl + W to cut word
• Ctrl + Y to restore cut words
• ↑ to display previous command
• Ctrl + D to logout and close Linux terminal (or to make Mac terminal stop responding and force you to close it and reopen it 🙄🤦).
• Ctrl + C to kill a process that's taking forever, or when I run a script or program by mistake.
• Ctrl + L to clear the screen.
• Ctrl + Z to suspend Vim. (Restore Vim with the fg command.)
• Ctrl + A to jump to the start of the line.
• Ctrl + E to jump to the end of the line.
• Ctrl + R to reverse search through command history.
• Tab to autocomplete commands and file paths.
• Alt + . to display last argument of the last command.

Bottom line

You don't have to move like a snail 🐌 when using the terminal. Try these shortcuts out today and become the Speedy Gonzalez ⚡ of executing commands. (Leave your nerdy coworkers in awe 🤓🙃.)

Further reading

• Bash cheatsheet

More battle rap slogans I like!

Real Sikh

Said vs A. Ward:

I'm on that Jersey sh*t, that going all out sh*t
Real Sikh, and I'm the problem that you want rounds with?
You were supposed to put in work, but it's wrong now b*tch
Because you can't show up to work, when you call out Sikh

Arsonal

Said vs Tay Roc:

My sh*t is real, my sh*t is raw, my sh*t is authentic
You can't spell bars without putting that "ars" in it

Gucci Gotti

Said vs Loso:

And when it's real, y'all can tell, y'all can see it in their eyes
Your turn
See if you can make n*ggas believe them lies
N*gga time

Showoff

Said vs Head ICE:

Don't ask me why I end my rounds with show off n*gga
Three reasons — one being I'ma show off n*gga
Ask my psychiatrist, he'll tell you that Show off n*gga
And I'm a stone cold killer the way Show off n*ggas
Show off n*gga

Danny Myers

Said vs Anderson Burrus:

You on the ground with this sh*t
This wack MC got another round of this sh*t
Yikes!

Related posts

• Best battle rap slogans #1

As you may or may not know, I watch a lot of battle rap 😄. Here's a list of some of my favorite battle rap slogans. Enjoy!

Ill Will

Said vs Bill Collector:

I killed you n*gga but I'm still your folks
I just want you to know when you go against Ill, your will get wrote
N*ggas say they the best, but I don killed the goat
Any ill will towards Ill Will, Ill will get ill and you will get smoked

Jaz the Rapper

Said vs Hollow Da Don:

If y'all don't remember how I does this, good I'ma remind you
It's my first time battling in Houston, I'm 'bout to have a good time too
But if you loved me last time, tonight? I'm that times two
I work on my timing to address bullsh*t when it's time to —
And it's time to

A. Ward

Said vs Charlie Clips:

I did not come here to get personal with you
I brought enough bars to body you, and any person that's with you
I tell them fall in line
Hey, God is good, all the time

E Ness

Said vs O Solo:

First round is bars
Second round is personal
Third round I grab the chainsaw and get surgical

Said vs E Hart:

Because n*ggas don't like to hear the truth but here it goes
I'ma fry these n*ggas till I'm 50 years old
Cause when I wear Da Vinci it's like 50 pair of those
I got 32 questions to ask, where the hoes?

E Hart

Said vs QB Diamond:

I don't talk much, y'all know it's simple with me
But tonight I will smack a b*tch, bring out the pimping in me
What you ain't know? I tried telling you, it's different with me
Unlimited bars, just call me infinite E

O Solo

Said vs E Ness:

It's the most electrified
Your father's uncle, your father's uncle
On your mother's side

Marvwon

Said vs Tay Roc:

There are only 3 things promised in life, that's death and taxes
And my legend status
When you play the game as good as Iverson
They should never expect you to step in practice
And this is practice

Said vs Tay Roc:

I'm a motherf*cking legend n*gga, are you crazy dude?
I'm a real Detroit n*gga, and I just brought them .380s through
The last thing he gon' see is the D over that navy blue
Like "n*gga, look what you made me do"

Let's admit it: the speed of this blog sucks. I've been trying to ignore it for a while, because I was thinking my code was perfect 😇 but it got too bad to ignore. Load times were taking up to 4 seconds, and it was embarrassing.

In this blog post, I'd like to take you through that journey and speak on the lessons I learned along the way.

4 seconds? That's an eternity!

I know, and I agree. So I had to ask Gemini¹ about it².

Me: "Why is my Flask app slow?"

Gemini: "Because you made it that way. Have you tried profiling it?"

Me: "Profiling? You mean analyze its performance to identify bottlenecks and areas for optimization? Why would I want to do that?" 🤔

Gemini: 😐

Me: 😅 "Oh yeah, you right. I'll get right to it."

So I downloaded a profiler using pip called Flask-Profiler, only to eventually find out that there is a built-in profiler in Flask 🤦‍♂️🏾. I eventually figure out that my website takes 4 seconds to load — on localhost³! So I turned to my AI genie once more:

Me: "Gemini, help! The profiler said my app takes 4 seconds. How long should it take for my website to load on localhost?"

Gemini: ... 🤔 ... "It should take your website 300 - 500 milliseconds at most to load. You must really suck at making websites."

Me: 🙄 "Thanks for the compliment. So what can I do to make it faster, wise guy?"

Gemini: ... 🤔 ... "Have you tried the Flask-Caching library for Python?"

Me: 😯 "What's that?"

Gemini: "Flask-Caching is a Flask extension that adds caching to your application. It stores the results of functions, like database queries or rendered HTML pages, in a fast storage system. The next time a request is made for the same content, it's served directly from the cache instead of being regenerated, which significantly speeds up your application and reduces the load on your server."

Me: 🤯

I rush to download the library and create two caches in my Flask app, a memory cache for storing relatively constant data in my computer's memory, and a file cache for storing data like rendered HTML pages on my file system. Now with all confidence, I restart the server and refresh the home page. I take a look at my results on the qutebrowser's devtools.

Me: "What? It's still taking 1 second to load. I mean, that's a significant increase, down to a quarter of the initial time taken, but why still so slow? 😩"

Gemini: ... 🤔 ... "If you are using the Flask-Caching library and it's still that slow, the situation is worse than I thought. At this point, it's not Python's fault, it's not Flask's fault, it's not Flask-Caching's fault, it's completely on you! You may want to take a look at what you've coded."

Me: "Fine, how do I measure durations of functions in Python?"

Gemini: ... 🤔 ... "You could use the time.perf_counter() from the time library. It has ..."

Me: (Stops prompt.) Say less. 😤

I go down the rabbit hole of my own code ... only to eventually find the culprits, each of them taking at least 0.91 seconds to load:

def index(page=1):
    try:
        page = int(page)
        db = Database(cache=DataCache()
                      if Config.env.data_cache_enabled
                      else None)
        posts = db.posts.previews.get(page=page)
        if len(posts) == 0 and page > 1:
            raise RuntimeError(f"No posts for page {page}.")

        return render_template("index.html",
                               title=Config.SITE_TITLE,
                               cache_hash=Config.env.cache_hash,
                               heading=Config.SITE_HEADING,
                               subheading=Config.SITE_SUBHEADING,
                               base_url=Config.BASE_URL,
                               og_title=Config.OG_TITLE,
                               og_image=Config.OG_IMAGE,
                               og_url=Config.BASE_URL,
                               header=Header(),
                               footer=Footer(page_count=db.posts.page_count,
                                             rss_visible=True),
                               posts=posts,
                               tags=db.posts.tags.get(),  # <- CULPRIT #1
                               history=db.posts.history.get())  # <- CULPRIT #2
    except RuntimeError:
        abort(404)

The db.posts.tags.get() and db.posts.history.get()) functions were to blame! The ironic thing about it is that my blog doesn't even display them on any page. They were features I was planning to add to the early design of my blog but I later decided to keep it simple and leave them out of the webpage. Unfortunately I forgot to take the queries out.

What's worse is that they both would keep getting slower and slower and dragging the page load longer and longer with every new post, because the functions had to go through every blog post file.

After deleting those functions from the file, pages loads were way faster, ranging from 500 - 800 milliseconds for the home page and 200 - 300 milliseconds for a blog post. These are not the most ideal of speeds but it's way better than 4 seconds!

Bottom line

I've learned a couple lessons:

• Don't just assume, measure. That's the only way to keeping your website fast. You never know what could be hiding in your code.
• Caching can't save you. Find out the root cause to issues.
• Don't look down on SSGs. I used to think that they were somewhat redundant and unnecessary because they create a whole bunch of static files that need to be diffed later. Now I know they have their place. In fact, save yourself the stress and use one!⁴

You will recognize them by their fruits. Are grapes gathered from thornbushes, or figs from thistles?

Matthew 7:16, The Bible

Fruit inspectors in the faith,
Guarding who can pass the gate,
Looking for corrupted seed,
Ignoring their own evil deeds.

Most people in the faith are alright. They understand the one thing that binds all Christians: the gospel 🙏.

But there are tares among us. There is a certain group of people that I recently heard can be identified as fruit inspectors.

What is a fruit inspector?

A fruit inspector is a person who believes that Christian believers can recognize someone's spiritual condition by their actions or fruit. If they analyze a person's actions and see that it doesn't align with God, they claim the believer does not believe and is condemned to hell.

It’s not a biblical title, but the concept is loosely based on Jesus’ teaching (Matthew 7:15–20).

In that scripture, Jesus is warning about false prophets, saying their actions and results (or fruits) reveal their true character — even if they appear godly on the outside.

However, fruit inspectors use the fruits to condemn people as not being fit for heaven.

They are right; none of us are fit for heaven.

This is the whole purpose why Jesus came, to redeem us all. None of us should go if we look at our works because none of us are faithful:

As it is written, There is none righteous, no, not one.

Romans 3:10, The Bible

Fruit inspectors are gatekeeping the kingdom preventing eligible men and women from going to heaven, whether they know it or not. They ironically become false prophets themselves because they are prophesying that these people will not go to heaven.

So if it's not by their fruits, how would I know them?

It is not wrong to judge people's actions as good or bad in accordance with the Bible. But if we are to judge, we should only judge the action, not the person. We don't know if the person is born again or not.

The only way to know is to recite the gospel and ask if he/she believes. They could be in one of the following situations:

• They have never heard of Christ before.
• They have never believed Christ before.
• They have believed Christ before, but they have fallen away.
• They have believed Christ before, but keep falling away and believing, then falling away...

In any case, if they have believed once, they are saved for eternity! God will keep them until the last day:

27 My sheep hear my voice, and I know them, and they follow me:

28 And I give unto them eternal life; and they shall never perish, neither shall any man pluck them out of my hand.

29 My Father, which gave them me, is greater than all; and no man is able to pluck them out of my Father's hand.

John 10:27–29, The Bible

The evidence is also seen with Abraham, because Abraham lost faith that God would give him Isaac. That's why he laughed when God mentioned it:

Then Abraham fell upon his face, and laughed, and said in his heart, Shall a child be born unto him that is an hundred years old? and shall Sarah, that is ninety years old, bear?

Genesis 17:17, The Bible

And yet, God still kept his promise, despite Abraham's doubt:

And Abraham called the name of his son that was born unto him, whom Sarah bare to him, Isaac.

Genesis 21:3, The Bible

Abraham is still known as the father of faith, despite his shortcoming.¹

Bottom line

In summary, your belief in Christ is not based on your actions. We walk by faith, not by sight. We are going to sin whether we are born again or not. Once we believe the gospel, Jesus saves us from the wages of sin (i.e. death) and gifts us with eternal life that cannot be taken back.

Now that's good news!

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler, software author

I know the script is hard to read,
But reading's not the goal;
You're not supposed to understand —
That's why they call it code!

Just like music, poetry, or even language, code is a form of communication. Each line, each variable name, each class name etc. tells a story and gives context to the reader of the code.

Code has two purposes: to function and to communicate. Though your functional code does not have to communicate (i.e. it doesn't have to be readable), failing to do so may leave future developers (including you) puzzled at what you intended at the time of writing the code (i.e. if modifications ever need to be made).

First example

Take for instance, which is better?

This:

p = Point(True, 10, 20)

Or this:

p = Point(10, 20)

I think it is clear to see that the second block of code is slightly better than the first. Why? Because I can assume that 10 is the coordinate for the x axis and 20 is the coordinate for the y axis. That is all to it.

We could even make it more explicit:

p = Point(x=10, y=20)

This works too, but I would say either method would be preferred over the first.

So what's wrong with the first block of code?

The real problem is that we can't tell what the True argument is for. Thankfully, named arguments exist in Python¹:

p = Point(has_label=True, x=10, y=20)

However, this still feels worse. Why? A couple reasons:

• We would be unable to set x and y without setting has_label².
• It just doesn't look like every other Point object we may have encountered elsewhere. Why break convention if we don't have to?

I would argue a better constructor would be this (i.e. assuming that has_label must be used in the constructor):

p = Point(x=10, y=20, has_label=True)

At this point (pun intended 😉), it depends on how the user intends to make use of Point, but this is a lot less jarring than how it looked before.

In the old code, I would have to look up what the Boolean flag (True) represents; in the new code, its purpose is stated right in front of you. This may seem like a small change, but little changes like these really draw the line between amateur and professional developers.

Second example

Which is better?

This:

d = DateTime(2025, 8, 15, 13, 4, 20)

Or:

d = DateTime(Date(2025, 8, 15), Time(13, 4, 20))

Once again, I would say the second. There is nothing wrong with the first per se, but it's definitely harder to read compared to the second. Sometimes, there is no wrong or right answer; it's all contextual.

Bottom line

Every line of code tries to communicate to its reader, whether we like it or not. What story is your code telling?

JavaScript is the world's most misunderstood programming language.

Douglas Crockford, computer programmer

A type for <script>s, a type for <style>s,
A type for <div>s and <span>s,
But JavaScript's the type of code
That's not at all a fan.

I read an article on dev.to (again) that talked about how important it is to know types used in JavaScript to do Typescript.

This is already a problem. With the effort made by the browser and the creator of JavaScript to hide types from the developer, why are developers so obsessed with bringing them around?

JavaScript is weakly typed for a reason: it makes easier to read, write, understand and remember.

Let's take a look at the same example,

In JavaScript:

const input = document.getElementById("myInput");

In Typescript:

const input = document.getElementById("myInput") as HTMLInputElement;

This leads me to ask, why do I care if an object is a HTMLInputElement? How does that make the code easier to understand or write, or even read? The code itself implies that it is an input element; choosing the variable name input makes it even easier!

Now, knowing the type could be useful if you have a lot of code and you are debugging. But to read, write and understand code? I don't think you need them at all. And to add to that, there are other ways to debug without the types, like using DevTools and the built-in browser debugger.

The JavaScript code snippet above is also easier to remember compared to its Typescript counterpart.

I'm not against static typing in general; I do believe it fits lower level languages like C, C++, Java, C# etc. I just don't believe it should be used for interpreted languages like JavaScript (or Python). JavaScript is a scripting language and scripting languages should be easy to script!

Bottom line

Nobody cares about types in frontend development (and you shouldn't either)! Learn to choose clear variable names and that can take you a long way.

70 Jesus answered them, Have not I chosen you twelve, and one of you is a devil?

71 He spake of Judas Iscariot the son of Simon: for he it was that should betray him, being one of the twelve.

John 6:70-71, The Bible

In reference to John 12:1-8

All money to be given to the Son of man I take;
That means I am the least likely to make money mistakes;
Why would Mary anoint his feet and bring us all such gloom?
We would have made a lot of cash from selling the perfume.

Disclaimer: Judas was not a publican; he was the treasurer for Jesus and the disciples. I use the word as a metaphor because he behaves very similar to them.

In this post, I would like to explore another exception to the Pharisee-publican rule, Judas Iscariot.

Who was Judas Iscariot?

Judas was a disciple of Jesus that betrayed him. He had the same greed of a publican; he stole money as the treasurer for Jesus and the disciples:

4 Then saith one of his disciples, Judas Iscariot, Simon's son, which should betray him,

5 Why was not this ointment sold for three hundred pence, and given to the poor?

6 This he said, not that he cared for the poor; but because he was a thief, and had the bag, and bare what was put therein.

John 12:4-6, The Bible

The strange thing is that this is not what makes Judas different, after all, publicans were greedy too.

What makes Judas different from the publican in Luke 18:13-14 is the fact that Judas did not believe in Jesus:

But there are some of you that believe not. For Jesus knew from the beginning who they were that believed not, and who should betray him.

John 6:64, The Bible

This was the biggest issue with Judas; he shut out possible redemption by hardening his heart. Jesus wants to save you, but he will not force it upon you; it will forever be a choice.

Even after being remorseful and returning the money used to betray Jesus, Judas never believed that Christ could save someone like him, leading him to take his own life:

3 Then Judas, which had betrayed him, when he saw that he was condemned, repented himself, and brought again the thirty pieces of silver to the chief priests and elders

4 Saying, I have sinned in that I have betrayed the innocent blood. And they said, What is that to us?

5 And he cast down the pieces of silver in the temple, and departed, and went and hanged himself.

Matthew 27:3-5, The Bible

Bottom line

The publican and the prostitute are not always humble. We must learn to humble ourselves before Jesus in order to receive the permanent gift of eternal life, and the knowledge of God through him.

Or as the book of Proverbs puts it, pride comes before a fall:

Pride goeth before destruction, and an haughty spirit before a fall.

Proverbs 16:18, The Bible

We must also remember that Jesus is willing to redeem anyone that seeks it, anyone that believes in Him. Salvation is a free gift that none of us have to earn; we just have to reach out and receive it through faith.

Further reading

• The Bible way to heaven

Related posts

• The way of the Pharisee
• The way of the publican (and the prostitute)
• Nicodemus: The humble Pharisee

There was a man of the Pharisees, named Nicodemus, a ruler of the Jews:

John 3:1, The Bible

Rabbi, you do miracles
That can only come from God;
How can I be born again?
Go back inside my mom?

With the last couple posts I've posted, it may seem like Pharisees were always proud and publicans (and prostitutes) were always humble. Well, that was the rule, but there were definitely exceptions.

One notable exception was Nicodemus.

Who was Nicodemus?

Nicodemus was a Pharisee, but he was different. Nicodemus was curious about Jesus. He didn't just dismiss him like his peers.

Nicodemus knew that for Jesus to perform these miracles, he must have been sent from God. And with that in mind, Nicodemus visited Jesus at night (so as not to be seen by fellow Pharisees) to inquire:

The same came to Jesus by night, and said unto him, Rabbi, we know that thou art a teacher come from God: for no man can do these miracles that thou doest, except God be with him.

John 3:2, The Bible

Jesus answered him:

Jesus answered and said unto him, Verily, verily, I say unto thee, Except a man be born again, he cannot see the kingdom of God.

John 3:3, The Bible

As we can see, even though Jesus was normally harsh to the Pharisees, he wasn't like that with Nicodemus, because Nicodemus humbled himself before him, so Jesus told him how he could receive everlasting life:

For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.

John 3:16, The Bible

Once again, this proves that Jesus is not a respecter of persons. He will save the Pharisee, the publican, the prostitute, everyone!

Nicodemus also defended Jesus when some leaders wanted to arrest Jesus:

50 Nicodemus saith unto them, (he that came to Jesus by night, being one of them,)

51 Doth our law judge any man, before it hear him, and know what he doeth?

John 7:50-51, The Bible

Nicodemus also helped Joseph of Arimathea to bury Jesus:

39 And there came also Nicodemus, which at the first came to Jesus by night, and brought a mixture of myrrh and aloes, about an hundred pound weight.

40 Then took they the body of Jesus, and wound it in linen clothes with the spices, as the manner of the Jews is to bury.

John 19:39-40, The Bible

As you can see, Nicodemus revered Jesus, even after death.

Bottom line

There is hope for everyone, even for the Pharisees. As I've discussed above, it all depends on true humility from the inside. This is why Jesus says we should focus on cleaning the inside of the cup:

25 Woe unto you, scribes and Pharisees, hypocrites! for ye make clean the outside of the cup and of the platter, but within they are full of extortion and excess.

26 Thou blind Pharisee, cleanse first that which is within the cup and platter, that the outside of them may be clean also.

Matthew 23:25-26, The Bible

Further reading

• The night visit
• The Bible way to heaven

Related posts

• The way of the Pharisee
• The way of the publican (and the prostitute)

13 And the publican, standing afar off, would not lift up so much as his eyes unto heaven, but smote upon his breast, saying, God be merciful to me a sinner.

14 I tell you, this man went down to his house justified rather than the other: for every one that exalteth himself shall be abased; and he that humbleth himself shall be exalted.

Luke 18:13-14, The Bible

The publican would not lift up his eyes;
He knew that God could see through his disguise;
He knew that he got rich by telling lies;
"Please show me grace and mercy, Lord", he cried.

Yesterday I spoke about what to expect from Pharisees and how their mentality makes them think of themselves as better than their fellow men.

Today, I would like to talk about the yin of the Pharisee — the publican — and what we can learn from the sinner.

Who were the publicans?

Publicans were the tax collectors in the Bible; they collected tax on behalf of the Roman government.

I always wondered why they were mentioned a lot in the New Testament of the Bible. What was their significance?

So I asked ChatGPT, and here's what it said:

• Despised by Jews: Publicans were often Jews working for the Roman occupiers, so they were seen as traitors. Many were also corrupt, charging extra and keeping the surplus.

• Symbol of sinners: Because of their reputation for greed and dishonesty, publicans became a symbol of moral and spiritual failure in Jewish society.

• Outcasts: Publicans were social and spiritual outcasts, yet were still capable of redemption through humility, repentance and faith.

From what ChatGPT said, we can come to some interesting conclusions:

• Publicans were willful sinners; they were knowingly overcharging people in taxes to make a quick buck.
• Publicans had a bad reputation and were looked at as the scum of the earth.
• Publicans were rejected by many people, making them outcasts.

Who were the prostitutes?

Prostitutes were women who engaged in sexual relations outside of marriage for payment.

The prostitutes were also despised by Jews, symbols of sinners and outcasts. The main difference was that publicans charged extra to get a financial gain, and prostitutes charged sex for the same advantage.

Just like the publicans:

• Prostitutes were willful sinners.
• Prostitutes had a bad reputation.
• Prostitutes were rejected by many people.

Pharisees would look down on both publicans and prostitutes thinking, "Why can't they both be more like me?" or "Thank God I'm better than them."

What the Bible says about publicans and prostitutes

Publicans and prostitutes may seem like they are beyond redemption; they are willful sinners that do not want to change, or want to change but refuse to do so. But there is even hope for them, according to Jesus:

Verily I say unto you, That the publicans and the harlots go into the kingdom of God before you.

Matthew 21:31b, The Bible

The main attribute that distinguishes them from the Pharisee is their understanding that they need a savior. They know what they are doing is wrong, but they know only a higher power can deliver them from it.

These people are more likely to believe in Him than the Pharisee, because the Pharisee is trusting in his own power.

As stated in the Bible, God desires to show us mercy (to the publicans and prostitutes), not to demand sacrifice (as the Pharisees believe):

For I desired mercy, and not sacrifice; and the knowledge of God more than burnt offerings.

Hosea 6:6, The Bible

We can see when he showed Zacchaeus the publican mercy (Luke 19:1-10) and when he showed a woman who committed adultery (similar to a prostitute) mercy (John 8:1-11). In both cases, none were worthy of salvation, but Jesus proved that the gift of salvation is for everyone, if you are humble enough to receive it.

Bottom line

The moral of the story is not to live like the Pharisee or to live like the publican or prostitute, but to understand that Jesus' mercy is limitless. Whether we like it or not, we will sin, but this should be a reminder of Jesus' mercy on us and how we should show mercy to others.

It also reminds us to be careful not to think we know what to do at all times like the Pharisee but to be humble enough to seek it out from God; the knowledge of God is more than burnt offerings.

Or, as Paul the apostle put it:

Wherefore let him that thinketh he standeth take heed lest he fall.

1 Corinthians 10:12, The Bible

Further reading

• The parable of the Pharisee and the publican
• The Bible way to heaven

11 The Pharisee stood and prayed thus with himself, God, I thank thee, that I am not as other men are, extortioners, unjust, adulterers, or even as this publican.

12 I fast twice in the week, I give tithes of all that I possess.

Luke 18:11-12, The Bible

The Pharisee is not like other men;
Not like extortioners who give God stress;
He fasts and prays and tithes more than the rest;
He doesn't have to ask 'cause he knows best.

I watched a YouTube video today that made me think of the real nature of the Pharisees in the Bible and how I'm sort of similar.

As highlighted in the above scripture, the Pharisee separates himself by thinking of himself to be better than other men, which brings me to my first observation:

The Pharisee tends to measure himself against the standards of other men as opposed to the standard of God:

• Churchgoers compare themselves to non-churchgoer.
• The chaste compare themselves to the sexually immoral.
• The sober compares himself to the drug addict.
• The React JS user compares himself to the user of Angular/Vue user.

This sort of thinking makes us self-righteous, because we believe we just need to be better than other people. But that is not the standard God wants for us:

Thou shalt be perfect with the LORD thy God.

Deuteronomy 18:13, The Bible

Or in the words of Jesus:

Be ye therefore perfect, even as your Father which is in heaven is perfect.

Matthew 5:48, The Bible

If we were looking at God's standard, we wouldn't be so judgmental of others; we would more judgmental of ourselves and more focused on what God's word says about anything we deal with.

Therefore:

• The churchgoer should ask, should I go to church and how many times does God want me to go to church?
• The chaste should ask, should I be chaste and how many people does God want me to sleep with?
• The sober should ask, should I be sober and how long does God want me to be sober for?
• The React JS user should ask himself, should I be a React user (No 😑) and what does the web standards require of me?

However, even knowing God's standard doesn't fully help. We are incapable of keeping God's word:

For all have sinned, and come short of the glory of God;

Romans 3:23, The Bible

The solution? Jesus Christ!

He fulfilled the law so that we don't have to. If you believe in Him today, he will save you from the repercussion of sin, which is death:

For the wages of sin is death; but the gift of God is eternal life through Jesus Christ our Lord.

Romans 6:23, The Bible

Bottom line

We should be more self-aware than self-righteous. Self-righteousness leads to holier-than-thou behavior and thinking of our fellow humans as less.

If we meditate on God's standard, we would be more aware of our flaws and we could use that to become better people and to work on the parts of ourselves that fall short. It also makes us aware of our need for grace from God and man.

Further reading

• The parable of the Pharisee and the publican
• The Bible way to heaven

Code less. Create more. Deploy everywhere.

Qt motto, Qt Company

A framework made to bring you smiles
Without a lot to bear;
Code less, no stress; make more — galore;
And deploy everywhere!

The Qt C++ framework (with Qt officially pronounced as "cute") is software I hold dear to my heart. I have used it since I started learning C++ back in 2010. In fact, I would say Qt was the reason I learned C++.

At the time, I already knew the C programming language but I was looking for a programming language slightly higher level than C to build desktop user interfaces for the code I wrote. I was working with mostly microcontrollers and embedded systems then.

I searched for the best desktop UI framework on Google and Qt popped up on Stack Overflow. Qt was among the favorites being used to make applications like Autodesk Maya, Blender, VirtualBox and Wireshark, so I chose Qt; it just happened to be written with C++.

In this post, I would like to discuss some of the benefits of using Qt.

It's cross-platform

Qt can be used to build applications that run natively on Windows, Mac, and Linux, and in recent years have extended their reach to Android, iOS, Tizen and even the web.

C++ is its core language

C++ gets a lot of hate in programming communities but it is definitely one of my favorite languages (along with Python and JavaScript). I love how close it is to the hardware and how easy it is to connect that knowledge with software.

Qt being written with C++, a fast and efficient language that was similar to C, added to its flair for me.

It has QML

QML, which stands for Qt Modeling Language, has changed the way I think about UI development.

User interfaces can be described with ease in this language. It made me to understand frontend-backend separation more and how that could lead to cleaner code.

It has great documentation

Qt's documentation is so simple and straightforward; I was surprised to see that other documentations are not always the same. I have lost a couple hair follicles from pulling while reading the Android documentation. Qt invests a lot of time in making sure the documentation is easy to understand and apply compared to other UI frameworks.

Easy to use

There is not a lot of required to get started. You could make a button appear on the screen after downloading the Qt SDK with the following code:

#include <QApplication>
#include <QPushButton>

int main(int argc, char* argv[])
{
    QApplication app(argc, argv);
    QPushButton button;
    QObject::connect(&button, &QPushButton::clicked, &app, &QApplication::quit);
    button.show();
    app.exec();
}

Consistency in code

Classes in Qt with similar behavior have consistent interfaces. For instance, both QTcpSocket and QFile have a read() and write() function, along with the ability to use the stream operators (>> and <<) on them. (They both inherit from QIODevice.) This makes it easy to learn similar classes quickly.

Great API standards

Compared to other UI frameworks, I think Qt's methods are a little more consistent and easy to invoke and memorize. Compare the code for rendering a button in Qt with that of Java Swing and Android:

import javax.swing.*;

public class ButtonExample {
    public static void main(String[] args) {
        // Create a frame (window)
        JFrame frame = new JFrame("Swing Button Example");
        frame.setSize(300, 200);
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        // Create a button
        JButton button = new JButton("Click Me");

        // Add action listener to handle clicks
        button.addActionListener(e -> {
            JOptionPane.showMessageDialog(frame, "Button was clicked!");
        });

        // Add button to the frame's content pane
        frame.getContentPane().add(button);

        // Make the frame visible
        frame.setVisible(true);
    }
}

import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.Toast;
import androidx.appcompat.app.AppCompatActivity;

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Button myButton = findViewById(R.id.myButton);

        myButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                Toast.makeText(MainActivity.this, "Button clicked!", Toast.LENGTH_SHORT).show();
            }
        });
    }
}

I know, some complicated stuff 😒.

Multi-language support

Qt supports C++ and Python officially, but work is being done to extend it work with more languages.

Comprehensive framework

Qt also has non-UI modules for database, networking, remote objects etc. This reduces the number of dependencies you need when using it.

It's open source

I had no money when I started programming, so this is important. It was good to use a framework that was completely free to use.

Bottom line

Without Qt, I don't think I would be so immersed in the UI/UX world. Qt carefully crafted their APIs and gave me a reason to care. I appreciate the effort of all the engineers that contributed.

Qt is not perfect. I will definitely circle back later to talk its shortcomings.

10 And Moses and Aaron went in unto Pharaoh, and they did so as the LORD had commanded: and Aaron cast down his rod before Pharaoh, and before his servants, and it became a serpent.

11 Then Pharaoh also called the wise men and the sorcerers: now the magicians of Egypt, they also did in like manner with their enchantments.

12 For they cast down every man his rod, and they became serpents: but Aaron's rod swallowed up their rods.

Exodus 7:10-12, The Bible

Vain Vane, go away;
We don't want you here today;
We prefer vanilla tech;
Not the vain crap you inject.

Vain Vane, you're a pain;
Wind-twisted just like your name;
You cause my bloody veins to boil;
You give developers much toil.

I'm very surprised that new JS frameworks are still promoted in this time and age. I hold fast to the belief that all JS frameworks were never a good permanent solution. I was hoping that with all the problems of React and Angular, we would move away from this framework obsession.

But lo and behold, another "framework that is not really a framework" called VaneJS rises from the ashes. When will these people quit?

In this post, I would like to take a look at the false advantages of VaneJS and compare them to a no-framework setup.

It has zero build steps

His claim: Just add a single static .js file to your project. No bundlers, no compilers.

My opinion: You know what else has zero build steps? Vanilla JavaScript!

Having no build steps is only a relative advantage; it only holds up if you compare it to other JS frameworks. But if you really don't want any build steps, just use HTML, CSS and vanilla JavaScript.

It's backend friendly

His claim: Works out-of-the-box with PHP, Laravel, Django, Express, ASP.NET — whatever you want.

My opinion: So does vanilla JavaScript.

No paradigm shift

His claim: Feels like HTML, behaves like a reactive system.

My opinion: How is that an advantage? HTML, CSS and JavaScript are usually separated for good reason. They all have different goals, and are more manageable when they are updated separately.

Not every project needs a reactive system. Sometimes building towards that in your project provides a better, more lean solution than a one-size-fits-all approach where you have to ship a large framework to the browser.

It has minimal mental overhead

His claim: You don’t need to "learn a framework." If you know HTML and JS, you’re good.

My opinion: The most minimal mental overhead is when you use the vanilla web languages: HTML, CSS and JavaScript.

Reactive stores between pages

His claim: Yes, you can store values and retrieve them across HTML pages.

For example:

<!-- about.html -->
<p data-vn-bind="mystore.name"></p>

// main.js
$setStore("mystore", { name: "SharedValue" });

My opinion: Has anyone ever heard of localStorage and sessionStorage? I think both of these features of the browser are flexible enough to hold any type of data you need to persist between page loads.

Also, does anyone really want to know what data-vn-bind means? Or what $setStore() does? Is any of this easy to interpret without reading the manual?

I know you need to read the documentation to learn about localStorage and sessionStorage but at least the only dependency it has is the browser. You don't need to download a whole framework to the browser.

It's really equivalent to bringing sand to the beach.

Once again, I don't see how this is an advantage.

Smart inline events

His claim: Attach multiple events inline:

<button data-vn-on="click:myFunc({user.name}); mouseover:logHover()">Click me</button>

$event("myFunc", ({ params }) => console.log(params[0]));
$event("logHover", () => console.log("hovered!"));

My opinion: You would be better off learning the JavaScript event system and how it works with the DOM. It is guaranteed to work on every browser, and you would have a better understanding of the simplicity of JavaScript coding.

Bottom line

Just the same way Aaron's staff swallowed up all the other staffs of the magicians, HTML, CSS, vanilla JavaScript, and the browser would swallow every framework out there.

So learn HTML, CSS and JavaScript. That is all you need to make websites. Unless of course you like pulling teeth.

Further reading

• We can and should simplify web development — dev.to

One of them was quiet,
The other liked to hiss;
I never knew they'd bite me once
They leaned in for a kiss;

The venom power's strong,
I fell right for their trap;
One spun a bed of web,
The other tripped me for a nap.

I watched a YouTube video the other day where the speaker spoke about powerful languages like Lisp and Tcl. I asked myself, "Why don't I know these languages?" Then I thought, "because I know Python and JavaScript!"

These are not the best programming languages out there, I haven't tried enough languages to make that claim. But they are very effective in helping me to get things done.

But what makes them so effective for me?

They both use modules

Modules are files that contain bits of code. These modules can be imported into other code files. In both Python and JavaScript, modules can be aliased and can help you contextualize your code better.

For example, in Python:

from shapes.square import Area as SquareArea
from shapes.circle import Area as CircleArea

side = 4
SquareArea().calculate(side);

radius = 4
CircleArea().calculate(radius);

For example, in JavaScript:

import { Area as SquareArea } from "./shapes/square";
import { Area as CircleArea } from "./shapes/circle";

const side = 4
new SquareArea().calculate(side);

const radius = 4
new CircleArea().calculate(radius);

Being able to split your code neatly into smaller files also makes maintaining code easier.

They are both interpreted

Interpreted languages like Python and JavaScript do not have to compile before they are run, making rapid application development (RAD) possible. No building is required at all¹.

For Python, restart python. For JavaScript, refresh the browser.

They both have REPLs

REPL stands for read-eval-print loop. It's pretty much a computer programming environment where you can:

• put in commands (i.e. the computer reads the command)
• press Enter on your keyboard (i.e. you request the computer to process the input)
• wait for the computer to process what you put in (i.e. the computer evaluates the command)
• wait for the computer to show the results on your screen (i.e. the computer prints the results it got)

This is basically how a shell works.

This makes debugging and testing so easy and quick because you don't have restart the entire program each time. I love this feature and it really comes in handing when writing websites, even this blog.

For Python, you would just call the python command to enter the Python shell. Then you can type commands as you like:

$ python
>>> import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

For JavaScript, you can inspect any element on the webpage by right-clicking and selecting Inspect, then switch over to the Console tab of your browser. From there, you can access the DOM:

>> $0.nodeName
"IMG"

They both are used for the web

I like that I can write any program for the web using these languages (along with HTML and CSS). I just need to restart the server and/or refresh the browser to see my changes.

They are easy to read

Reading through some well-written Python and JavaScript code is very relaxing to the brain. Ideas can be expressed so neatly.

They both use weak typing

Strong typing is not a language flaw at all, but in some contexts, it could be really distracting. I love languages where the chosen names by the programmer make the code more legible than using the types.

In my experience, I only care about typing when I need to debug an issue. Also, splitting my code well into proper contexts makes types less useful.

Here is an example of no typing with JavaScript:

class BankAccount {
  constructor(owner, balance = 0) {
    this.owner = owner;
    this._balance = balance;
  }

  deposit(amount) {
    if (amount > 0) {
      this._balance += amount;
      console.log(`${this.owner} deposited $${amount}.`);
    }
  }

  withdraw(amount) {
    if (amount > 0 && amount <= this._balance) {
      this._balance -= amount;
      console.log(`${this.owner} withdrew $${amount}.`);
    } else {
      console.log('Insufficient funds or invalid amount.');
    }
  }

  get balance() {
    return this._balance;
  }
}

// Usage
const account = new BankAccount('Alice');
account.deposit(100);
account.withdraw(40);
console.log(`Balance: $${account.balance}`);

And strong typing with Typescript:

class BankAccount {
  private owner: string;
  private balance: number;

  constructor(owner: string, balance: number = 0) {
    this.owner = owner;
    this._balance = balance;
  }

  deposit(amount: number): void {
    if (amount > 0) {
      this._balance += amount;
      console.log(`${this.owner} deposited $${amount}.`);
    }
  }

  withdraw(amount: number): void {
    if (amount > 0 && amount <= this._balance) {
      this._balance -= amount;
      console.log(`${this.owner} withdrew $${amount}.`);
    } else {
      console.log('Insufficient funds or invalid amount.');
    }
  }

  get balance(): number {
    return this._balance;
  }
}

// Usage
const account = new BankAccount('Bob');
account.deposit(200);
account.withdraw(50);
console.log(`Balance: $${account.balance}`);

Which do you prefer to read? Which one makes sense faster?

They are both easy to teach

Compared to lower-level languages like C and C++, Python and JavaScript are easier to become proficient in, as the programmer does not need to understand low-level concepts to get things done. For example, a knowledge of pointers does not help much in writing Python or JavaScript code.

Additionally, it makes it easier for programmers who already know C and C++ (like me) to learn. I also think this is why I appreciate the Python and JavaScript.

They both have clear goals and domains

In the words of Guido van Rossum (the creator of Python):

My goal is to make Python a language that is fun to use, and one that is so easy to learn that it brings the joy of programming to as many people as possible.

JavaScript has the goal to be the language for the web.

Brendan Eich's goal for JavaScript was to create a lightweight, interpreted scripting language for the web that could make web pages interactive.

Python has many domains such as machine learning, web development, data science, automation, game development, embedded systems, finance and fintech, desktop applications and many more.

JavaScript, once again, has the web, though it has also been ported to many platforms with technologies like Node.

They both are easy to maintain

Since they are easy to read and easy to write, they are also easy to maintain.

They both are easy to test

You can test either of them directly from shell (i.e. the terminal for Python and the web console for JavaScript). To test a function added to a class, you simply enter the shell, create an instance of the class and run the function.

They both can be extended

If functionality is missing from the main libraries, Python can be extended with C, C++ and many other languages; JavaScript can be extended with WebAssembly and web components.

They both have a plethora of libraries

Not only do they have a lot of libraries, each one can be added to your project using a package manager: pip for Python and npm for JavaScript².

They both are well supported

They have strong communities that are willing to help and support you. Developer forums like Stack Overflow³ are full of solutions.

They both empower the entrepreneur

As someone that wants to make money on the web someday, they both help my life quite a lot. It doesn't take much to get anything working quickly in these languages, depending on the tasks at hand of course.

Bottom line

If you are looking for languages that are easy to set up and get straight to it, look no further than Python and JavaScript. They can got you covered!

Bring ye all the tithes into the storehouse, that there may be meat in mine house, and prove me now herewith, saith the LORD of hosts, if I will not open you the windows of heaven, and pour you out a blessing, that there shall not be room enough to receive it.

Malachi 3:10, The Bible

This morning, I attended church (like I do on some Sundays) and was greeted with an interesting message. The title of the message was Storehouse. In summary, the pastor was advising us to tithe regularly.

In this blog post, I would like to prove to you that tithing is not a Christian practice.

The origin of tithing

Tithing is giving 10% of whatever you make to God, or more specifically, the church.

The first time tithing was mentioned in the Bible was in the book of Genesis when Abraham gave tithes of everything he recovered in war to the priest Melchizedek:

And blessed be the most high God, which hath delivered thine enemies into thy hand. And he gave him tithes of all.

Genesis 14:20, The Bible

To whom also Abraham gave a tenth part of all; first being by interpretation King of righteousness, and after that also King of Salem, which is, King of peace;

Hebrews 7:2, The Bible

Abraham gave willingly at the time in gratitude for God delivering his cousin Lot back into his hands after he was kidnapped by some kings.

It became a law to the children of Israel when Moses brought the law from God to the people in Leviticus:

And all the tithe of the land, whether of the seed of the land, or of the fruit of the tree, is the LORD's: it is holy unto the LORD.

Leviticus 27:30, The Bible

From this, we can establish that tithing is under the Mosaic Law.

Christians are not under the law

What does Paul say about the law?

For Christ is the end of the law for righteousness to every one that believeth.

Romans 10:4, The Bible

Christ fulfilled the law, which means we are no longer under the law, as he said in the book of Matthew:

Think not that I am come to destroy the law, or the prophets: I am not come to destroy, but to fulfil.

Matthew 5:17, The Bible

Paul also says this:

For sin shall not have dominion over you: for ye are not under the law, but under grace.

Romans 6:14, The Bible

The law was never for the Gentiles i.e. the Christians; it was only for the Jews.

Christians are under God's grace through Christ. Our work as Christians is to believe Christ, Jesus said it himself:

Then said they unto him, What shall we do, that we might work the works of God?

Jesus answered and said unto them, This is the work of God, that ye believe on him whom he hath sent.

John 6:28-29, The Bible

Even Leo, the Brave browser's AI assistant says:

In the New Testament, Jesus and the apostles did not explicitly command Christians to tithe, but they did emphasize the importance of giving and stewardship.

The practice of tithing is not explicitly required for Christians, but the principle of giving generously and joyfully is strongly encouraged.

Leo, the Brave browser's AI assistant

Other points against tithing

There were multiple tithes to be paid, making it more than 10%

The children of Israel were required to bring a second tithe to Jerusalem for celebration (Deuteronomy 14:22-27) and a third tithe for the poor and needy (Deuteronomy 14:28-29 and Deuteronomy 26:12).

If Christians were to pay tithes, which tithe should we pay?

Tithes were never paid with money

Tithes were a requirement for farmers and herdsmen. The Bible specifies that tithe should be given from agricultural produce and livestock, such as corn, oil, and oxen (see Leviticus 27:30-32). People from other vocations, such as carpenters, fishermen, tax collectors, and craftsmen, were not required to tithe.

The children of Israel were never told to pay tithes with cash.

So never give to the church?

Of course you can, if you want. God loves a cheerful giver.

The only giving in the church that falls under willful giving is offering:

Every man according as he purposeth in his heart, so let him give; not grudgingly, or of necessity: for God loveth a cheerful giver.

2 Corinthians 9:7, The Bible

If you want to take it a step up, you can lend to God instead:

He that hath pity upon the poor lendeth unto the LORD; and that which he hath given will he pay him again.

Proverbs 19:17, The Bible

Rebuttals for the pastor

These are all paraphrased quotes from the pastor and my responses.

"We the church don't need your tithes!"

Yes, you do. Stop lying on the pulpit! Actions deafen, words whisper. In other words, if you didn't need it, you wouldn't ask for it.

The book of Proverbs says you shouldn't give to the rich, so don't give to any church that says this.

He that oppresseth the poor to increase his riches, and he that giveth to the rich, shall surely come to want.

Proverbs 22:16, The Bible

"It shows you trust God with your finances!"

There is no biblical backing for this statement. Just believe in Christ and rest.

"Tithing is returning to God, the first of whatever He's blessed me with."

Once again, there is no biblical backing for this statement.

"You are not giving out of law, you are giving out of love."

No, giving out of love is offering. Tithing is lawful giving.

"God would never need my money."

That's correct! So keep your money in your pocket or give to the poor instead.

"It's testing humanity's faithfulness to him."

No, it's not. Humans are not faithful, God is! That is why Christ had to come and die for our sins.

"He's testing you, not tempting you. The enemy is tempting you to not pay tithes."

Once again, there is no biblical backing for this statement.

"When we don't give tithes, we are telling God we don't appreciate him giving to us."

No biblical backing!

"If you don't tithe, you are robbing God of the opportunity to bless you."

No, you are not. The opposite is true because you are not operating under grace, you are under the law. If you are under the law, you will be judged by the law:

For as many as have sinned without law shall also perish without law: and as many as have sinned in the law shall be judged by the law;

Romans 2:12, The Bible

"Grace has a greater demand than the law."

False. That is the antithesis of grace. The law tells us to do; grace reminds us of what God has done so we don't have to do anything ourselves.

"I'm not giving out of routine, I'm giving out of response."

No, you are not. If you are responding, you are responding under the law. Unless it is willful, which would make it an offering. Tithing is not willful, it is lawful.

"He doesn't need it, we need it."

Freudian slip — the church does need it.

The bottom line

Give your money to the poor. Give offering to the church (if you like). Don't give tithes.

But in the end, you can do whatever you want. 🤷‍♂️

BEM (Block-Element-Modifier) in CSS is an industry standard in web development; I know a lot of people who use it. I learned it, mastered it and started using it in my own projects.

However, like all systems and tools I've used, I started to question it. Was BEM really the prized gem that I've always thought it was?

In today's blog post, I would like to talk about BEM, why I used it, and why I don't use it anymore.

What I like about BEM

BEM was magic when I first discovered it. It solved a few issues:

• Scoping: This is the number one problem it solves — scope leaks. Scope leaks can cause your CSS to break in unpredictable ways.
• Name clashes: With BEM, you can rest assured that no two elements would have the same name on the same page.
• Readable: BEM names were easy to understand and to trace down in HTML.
• Less cascade conflicts: Because every element had a different name, a lot of conflicts disappeared.
• Modularity: Adding styles does not break existing styles.

What I hate about BEM

With all the advantages listed above, I thought BEM was the perfect solution. Until I used it. Then I used it again. And again. And again.

Then I noticed a few shortcomings:

• Long names: BEM names were just too long. And they only got longer and longer the more elements you add to your page. (Kinda like O(n) in algorithmic complexity lingo.)
• Code is not DRY: Don't Repeat Yourself is important to all developers when it can be achieved. This should be no exception.
• Ugly code: Not only was the code long and repetitive, it was also unpleasing to look at.

There was no cure for these issues; they are all inherent in BEM.

So you could imagine how elated (and surprised) I was to find a solution.

Introducing GPS

As I was looking for a solution to the shortcomings of BEM, I stumbled upon an article titled BEM is terrible.

In that article, the author introduced the concept of GPS: Global, Page (or View), Section. I have never heard of it, but I was intrigued to find out that it's a new system that could be better than BEM.

However, after reading the whole article, I discovered that the method is not new at all. In fact, it sounds more like how these technologies were supposed to be used.

In summary, the foundation of what he is saying is this:

• Use IDs in CSS when you need to reference HTML elements that are unique (similar to every student in school having an ID).
• Use class names in CSS when you need to reference HTML elements that will be repeated in the HTML document, or have a repeated style (similar to every student in school being grouped by classes).

If you follow these principles, everything falls in line. I used to think that IDs were evil because of specificity, but this could not be further from the truth. CSS becomes more powerful when you learn to embrace its strengths.

Usage examples of GPS

My blog

With BEM, the code for my blog home page was looking like this

<div class="feed">
    <article class="feed__item">...</article>
    <article class="feed__item">...</article>
    <article class="feed__item">...</article>
    <article class="feed__item">...</article>
</div>

With GPS, you'd have something simpler:

<div id="feed">
    <article>...</article>
    <article>...</article>
    <article>...</article>
    <article>...</article>
</div>

You see? Shorter names. Less bytes. Less cognitive load. More communication. No clutter. It's genius.

Now in CSS, instead of this with BEM:

.feed {
    /* CSS styles here */
}

.feed__item {
    /* CSS styles here */
}

I do this with GPS:

#feed {
    /* CSS styles here */
}

#feed > article {
    /* CSS styles here */
}

A client's website

Below is a simplified version of code I wrote for a client of mine using BEM:

<div class="appointment-summary">
    <h2>Appointment summary</h2>
    <div class="appointment-summary__cart">
        <div class="appointment-summary__cart__summary">
            <p>2 services</p>
            <div class="appointment-summary__cart__summary__details">
                <div class="container">
                    <span>$175.00</span>
                    <svg class="separator" viewBox="0 0 24 24">...</svg>
                    <div class="appointment-summary__cart__summary__details__duration">
                        <svg class="icon icon--time" viewBox="0 0 24 24">...</svg>
                        <span>2 hr</span>
                    </div>
                </div>
                <div class="appointment-summary__cart__summary__details__buttons">
                    <button class="button--arrow-toggle"><svg class="icon icon--chevron-up">...</svg></button>
                    <a id="book-appointment-mobile-button" href="booking-complete.html" class="button button--primary button--next button--book-appointment">Book Appointment</a>
                </div>
            </div>
        </div>
        <div class="appointment-summary__cart__services">
            <div class="appointment-summary__cart__services__service">
                <p>Wash and Blowdry</p>
                <span>$55.00</span>
                <svg class="icon icon--trash">...</svg>
            </div>
            <div class="appointment-summary__cart__services__service">
                <p>Jumbo Box Braids</p>
                <span>$120.00</span>
                <svg class="icon icon--trash">...</svg>
            </div>
        </div>
    </div>
    <a id="book-appointment-button" href="booking-complete.html" class="button button--primary button--next button--book-appointment">Book Appointment</a>
</div>

Using GPS, a lot of complexity goes away:

<div id="appointment-summary">
    <h2>Appointment summary</h2>
    <div id="cart">
        <div id="summary">
            <p>2 services</p>
            <div id="summary-details">
                <div class="row">
                    <span>$175.00</span>
                    <svg class="separator">...</svg>
                    <div id="summary-duration">
                        <svg class="icon time">...</svg>
                        <span>2 hr</span>
                    </div>
                </div>
                <div id="summary-buttons">
                    <button class="arrow-toggle"><svg class="icon chevron-up">...</svg></button>
                    <a id="book-appointment-mobile-button"
                        href="booking-complete.html"
                        class="button primary next book-appointment">
                        Book Appointment</a>
                </div>
            </div>
        </div>
        <div id="cart-services">
            <div class="service">
                <p>Wash and Blowdry</p>
                <span>$55.00</span>
                <svg class="icon trash">...</svg>
            </div>
            <div class="service">
                <p>Jumbo Box Braids</p>
                <span>$120.00</span>
                <svg class="icon trash">...</svg>
            </div>
        </div>
    </div>
    <a id="book-appointment-button"
        href="booking-complete.html"
        class="button primary next book-appointment">
        Book Appointment</a>
</div>

The CSS with BEM:

.appointment-summary {
    /* CSS styles here */
}

.appointment-summary h2 {
    /* CSS styles here */
}

.appointment-summary__cart {
    /* CSS styles here */
}

.appointment-summary__cart__summary {
    /* CSS styles here */

}

.appointment-summary__cart__summary p {
    /* CSS styles here */
}

.appointment-summary__cart__summary__details {
    /* CSS styles here */
}

.appointment-summary__cart__summary__details .container {
    /* CSS styles here */
}

.appointment-summary__cart__summary__details span {
    /* CSS styles here */
}

.icon {
    /* CSS styles here */
}

.icon--chevron-up {
    /* CSS styles here */
}

.appointment-summary__cart__summary__details__duration {
    /* CSS styles here */
}

.appointment-summary__cart__summary__details__duration span {
    /* CSS styles here */
}

.appointment-summary__cart__summary__details__buttons {
    /* CSS styles here */
}

.appointment-summary__cart__services {
    /* CSS styles here */
}

.appointment-summary__cart__services__service {
    /* CSS styles here */
}

.appointment-summary__cart__services__service p {
    /* CSS styles here */
}

.appointment-summary__cart__services__service span {
    /* CSS styles here */
}

With GPS:

#appointment-summary {
    /* CSS styles here */
}

#appointment-summary h2 {
    /* CSS styles here */
}

#appointment-summary #cart {
    /* CSS styles here */
}

#appointment-summary #summary {
    /* CSS styles here */
}

#appointment-summary #summary p {
    /* CSS styles here */
}

#appointment-summary #summary-details {
    /* CSS styles here */
}

#appointment-summary #summary-details > .row {
    /* CSS styles here */
}

#appointment-summary #summary-details > span {
    /* CSS styles here */
}

#appointment-summary .icon {
    /* CSS styles here */
}

#appointment-summary .chevron-up {
    /* CSS styles here */
}

#appointment-summary #summary-duration {
    /* CSS styles here */
}

#appointment-summary #summary-duration > span {
    /* CSS styles here */
}

#appointment-summary #summary-buttons {
    /* CSS styles here */
}

#appointment-summary #services {
    /* CSS styles here */
}

#appointment-summary #services > .service {
    /* CSS styles here */
}

#appointment-summary #services > .service p {
    /* CSS styles here */
}

#appointment-summary #services > .service span {
    /* CSS styles here */
}

There you have it. Shorter. Simpler. Clearer. 😄

Few criticisms on GPS

One thing I dislike about GPS is the recommendation of prefixes like g- for global styles and p- for page styles. I believe that prefixes are unnecessary, superfluous and make my CSS a little less readable.

I think the best thing is to allow these styles to be inferred by their context.

For instance, an About page may be structured like this:

<html>
    <body id="about">
        <div id="intro">
            <img src="images/our-team.webp">
            <p class="g-full-width">Meet our team</p>
        </div>
    </body>
</html>

The g- in g-full-width indicates that the values are read from the global styles.

However, I would argue that there is no difference between defining the selector as full-width (as opposed to g-full-width). I should not really care about where the value comes from. If I wanted to overwrite the value for some reason, I could use IDs to do so:

/* In global CSS */
.full-width {
    /* Full width in global context */
}

/* In page CSS */
#about .full-width {
    /* Full width in about page context */
}

I've never tried this before, but I plan to give it a shot and see if I run into any roadblocks. I believe this is a much simpler approach and could make my CSS code even more readable.

The bottom line

It's sad how I overlooked the basic principles of the web and dabbled into something that made using the web harder. 🤦

Oh well, I'm happy to have found a way that works best for me. 😄

For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.

John 3:16, The Bible

The only thing I hate more than recording my own singing is releasing the audio to the public. But I love Jesus so I had to drop this.

Best you listen on mute 😜. (You've been warned. 😏)

My whole life has changed
Since you came in, I knew back then
You were that special one
I'm so in love, so deep in love
You made my life complete
You are so sweet, no one competes
Glad you came into my life
You blind me with your love
With you I have no sight

Ginuwine, from his song Differences

Please listen to the original song when you can. Ginuwine is a R&B genius 🎶!

The bottom line

We love him, because he first loved us.

1 John 4:19, The Bible

Chess is a war over the board. The object is to crush the opponent's mind.

Bobby Fischer, chess grandmaster

The pawns are pushed, the bishops set,
The horses out the stall;
A castled king, a centered queen,
The rooks ready for war.

Back in college, I played lots of chess. I would play with my fellow college mates for fun when there were power outages during the day (which happened a lot back in my home country, Nigeria).

Ever since I've left college, I've played chess on and off. I would go to meetups (through meetup.com) to play with random people and get floored every time. I tried playing online for a while, but I prefer over-the-board games. I like to hold the pieces, see the board fully, and look my opponents in the eye. Without all that, are you really playing chess?

A friend of mine recently asked me to join chess.com. I was reluctant at first because I don't like to play online. Plus, if I was going to play online, I would rather play on matches on lichess instead, since it's open-source. However, after we spoke on the phone, I was convinced to try it out.

But first, I had to fix the over-the-board issue.

Electronic chess

I don't like playing chess on a flat board (on a flat screen) so I had to find a solution online.

After a little googling, I stumbled upon Chess Up 2 and Chessnut Evo. Both are electronic chessboards for playing chess online and offline. What's special about these chessboards is that they have built-in screens and chess squares that light up. They both looked pretty good in the YouTube videos I watched.

After little contemplation, I purchased the Chess Up 2 board. I was skeptical at first, because I didn't know how much I'd like it. I was even more skeptical when I received the first board because it didn't work properly. None of the squares lit up, but the built-in screen seemed to work.

I had to contact Bryght Labs (i.e. the makers of Chess Up 2) via email. After a little back and forth, they sent me a brand new board and voila! Everything worked!

I've used the device for a couple days now, and I can say that it's money well spent. I like all the features of the board and the fact that I could play online games with it. I can play AI and even get AI to assist me against AI opponents. I never knew I would love chess again this much.¹

Using the chessboard element

The next step was to blog about my new (or should I say resurrected) hobby. I want to share the games I play so I (and everyone that visits this blog) could watch them again and again.

I learned about the <chess-board> web component and I was blown away! It's an open-source, custom HTML element that displays a chessboard on a web page. I coupled that with the chess.js module and created a way to display my games.

So after I played my first online game with my friend, I downloaded the Portable Game Notation (PGN) file from the chess.com Android app and sent it to my computer. I parsed all the moves and loaded them into a JS array, then I created a class called ChessGame that handles everything for me. ChessGame combines the display of <chessboard-element> and the logic of chess.js to bring my games to life.

The JS file for this page looks something like this:

import { ChessGame } from "../common/chess-game.js";

const moves = [...]; // An array of moves

const board = document.querySelector("#board");
const game = new ChessGame(board, moves);

const backButton = document.querySelector("#back-button");
const nextButton = document.querySelector("#next-button");
const resetButton = document.querySelector("#reset-button");
const flipButton = document.querySelector("#flip-button");

backButton.onclick = e => game.undoMove();
nextButton.onclick = e => game.makeMove();
resetButton.onclick = e => game.reset();
flipButton.onclick = e => game.flipBoard();

With this, I can display games that I've played and allow users to see every move played by me and my opponent.

My first online game

Here's my first online game against my friend that convinced me to join chess.com. I played as black in this game.

I commented on some of the moves. Feel free to playback the game till the end.

Jazz is the only real music that is gonna last; all that other bullshit is here today and gone tomorrow.

Jimmy Smith, jazz organist

A quote from Jimmy Smith that I heard from the last track of Drake's album Nothing Was The Same got me thinking about how many unique contexts the idea could fit in.

The full original quote by Jimmy Smith was from his track Jimmy Smith Rap on his album Off The Top:

The sample from the Drake track called Pound Cake/Paris Morton Music 2 alters it a bit to say "Only real music is gonna last; all that other bullshit is here today and gone tomorrow":

Pretty much the same thing, but slightly edited. I think this applies to a variety of subjects, so here are my derived quotes 🕺🏾:

The web is the only real platform that is gonna last; all that other bullshit is here today and gone tomorrow.

Another one:

Raw food is the only real medicine that is gonna last; all that other bullshit is here today and gone tomorrow.

And finally:

Jesus is the only real king that is gonna last; all that other bullshit is here today and gone tomorrow.

I highly recommend listening to both albums, Nothing Was The Same and Off The Top 🔥.

A lot of bloggers that I follow have responded to the ultimate Blog Questions Challenge and I thought I would give it a go myself.

Why did you start your blogging in the first place?

Funny enough, this question was supposed to be what my first blog post answered, but at the time I had no idea, so I didn't make the first blog post post.

However, now I can say I blog to talk about observations and opinions I have concerning:

• The web
• Life events
• Tech (of course)
• The cosmos
• Music
• Poetry
• Christian faith and religion
• Random stuff

I always allude to the fact that everything is just ramblings in my head that are trying to get out, and my blog is that outlet.

What platform are you using to manage your blog and why did you choose it?

I use a custom stack I like to call the FUN stack: it includes Flask, uWSGI and Nginx.

Flask is a micro-framework for building web applications in Python. uWSGI is a production-ready application server primarily used for deploying Python web applications. Nginx is a web server. Each of these technologies run on my Vultr Virtual Private Server (VPS).

So the flow is like this:

1. I write my blog post in a Markdown file and upload it to the VPS (with rsync).
2. When a user visits my website, Nginx receives the request and forwards it to the uWSGI process.
3. uWSGI manages multiple websites that I run on my VPS (using Emperor). uWSGI forwards the request to the Flask application responsible for the website.
4. The Flask application pulls the data from the Markdown file, converts it to HTML and sends the full HTML page down the chain again until it gets back to the user.

It may seem like a long process, but all of this happens in milliseconds. Everything else (like image resizing, image format conversion etc.) is handled by custom Bash scripts I wrote.

I like this way of writing blog posts the most because:

• I understand each part, making it simple to set up. Most of the setup requires configuration files that are set-and-forget.
• Each of them is open-source and have been maintained for a long time.
• I don't have to use CMSs and JS frameworks.
• It's flexible, I can have it my way (like Burger King 🍔).
• There are NO BUILD STEPS! I just push to my server and reset the running processes. (I know, magic. 🤩)

Have you blogged on other platforms before?

I used to blog on Google's Blogger back in 2016. I also tried to set up the Ghost blogging platform back in 2020. In both cases, I got distracted (which happens to me more often than I could count).

I'm happy that I don't use these platforms though; I love to own my data!

How do you write your posts?

When I'm inspired to write, I open Markdown file template (that I created and customized myself) in my Vim text editor and let my fingers wiggle. I don't post it until I've read it a couple times and I'm satisfied with my editing. If I'm not satisfied enough, I let the post sit for a while until I get to that point. That could range from a few minutes to a few weeks.

When do you feel most inspired to write?

Almost never 😜. Inspiration comes so randomly. It usually comes when I'm watching a YouTube video, or I'm reading a book, or I'm lost in thought.

To remedy this issue, I try to journal every morning to get me more into the spirit of writing.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

It depends on the post, but I'm more likely to let it simmer, especially if it's a pretty long post. I'm also not afraid to make updates to my posts after the first couple hours/days of release.

What's your favorite post on your blog?

None; I hate them all equally 🙃.

Any future plans for your blog?

Yeah, I really need to work on my About page and the frequency of posting. I also want to add a couple new pages for the books I've read, what I'm doing now etc.

Why do you write? Other than your blog, do you write long-form content elsewhere?

I like to write because:

• I like to express my opinions and observations. It is very liberating. It makes me process my thoughts better and helps me to get better at expressing my thoughts for people to understand, a very important quality for a webmaster to possess.
• People can tell me I'm wrong when I'm wrong, or just criticize me in general. I'm not an island of knowledge; I think that the feedback from visitors can really help me to see the world in new ways.

I don't write long form content anywhere else (for now).

SQLite is not so bad
It has a couple perks
But so does every other file —
Be sure to use what works

With all my recent mentions of SQL, the title may seem clickbait-y or a little tongue-in-cheek, but I mean it: SQLite is not all that bad.

How did I come to this new conclusion? I read an article of course. It speaks about some of the superpowers of SQLite and to be honest, I was impressed. Here are a few:

• Data is stored on a single file. (I've always known this, but the article reminds me of how big of advantage it is.)
• Data access is relatively fast when compared to the file system.
• It uses weak typing, making it throw errors less and easier to adapt by beginners.
• It accepts JSON now.
• There is a workaround for its read/write locking nowadays.

However, with all that said, I still believe that we have to choose the tools we use carefully. SQLite would not always be the best solution; sometimes a simple text/JSON/CSV file would suffice. Every situation should be carefully examined before you make a decision.

Moreover, most of the time the decision you make can always be changed; there are many ways to convert SQLite data to other forms and vice versa.

For me, I will stick to using the file system for most of the websites I run, since I don't have a lot of files to store. However, for my clients that I design websites for, I most likely would use SQLite as it makes the development process a little easier. I get the added benefit that all their data is in a single file. (It sounds kinda eerie if I keep repeating that to myself.😨)

Bottom line? Use what you need when you need it.

A game is the complete exploration of freedom within a restrictive environment.

Vineet Raj Kapoor

Let my web-game-creating career begin 🥳!

Today, I would like to present my first game for the web called Simon Says, and I did it all using web components.

Without further ado, let's just jump in.

The game

Here she is: the web game component more powerful than Superman, Batman, Spider-Man, and the Incredible Hulk put together!

In Simon Says, once the game starts, the CPU 🤖 will light up some boxes on the screen. Your objective is to tap the boxes that were lit up by the CPU 🤖, but you'll have to wait your turn to do so.

This version of Simon Says resembles the electronic version more than the kids version.

You could see it more-or-less like a memory game — or a game of "follow the leader"🚶‍♂️🚶‍♂️🚶‍♂️.

A little history

This is not my first time making this game. I made it back while I was in college NOT studying for my classes. I made the game in C++ with a GUI framework called Qt. I really wanted to make a game because I knew that was what C++ was mostly made for (at least so I thought).

That project was successful but I ran into an issue: I lost all the code! How it happened doesn't matter. The whole incident proves why the web could be a better solution for (some) games. If I had the game online, maybe I would still be playing it by now; all I would need to do is host it.

That is definitely not the only reason I prefer web to native game development. Here are a couple more:

• The web has no build steps. Goodbye to waiting for 2 hours of compilation for 2 lines of changes to source code.
• I can add games as part of any web page just by dropping a web component in.
• You can add games as part of your web pages by just copying and pasting my web component. (Don't worry, you couldn't go to jail even if I wanted to snitch 😉.)
• It's cross-platform. Players can use the browsers on their phones, laptops, desktops, tabs, smart TV, Raspberry Pis etc. to access web games.
• Everyone uses the web, making marketing and discoverability easy.
• I can update my game whenever I want. Players get the latest updates as long as they are online.
• I can send a link to anyone and they get instant access to the game.
• I could get and control analytics if I want. (I don't.)
• The web is ubiquitous; you can play anywhere, anytime.

"Why'd you do it?"

• To see if I could get web components working on my blog.
• To see if I could build a full game using JavaScript without losing my sanity.
• For fun.
• To prove the simplicity involved in creating games for the web.

"How can I use it in my website?"

Simple. Add this to your HTML page:

<script type="module" src="https://mmhq.me/static/js/wc/simon-says/simon-says.js"></script>
<simon-says></simon-says>

Future plans

I plan to fix any bugs and to enhance it much more with animations and better scoring when I get the chance.

I also plan to make more game web components and display them all in an upcoming Wall of Game. Stay tuned!

The bottom line

I hope you have as much fun playing this game as I had making it.

Feel free to send feedback via email of your the highest score or complaints, criticisms, comments, or compliments you have on your mind.

And yes of course, 3D games are coming next (in 2034 🙃).

I admit it; I used to hate testing. It never made any sense. Why would I want to write more code (test code, that is) when I already have code to write?

With time (and many years of force by the industry), I have learned to understand its importance and place in a software project. However, I have also learned to understand its abuse.

Let's take a look at a practice that is commonly abused, TDD.

TDD: the "poster child" of software development

What is TDD?

Another method that developers made to help you code slower and miss deadlines more often. TDD stands for Test-Driven Doom, oh wait, I mean Test-Driven Development, and it's all about telling you how your code is wrong and how you can stop whatever you are doing to make sure you are writing code correctly.

First off, you may think that the first objective is to write code, but really, your first objective is to write test code for code you haven't written yet. That is the proper way to write code.

Then after you write that code, make sure that the code doesn't pass. If it passes on first run, you are definitely doing it wrong. In fact, if it compiles on the first run you are one confused individual. You have to make sure it doesn't pass. Then you write the code for the test code you wrote earlier, then keep writing and correcting the code until it passes — then, and only then, have you completed TDD.

Of course, I'm being hyperbolic here, but you see my point.

The problem with TDD

So as you may have noticed, TDD is not my cup of tea. It has a few shortcomings:

• It's recommended for every project. I don't even think I'm exaggerating. Every senior developer swears that it works for every project (and can cure cancer) and I can testify that that's not true. Never have I looked at a failed project of mine and said, "Yup, this project would have been much better using TDD."
• It stifles tinkering, imagination and exploration. It causes me to do a lot of upfront thinking, which is not always a bad thing. However, if I'm dabbling into projects that I'm not too familiar with or I'm not sure of the full direction, I want to plan what I can plan on paper, then code at my computer. That way, I can just jump into code when I get on my computer.
• They claim it helps you to know how to start your project. However, in my experience, you have to do this for every project you ever encounter: you have to determine what code to write first. You don't need TDD to do this.
• They claim that it enforces good practices. I don't like the term "enforces" in this context. I believe every developer should have the freedom to do whatever they want to do when developing. And as for "good practices"; what encourages good practices is extensive coding i.e. you must code to be better at coding.

But still, I use TDD...

It's ironic, I know. But sometimes it works. Just not every time.

TDD purists would swear up and down that they always use TDD and follow the laws of programming to the T.

But let's be honest: the importance of practices like TDD are nowhere close to that of other practices and philosophies like KISS (Keep It Simple Stupid), SOLID, or even YAGNI (You Ain't Gonna Need It).

...but most times I don't

TDD is bad when it gets in the way of tinkering.

There are times when I'm writing experimental code. Writing test code for experimental code is not wise as the code may be deleted later.

I consider most of the code I write as experimental; I don't know the final structure I would choose when I start writing code. Most times I just plan on paper and just jump into code right after: I don't see why I should do otherwise.

I'm not saying that you should not plan when writing code. I'm just saying that it is okay to not use TDD. Sometimes, I even write the tests after I finished writing the code.

I guess the main problem with TDD for me is that I have to write test code for code that I'm not sure is going to stay in the project. That's way more code than I'm willing to write.

What is the alternative?

Simple. Write the code first, then write the test code. A foolproof solution that has been working for years for me. That way when I do write test code, it's more likely to stay in the codebase.

(I know, TDD purists would argue I deserve death by lethal injection for making such a claim but they're have to catch me first! 🙃)

The bottom line

I use TDD when:

• I already know exactly how the resulting API should look.
• I'm in a corporate setting, where a lot of planning is done ahead of time.
• I know how the new code would interact with the current codebase.
• I'm adding features to an existing codebase (especially one where some tests have already been written).

I don't when:

• I'm tinkering.
• I want to be free and control how I write my software (which is almost always).

In conclusion, don't let anyone tell you how to write code. Hone your craft; choose the practices that work for you.

If you can’t give me poetry, can’t you give me poetical science?

Ada Lovelace

Today I read a couple articles on Ada Lovelace. She was the first programmer ever, which makes her the grandfather of my profession, programming 🤓 (a real G 😉). But she wasn't only a programmer, she was also a prophet.

Long before the formalization of universal computing by Alan Turing a century later, Ada predicted that computers would be used to create music, generate graphics, and even perform tasks beyond just mathematical operations.

What fascinated me about Ada Lovelace the most was the fact that she claimed that her knowledge of poetry helped her to make that prediction. She also coined the term poetical science.

What is poetical science?

Ada Lovelace didn't explicitly define the term poetical science, but she used the term to describe her unique approach to mathematics and science. She believed that imagination and insight can be paired with science to unlock new discoveries.

How is programming poetical science?

We may say most aptly that the Analytical Engine weaves algebraical patterns just as the Jacquard-loom weaves flowers and leaves.

Ada Lovelace, a display of her mastery of metaphor

Programming is essentially instructing a computer on what to do. However, like Ada described, when we program, we don't program by explicitly flipping switches on an electronic board (which is what essentially the transistors in all computers do); we program using a human-like language.

For instance, in object-oriented programming, we use objects. These objects are not real, just metaphors; they are representations of objects in real life. So a file in a program is not "a folder or box for holding loose papers", but a sequence of bytes that represents data in the system.

In Python, to open and read a text file called doc.txt, we could run the following code:

with open("doc.txt") as file:
    print(file.read())

Did you catch that? I said open and read even though the computer is just manipulating and transforming a sequence of bytes you call a file. It's all metaphor.

When you call open(), you are not really opening a file or opening a folder with documents inside; you are manipulating some bytes. And when you call read(), you are not really reading a file or deciphering text on a sheet of paper in a folder; you are transforming bytes to alphanumeric characters and rendering them on a screen.

As much as we think what we are doing as programmers is scientific, there is a lot of poetry that is mixed in.

The bottom line

Looking from Ada's perspective, we can conclude that programmers are machine poets; we tell the computer sweet nothings in rhyme and meter and she rewards us with her virtual innards.

It's nice to know that poetry lies at the very foundation of this art called programming; I need to read more Shakespeare to improve my coding skills 🙃.

I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.

Bill Gates, founder of Microsoft

You may not have noticed, but my blog is missing a lot of features 😆. I am well aware of these omissions. They exist because I'm building this blog progressively: I add features as I need them.

Also, it doesn't help that I start all my HTML and CSS files for this blog from an blank page (as opposed to using various often bloated web frameworks and toolkits 🤮).

I do this because I prefer to learn every bit of the web without too many abstractions; abstractions can blind you from a lot of things. (It's part of what they are created to do.)

So what is this blatantly missing feature that every blog should have? A comment section of course 😆!

I need feedback so that I can have my ideas validated and challenged. I am willing to hear what anyone interested has to say.

The plan

I planned to do it the lazy way.

Since I lacked a comment section, I set up a separate email to respond to replies, comments, criticisms etc.

Email has been supported by the web for such a long time that it was a no-brainer. Everybody has one these days, and it costs absolutely nothing. Sounds like an accessible medium to me 😉.

With this goal in mind, I had to make a couple changes to my website code.

The HTML code

The ease of the web is unfathomable sometimes. Sometimes, all it literally takes is one line:

<p class="reply-request">If you would like to reply to or comment on this blog post, feel free to email me at <a href="mailto:efe@mmhq.me?subject=Re: {{ post.title }}">efe@mmhq.me</a>.</p>

That's it! Let's break it down:

• <p>: Represents the paragraph element in HTML and instructs the browser to create a new paragraph. The class attribute is set to reply-request so that it could be referenced in CSS. (More on that later.)
• <a>: Represents the anchor element in HTML and instructs the browser to create a new hyperlink or link for short. The magic here is what this specific link does. The key to its functionality is the href attribute's setting starting with mailto. (More on that later.)

These two HTML elements are sufficient to add commenting the lazy way. Clicking on the link at the bottom of this page would automagically open your default email app with the subject title set to "Re: New blog feature rollout" and the email recipient set to my email, efe@mmhq.me.

How? With the magic of mailto, or more specifically, mailto:efe@mmhq.me?subject=Re: {{ post.title }}. Let's break it down:

• mailto:: A powerful URI scheme for email addresses. This instructs the browser to open your email app when the link is clicked.
• efe@mmhq.me: The email address to send to.
• ?: Syntax token that denotes the beginning of a query. The text after this would be read as a series of attribute-value pairs for the mailto scheme.
• subject=: An attribute for mailto called subject. Tells the browser to use whatever value that follows as the subject of the email.
• Re: {{ post.title }}: The subject of the email. Re: denotes that its a reply to a post, and {{ post.title }} is the Jinja2 way of saying "Replace with my post title here". When the final HTML document is created on my server, the {{ post.title }} becomes the title of the blog post. (For example, Re: New blog feature rollout for this post you're currently reading.)

Simple right? With everything working almost perfectly¹.

This is a known feature but not celebrated enough. It's not even new. This has been supported by browsers for a long time (maybe even since Web 1.0).

And this is why I love the web, I could be lazy and add this feature now until I am ready to finally upgrade to a killer comment section.

Till then, I can get back to what's important: 😴.

The CSS code

Not much was needed to style the added paragraph:

.reply-request {
    margin-block-start: var(--space-l);
    font-size: var(--step--1);
    font-style: italic;
}

• .reply-request: References the <p> element created in HTML.
• margin-block-start: var(--space-l): Instructs the browser to set the top margin of the paragraph to my large space setting, a variable I've defined in my root style.css file.²
• font-size: var(--step--1): Instructs the browser to set the font size to Step -1, a variable I've set in my root style.css file. This sets the font to a size a little smaller than my base font size, Step 0.³
• font-style: italic: Instructs the browser to render the text in italics.

That's it! No JavaScript required 👌.

Bottom line

Build progressively when you build for the web. It's a feature of the web, not a bug 🤩.

Your laziness is welcome 😄.

The buffoonery is at an all-time high.

O'shea Duke Jackson, YouTuber

I was shopping for some items at CVS today when I stumbled upon something surprising on the shelf. In the "Diet Needs" section for the store, there lied different supplements.

That's normal; I can understand if people need supplements. I personally take Vitamin D supplements because I can't get enough Vitamin D from the sun.

But what really shocked me was that I found supplements for fiber.

This may not seem like a big deal, but think about it: is there any other place you can get fiber from?

Yes, there is. Fruits. Vegetables. Nuts. Seeds. All of which are very abundant on Planet Earth and needed by the body.

Yet, people are comfortable buying supplements for vitamins, minerals and nutrients that can easily (and preferably, if you ask the body) be absorbed from fruits, vegetables, nuts and seeds.

In other words:

All you need to do is eat the fruit.

You do not need to supplement everything. There are advantages of eating the fruit over supplements:

• Fruits contain more that just fiber. They contain vitamins, minerals and nutrients your body would thank you for. The supplements just contain fiber, and some other chemicals I can't pronounce or have any clue what they are or what they look like. Let's not even talk about what it could possibly do to your body.
• It is hard to overdose on minerals and vitamins when you eat a variety of fruit. I do not advise eating more than the recommended dosage on the package of the supplements, but even if you don't, we all have different biologies; the way my body reacts to one supplement is different from yours, which is different from John Doe.
• Fruits just taste better. Pills barely have any taste, and the taste of gummies can't even be compared to the taste of an overripe banana.
• Fruits come in different colors and are aesthetically pleasing. I believe that their colors symbolize their function, sometimes. An example is beets — their red in color and they help to produce nitric oxide, which promotes blood flow. Don't ask me how I know. (Ask ChatGPT instead.)
• Fruits can be prepared in a variety of ways: as a smoothie, as juice, as jelly etc. allowing you to create your meal or beverage. Supplements are in their final form pretty much.

So forget the supplement pills and gummies. Eat the fruit. That's all you need.

Go to, let us go down, and there confound their language, that they may not understand one another's speech.

Genesis 11:7, The Bible

I was wandering round the web recently and stumbled upon an article about the death of Web SQL. I couldn't ask for a better article.

In this blog post, I would like to dissect the downfall of Web SQL.

Web SQL almost made it

Every other (relevant) browser had implemented Web SQL already. Google Chrome was first and then Safari. But there was one stubborn one: Mozilla. Thankfully, they stood out and said "No, thanks" to SQL.

Why? A couple reasons:

There were many implementations of SQL

There is no true agreed-upon standard. This would cause frequent changes to APIs on the web, which is a horrible experience for developers and progressive learners (like me).

Imagine having to update your code every couple months because the standard changed, as opposed to once and never again. You might as well you JavaScript frameworks. 😒

It suffered from callback hell

I don't think we would miss code like this on the web (sometimes referred to as callback hell):

openDatabase(
  // Name
  'mydatabase',
  // Version
  1,
  // Display name
  'mydatabase',
  // Estimated size
  5000000,
  // Creation callback
  function (db) {
    db.transaction(
      // Transaction callback
      function (tx) {
        // Execute SQL statement
        tx.executeSql(
          // SQL statement
          'create table rainstorms (mood text, severity int)',
          // Arguments
          [],
          // Success callback
          function () {
            // Execute SQL statement
            tx.executeSql(
              // SQL statement
              'insert into rainstorms values (?, ?)',
              // Arguments
              ['somber', 6],
              // Success callback
              function () {
                // Execute SQL statement
                tx.executeSql(
                  // SQL statement
                  'select * from rainstorms where mood = ?',
                  // Arguments
                  ['somber'],
                  // Success callback
                  function (tx, res) {
                    // Do something with the result
                    var row = res.rows.item(0);
                    console.log(
                      'rainstorm severity: ' +
                        row.severity +
                        ',  my mood: ' +
                        row.mood,
                    );
                  },
                );
              },
            );
          },
        );
      },
      // Error callback
      function (err) {
        console.log('Transaction failed!: ' + err);
      },
      // Success callback);
      function () {
        console.log('Transaction succeeded!');
      },
    );
  },
);

Enough said.

Most SQL implementations end up buried in another interface

After SQL is used as a foundation for your database architecture, a common pattern found among developers is to create another layer (e.g an object-relational model or ORM) or library over the SQL layer. In a case like this, it may benefit developers more if the API exposed was more high-level than raw SQL.

Working with a single layer is easier to maintain, instead of working with SQL and another layer on top of it.

Mozilla failed to see its usefulness

Mozilla refused to implement the feature in Firefox stating:

"We don't think [SQLite] is the right basis for an API exposed to general web content, not least of all because there isn't a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don't want changes to SQLite to affect the web later, and don't think harnessing major browser releases (and a web standard) to SQLite is prudent."

Wise words from a decent browser vendor.

So what can we use instead?

IndexedDB is the answer. I haven't really used it myself, but I don't think it would be more difficult than SQL.

Of course, for people that still want to use SQL, there is the WASM option available maintained by the open-source community. 😒

The bottom line

If the web can cut out bloat, so can you. Get rid of something you don't need today.

Bloat always falls off like how Adobe Flash and Silverlight did on the web. Dispose of it before it sinks your ship.

More resources

• Web Storage and SQL - Vladimir Vukićević
• Web SQL in Memoriam - Nolan Lawson
• IndexedDB - W3 working draft

I watched a couple videos from the Google I/O '24 on YouTube and had a blast. In this blog post, I would like to highlight some of the features that I learned about.

The new features

• Size container queries

  • What's it for: Used to apply styles to an element based on the size of the element's container
  • Why I care: Can be used as an alternative to media queries

• :has()

  • What is it: Selector that targets elements based on whether they contain specific child elements or selectors
  • Why I care: Easier way to select elements

• Subgrid

  • What's it for: Allows child elements to inherit a grid layout from their parent, creating a more flexible and efficient grid system
  • Why I care: More control over the layout of child elements in a grid

• CSS nesting

  • What's it for: Allows you to style elements within other elements, creating a more organized and efficient stylesheet
  • Why I care: Shorter and better organized CSS code

• <search>

  • What is it: Custom element used to define a search field or input element
  • Why I care: Better accessibility (no need to input ARIA to specify search elements)

• Responsive <video> (using <source>)

  • What's it for: Allows you to support various media types in the same video element (just like <audio>)
  • Why I care: More control over <video>

• inert attribute

  • What is it: HTML attribute used to temporarily disable an element, preventing it from interacting with user events
  • Why I care: Easy way to disable elements

• color-mix()

  • What is it: CSS function used to blend multiple colors together, creating new colors based on specified mixing modes and ratios
  • Why I care: More colors to mesmerize site visitors

• :user-valid and :user-invalid

  • What is it: Pseudo-class used to style elements that have been marked as valid/invalid by the user
  • Why I care: Easier form validation

• Compression streams

  • What is it: JavaScript objects that allow you to efficiently compress or decompress data in real-time, without having to buffer the entire data set in memory
  • Why I care: Easier audio manipulation, when I eventually get the time

• Declarative shadow DOM

  • What is it: Method that allows developers to create a ShadowRoot without using JavaScript
  • Why I care: Easier way to incorporate web components into my designs

• popover attribute

  • What is it: Customizable overlay element that appears on top of the page, often used to display information or options
  • Why I care: Can finally create tooltips, toasts, snackbars and popups with ease (no more z-index battles!)

• Scroll-driven animations

  • What is it: Animations that trigger or change based on the user's scrolling position on the page
  • Why I care: Easy scrollytelling, all handled in CSS

• View transitions

  • What's it for: Allow you to animate changes between different views or layouts on a webpage
  • Why I care: Cross document view transitions

• Anchor positioning

  • What is it: Placement of an element relative to a specific anchor point, such as the top-left corner of the browser window or the parent element
  • Why I care: Easier positioning of elements on the page (reminds me of Qt Quick, which also uses anchors)

• <select>

  • What is it: Element used to create a dropdown list of options for users to choose from
  • Why I care: Can customize dropdowns easily

Features not quite ready yet

• The masonry layout

  • What is it: Layout technique that arranges elements in a staggered, multi-column grid, similar to the bricks in a masonry wall
  • Why I care: More eye candy for site visitors

• Third-party cookie deprecation

  • What is it: Process of phasing out cookies set by websites other than the one being visited, aiming to protect user privacy and limit targeted advertising
  • Why I care: Cripples advertising, protects users

• Scoped transitions

  • What is it: Allows you to limit the scope of animations to specific elements, preventing them from affecting other elements on the page
  • Why I care: More control

• Gesture-driven transitions

  • What is it: Transitions that occur based on user gestures like swiping, pinching, or tapping.
  • Why I care: More control

• @scope()

  • What's it for: Simplifies element selection by targeting specific DOM subtrees, avoiding overly specific selectors and reducing DOM coupling.
  • Why I care: Namespaces are finally in CSS, goodbye BEM!

Issues

My only issue with these features is that browser support is not universal yet. It may take a couple years 😢.

The bottom line

The web rocks. I'm happy to watch its growth and to be a contributor.

Long live the Wild Wild Web!

More resources

• The latest in Web UI - Una Kravets
• What's new in the Web - Rachel Andrews

Tell whoever's champ that next year, name the place and time
And warn that motherf****r I'm coming for the chain that's mine

Peter Morris, battle rapper

Peter Morris, also known as Thesaurus, is one of my favorite battle rappers in the game. I like his style a lot because I can hear a lot of poetry influences in his bars.

Let's take a glimpse of his poetic genius by analyzing some of his music.

This is the beginning of the end

Although Thesaurus is mostly known for his legendary battle rap performances, he has released a couple songs on YouTube. One that stood out to me is a song called This is the beginning of the end on his album, All I Know Is That.

All the poetic devices masterfully used by Thesaurus are worth analyzing, but let's focus on the rhythm and rhyme.

First verse snippet

In the first four bars of the first verse, Thesaurus kicks off with some smooth rhymes:

I'm speaking languages more lethal than you may assume
A secret play they have to keep in a containment room
I'm the seed of Satan sleeping in an ancient tomb
Once the beast awakens you'll be meeting with your maker soon

Beautifully constructed verse. Let's break it down.

The rhythm

The rhythm used by Thesaurus is a common meter in poetry, so common that the meter is literally called common meter. Common meter is a popular rhythm used in poetry (thus the name) called a iambic heptameter, or a fourteener. This rhythm is defined by having 7 (hepta-) iambs per line. An iamb is a weak syllable and a strong syllable in succession, kind of like a heart beat (the da-DUM sound). 7 iambs totals up to 14 syllables per line.

Let's break down the rhythm into weak and strong beats:

I'm speaking languages more lethal than you may assume
A secret play they have to keep in a containment room
I'm the seed of Satan sleeping in an ancient tomb
Once the beast awakens you'll be meeting with your maker soon

As displayed, the rhythm is regular and the bars scan well (a little too well if you ask me).

A lot of poets (like Emily Dickinson) used this meter. It's also called the hymnal meter because it was frequently used in hymns. Thesaurus masterfully repurposes the meter to craft an elegant verse.

Let's look at the rhyme next.

The rhyme

I'm speaking languages more lethal than you may assume
A secret play they have to keep in a containment room
I'm the seed of Satan sleeping in an ancient tomb
Once the beast awakens you'll be meeting with your maker soon

In this quatrain, you can see how Thesaurus cleverly gets each line to rhyme at multiple spots, and not just relying on the end rhyme. This makes his bars tight and more pronounced.

Second verse snippet

Thesaurus doesn't stop there. He continues to spit flames in the second verse.

Here's a quatrain embedded somewhere in the second verse:

I've redefined the standards that were set before me
'Cause my predecessors exercised their methods poorly
I'm just the guy to execute a plan
I'll always get the best of you unless you prove I can't

Once again, let's break it down.

The rhythm

As you can see, Thesaurus grabs reach of common meter once more, keeping each line about 14 syllables in length:

I've redefined the standards that were set before me
'Cause my predecessors exercised their methods poorly
I'm just the guy to execute a plan
I'll always get the best of you unless you prove I can't

There is a break in the normal line length on line 3, where he uses an iambic pentameter instead, another typical poetic meter. This variation revitalizes the quatrain.

The rhyme

Thesaurus has a way with rhyme and this song is an example of flawless execution:

I've redefined the standards that were set before me
'Cause my predecessors exercised their methods poorly
I'm just the guy to execute a plan
I'll always get the best of you unless you prove I can't

As you can see, he once again uses a lot of internal rhyme and assonance.

The bottom line

Poetry has a heavy influence on the battle rap community and it is nice to see people like Thesaurus who know how to use them in new and exciting ways.

More resources

• His bio
• The track
• His top ten rounds
• His YouTube channel
• Hymnal meter
• Iambic pentameter

For I desired mercy, and not sacrifice; and the knowledge of God more than burnt offerings.

Hosea 6:6, The Bible

Building websites today has become easier than it's ever been. All you need is a text editor and a browser, two programs that almost every home computer possesses today (and most times, right out the box).

To make your first webpage, you can create an index.html file anywhere on your computer, stuff it with the following content, and open the file in a browser:

<h1>Hello, world</h1>

And voila! You've made your first webpage. Slap on a domain name and throw it on a hosting service and you are good to go.

So why do we need build steps on the web?

That question reminds me of a story in the Bible.

Starving on the Sabbath

Jesus was walking through a field of corn with his disciples one Sabbath day. His disciples were hungry, so they plucked ears of corn from the field and ate them. The Pharisees saw them and told Jesus that his disciples are doing what is unlawful on the Sabbath.

What was Jesus' response?

And he said unto them, The sabbath was made for man, and not man for the sabbath:

Mark 2:27, The Bible

Huh? What was Jesus saying?

Jesus was telling the Pharisees that God created the Sabbath to serve man (by giving him rest) and not so that man serves the Sabbath. In other words, instead of focusing on the work others are doing, rest (like God did on the seventh day of creation).

In this analogy, sabbath can be replaced with web. The web was made for man, and not man for the web.

But today, with so many tools on the web, web developers tend to focus on work (i.e. build steps) and tend to do more work than necessary.

Why are build steps bad?

When I say build step, I mean any step that needs to be performed before deploying your website.

As innocuous as it sounds, choosing the wrong build steps can affect 3 areas every web developer should care about:

• 👤 User experience (UX): The overall experience of a site visitor when using your website.
• ♿ Accessibility (a11y): The degree to which your website is usable by as many people as possible, including disabled people.
• 👨‍💻 Developer experience (DX): The overall experience of the developer when building the website.

Let's explore some popular build steps on the web and measure how each listed area is affected.

The transpilation build step

This involves converting JSX, TSX, TypeScript, SCSS, SASS, Svelte templating language etc. into HTML that browsers can render.

Advantages

• You get to write lots and lots of JavaScript/TypeScript or whatever language and no HTML. Every developer's dream I suppose 😒.
• You get to place your code in separable components that can never be effectively reused outside of the project.
• You don't repeat yourself.
• You write shorter code.

Disadvantages

• 👤 The browser has to execute JavaScript first, which could fail and cause the screen to remain blank.
• 👤 You are going from HTML to JavaScript, back to HTML. This slows down the rendering.
• ♿ The code that is converted to HTML is often not accessible, as the transpiler lacks context of the content on the page.
• 👨‍💻 You have to write lots of JavaScript/TypeScript or whatever language you are using. Whatever language that is chosen will not be safer than HTML, meaning you should expect more issues than usual.
• 👨‍💻 Iterations are slower because you have to build every time .
• 👨‍💻 JSX sucks! It is not as pleasant to write as plain JavaScript. Or plain HTML. (The developer suffers.)
• 👨‍💻 If I have to build HTML, what is the point?

The minification build step

This step involves removing all the unneeded white space and sometimes obfuscating the data in a CSS or JS file to reduce the size of the data that is sent to the browser.

This sounds like a wonderful idea.

Advantages

• You get to remove the white spaces and save 0.001 KB of wasted data. Hooray 😒.
• You get to obfuscate your code, save space and contributing to the 0.001 KB saved 😒.
• You get to obfuscate your code, making it harder for people that have capable browsers to study it 😒.
• You get a false sense of achievement that you have saved a lot of bytes sent for the user 😒.

Disadvantages

• 👨‍💻 Contrary to popular belief, 0.001 KB of data is not a lot saved. You get the best savings when you use gzip to transfer your website (supported on the web as of HTTP 1.1).
• 👨‍💻 If it breaks someday (maybe due to updates in HTML or CSS syntax), you can't deploy.
• 👨‍💻 A different set of code sent to the browser makes debugging a Herculean task (though web developers love this pain).
• 👨‍💻 If your build step has to modify your CSS or JS and can't send it as is, what's the point?

Could be wrong on this one; it seems like the advantages are more here. 😒

The Webpack build step

Webpack is a powerful tool used to bundle modules together. A module is any file that processed by Webpack. In the case of Webpack, we're talking HTML files, CSS files, JavaScript files, images etc.

NOTE: This also includes running npm run build.

Advantages

• Module bundling for easier optimization
• Code splitting
• Dependency management
• Development tools and enhancements like hot module reload and source maps
• Asset optimization like image compression, tree shaking (i.e. removing unused code), CSS and JS minification
• Loaders and plugins for processing different files
• Environment-specific builds
• Easy framework integration
• Long term caching
• Community and ecosystem

Disadvantages

• 👨‍💻 Modules. (I want my HTML, CSS and JavaScript files to be considered unique and separate, thank you 😒.)
• 👨‍💻 Code splitting is unnecessary for plain HTML because the browser needs the whole HTML to render a webpage properly.
• 👨‍💻 Dependency management is unnecessary for plain HTML because if you only use HTML and CSS (and build from scratch), you would have very few dependencies.
• 👨‍💻 Hot module reload is unnecessary for plain HTML because you could just refresh the webpage.
• 👨‍💻 Source maps are unnecessary for plain HTML because the code sent from the server is the same code seen in the browser.
• 👨‍💻 Tree shaking is unnecessary for plain HTML because all the code in HTML is used. The CSS code can be cleaned up manually.
• 👨‍💻 Minification is useless, as I highlighted in the previous section.
• 👨‍💻 Loaders and plugins are unnecessary for plain HTML because the browser handles everything for us. We just need to provide the HTML and CSS.
• 👨‍💻 Webpack has to be aware of the type of build. Unlike Webpack, HTML and CSS have no control over your environment. They are just languages. (Thank God.)
• 👨‍💻 Framework integration is unnecessary for plain HTML if you are not using any frameworks.😜
• 👨‍💻 Who needs long term caching when you have Cache-Control and cache-busting techniques?
• 👨‍💻 Sadly, you have a lot of people using HTML and CSS but not a lot of people writing it. However, you can navigate the web world if you are willing to read documentation and answers online.

Am I the only one that notices that half of the advantages are solutions to the problems caused by Webpack itself? Maybe it's just me. 😒

The SSG build step

According to ChatGPT:

An SSG stands for Static Site Generator. It is a tool that generates static HTML pages from source files, usually using templates and content written in a markup language like Markdown. SSGs are widely used in web development for creating fast, secure, and SEO-friendly websites.

Advantages

• Faster load times
• CDN compatibility
• Reduced attack surface
• No server-side processing
• Simple to scale
• Efficient resource use
• Lower hosting costs
• Content management
• Template based design
• Community support
• Plugins and extensions
• Environmental and deployment flexibility

Disadvantages

• 👨‍💻 No real-time content. You can't easily make changes once an update to older content has been made.
• 👨‍💻 Workarounds for interactivity. Because it's HTML-focused, it makes it easier to extend your code. This makes it less scalable.
• 👨‍💻 Slow build times for large sites.
• 👨‍💻 Incremental builds, complex to configure.
• 👨‍💻 Steep learning curve; Contrary to popular belief, I don't think it's easier than just learning things properly
• 👨‍💻 Dependency on build tools. And you need to keep updating them.
• 👨‍💻 Updating your build pipeline. This could break things.
• 👨‍💻 Third-party dependence for advance features. Limited by what is available.
• 👨‍💻 Inflexibility for certain projects. For e-commerce or similar, forget about it.
• 👤 Third-party libraries used may have a different look-and-feel than the main theme library.

The SSR build step

Once again, educate us ChatGPT:

Server-Side Rendering (SSR) is a web development technique where the server generates the full HTML for a web page and sends it to the client (usually a browser) in response to a request.

Did you catch the fallacy? Rendering only happens at the browser, not on the server. Server-side rendering is really a myth.

The server's job is to serve HTML, not to render it. But I digress 😒.

Advantages