DEV Community: Joe Honton

How A Simple 500-Word Memo Changed the Way We Talk About the Internet

Joe Honton — Mon, 18 Oct 2021 15:35:26 +0000

In March of 1997, Scott Bradner penned a short memo titled “Key Words For Use in RFCs to Indicate Requirement Levels”. It is more commonly referred to as simply RFC 2119. The entire document fits comfortably on two pages of paper.

That memo would go on to become the single most referenced document of the Internet Engineering Task Force (IETF).

Some things may be allowed, some things may not. Some things should be accommodated, other things should not. Some things are required and simply must be present in a certain form, other things must never be present.

Scott Bradner and his 500-word memo (RFC 2119) gave us a way to succinctly specify all of the above, without ambiguity, by defining these five imperatives: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY.

Nearly every RFC written in the past 25 years has referenced RFC 2119 and used these imperatives to be explicit about what is mandatory, what is advisable, and what is allowed but not required.

Interestingly, RFC 2119 itself has only ever been updated once, to clarify that when these imperatives are not capitalized, they have their normal English meanings.

A longer version of this was posted to The unlikely trio MUST, SHOULD, and MAY in internet standards.

Variations on the HTML Two-Step

Joe Honton — Thu, 08 Jul 2021 19:08:48 +0000

It’s not that HTML is impossible to read or write — it’s just awkward.

For starters there’s the pinky finger problem. You know — the keyboard sequence for creating a tag: the left pinky finger holds down the Shift key while the right middle finger searches for the < key . . . then you release the Shift key while typing the tag's mnemonic characters . . . then once again with the left pinky Shift key thingy, while the right ring finger (or is it the one next to it?) fumbles around for the > key.

Then — after composing the paragraph or phrase or word — the whole process is repeated with the closing tag, with all the same keystrokes plus the ergonomic coup de grâce: the right pinky hitting the / key while remembering that the left pinky should momentarily let up on pressing the Shift key!

Try doing this for a sustained period and you’ll soon be filing a worker’s compensation claim for ergonomic injury. It’s like the party game Twister, where your body parts get tied in knots just by following the rules.

So writing HTML is unpleasant, but what about reading it?
In actual practice, HTML tags seldom appear stand-alone. Attributes are frequently applied to tags in order to associate them with styling rules (CSS). And on dynamic documents, attributes are applied to tags for dynamic manipulation (JavaScript). Both of these clutter the document significantly.

But the real problem is that tags and attributes aren’t just lightly sprinkled here and there; they’re dumped all over the document in a downpour — like one of those climate change rainfalls that floods the city so you can’t see the streets anymore.

Reading an HTML document — even one that has color syntax highlighting — makes you wish there was a legal signal-to-noise limit, with offenders getting fined. It’s not uncommon to discover documents where the noise is so many times greater than the signal that it’s impossible to find the author’s words.

If Clara Peller was still around, she’d be demanding to know “Where’s the content?”

HTML wasn’t supposed to be like this.

Excerpted from Variations on the HTML Two-Step.

Excellence in Software

Joe Honton — Thu, 22 Apr 2021 02:36:29 +0000

The “Excellence in Software” score that all software should strive for is “AAAA”. This is tough. Only the very best will achieve it.

The acceptance criteria to use depends upon the type of software under development. For many apps and websites the criteria would be close to the following, with items grouped into four sections: accuracy, usability, safety and compliance. Consider these to be a good starting point.

Accuracy. These are the classic measures of bug-free software.

Does the software consistently produce correct results?
Does the software gracefully handle situations with missing, invalid or extreme input data?
Does the software faithfully save and restore user data?
Do sorting routines correctly work with foreign language data?
Do search routines find and filter results in a way the user expects?
Do summary records always reflect the true sum of the details?

Usability. These are measures of how well the software accommodates users with different levels of sophistication; users having older hardware; and users with less-than 20/20 health.

Does the software work on every device and browser used by the top 98% of users?
Does the user interface have readily available hints and prompts to help new users understand and operate each aspect of the software?
Are form validation messages given to the user in a place and manner that is obvious?
Do background colors and text colors have sufficient contrast to be readable?
Does informational feedback still work for people with protanopia (red-green color blindness)?
Do web components and generic HTML tags have appropriate WAI-ARIA roles assigned?
Does the software accommodate screen readers by numbering HTML tabindex attributes in a most-significant to least-significant order?

Safety. These are measures of how well the user’s data is protected from accidental loss, bad actors, and catastrophic failures.

Does the data backup schedule provide a stable snapshot of everything at hourly, daily, and weekly intervals?
Can the data restoration process be completed within two hours?
Is the catastrophic data storage facility in a separate location from the online data?
Are user credentials properly encrypted during storage and during network transmission?
Is multi-factor authentication triggered when access is requested from a new location?
Are web servers configured to use up-to-date TLS protocols?
Are the website’s Content Security Policy (CSP), Feature Policy, and Referrer Policy properly set up to detect and report breaches?
Are sequential records protected from brute force and replay attacks?
Are user interface redress attacks prevented with proper use of the frame-ancestors CSP header directive?
Is user input sanitized to catch cross-site scripting injections when saving data to the database?
Are financial transactions protected with the use of HMAC-based cross-site request forgery tokens?
Have all files been scanned for viruses before deployment?
Are DevOps’ server credentials stored separately and outside project repositories?
Does the project’s testing protocol include explicit checks for common data breaches?
Are web server access logs regularly monitored for abnormal conditions?

Compliance. These are measures of the software’s adherence to industry standards and civil law.

Do the website’s documents use HTML and CSS in a way that passes W3C validators?
Do browsers evaluate the website’s JavaScript without generating console warnings or errors?
Does the website have a data privacy policy that complies with the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA)?
Does the software’s eCommerce process comply with Payment Card Industry Data Security Standards (PCI DSS)?
Does the software comply with the Access to Information and Communication Technology (ICT) Section 508 standards for government sites?
Does the software adhere to the terms and conditions of each third-party software license it uses?
Are third-party software libraries that are distributed under GNU or MIT licenses properly acknowledged on a public-facing document?
Does DevOps have a written schedule of expiration and renewal dates for all limited term licenses?
Has the company established a vulnerability disclosure policy with a way for outside security researchers and bounty hunters to privately provide notification of issues?

Excerpted from Excellence in Software originally published in Level Up Coding.

Taking Responsibility for Ethical Design

Joe Honton — Mon, 05 Apr 2021 16:52:10 +0000

We have an ethical dilemma: how can we protect an individual’s personal data from misuse, while still providing a useful experience?

There are aspects to this that need our thoughtful consideration: data as a commodity, data amalgamation without express consent, data archival for indefinite periods of time, the expungement of data for the protection of our youth, data custodianship version ownership, and others like these.

In short, for each new tech project we should be asking: why are we collecting this data? how long do we really need to keep it? and what harm could result from its misuse by us and others?

In days gone by, public domain records were limited to birth, wedding, and death certificates. For anything else, the picture was filled out by family albums and newspaper clippings. Data archiving was limited to what the archivist could squeeze into his cinder-block storage facility. Data retention was fallible: fires, floods, and mold took turns at reducing history to a sketch.

In contrast, today it seems that everything we’ve ever done, said, posted, or photographed, is being captured and archived, unable to fade from memory.

But some things should be forgotten, otherwise our children won’t be able to grow up and experiment and make mistakes. Teenagers need to be protected from themselves. We need to have regulations in place to allow them to expunge the data of their misdeeds, their bad choice of words, their poor judgment with cameras. How else can we protect them from being forever dragged down after they’ve matured?

And we need to have better rules about the ownership of data we generate as a by-product of our tech activities. Who should have ultimate control over the ownership and retention rights of such data, the individual, or the business that stores it? Who really owns it? If internet companies are custodians of that data, what responsibilities do they have to the people whose lives are being recorded?

We need to develop a social contract, where tech companies and the users they serve, agree that personal data is not a commodity. At a minimum it should begin with:

A non-amalgamation clause in our end-user licensing agreements that restricts or prevents us from joining data that we collect with data that we obtain from third parties without express consent from the user.
A data retention clause that prohibits the archival of transaction data for unlimited periods of time without the express consent of the user, and that mandates that we erase those transactions when that period expires.
A data collection clause that restricts us from capturing or storing ephemeral data, such as GPS way-points.
A data purging clause that specifies how long usage data — such as movies seen, books read, or music listened to — can be kept before mandatory deletion must occur.
When we start putting these kinds of guidelines in place, we’ll begin to regain the trust that’s been lost.

Excerpted from Ethical Design in the Orwellian Commons.

Cross Domain JSON Requests

Joe Honton — Mon, 29 Mar 2021 17:10:34 +0000

The use of dynamic requests to backend servers is prevalent in modern web applications. Despite its commonplace nature, there are some gotchas that trip up even experienced developers.

TL;DR

In order to successfully preflight a JSON-encoded request to a different domain, the browser's fetch request must include the HTTP header access-control-request-headers: content-type.

In order to signal that a JSON-encoded request from a different domain is permitted, the remote server must be correctly configured to respond with the HTTP header access-control-allow-headers: content-type.

Basic CORS rules

Before getting started, let's review when Cross Origin Resource Sharing (CORS) is required.

CORS is only used when a web page needs to access something that is hosted on a different domain.
CORS is never used for HTTP requests made with the methods: GET, HEAD or OPTIONS
CORS is a browser-to-server protocol. It uses HTTP for communication, but HTTP per se knows nothing about CORS. Because of this, requests sent via cURL, or tools like Postman, do not involve CORS, and will succeed, while the same request made by the browser will fail.
CORS does not enhance website security, rather it weakens security. Implementing it carefully is important.

Simple CORS requests

There are two types of CORS requests: simple and preflight.

Consider a scenario where a web page hosted on www.example.com submits a <form> to a backend server at api.example.com. This is an example of a simple CORS request. It follows this path:

The browser determines that the remote resource is not on the same domain as the web page, so it adds an extra header to the POST request: origin: www.example.com.
The remote server recognizes that this is a request coming from a different host, and checks its rule book to determine how to respond.
If the specified origin is not in the remote server's configuration, the server responds with status code 403 and an empty payload.
On the other hand, if the remote server is configured to honor requests from the specified origin, it handles the request, returning an appropriate status code such as 200.

In this example, the type of payload is significant. POST requests having content type application/x-www-form-urlencoded are made using the simple CORS protocol. This is the HTML <form> submission standard. Here's what the software developer codes:

fetch('https://api.example.com/order_handler', {
    method: 'POST',
    mode: 'cors',
    body: wwwFormData
});

One further note before moving on, the use of the CORS protocol is only triggered by the browser when dynamic requests are made by JavaScript. In the above example, if the wwwFormData had been submitted directly by a SUBMIT button, CORS would not be invoked. The HTML for this type of submission is simply:

<form action='https://api.example.com/order_handler' method='POST'>

Preflight CORS

The second type of CORS request involves a preflight request made using the HTTP OPTIONS method.

Consider the same scenario as above, but this time the developer chooses to format the data as JSON. The communication exchange follows this path:

The payload is specified by the developer to be content-type: application/json.
The browser does not recognize this content type as one of the CORS "safelisted types", so it sends an OPTIONS request to the remote server with two headers origin: www.example.com and access-control-request-headers: content-type.
As before, the remote server checks its configuration rule book to determine whether or not to honor requests from that origin, and further checks to see if it is ready to handle non-standard content types.
If both of those conditions are satisfied, the server responds to the OPTIONS request with two headers: access-control-allow-origin: www.example.com and access-control-allow-headers: content-type.
The browser sees that the remote server intends to honor the request, so it issues a POST request with the JSON payload and the origin: www.example.com and access-control-request-headers: content-type headers.
The remote server honors the POST and responds with an appropriate status code.

The software developer codes it like this:

fetch('https://api.example.com/order_handler', {
    method: 'POST',
    mode: 'cors',
    headers: {'content-type': 'application/json'},
    body: jsonData
});

Configuring the remote server

Every web server has a way to enable CORS, and a way to allow content-type headers. Here are links to the docs for a few of them:

For Apache Web Server, add this to the remote server's configuration: Header always set Access-Control-Allow-Headers "content-type"
For Nginx Web Server, add this to the remote server's configuration: add_header Access-Control-Allow-Headers "content-type"
IIS Server CORS configuration
Amazon EC2 CORS configuration
Read Write Serve HTTP/2 Server CORS configuration

Originally published at Cross Domain JSON Requests. Read more JavaScript Fanboi articles here.

Infinite Scroll As A Design Pattern

Joe Honton — Mon, 22 Mar 2021 18:28:46 +0000

Software developers wanting to implement infinite scroll can easily get started with the browser's IntersectionObserver callback function.

As a working example, we could create a component for use on a blogging site which automatically fetches another article when the reader has reached the end of the original article.

Here's what the code looks like:

const observer = new IntersectionObserver((entries) => {
    if (entries[0].isIntersecting == true) {
        fetchNextArticle();
    }
}, {threshold: 0});

const bottomOfPage = document.querySelect('#bottom-of-page');
observer.observe(bottomOfPage);

There isn't much to it. The bottom-of-page element could be any HTML element, but in its simplest form it is just a clear div, that has non-zero dimensions, situated somewhere after the original article's content.

The observer is called when the reader scrolls to a point where the target div becomes visible. A threshold value of 0 will trigger the callback when any part of the div is in the viewport. A threshold value of 1 will only trigger it when all of the div is in the viewport.

The fetchNextArticle function is where the just-in-time loading happens:

const articleUrls = [
    '/feb-28-2021.html',
    '/feb-21-2021.html',
    '/feb-14-2021.html',
    '/feb-07-2021.html'
];

const nextIndex = 0;

async fetchNextArticle() {  
    // fetch the article using HTTP
    const response = await fetch(articleUrls[nextIndex++]);
    if (response.status != 200 && response.status != 304)
        return;
    const templateText = await response.text();

    // get the <body> of the article's HTML
    const template = document.createElement('template');
    template.innerHTML = templateText;
    const body = template.content.querySelector('body');

    // create a new <article> and insert it
    const nextArticle = document.createElement('article')
    nextArticle.innerHTML = body.innerHTML; 
    bottomOfPage.parentNode.insertBefore(nextArticle, bottomOfPage);
}

In this example, there are four articles that are queued for just-in-time loading. Of course in practice, that queue should be dynamically built to match the reader's interests.

This bare-bones example is a good starting point, but savvy developers can easily imagine improvements:

Querying the next article's <title> and <meta> tags to extract open graph data, like featured image, dateline, byline, and lede paragraph.
Removing unnecessary headers, footers, menus and advertising links from the article's <body>.
Giving the reader a way to toggle between two views of the article: a collapsed UI card and an expanded full-text view.

All of this has been implemented in the rwt-piqueme DOM component, which is ready-to-use via NPM.

(An expanded version of this article originally appeared on Medium.)

Every Place That Uses Daylight Saving Time

Joe Honton — Tue, 16 Mar 2021 02:08:03 +0000

Software developers work with dates and times on a regular basis. We understand the rules for determining leap years, the methods for calculating time spans, and the proper use of time offsets from Coordinated Universal Time.

Unfortunately, when it comes to summer-time versus winter-time there’s a big gap in our understanding. Relying on the time broadcast from the nearest cell-phone tower may be good enough for lay people, but programmers need to know a lot more.

Standard time zones

We know that standard time is nominally sliced into 24 zones, each of 15 degrees longitude. But the true list of standard times is not that clean, because many places have decided to stretch and pull time zone borders to fit administrative borders. This has given rise to time zones that are unusually wide, such as China, whose eastern limit at 73.5°E, and western limit at 134.5°E, spans four nominal time zones.

Other countries have adopted time zones that don’t neatly fit the usual one hour increment. For example, India standard time is 30 minutes different from neighboring Pakistan and Bangladesh. And strange as it may seem, Nepal standard time is set at the 45 minute mark, meaning clocks in Kathmandu are two hours and fifteen minutes behind its neighbor to the north.

Furthermore, in the South Pacific, some islands have decided to align their clocks with the east and others with the west. They’ve contorted those 24 nominal slices into 26 actual zones. This may seem odd to mainlanders, but it does prevent the awkwardness and confusion of dealing with trading partners whose clocks and calendars might otherwise be different.

And then there’s daylight saving time. This perplexing idea and its non-uniform set of rules has been generating controversy ever since it was first tried in 1916.

Nobody likes the idea of getting out of bed at 4 o’clock in the morning, even if that’s when the sun rises. So why not get up at 5 o’clock, and use that extra hour of summer daylight to do some extra work in the evening.

At different times over the past century, daylight saving time has been enacted or repealed by countries which have justified their reasoning in a variety of ways: wartime production schedules; the availability and price of oil; computerized electoral machines that couldn’t be reprogrammed; severe drought drying up hydroelectric dams; better use of national tourist attractions; accommodating the daylight fasting rules of Ramadan. And in one case — favoring restaurant diners over beach-goers!

The rules keep changing. Savvy programmers must take defensive action in whatever implementation they choose. Here’s a round-the-world examination of the daylight saving rules for 2021.

For the list of zones for the whole world see Medium.com

Data files for software developers

Time zone data and daylight time rules are administered by the Internet Assigned Numbers Authority. The Time Zone Database is available for download from IANA.

This database is maintained by volunteers who submit changes that they learn about through local news. Every country in the world is free to use whatever time zones and whatever daylight rules they wish, and they are under no obligation to inform IANA about any changes. Volunteers are needed to keep the database up-to-date.

Daylight saving time data files for 2021 can be obtained from the daylight-saving-time-2021 GitHub repo.

Time zone data visualization is available at timezone.earth.

JavaScript Modules Versus Components

Joe Honton — Tue, 02 Mar 2021 18:39:51 +0000

Excerpted from Medium.com

In JavaScript we learn that “A module is just a file. One script is one module. As simple as that.”

But of course nothing is simple in JavaScript: there are AMD modules, CommonJS modules, UMD modules, and native ES modules.

And when we finally wrap our heads around the module mess, we’re still left with a variety of definitions for “component”, which is where the confusion begins to get opinionated.

Way back in 2011, the Web Hypertext Application Technology Working Group (WHATWG) defined the Component Model to complement its work on the all-important Document Object Model (DOM).

To quote from the WHATWG wiki: “The Component Model introduces comprehensive support for creating DOM elements.” And it goes on to explain that “the Component Model formalizes the concept of loosely coupled, coherent units of behavior in the Web platform.”

This was at a time in history when you could explain it this way — to the delight of everyone: “Examples include layout managers, combinations of Dojo and jQuery widgets, isolated widgets, such as Like/+1 buttons, and built-in HTML elements themselves.”

Lately, I’ve been hearing the phrase “vanilla JavaScript” used to indicate that no framework or library is involved in a coding solution. So in a similar fashion, it appears that “vanilla component” could be a good way out of this mess. Personally, I like to call them DOM Components, giving credit where credit is due.

Take Control of Mouse and Touch Events to Create Your Own Gestures

Joe Honton — Tue, 23 Feb 2021 00:40:07 +0000

Developers looking for an easy way to listen for gestures will find no support from the browser. Gestures must be built from the underlying pointer events and mouse events APIs. Further complicating matters, those APIs are not symmetrical.

Handling the raw mouse and touch events is the key to creating a gesture API.

These are the steps a developer will need to take to recognize gestures:

Capture the starting and ending position of each finger or mouse pointer.
Compute the distance and direction of each pointer’s movement.
Calculate the geometric relationship between multiple pointers.
Determine a pointer’s speed using the system clock.
Check whether any special touch zones should be applied.
Suppress any automatic browser-generated actions.
Discard any unwanted raw events.

The algebra for each of these is in this full length article.

Key points:

Simple gestures like tap, press, and doubletap can be recognized from a single stationary pointer.
Gestures like horizontalflick and verticalflick can be distinguished from swipeleft/swiperight and scrollup/scrolldown by monitoring the system clock.
Two finger-gestures can recognize a change in their relative distance as a pinch or spread.
Two fingers moving in tandem can be recognized as horizontalpan, verticalpan, or a twofingertap.
Two fingers with a change in the sweep angle can be recognized as a clockwise or counterclockwise gesture.

For demonstration purposes, many of these have been implemented in the gesture API used by the Simply Earth website. When viewed on the desktop, the mouse plus Ctrl, Alt, Shift combinations are used to initiate gestures. When viewed on mobile devices, two-fingers are used to initiate all of the same gestures.

Has Open Source Licensing Reached Its End of Life?

Joe Honton — Mon, 15 Feb 2021 14:43:36 +0000

Recently, I finished working on a software project that I’m especially proud of. It took months of effort to complete, and the final result was something that perfectly fit my needs. It was a labor of love.

It’s not important to reveal the purpose of the software here, or the technical details of its inner workings. Simply allow me to say that it’s something that I will use right away, and that other programmers may find useful as well.

When the project was complete, there were a few important decisions that I needed to make. How do I share what I’ve created? How can I get fair compensation for my efforts? And how do I protect what I’ve created from unscrupulous profiteers?

Getting fair compensation for our individual efforts is part of the equation here. Yes, I’m aware that GPL licensing makes a distinction between “Free as in Speech” and “Free as in Beer”. Yes, I know that I can charge a fee for my efforts.

I’m curious to know what other software developers are doing about this. What considerations go into the decision-making process? What works and what doesn’t?

Lately I’ve begun to wonder if open-source licensing has failed to keep up with technology. The first version of GPL debuted in 1989, and was updated soon after in 1991. The most recent revision of GPL was in 2007. That was 14 years ago!

I've explored this topic more fully in this JavaScript Fanboi article.

I haven’t figured out where to go from here, but it feels like something needs to change.

High Performance HTML Rendering: How to properly use a game loop with HTML canvas drawings

Joe Honton — Mon, 08 Feb 2021 18:17:52 +0000

Game programming uses a software pattern called a game loop. It’s an important technique for any software developer to study, having applicability to serious endeavors beyond graphic animations, for example in: time-series charting, interactive data visualization, and scientific modeling.

This article shows how to improve the continuous requestAnimationFrame callback to handle:

real-time fidelity,
throttling things to a fixed rate,
placing canvas drawing functions behind promises,
completely skipping unnecessary drawing.

Make Professional Components with Pub/Sub and Custom Events

Joe Honton — Tue, 02 Feb 2021 03:42:44 +0000

Publish/subscribe is a classic software design pattern that allows pieces of an application to be decoupled. It uses messages instead of functions, closures, or callbacks. It promotes an architectural style that has flexibility through independence.

I recently applied the pub/sub pattern to the state management of a DOM component. Its implementation was at times confusing, but the final result was a satisfying UI/UX. The extra effort was worth it.

The full story is on Medium at https://medium.com/javascript-fanboi/2021-033-pub-sub-and-custom-events-a9ff6f93152

Bottom line: The pub/sub pattern helps remove dependencies between the source of truth and the user interface.

Unfortunately pub/sub can become a tangled mess — because the code for publishing and subscribing are almost always in separate modules. The key to success is staying organized.