Category: Uncategorized

Early this week Automattic launched “Built by WordPress.com Express,” an awkwardly named “webdesign” service.

Here’s the sales video:

Display content from YouTube

Click here to display content from YouTube.
Learn more in YouTube’s privacy policy.

Always display content from YouTube

Open “Introducing Built By WordPress.com Express” directly

The tagline “Real sites, built by real people.” is a good one. It acknowledges that most people who need a website are not web designers. It positions their service as an alternative the steep learning curve to doing-it-yourself (with WordPress or elsewhere).

It feels a little like WordPress VIP lite (very lite!). In fact, I’m fairly certain some of the screenshots in the video are from VIP clients.

Reading between the lines, the service seems to be a layout service. You pick a pre-existing theme, provide the content and US$500 and then they’ll “do it for you.”

This is bad on so many levels! (well at least 4 I can think of off the top of my head)

Easy To Replicate

Some are speculating that this service is a desperate attempt to increase profitability for an upcoming IPO. I find this plausible.

Unfortunately, if this service proves to be a hit, is incredibly easy for Elementor, Wix, Squaresquares, etc to replicate. Set up a network of “experts” poached from fivrr and some minimal organization to manage the workflow.

Whether A8C’s competitors could pull it off as well with good templates, solutions that work and great support is almost besides the point. This segment of the market is just looking for a solution to the basic problem of “I need a website.”

Hard to Support

A $500 WP Express customer is going to expect the same level of support as a $500,000 WP VIP customer. Period. If the goal is raising profit, the support costs are sure to challenge that goal.

Solves Half The Problem

The design — as in the visual appearance — is only half the problem you need to solve when building a website. Maybe even less than half in many cause.

A beautiful website is useless without a cohesive content strategy. Professionally written, thoughtful content will always give you a leg up on the competition… the competition who whipped together a website for $500 without a second thought.

The marketing copy on the sales page strongly implies that your content is unimportant. Providing content is simply the 3rd item on a 5-item list, equal weight to providing your business address and sitting back and relaxing.

oof.

Devaules WordPress

This is the biggest problem.

The popularity of WordPress is built on the hard work and goodwill of freelancers. Passionate people who’ve spent the past 2 decades spreading the Gospel of Matt.

Any of these freelancers will tell how hard it can be to convince a potential client that their website is worth more than approximately $500. Imagine how much harder this becomes when wordpress.com is setting the going rate at $500! Why would they ever hire you?

To quote @briancoords on twitter “a massive private company and also the sole entity allowed to commercially profit off the WordPress trademark devaluing WordPress could be harmful for anyone trying to earn a living anywhere at any price point.”

Not to mention that the templates themselves are kind of ugly.

Agreed, and it’s concerning because it devalues and makes WordPress look like a bad design tool.

— Daniel Schutzsmith (@schutzsmith) August 31, 2022

This feels like a gut punch.

I’m always rooting for Automattic. But I hope this goes nowhere fast and we never hear about it every again.

Seven months ago I wrote a blog post with some of my initial thoughts and reasoning behind buying a Hyundai Santa Fe PHEV. I have been keeping detailed fuel economy records since December 8th, in attempt to quantify and understand its gasoline usage over time.

Above is the screenshot of my spreadsheet. Due to COVID travel restrictions and continued work from home, the majority of this data is running errands inside the city. Two exceptions being two trips to Riding Mountain Nation Park, at the end of December and the weekend of the 20th.

During the winter months, I was having mixed feelings about my decision. As things have warmed up, I’m getting more optimistic.

Mysterious Algorithm

The algorithm that determines when to engage the gasoline engine is confounding.

Below -20C the engine always engages, in fact the system displays a warning message informing you that it’s too cold to drive in electric mode. I suppose this makes a certain amount of sense since battery performance is very poor at very cold temperatures, as well the engine needs to warm its oil if it’s going to run at all. So I suppose it is “priming” the engine and providing additional heating during these times.

Above roughly +15C the engine never engages.

At temperatures in between, the engine status seems highly dependent on whether or not you’ve got the cabin heat on. The heat seems to be drawn from the engine like a traditional car (and not from a fully electric heat pump, like I was hoping). In temperatures, above -10 or so the engine does eventually stop once enough heat has been built up.

But there are other times, that the engine engages seemingly at random. It’s quite frustrating. Even turning off the heat won’t guarantee that the engine will turn off.

Sometimes when the engine is running for no apparent reason (i.e. relatively warm outside, no heat needed inside) turning the car off and on again seems to kick the car into EV mode. But not always.

As frustrating as that is, even during these periods the batteries are propelling the car, the engine only runs at an idle. So fuel usage is still low.

In fact, the engine almost never goes above idle RPM, except in “sport” mode or if you floor it.

Cold Weather Fuel Economy Sucks

Winnipeg experienced on of the coldest winters on record this year.

You can see this reflected in the data above. The worst fuel economy was mid January at 13.4L/100km. While this is utterly disappointing for a car capable of full EV, I’d expect this is not worse than a non-hybrid Santa Fe during similar temps.

The interesting thing about the characteristics of the EV algorithm is that at these super cold temps, your fuel economy actually increases the further you drive. I think this is due to the fact that the engine is mainly idling so it’s burning a constant amount of fuel while you’re continuing to drive further and faster without using any more fuel.

Warm Weather = Full EV

Based on what I’ve seen in May (if we didn’t take any road trips) I wouldn’t expect to buy more than one tank of gas this entire summer.

At temperatures above 15C the gas engine stays off 98% of the time. It does still randomly engage occasionally for short periods of time (perhaps to charge the DC battery?). And also sometimes when getting up to speed quickly.

I am very pleased by this warmer weather performance.

Conclusions

I fully expect the summer driving on electricity to outweigh the poor performance during this extremely cold winter. If next winter is closer to seasonal I’d expect to say below 9L/100km even in January. The fuel savings should only add up over time.

If you need a vehicle, a PHEV is a great transitional vehicle while the electric infrastructure gets built out. Even in the coldest Winnipeg winter.

As someone who has been in the industry for nearly as long as the industry has existed, the trajectory of modern web development is concerning. Oftentimes the “modern” tools seem overly abstract, interdependent and complex. The “modern tools” I’m referring are a range of technologies designed to improve development processes: dependency management (NPM, composer, etc), frameworks (react, laravel, etc) and “DevOps” in general (docker, AWS soup, etc). Slot in any trendy solution of the day.

Or to put it another way…

Modern web development pic.twitter.com/p84IVkC2aQ

— Jared Palmer (@jaredpalmer) June 22, 2019

It’s not that there’s necessarily anything wrong with any of these tools. It’s more that I’m concerned that they are hurting our approach problem solving.

---

Early this week a Hacker Noon article — Understanding Kafka with Factorio — from a few months ago made it’s way into my work slack.

This post is a prime example of the way of thinking that concerns me the most. For starters, comparing a web development problem+solutions to Factorio — one of the most complex and difficult RTS’ to date — is very telling in and of itself.

The author starts by setting up problem that should be familiar to many developers.

Let’s say we have three microservices. One for mining iron ore, one for smelting iron ore into iron plates, and one for producing iron gear wheels from these plates. We can chain these services with synchronous HTTP calls. Whenever our mining drill has new iron ore, it does a POST call on the smelting furnace, which in turn POSTs to the factory.

So, we have 3 services that depend on each other in a linear fashion. If any one of them fails, the entire system breaks. There appears to be zero fault tolerance and that could be bad.

Enter Kafka…

With Kafka, you can store streams of records in a fault-tolerant and durable way. In Kafka terminology, these streams are called topics.

With asynchronous topics between services, messages, or records, are buffered during peak loads, and when there is an outage.

Neat.

But hang on. Now we have four points of failure instead of three! In fact, we’ve now introduced one single point of failure. If the Kafka layer fails the entire system fails.

Why should we trust Kafka more than we trust the 3 microservices, we built? Are there ways to make the individual microservices more fault tolerant?

Why not both? The author of this post seems like a solid developer who knows what he’s doing. Perhaps the underlying assumption is that our microservices are already as fault tolerate as they could possibly be and we should add Kafka as an additional layer of fault tolerance.

We’ve introduce a fourth complex and specialized technology into the stack. Now we need a Kafka specialist on our team…

---

This post is not meant to be an analysis or critique of Apache Kafka.

It’s meant to provide an example of the way modern web developers tend to solve problems. We tend to build or implement complicated systems that provide an abstraction layer above problems, without adequately addressing the root problem.

I’m quite concerned that we’re fostering a generation of web developers who are building houses of cards on top of houses of cards, to solve problems that don’t fully understand, without properly addressing those problems.