Skip to main content


Happy Father's, Mother's, Sister's, Brother's, Son's, and Daughter's Days

Today is Father's Day in the US. And to celebrate it, my wife and kids got me 6 pairs of socks, 2 shirts, several packs of sour candies, a $25 Domino's Pizza gift card, and a mug emblazoned with the phrase "Good Man, Great Dad". I'll probably never use any of those things; they're all crappy IMHO. (Well, maybe I'll use the gift card and eat the candies; I love sour candies.) But this post isn't a Father's Day rant about the crappy gifts that men receive in comparison to women on Mother's Day; rather, it's about a conversation that I had with my son Kyle about why there isn't a Brother's or Sister's Day too. To quote him: "The world should really have a Brother's Day and a Sister's Day. If not, they should get rid of Mother's Day and Father's Day. I know it's traditional but It's really not fair."  Clearly, he felt left out! Not wanting to let a good opportunity to have an in depth conversation w
Recent posts

A better UI/UX for Cookie consent banners

I'm sure you've seen them before; those pesky, inescapable  Cookie consent banners !  They typically appear at the top or bottom of websites -- often obscuring important content.  For example, if you were to visit  CNN ,  Zara , or  Unicef  today; or, any other news, e-commerce, or charitable website for that matter -- especially those with an international presence -- you'd likely see one; a UI / UX eyesore.  Such Cookie consent banners, ubiquitous and omnipresent, have become the defacto solution for complying with an important part of the European Union's (EU) ePrivacy Directive  (ePD). If you're unfamiliar with the ePD, it basically mandates that websites first obtain a user's consent before storing and/or retrieving any Personally Identifiable Information  (PII) about them in and/or from HTTP cookies.  ( HTTP Cookies are small pieces of data stored by websites in a user's web browser for easier retrieval later.)  The Cookie Law, as the ePD has becom

Using HTML tables for website layout

I first became a front-end web developer in the year of our Lord, 1998.  Back then, the HTML specification had just reached version 4.0; Internet Explorer 7 was the dominant browser; and, the mantra of separation-of-concerns  was still being preached to web developers.  (Back then merely uttering the phrase CSS-in-JS  would've gotten you killed, professionally speaking.)  What's more, back then, HTML tables were still de rigueur; in fact, many websites used them for layout purposes ( DIV-itis hadn't caught on with the masses as yet; that would happen several years later.) Yes, it was the stone ages of the web -- in comparison to today.  Today, there's a wealth of newer technologies for developers to choose from when building websites, i.e. HTML5 , CSS4 , ES9 , etc.  Long gone is the mantra of separation-of-concerns and in its place sits CSS-in-JS, mockingly.  And, long gone are table-based layouts too; they gave way to the aforementioned DIV-itis phenomenon and t

A case for WordPress; or, not your own CMS

I've worked at several major companies thus far in my career; and, at each of those companies, I've had to use an in-house Content Management System (CMS)  to create and modify digital content.  For a long time, I couldn't understand why those companies would choose to allocate time, resources, and ultimately money to create a customized CMS in spite of having functionally equivalent, open source solutions readily available in the marketplace.  What was their rationale for doing so, I often wondered?  Was their businesses so unique that an off-the-shelf CMS simply wouldn't cut it; were the security risks associated with an open source CMS too great of a burden to bear; or, was it because the software engineer(s) in charge at the time simply wanted to showcase their PHP, Java, Python, etc. programming skills by building yet another CMS from scratch.  Well, in the years since I first pondered that question, I've come to realize that the answer is often the latter rea

Lessons from my children, Kyle and Alexis

I'm the proud father of two wonderful children, Kyle and Alexis. Kyle's an energetic six (6) year old boy and Alexis is his equally lively three (3) year old sister; they're both very cute and smart and headstrong.  From time to time, my children will say things - sometimes directly to me or to their mother or others - that gives me pause as a parent.  It's usually something clever or witty but on occasion, it's bad too.  In such moments, I often find myself awestruck by the seemingly guiltless words coming out of their mouths.  Naturally, I've decided to chronicle all of their "wise for their age" utterances in this blog post. Date: 12/13/18 (approximately) Scene: We're in the bathroom; Kyle sits down on the toilet to pee. Me: Why are you sitting down to pee? Kyle: So I don't spill pee everywhere. Lesson: More males should've been taught to sit down to pee; myself included. I must admit though, as a 41-year-old man, that statement

A newbie's guide to website optimization

Okay, you're here; welcome.  Let's get started right away.  First, you should always minify and compress your website's static resources using Gzip , Brotli , Lossless , etc.  (To be clear, by static resources, I mean HTML, CSS, JS, images, videos, fonts, etc.)  Next, you should use a Content Delivery Network to host said static resources, i.e. Cloudflare , Cloudinary , Fastly , etc. You shouldn't , however, bundle your static resources together; in particular, your CSS and JS files.  There was once a time, long ago, when it was considered a good strategy to bundle and shard your static resources, but that time's long since past.  Nowadays, with the ubiquity of HTTP/2 , you're actually doing your users a huge disservice by bundling.  In case you're unfamiliar with it, HTTP/2 reduces "latency by enabling full request and response multiplexing, minimizes protocol overhead via efficient compression of HTTP header fields, and adds support for request

Five common mistakes that websites make with Google Tag Manager

Google Tag Manager  (GTM) is one of Google's best products - second only to its ubiquitous and feature-rich Google Analytics product.  GTM, as its name implies, is a tag manager that's used to embed JavaScript, HTML, and/or CSS code into websites.  Such code can include, but is not limited to, analytics scripts like Google Analytics, tracking beacons from online advertisers, and proprietary content from websites themselves.  There's no denying that GTM is a powerful tool; one that represents a major shift forward from the bad old days of self-hosted, spaghetti-code.  But like most technology, if it's not used correctly, GTM could end up causing more problems for a website than it solves.  Problems having to do with slow performance, mostly; but also tag misfires, data corruption, and quota limitations.  In this article, we'll be discussing solutions to such problems by exploring the five (5) common mistakes that websites make when setting up GTM. Mistake #1: Not