The popular web framework can be used to solve the problem of how to put text on a screen, but it’s almost like someone fed a machine the JavaScript specification and it iterated on a random sequence of code that parses until it hit on a result that creates an acceptable web page.

React’s syntax is bizarre, heavily uses obscure, little used language features that nobody knows about, and in fact only exist because the JavaScript spec is so loose.

There also appears to be no deliberate design or regard for conventions, readability, or structure. Even it’s English terminology looks like something generated by a machine that was fed a dictionary.

componentDidUpdate ???

With a little further reflection, I don’t think the AI accusation is that far off.

Really smart developers just out of college who are tasked with bizarre misguided questions like

How can we write PHP — in JavaScript?

Then, with no real world experience, and being hyperfocused on generating code come up with a solution that satisfies business who care nothing about code.

And then more really intelligent people learn to code by looking at that code and so on… and nobody stops to think about what should be done or how it can be done better. And code is never really maintained anymore — it’s easier to scrap it and just get funding to build a new company.

So a randomized algorithm that generates a solution optimized for a single task is created by a large group of people who think like computers comes up with an answer the same way it would answer the question —

Is this a picture of a cat?

I’ve been looking to level up my Javascript coding skills, and I came across this “mock” coding interview with Dan Abramov by Ben Awad.

I got the first question right (sortof) which asked about the difference between var, let and, const in Javascript. Short answer:

Variables declared with var are hoisted to the top of the function scope.

So if you declare a function with var like this:

function greet() { 
  console.log(x);
  var x = "hello";
  console.log(x);
}

You will not get a compile error. But it will print “undefined” the first time. Because the var declaration is “hoisted” before executing so the function ends up executing something like this:

function greet() { 
  var x;
  console.log(x); // this will print "undefined"
  x = "hello";
  console.log(x); // this will print "hello"
}

But if you declare your variable with let like this:

function greet() { 
  console.log(x);
  let x = "hello";
  console.log(x); 
}

The variable ‘x’ will not be hoisted, and you will get an error:

Uncaught ReferenceError: Cannot access 'x' before initialization

Oh, and const isn’t really a constant. Unless you’re talking primitives like numbers and strings. It only means you cannot reassign the variable — only modify it’s contents. Like this works:

const x = {a:1, b:2};
x.a = 3; // this works, x ==> {a:3, b:2}

const y = [1, 2, 3];
y[0]; = "changed" // this works y ==> ["changed", 2, 3]

I was feeling fairly good about myself, especially when I was able to fairly easily (mostly) solve the CSS question which asked to center a React component vertically and horizontally on the page because I’d recently been playing with display: flex.

body {
  display: flex;
  justify-content: center;
  align-items: center;
  width: 100%;
  height: 100%;
}

Only it didn’t center vertically.

But I got it to work by setting the body height to 100vh (not 100%).

body {
  height: 100vh;
}

Except it was off by a few pixels because of the borders I added to check:

body {
  border: 1px solid red;
}
.App {
  border: 1px solid green;
}

So I compensated:

body {
  width: calc(100vw - 2px);
  height: calc(100vh - 2px );
}

And then I watched how they did it.

Turns out you need to specify: html, body { /* style */ } — but I considered that to be good enough because it’s one of those browser quirks.

html, body {
  width: 100%;
  height: 100% 
}

I was feeling pretty good at that point. And even better when a React contributor essentially said “Don’t use Redux.” Which was what turned me off right at first (ok, after JSX).

I was totally blown out of the water about how to reverse a B-Tree — but it turns out that it was fairly easy using recursion. (I don’t do recursion well).

But the answer is fairly simple once you see it (and trust the recursion):

function invertTree(node) {
  var temp = node.left;
  node.left = node.right;
  node.right = temp;
  invertTree(node.left);
  invertTree(node.right);
}

At least I got the part about only using 1 temp variable.

Next was a real brain teaser … about how to guess which hole a rabbit is in. Out of 100 holes. And it moves every time by 1 hole, either plus or minus 1.

Watch the explanation here:

I was happy to see that Dan Abramov, like myself, considered this be possibly non-deterministic.

The best I could come up with was to either:

1) Guess randomly until I got it right (odds of 1% each try, probably get it in a few hundred tries)

2) Guess the same number (eg. 50) until it lands on that number.

The problem with either of these methods is that it is entirely possible that it never gets it right.

Then Ben Awad gave a hint about how it will always be even or odd.
So here is my solution, unoptimized. I will have to watch to see if there is a better one.

# rabbit.js

function random (n) { return Math.floor(n * Math.random()) } // (generate a random number between 0 and n-1)
function left_or_right() { return random(2) ? -1 : +1 } // (randomly) return -1 or +1 

// rabbit's initial position 
let rabbit = random(100)

function move() {
	rabbit += left_or_right()

	if (rabbit < 0) {
		rabbit == 1
	}
	if (rabbit > 99) {
		rabbit == 98
	}

	console.log(`The rabbit moved to ${rabbit}`)
	return rabbit
}

function look(hole) {
	if (rabbit != hole) {
		console.log(`wrong! (The rabbit was in ${rabbit}`)
		move()
		return false;
	}
	else {
		console.log(`right! (You found the rabbit in ${rabbit}`)
		return true;
	}
}


let hole = 0
let found = false
let guesses = []

while (! found)
{
	guesses.push(hole)
	found = look(hole)

	// finish if we found the rabbit
	if (found) { break }

	// test each hole twice to make sure the rabbit doesn't pass us ( 0, 0, 1, 1, ...)
	guesses.push(hole)
	found = look(hole)

	// check the next hole
	hole += 1
}

console.log(guesses)
console.log(`It took ${guesses.length} guesses to find the rabbit`)

Google is ending it’s free email service with GSuite including GMail with custom domains.

What is your strategy going forward?

If you want to continue, it will cost you at least $12/user a month. If you have a small company with 10 people, that’s $1440 every year for email @yourdomain. Sure, you also get Google Docs and collaboration and file storage, but it’s enough for small business to reconsider. And if you don’t use their applications, it’s a hefty fee.

So what are your options?

Pay for Google Workspace

$6 / $12 / $18 — per user, per month.

This will include Google docs, sheets, etc and collaboration tools. The benefits of doing this is that normal workflow will not be disrupted. But it is expensive, and it would reward bad behavior.

I take this as a wake up call and an incentive to get off of Google — which is too powerful, and needs to remind itself continually to not be evil — or at least try to convince us that it is.

Switch to Microsoft 365

$5 / $12.50 / $20 — per user, per month.

This also includes Microsoft Office — including the desktop versions at the higher level.

If you are Microsoft shop already, this is definitely a reasonable choice. Outlook (offline) or the rebranded Hotmail webmail app are both a better UI experience than Gmail.

However, the cloud services, collaboration, and integration of Google Drive, docs, sheets, and forms makes a compelling case if you use those tools.

Use an alternative cloud service like Zoho

$1 / $4 / $6 or $7? — per user per month.

Zoho has cheap email but the workspace plan for $6/month also includes office applications. The quality is lower than Google or Microsoft though.

Zoho is a good option for a distributed workforce for teams that also use their business CRM and support tools, but at $37/month per employee can get pretty expensive. It’s a bit clunky however, and Zoho has had recent public data breaches.

Overall, I’d say that if you’re already using Zoho apps, its a workable email solution, but you’re better off with Google or Microsoft for just Email, Documents, or Collaboration.

Break free from the cloud

Another option is to skip an all in one cloud solution and use a free desktop office suite (LibreOffice) for documents. You can also pay for Microsoft Office.

There are many webmail clients, but you can also download email to an app (like Outlook or Thunderbird) on your desktop or mobile device. Like everyone used to do.

That still needs a solution for sending and receiving email. Gmail is still an option — if you only have and @gmail.com email address. But for professional or personal email with your own domain @yourcompany.com — you’ll need another solution.

Forward email from your domain provider to a free or cheap service.

• Namecheap
• Godaddy

You can forward email to a free service like Gmail, or to any another email account. This is a viable, quick solution for individuals with a custom domain and one or more email aliases.

Use a low cost hosted email service.

• Fastmail
• Protonmail
• Namecheap

You can set up email @yourdomain and have it forward to another service (like Gmail) or download to your own app.

There are a lot of webmail applications, but most of their interfaces are limited. And so are their storage options. So I would recommend setting up POP3 and downloading your email to use with a your own client. This can be tricky for non-technical users.

Use a traditional email server.

This last option is going to take some technical expertise or hiring someone to do it. Traditional email services have languished in the era of free Google email, but that era is coming to an end — quickly. I suspect many small businesses will need to take back ownership of their email and that traditional email services and profession email managed service providers will be making a comeback.

Currently, Google has the best spam filtering (by far). Microsoft is ok, but few webmail services can compare. There are commercial and open source spam filtering and antivirus tools, but they also require expert configuration and management. That is another area I expect to see more innovation.

I’m investigating all of these options, but in the long run, hope to take ownership of my email and help others to avoid being stranded in such a predicament again. The value of a good email administrator has definitely gone up.

Here is my own strategy:

1. Pay for the first year of Google Workspace for my own small business accounts.
2. Migrate (or remove) non-essential email (alternate domains, aliases) to the main account to reduce per-user fees.
3. Forward / Redirect email from other domains to primary email accounts using Namecheap and GoDaddy free wildcard email forwarding.
4. Evaluate Zoho mail for another small business where CRM and Support collaboration tools are needed.
5. Backup all Google mail and documents to cloud (and local) storage.
6. Investigate traditional email service provider for long term solution after year 1. Evaluating Fastmail or Protonmail for one small business.
7. Use desktop and mobile email clients that use POP3 to download and IMAP for server storage — I think email protocols need a major overhaul.
8. Use Microsoft Office (where licenses are already in use) and Libre Office (where full compatibility with Microsoft is not necessary).
9. Make a goal of owning my own data (email and documents) with local and cloud backups.
10. This includes evaluating other “free” cloud business services that may go away or become more expensive like Google email
11. Support open source software and independent, decentralized protocols.

I’d like to hear your strategy for migrating off of Google Gmail & GSuite and would be happy to discuss them with you.

Tests tend to make your code more resistant to change and refactoring. There are things you can do to alleviate this, but at the cost of complexity in the test code (or experience in the developer.)

See: Tests are Great Calcifiers.

This is true of tests at all levels — unit, api, ui automation.

However, it’s actually inversely costly.

Unit tests, which are the easiest to write, and most focused, are most often tightly coupled to the implementation — and makes refactoring without ignoring or rewriting tests harder.

API tests are usually very tightly coupled to the API, making it resistant to change, but also can be easier to refactor or replace along with the API code.

UI tests can be tightly tied to the implementation, but patterns like page objects and user actions allow loose coupling between the tests and the implementation. However, it takes knowledgable and experienced developers to write loosely coupled UI tests.

So it turns out that the cost of tests — and their likelihood of being tightly coupled to the production code — at least as it relates to the risk of calcifying your application, are greater at the lower level, and lesser at higher levels.