Quantum Computing Realizations

I've always been highly interested in quantum computing. And, as I've mentioned before, quantum computing is not yet practical.

There are key differences between a quantum computer and a classical digital computer. Basically, quantum computers store and process data using quantum error correction to manipulate quantum particles.

Over the years, while discussing quantum computing with others, I came across two interesting realizations.

First, is that digital computer bits only store data where as quantum computer bits, called qubits, not only store data, but they also process it. And they process their data, in parallel, while entangled with other qubits – no central processing unit required to bottleneck the data flow.

Second, it is hard for someone to be interested in quantum computing without also being interested in quantum mechanics which is the overarching theory that describes the behavior of matter. If you want to know what it's like to physically entangle quantum particles, operate on them, and measure their outcome then you can run your own quantum computer "program" (circuit) for yourself using a real quantum computer.

Algorithm vs Model

Algorithm: Step-by-step instructions. These instructions can be written down on paper or programmed into a computer.

Model: A model analyzes data to determine patterns, relationships, and behaviors based on that data.

/^1?$|^(11+?)\1+$/

Here's a fascinating Regular Expression for identifying prime numbers:

/^1?$|^(11+?)\1+$/

A Regular Expression is a sequence of characters that specifies a match pattern in text. For example, it could be used when writing code for a website to detect if someone entered a properly formatted phone number, ZIP code, etc.

Instead of entering numbers in base 10 or binary (base 2), this Regular Expression uses the unary numeral system (base 1). Base 1 is probably how the earliest humans first counted. 111 = 3, 11111111 = 8, etc.

It seems the more I learn about Regular Expressions, the less I know. 🤷‍♂️

Here's a ten minute explainer video that demos regex101.com for testing Regular Expressions.

My First Quantum Computer Program

I ran my first program on a quantum computer, today.

I've run programs on quantum computer simulators in the past, but today was the first time I ran a program on an actual quantum computer. It wasn't anything special – my program simply simulated a coin flip. I guess that's the Hello World equivalent on a quantum computer.

About a year and a half ago, I gave a presentation on quantum computing, which has always fascinated me. However, quantum computing is a lot like nuclear fusion or bitcoin in that it's not yet practical. We can see that these technologies are real and feasible, but they'll require some more engineering, both technically and socially, for them to be in widespread use.

Currently, quantum computers are at the stage that personal computers were in the early 1970s. The design and engineering involves circuits. Next step will be programs and then practical applications.

What I Did

Today's program emulated a coin flip by passing a qubit through a Hadamard gate which puts the qubit into a superposition state. A Hadamard gate takes a qubit as input and its output has a seemingly random 50/50 chance of being |0> or |1> when measured. But what's fascinating about a Hadamard gate is that, if you take the output of from a Hadamard gate and pass it through another Hadamard gate then the qubit will always return to its original state.

My code snippet: Simulating the flip of a coin on an actual quantum computer

How I Did It

Like a true script kiddie, I followed a YouTube tutorial. I literally stopped the video when Toby showed her code, took a screen shot, imported the screen shot into the Apple Photos app, and then I copied and pasted the code from the photo into my web based text editor on IBM's Quantum Lab. The code I wrote was in Python utilizing the Qiskit SDK and it was free to run on IBM's system; a bargain at twice the price.

Refactoring vs Porting vs Optimizing

I've heard people use these terms, interchangeably. Since good definitions make for clear ideas I wanted to explicitly define them.

Refactoring: Restructuring computer code (factors), without changing its external behavior (functionality), to make it more readable, or change its design, reduce complexity, etc.

Porting: Changing code so it’ll run in a different execution environment (language, operating system, CPU, etc) than originally designed for. This makes the code more "portable."

Optimizing: Modifying code to be more efficient without changing its functionality so it runs faster or uses less memory, etc.

Frequently, code changes focusing on one of these areas will have other benefits. For example, when porting code, it might also be optimized and refactored. 

Timer Objects for Network Latency

The heart of the Timer class.

I left out a simple tip from my "Tricks I Learned At Apple: Steve Jobs Load Testing" piece about timer objects. Below, is a complete, yet simple, Timer object class I wrote shortly after leaving Apple when I was working with SMS Hayes AT commands and RESTful APIs.

Exponential Notification

Timer objects do nothing more than measure the time it takes for a server's request/response loop to complete. Since this type of call is made over a network, it might finish very quickly (as expected) or, if the network is down or congested, it could take along time. If it takes a long time, the system admins will want to know. A good notification method is not to send an e-mail update or text message every single minute, or so – that ends up flooding people's inboxes. Instead, an exponential notification would be a much better idea. For example, notify the system administrators immediately, then wait one minute before the next notification, then wait two minutes, four minutes, eight minutes, etc. Finally, send a last notification once the issue's fixed.

Initiating the timer is simple...

Timer timer = Timer.startNewTimer();

NSLog.debug.appendln("Start time = " + timer.startTime());

Response response = saleTransaction.submitTransaction();

timer.stop();

NSLog.debug.appendln("Stop time = " + timer.stopTime());

And, lastly, the complete Java timer class is anticlimactic.

package com.woextras;

import com.webobjects.foundation.NSTimestamp;

public class Timer

{

private NSTimestamp _startTime = null;

private NSTimestamp _stopTime = null;

public static Timer startNewTimer()

{

Timer timer = new Timer();

timer.start();

return timer;

}

public void start()

{

_startTime = new NSTimestamp();

}

public void stop()

{

_stopTime = new NSTimestamp();

}

public NSTimestamp startTime()

{

return _startTime;

}

public NSTimestamp stopTime()

{

return _stopTime;

}

public Long elapsedTime()

{

long completionTime = -1;

if (_startTime != null)

{

long startTime = _startTime.getTime();

long stopTime;

if (_stopTime != null)

{

stopTime = _stopTime.getTime();

} else

{

stopTime = new NSTimestamp().getTime();

}

completionTime = (stopTime - startTime) / 1000L;

}

return completionTime;

}

}

Java and JavaScript Objects

Dave Winer posted a lesson-learned tip about JavaScript. Although Java and JavaScript are unrelated languages, they have many similarities.

var d1 = new Date ("March 12, 1994");
var d2 = new Date ("March 12, 1994");
alert (d1 == d2); // false

It seems that JavaScript, like Java, is actually comparing the two Date objects, d1 and d2, to see if they're the same object in memory, not the same value. Since these instance variables are not referencing the same object the alert line of code returns false.

Although, at first blush, this seems unintuitive, it actually allows greater flexibility when making comparisons. If you don't want to compare the two objects, but rather the value of the two objects, then you can simply send the Date object the getTime() message which returns true.

var d1 = new Date ("March 12, 1994");
var d2 = new Date ("March 12, 1994");
alert (d1.getTime() == d2.getTime()); // true

And, finally, to prove my theory to myself...
var d1 = new Date ("March 12, 1994");
var d2 = d1;
alert (d1 == d2);  // true

Better UX via the Mouse Pointer

That arrow is the mouse pointer making the entire area clickable.

Background

Paul Fitts was an Air Force officer who, during the 1950s, developed models of human movements that are now primarily used in human-computer interactions and aviation.

This is CNN

This morning, I was on CNN.com looking at a photo gallery when I noticed that my mouse pointer had changed from its typical pointer to a thin arrow. Depending on which half of the screen I moused over, the arrow either pointed to the right (indicating that I could click to go to the next photo) or left (previous). 

I haven't seen a lot of good use cases for changing the mouse pointer icon via CSS (HTML). Up until now, the best one I've seen is of a hand "grabbing" to indicate that a UI element is draggable.

The beauty of CNN changing the mouse pointer is it makes the entire image, and the area around it, a target without adding a new UI element. A large target, nearby, is one key to good UX. It's what makes the corner pixels on macOS such a great target since the corner pixels effectively have dimensions that are infinite in length. This is why the screen corners are commonly used as a quick way to invoke the screen saver and lock your computer.

Kurt Beyer Radio Interview on Grace Hopper

Here's a great radio interview with Kurt Beyer regarding his book that I read about Rear Admiral Grace Hopper, USN. She faced a ton of challenges as the pioneer of computer programming, and she was a key developer of the COBOL programming language which is still heavily used.

Kurt Beyer and I are from the same hometown and went to the same military college, where he was the highest ranking Midshipman my junior year. He caught my eye, again, when I read his excellent book about Grace Hopper.

http://blogs.wgbh.org/innovation-hub/2017/12/8/life-legacy-grace-hopper/

Database Architecture & RDBMS Best Practices

The most popular database is Excel. Knowledge workers use Excel spreadsheets as simple, non-relational databases more often than as an accounting worksheet. That's OK, because it works. The big boys (software developers) use relational databases, which is like tying together each worksheet in Excel; the tying together (joining) of database tables is the relational part.

In my computer science college classes I was taught that each row in a database requires a primary key. Just like each row on your Excel spreadsheet has a unique number: 1, 2, 3; each row in a relational database needs a way to find that row of data, quickly. In academia – in other words, in theory – I was frequently taught to use something like a person's social security number (SSN) as the primary key for a database table. But, in practice, that doesn't work nicely. In theory, there's no difference between theory and practice. In practice there is.

One of the key tenets of primary keys is that they must never change unless every single reference to that primary key (the relationship joined by a foreign key) is also updated which is not a trivial task

There are a few issues with using a person's SSN as a primary key. One issue is that it's a long number, much longer than a 1 – 5 digit integer typically used as a primary key, so it takes a database engine longer to compare numbers during a lookup.

More importantly, what happens if a person's SSN changes? SSNs can change in domestic violence cases, identity theft, when two people are mistakenly issued the same SSN, etc. You may think, since these are such rare cases, that it's not a big deal for a database; but software systems have to be developed to handle every possible case to work effectively. Good software should reflect a true reality, not a theoretical reality. So, to solve this issue, most databases issue a sequence of integers for each row. In the case where databases are in a cluster, each database might tag a digit on the end representing which database server issued a specific primary key. In other words, instead of 1, 2, 3; database server #4 in a cluster might issue 14, 24, 34, etc. as primary keys to avoid any primary key collisions.

Database Best Practices

Having done a bit of database work at Apple, I've learned some best practices that are worth sharing. A RDBS should start off in third normal form which means only primary/foreign keys are duplicated in separate tables – the rest of the data should be unique to each table. Later, when there's a performance issue, the database can be optimized, as needed, by denormalizing the data.

1. Primary keys: Never build intelligence into a primary key – a primary key is simply an artifact of the database and it should represent nothing more than a way to access a row in a database table (i.e., don't use SSN as a primary key). Just like a software developer doesn't care what GUID is assigned to an object in memory, neither should a database designer care much about the contents of a primary key. Creating a primary key that's a simple integer is highly efficient since a computer can quickly find and compare numbers (in the case of integers) much faster than a string of nine characters (in the case of SSNs).

I once consulted with a retried Army first sergeant at DTIC, around 1999, who made her RDBS primary keys positive and negative integers. The primary keys for active personnel were positive integers and the retired personnel primary keys were negative integers. While this sounds smart, it's actually too clever. This was pre-9/11 so it was rare for a retired person to come back on active duty. The reason this was a bad decision is that it can be dangerous to change primary keys, and then update all related tables' foreign keys.

2. Table Names: Database table names should be singular (Employee, Order, Transaction, Statistic, etc); they should be named for what each row in the table represents, not the entire collection. The reason is that, typically, there's a one-to-one mapping between a row in a database table and an object used in code. For example, in code, an instance variable referencing an Employee object should represent a single employee from the database while an instance variable that's plural, such as Employees, should represent a collection of objects such as an array or dictionary.

3. Lookup Tables: A lookup table is a simple static database table that's used to populate a list or collection. For example, a list of countries that your company ships to. Perhaps, your company only ships to the U.S. and Canada. Later, when you start shipping to more countries, how do you update the pop-up list of countries on your website or mobile app? With a lookup table, you simply add another row to the table with the new country that you ship to. Updating the database table is easier than changing your code, recompiling, and deploying. Typically, a look up table also has a column representing a sort order. This is done so the list can be displayed in a specific order with, say, the U.S. listed first, instead of Afghanistan, since most of your customers are located in America.

4. Compound Primary Keys: A database table should have a single primary key for a typical one-to-many relationship to another table (join). Sometimes, you need a many-to-many relationship. For example, a Person table/object joined to an Address. A person might have multiple addresses (homes), and an address might belong to multiple people. In these cases, where a many-to-many relationship is needed then a simple middle table is set up that contains only two columns which contain two primary keys propagated from the two joining tables. One of the primary keys in the middle table is the primary key of the Person and the other is the primary key of the Address. Technically speaking, the two primary keys of the middle table are propagated foreign keys. One of the middle table's primary keys is a foreign key from the Person table and the other is a foreign key from the Address table.

I'm not aware of a practical case where more than two primary keys are needed in a database table. In cases where I've seen three (or more) primary keys in a database table I realized that the database designer didn't have a good understanding of relational databases. What they typically needed was a single primary key and indices created for their other columns to optimize their lookup speeds.

5. Number vs Varchar: 

Do not use a numeric type for defining data fields which won't be used for calculations (i.e. "math"). In other words, credit card numbers, phone numbers, SSNs, etc., should be string types (i.e. varchars) in a database model. One specific problem I've encountered on a production system is when a developer stored the credit card security code (CSC) as a numeric data type. Although this credit card code is always numeric, it can contain an important leading zero. When I saw my CSC repeatedly failing at checkout on an e-commerce web site, I immediately knew the problem and confirmed it by reaching out to the DBA.

The Beauty of Binary

Boolean algebra was invented by George Boole in the mid-1800s, long before binary numbers had any practical purpose. While binary, which is base 2, is not the simplest numeral system for humans, it's ideal for computers. It's a simple way to store and transfer information. As a matter of fact, you can think of DNA as binary since it only has two combinations (CG or AT) that store all the genetic information of our makeup.

(The simplest and oldest numeral system for humans is unary, which is base 1. Think: tallying numbers with four ones, 1111, while the fifth tally is a diagonal line striking through the four tallies to make one group of five. Actually, traditional tallying seems more like a cross between base 1 and base 5, but I digress.)

There is an elegant simplicity in binary in that each digit is either a one or a zero. On or off. No room for any gray area, even though fractions and negative numbers can still be represented in binary. Additionally, some numbers that can't truly be expressed in one base, for example, 1/3 in base 10, can be simply written in, say, base 3 as 0.13.

Since computers use binary, some integers operations are child's play to a computer, especially bit shifting. As humans, we can't easily figure out multiplication of large numbers in our head. For example, what is 123 x 45? That will require a pencil and paper or calculator. But, we can easily figure out the answer to 12345 x 100, even though the latter deals with much larger numbers because we simply shift the digits three places. But, for humans, this calculation only works for powers of 10, since we think in base 10. Computers, however, get this luxury when they're multiplying by integers that are a multiple of the base. Multiplying a base 2 number by 2, 4, 8 is as simple as shifting the bits by one, two, three, or four places. For a computer, like a human, this is a much simpler task than working through the traditional arithmetic.

Hacks and Tricks of the Trade at Facebook

Software engineers love hacks that become tricks of the trade.

A hack is regarded as something that gets the job done in a clever way, but it's usually brittle. It's an inelegant, but effective, solution to a computing problem, sometimes referred to as a kludge or jury rig.

Any software engineer who's coded on a daily basis has written a hack. Every so often, a hack rises to the level of innovative breakthrough and is recognized by a prominent person in the industry.

As I've said before, innovation is anything that reduces the cost of a transaction in terms of time or money. The best hacks are the ones that already use the current infrastructure in an innovative way.

Until a decade ago, most every time a website served up a webpage it would go to the database to refetch data. For example, an e-commerce store would look up the products that are on sale each time a user requested that page. The problem was that many pages were served up at the same time, with redundant hits to the database. After all, the list of items on sale isn't going to change from one minute to the next.

About ten years ago, as servers needed to handle more load, there was a rise in open source caching technologies to minimize the number of trips to a database. This was a big gain for read only data, which doesn't change often. Storing data in memory (as a cache does) reduces the overhead of interacting with a database. A database's job is to ensure data reliability by running many checks, formally know as ACID properties. But many of these checks are unnecessary if the data doesn't change very often. So, rather than make a trip to the database, the data is simply stored in memory so it's retrieved much faster.

Facebook Tricks

I recently heard about a brilliantly simple trick that Facebook uses to speed up their site. When a Facebook user logs into their account, their data is fetched from the database. While fetching the data, the user has to wait. The amount of wait time could be imperceptible to the user, or it could be a noticeably long time if the website is under a heavy load. "Heavy load" is a relative term, but Facebook services more than one billion users per day, so saving any amount of time makes a noticeable difference.

Wouldn't it be great if Facebook's servers knew what data a user needed before the user formally requested it? Well, that's effectively what Facebook's done with their little trick that simply involves sending an encrypted UDP (datagram) ahead of the formal TCP/IP request. UDP requests are fire-and-forget, meaning there's a small chance they might not arrive at their destination. TCP/IP, on the other hand, guarantees delivery (or notice of a failed delivery). TCP/IP is the reason that webpages render perfectly compared to the BBS's of the 1980s that used unreliable dial-up modems where static and interference would be misinterpreted as data and displayed as garbage text.

So, the UDP datagram arrives well ahead of the TCP/IP request which enables Facebook's servers to pre-fetch the data and load it in its cache before the formal TCP/IP request arrives. A simple yet elegant way to optimize a website for speed.

Random Thoughts on Randomness

Here's a random thought on randomness...

In a typical state lottery, like California's Powerball, a player chooses five or six combinations of numbers between 1 and 59.

So, how likely is a lottery's winning set of numbers to be 1, 2, 3, 4, 5 or 1, 2, 3, 4, 5, 6?

Surprisingly, it's no more or less likely than California's most recent Power Ball winning numbers: 3, 13, 17, 42, 52, 24. Random numbers are random numbers. While 1, 2, 3, etc doesn't seem random, it's no different than any other combination with non-patterns. Don't forget, since we're dealing with pure numbers there's solid mathematics behind it.

Lazy Programming

There are two types of lazy programming, good and bad.

Good Lazy

Lazily instantiating and populating data structures is a perfect example of a good design pattern. This technique is also how CDNs populate their edge servers. Don't create or store anything until the last possible moment.

When implementing this technique, I use accessors that have the same name as my instance variables (ivars). Below, my _employees ivar is set to null when a class is instantiated and it's not populated until the first time it's touched (accessed). This is the beauty of key-value coding accessor methods.

private NSMutableArray _employees = null;

public NSMutableArray employees()
{
    if (_employees == null)
    {
        this.setEmployees(new NSMutableArray());
    }
    return _employees;
}

public void setEmployees(NSMutableArray newEmployees)
{
    _employees = newEmployees;
}

Depending on my performance requirements, this design pattern would work if I needed to save memory. However, if memory isn't an issue, but, rather speed, this might not be an ideal solution since each time the employees() method is called there's a an O(1) test performed to see if the private ivar is null. In cases where speed needs to be optimized then it's best to pre-populate the data structures (caches) before the web app begins accepting requests. At the Apple Online Store, we pre-populated only when necessary. In every case, though, the key is to avoid premature optimization.

Bad Lazy

The goal of a software engineer is to provide the best possible user experience (BPUX).

As a programmer, I'm not shooting for perfection but I know when something can be done better. (If I went to sleep last night then I had time.)

If I have to code something that's singular or plural I'll go out of my way so it doesn't read:
You have 1 item(s) in your cart.

It's not very hard to code:
You have 0 items in your cart.

You have 1 item in your cart.

You have 2 items in your cart.

There is no shortage of websites where I've entered my phone number (760.444.4721) or credit card number (4111-1111-1111-1111) only to hit enter and been told I made a mistake and my digits need to be reentered with only numeric characters.

Some programmer had to go out of their way to search the string I entered, confirm there was a non-numeric character, and then return an error message to me. This is my big pet peeve – it's too in-your-face. I entered all the information the programmer needed and they could have parsed out the digits. When I'm coding, I simply write a cover method to return only the numeric digits.

Software engineers aren't sales people, so they don't live the ABCs.

Cache is King in Safari

One trick to speeding up an application is caching. Rather than fetching data from a database or over the network each time you need it, it's better to retrieve the data as soon as possible and hold on to it as long as possible --- and no longer. The only thing worse than slow or no data is bad data.

Autocomplete prefetching over the network before I hit enter.

Last week, I was monitoring a web server log for a URL shortener when I noticed a neat trick Safari does. Rather than waiting for me to hit enter after I typed in a URL, Safari automatically loaded the webpage during the autocomplete phase. It's a brilliantly simple solution. After all, why not start loading a webpage before I ask for it? Actively loading data before it's needed is known as warming up the cache. It's smart since it makes for the best possible user experience (BPUX).

There's nothing like proper optimization, done in small steps, when needed. On the other side of the coin is premature optimization which is the bane of any software engineer's existence. (Rules to Code By)

Another Safari optimization trick I read about but haven't confirmed is that, after loading a web page, Safari will prefetch each link's IP address for faster loading when a user clicks on it since the DNS lookup has already been done.

Anything to speed up my Internet experience is OK by me.