My package—shipped via FedEx and already one day late—was "out for delivery" today.

It's now almost tomorrow and it's still not here.

This happens all the time.

For the past few days, I've been evaluating Mighty, a Chromium-based web browser that runs in the cloud and streams the actual content back to your computer. Traditionally, we'd call this a "thin client"--in other words, it doesn't do any of the processing locally.

For me, the allure of Mighty was the ability to shut down Chrome and regain gigabytes worth of RAM. My machine only has 16GB of memory and Chrome can consume just about all of it depending on the number of open tabs and how long they've been left that way. That's not to mention the other RAM-hungry apps I use for work on a daily basis, all fighting over the same few available gigabytes. Mighty solved this, using only about 1GB of RAM in total even with dozens of open tabs.

In general, Mighty is a cool concept and works pretty well. Upon launching it for the first time, it prompted me to import my existing Chrome profiles, carrying over all of my account data, cookies, passwords, and so on, which made for a seamless transition. I was up and running in minutes.

As I browsed the web, pages rendered flawlessly and usually quicker than before. I chalk that up to the lightning-fast broadband connections that Mighty employs behind the scenes. They can load everything in the cloud and stream a highly optimized bundle to your screen. Text remains selectable so you can copy and paste, videos play normally, and you can't really tell that you're using a browser that's running on a computer hundreds of miles away. I even ran a speed test, which yielded jaw-dropping results of almost 5gbps download and around 4gbps upload. What Mighty pulled off is pretty amazing.

There are a couple of downsides, though. The first thing I noticed is that pinch-to-zoom doesn't work on many web pages, at least on macOS. It does work on sites like Google Maps, where you'd expect it to, but if you're just trying to make text or images larger, you'll have to resort to zooming the page using the browser's hotkeys (e.g., Ctrl++ and Ctrl+-).

Casting your screen or a tab to a Chromecast is also broken. The option is there, but no devices ever appear. I'm assuming this is because the actual browser is running on a remote network, so it can't find any of the local streaming devices on your own network. As far as I could find, there's no workaround for that one other than launching your local copy of Chrome.

But my biggest complaint is the price. At $35/mo, Mighty is rather expensive. Multiply that times twelve, and you're at$420/yr, which is the price of the 32GB RAM upgrade for a 2021 M1 MacBook Pro. No doubt, Mighty has steep salaries and a pricey hosting bill to pay, so they have to price their product accordingly. But a lot of the problems they purport to solve can also be alleviated by just throwing more RAM at your computer (or by selling your current model and buying the next one higher).

Maybe I'm just not their target customer, though it feels like I am: someone who can't or doesn't want to shell out the extra bucks for a better computer, but needs the performance benefits Mighty brings to the table. But at the end of the day, the cost/benefit analysis just doesn't hold water for me. It will be interesting to see what happens as time progresses.

Amazon's Echo ecosystem is a pretty nifty thing to have around the house. From today's weather, sunrise/sunset info, and Amazon Music, it's a tool that both adults and kids use daily.

One skill in particular that we've grown attached to is Sleep Jar. For the uninitiated, Sleep Jar is a set of audio loops designed to help you fall and stay asleep. They range from ocean waves to a ticking clock (that would drive me nuts) to a box fan, and so much more. Our favorite is called "rain sounds," which provides a soothing backdrop of a rain shower droning outside. It just puts you right to sleep.

All of that is great, but for one fatal flaw--using it with the Amazon Kids parental controls.

In our day and age of ever-increasing technological connectivity, it's vitally important that our children have a balanced diet when it comes to their use of technology. It's everywhere they look in the form of TVs, game systems, smartphones, tablets, and even fitness devices! In our home, we do our best to expose our children to technology in a limited manner, ensuring that they're not overdosing on screen time. When the kids reach their teen years, we don't want them to be internet/gaming/social media-addicted monsters, but rather to be well on their way to becoming stable, beneficial contributors to society at large, as God allows.

One way we do that is by leveraging Amazon's Kids+ services to set limits on when and how various Amazon devices (like Fire tablets and Echo smart speakers) can be used. Amazon's tooling in this area is better than some, but ultimately leaves a lot to be desired. Companies honestly don't put nearly enough investment into ensuring children can safely use their devices with appropriate, granular limits.

In the case of the Amazon Echo and its assistant, Alexa, the Amazon Kids parental control dashboard allows setting time-based limits on when it can be used. Recently, we set the "bedtime" hours on the Fire tablets to span from 8:30 PM to 8:00 AM. When we later went to ask Alexa to "play rain sounds" in time for bed, we were met with the response "Sorry, I can't play right now. Ask again later."

At first, I didn't make the connection to the parental controls we'd set for the tablets. I tried rebooting the Echo, using my phone's Alexa app to turn off "do not disturb" mode, and so on, but to no avail. Once I finally recalled that we'd recently set up bedtime hours, I hopped into the parent dashboard for Amazon Kids and adjusted the time window accordingly. Within a minute or so, Alexa was back to responding normally.

The lack of granularity on these parental controls is incredibly disappointing. It's perfectly reasonable to expect that certain Alexa skills should be available even after the bedtime period begins. Things like setting alarms, playing sleep sounds, or even playing music for a bit could all be legitimate uses of the Echo "post-bedtime."

Amazon should allow parents to further customize what's available outside of "normal usage" hours. Unfortunately, I haven't seen much change or innovation occurring in this space in quite a while. I'm sure there are plenty of other parents out there who feel the same way. Having excellent parental controls for this type of tech could be a great competitive differentiator. Will anyone step up to the plate?

As more and more software moves into "the cloud," a differentiation needs to be made between things that are deployed in a datacenter managed by Amazon or Google and those deployed within an organization's own data center, behind its own firewalls and network appliances.

The most common verbiage for referring to a company's data centers is "on-premises."

Except that it isn't.

You'd think that the experts working in the technology industry would use the correct terminology, but by and large, they don't. Day after day I hear developers, managers, and executives alike butcher the English language by claiming that software is running on-premise.

Let me grab the dictionary for you. A premise is "a previous statement or proposition from which another is inferred or follows as a conclusion." Do you see the problem? I find it highly improbable that you can run anything on a premise.

The term you're actually looking for is on-premises (notice the extra "s" on the end). Again, referencing our dictionary, the word "premises" is "a house or building, together with its land and outbuildings, occupied by a business or considered in an official context." Ah, that sounds more like it!

Your company might have a premises for its headquarters, or for a datacenter, and so on. On the other hand, your company is probably founded on a premise, which is why you exist.

So, next time you're thinking about your data centers, remember--they're on the premises and should be referred to as "on-premises**"** or "on-prem" (the shorter version works too!). Using the wrong word might just make you look poorly educated. ;-)

I and your grammar-loving colleagues will thank you.

I've used WordPress for...well...it seems like forever. As the defacto website publishing platform, there's almost no discussion when starting a new project: grab WordPress, some trusted plugins, and begin building. At the same time, I've been a long-time critic of WordPress's architecture, and have longed for a good alternative.

Granted, things have improved in some areas over the years, but it's still a huge mess overall. Additionally, it's technically important to keep up with WordPress version updates, given that security vulnerabilities are frequently discovered and fixed. Numerous sites have been breached due to outdated WordPress installations--and that's just the core. Most WordPress setups require multiple plugins to be installed--thus broadening both the attack surface and the amount of code that has to be maintained.

Given all of that (and the fact that I rarely found time to apply WordPress updates), the so-called "JAMstack" is pretty enticing: produce a website that requires zero (or at least very few) security updates, no databases, and no application runtimes. JAMstack sites are "static" in that they are just HTML, CSS, and some Javascript. As a result, they can also be lightning fast and aren't very susceptible to spikes in traffic.

JAMstack is still in the early adoption phase. There are some great frameworks out there for building static sites (Gatsby, Hugo, and Jekyll to name a few popular ones), but the tools surrounding them are still pretty rough. The authoring and site management experience pales greatly in comparison to what WordPress offers, and there are a lot fewer "batteries included" options (e.g. form handling, authentication, SEO analysis, etc).

Even so, several offerings are evolving rapidly. Netlify (which hosts this site) and Stackbit are definitely making it easier than ever to get up and running with a JAMstack site. Netlify has even championed an open CMS project/service for authoring and managing site content. Again--the experience is a bit rough, but it works well enough.

Given my own personal website was sorely in need of updating, and given I was tired of keeping PHP, MySQL, and WordPress up-to-date and running smoothly, I decided to hop on the JAMstack!

In brief, I replaced:

• A 2 CPU / 1GB RAM DigitalOcean droplet hosting ($10/mo)
• Apache HTTPD server
• PHP
• MariaDB (MySQL)
• WordPress + themes and plugins

with:

• Netlify hosting (free)
• Gatsby + a theme
• Netlify CMS
• Stackbit

The result is a completely static site (just HTML, CSS, and a sprinkling of JS) running on Netlify's freemium hosting platform. On the surface, it seems like a lot of disparate technologies that have to work together, but this is where Stackbit really shines. It pulls all of the technology pieces together into a cohesive package and then deploys them to a supported platform.

Once deployed, I don't have to do any maintenance on the infrastructure whatsoever. And if ever Netlify doesn't meet my needs, it would be simple to move the site over to Zeit's excellent Now platform or just drop it on a $5 DigitalOcean droplet running a simple nginx server. That's so much better than trying (and failing) to keep 7+ layers of infrastructure updated (and backed up!) just to run a simple blog.

These days, I can simply hop into Netlify CMS (or even a simple text editor), author a new blog post, PR the changes via GitHub for a quick preview, and finally merge the PR to get things into production.

For a developer, it's quick and easy. For those who are less technical, the Netlify CMS handles much of the complexity so touching GitHub is unnecessary. Again, it's not as smooth as WordPress yet, but that will change given enough time.

If you haven't tried JAMstack yet, give it a go! I think you'll see the potential.