Trusting the Secure Enclave

While we’re certainly proud of shipping this feature quickly, a lot of credit is due to Apple for how seriously the company takes device security and data privacy as a whole. The hardware feature of the Secure Enclave included on iPhones since the 5S make for a readily trustworthy connection to the device and its operating system.

From an application’s perspective, this relationship between a biometric scanner and the Secure Enclave is simplified to a boolean response. When requested through the Local Authentication framework, the biometry evaluation either succeeds or fails separate from any given state of an application.

The “reply” completion closure of evaluatePolicy(_:localizedReason:reply:)

This made testing from the iOS Simulator a viable option for gaining a reasonable degree of certainty that our application would behave as expected when running on a device, thus allowing us to prepare a build in advance of having a device to test on.

LABiometryType

Since we’ve been securely using Touch ID for years, adapting our existing implementation to include Face ID was a relatively minor change. Thanks primarily to the simple addition of the LABiometryType enum newly available in iOS 11, it’s easy for our application to determine which biometry feature, if any, is available on a given device. This is such a minor change, in fact, that we were able to reuse all of our same view controllers that we had built for Touch ID with only a handful of string values that are now determined at runtime.

One challenge we have that most existing iOS apps share is the need to still support older iOS versions. For this reason, we chose to wrap LABiometryTypebehind our own BiometryType enum. This allows us to encapsulate both the need to use an iOS 11 compiler flag and the need to call canEvaluatePolicy(_:error:) on an instance of LAContext before accessing its biometryType property into a single calculated property:

NSFaceIDUsageDescription

The other difference with Face ID is the new NSFaceIDUsageDescriptionprivacy string that should be included in the application’s Info.plist file. This is a departure from Touch ID which does not require a separate privacy permission, and which uses the localizedReason string parameter when showing its evaluation prompt.

Touch ID evaluation prompt displaying the localized reason

While Face ID does not seem to make a use of that localizedReason string during evaluation, without the privacy string the iPhone X will run the application’s Local Authentication feature in compatibility mode. This informs the user that the application should work with Face ID but may do so imperfectly.

Face ID permissions prompt without (left) and with (right) an NSFaceIDUsageDescription string included in the Info.plist

This compatibility mode prompt is undesirable enough on its own, but it also clued us into the need to check for potential security concerns opened up by this forwards-compatibility-by-default from Apple.

Thankfully, the changes to the Local Authentication framework were done in such a way that we determined there wasn’t a security risk, but it did leave a problematic user experience in reaching a potentially-inescapable screen when selecting “Don’t Allow” on the privacy permission prompt. Since we believe strongly in our users’ right to say “no”, resolving this design issue was the primary reason we prioritized shipping this update.

Ship It

If your mobile iOS app also displays sensitive information and uses Touch ID for biometry-based local authentication, join us in making the easy adaption to delight your users with full support for Face ID on the iPhone X.

Originally published at www.betterment.com on November 3, 2017.

Before I get to showing code samples, let’s go over the set up. First, open your Podfile and add the ‘Specta’ and ‘Expecta’ pods to the ‘<fileName>Tests’ target and run ‘pod install’ in your terminal.

// Podfile

Target ‘FISCardStreams’ do
end

Target ‘FISCardStreamsTests’ do
    pod ‘Specta’
    pod ‘Expecta’

end

Make sure you now continue working in the *.xcworkspace file.

Next, in XCode, with the Alcatraz Package Manager already installed, add the Specta Templates package by Luiza-Cicone. This will generate our *Spec.m files with the correct targets and some boilerplate code.

Now we’re ready to generate the test file. In our case, this is going to be a Spec for the FISComment custom class, so let’s create our FISCommentSpec file using the template. Create a New File with the following steps:

This new FISCommentSpec.m file load with the following boilerplate code:

#import “Specta.h”
#import “FISComment.h”

SpecBegin(FISComment)

describe(@”FISComment”, ^{
 
 beforeAll(^{

});
 
 beforeEach(^{

});
 
 it(@””, ^{

}); 
 
 afterEach(^{

});
 
 afterAll(^{

});
});

SpecEnd

Unfortunately, the headers aren’t set for using Expecta yet. We need to import it and define the shorthand:

#import <Foundation/Foundation.h>
#import <Specta/Specta.h>
#define EXP_SHORTHAND
#import “Expecta.h”

#import “FISComment.h”

The “SpecBegin(<className>)” and “SpecEnd” are wrappers similar to the “@implementation” and “@end” in your class files and the compiler will complain if these are interrupted or missing.

The “it(NSString *name, ^{ … });” blocks are the actual test containers with a string that describes specifically what the test does.

The “describe(NSString *name, ^{ … });” blocks are wrappers that prepend a string to the displayed name of all the tests (or “it” blocks) within it. These “name” strings are very useful in self-documenting what each test is intended to check for and what its scope is.

The “beforeAll(^{ … });”, “beforeEach(^{ … });”, “afterAll(^{ … });”, and “afterEach(^{ … });” blocks are for setting up (or resetting) the instance variables to test by and the instances of the test class to run tests on. Keep in mind that “beforeAll” and “afterAll” only get dispatched once for all of the tests that they contain, but “beforeEach” and “afterEach” get newly run for every “it” test block.

Since one of the great features of Expecta is its asynchronous nature, it’s generally advisable to use “beforeEach” in order to start each test fresh with the same data since “beforeAll” only gets called once. The “afterAll” and “afterEach” blocks aren’t typically needed unless resetting some outside class or user default. We won’t be using them here.

True to Test-Driven-Development (TDD) form, let’s start by writing some tests for FISCommentSpec. Let’s expect to write a designated initializer that sets all of the properties it needs, and a default initializer that calls the designated initializer to pass in non-nil objects.

Let’s declare the properties we want FISComment to have, and the instance names that we want to generate:

SpecBegin(FISComment)
describe(@"FISComment", ^{

    __block NSString *commentID;
    __block NSString *parentID;
    __block NSDate   *createdAt;
    __block NSString *content;

    __block FISComment *defaultComment;
    __block FISComment *designatedComment;

});
SpecEnd

You’ll notice that we need to preface these declarations with “__block” (Note: this is a double-underscore). This places all of these objects within the scope of every test block in the current file. Now let’s set them in “beforeEach”:

SpecBegin(FISComment)
describe(@"FISComment", ^{

    { ... }

    beforeEach(^{

        commentID = @”commentID”;
        parentID = @”parentID”;
        createdAt = [NSDate date];
        content = @”content”;

        defaultComment = [[FISComment alloc]init];
        designatedComment = 
            [[FISComment alloc] initWithCommentID:commentID];
    });
});
SpecEnd

And now we can next some describe blocks for the methods we’re going to write. Make sure you close out the “beforeEach” block before continuing:

SpecBegin(FISComment)
describe(@"FISComment", ^{

    { ... }

    beforeEach(^{

        { ... }
    });

    describe(@"default initializer", ^{
    });

    describe(@"designated initializer", ^{
    });
});
SpecEnd

Now let’s add some tests (“it” blocks) and test conditions:

SpecBegin(FISComment)
describe(@"FISComment", ^{

{ ... }

    beforeEach(^{

        { ... }
    });

    describe(@"default initializer", ^{
        it(@"sets all properties to default values", ^{
            expect(defaultComment.commentID).to.equal(@"");
            expect(defaultComment.parentID ).to.equal(@"");
            expect(defaultComment.createdAt).to.
                                       beKindOf([NSDate class]);
            expect(defaultComment.content  ).to.equal(@"");  
        });
    });

    describe(@"designated initializer", ^{
        it(@"sets all properties to submitted values", ^{
           expect(designatedComment.commentID).to.equal(commentID);
           expect(designatedComment.parentID ).to.equal(parentID);
           expect(designatedComment.createdAt).to.equal(createdAt);
           expect(designatedComment.content  ).to.equal(content);
        });
    });
});
SpecEnd

The readability of the condition lines is much of makes Expecta so great. Begin the line with the “expect(…)” which encapsulated the instance variable you are testing — in our case, each of the properties of a FISComment object. The “.to” is actually not required for the positive, but is a helpful syntactic tool that also acts a placeholder for the inversion specifier written as either “.toNot” or “.notTo”.

The final element is the match specifier — how the instance variables are being compared — which encapsulates the instance variable we are testing. In this example we are using “.equal(…)” and “.beKindOf(…)”, but there is an extensive list of built-in matchers detailed in Expecta’s documentation. Expecta is written to allow custom matchers to be written quickly, but in most cases, the built-in matchers can be applied.

At this point, we should run our tests to check that they fail. This important to make sure that you have not written tests that always pass and are thereby useless. This is the “Red” step in the Red-Green-Refactor TDD mantra.

Now let’s pursue those green lights by writing out our FISComment class to match our test’s expectations. We need it to have four properties, a designated initializer, and an overridden default initializer:

FISComment.h

@interface FISComment : NSObject

@property (strong, nonatomic) NSString *commentID;
@property (strong, nonatomic) NSString *parentID;
@property (strong, nonatomic) NSDate   *createdAt;
@property (strong, nonatomic) NSString *content;

- (instancetype)init;

- (instancetype)initWithCommentID:(NSString *)commentID
                         parentID:(NSString *)parentID
                        createdAt:(NSDate   *)createdAt
                          content:(NSString *)content;

@end

FISComment.m

#import “FISComment.h”

@implementation FISComment

- (instancetype)init {
    self = [self initWithCommentID:@””
                          parentID:@””
                         createdAt:[NSDate date]
                           content:@””];
    return self;
}

- (instancetype)initWithCommentID:(NSString *)commentID
                         parentID:(NSString *)parentID
                        createdAt:(NSDate   *)createdAt
                          content:(NSString *)content {
    self = [super init];
    if (self) {
        _commentID = commentID;
        _parentID  = parentID;
        _createdAt = createdAt;
        _content   = content;
    }
    return self;
}

@end

Now we can run our tests and see if they pass. If they do, we’ll see a list of green lights in the navigation window.

This is concludes the “Green” phase. Now that we have the ability to check whether changes to our code break our FISComment class methods, we can graduate to the “Refactor” phase. In our case, we’ve already written two very solid initializers so we don’t have anything to refactor in FISComment.

Class initializers have a variety of uses beyond translating JSON dictionaries to Objective-C data models. In addition to being particularly useful in Core Data applications, these common methods are class initializers that you may have called without realizing what they are:

[NSString stringByAppendingString:(NSString*)string];
[NSNumber numberWithInteger:(NSInteger)integer];
[NSArray arrayWithArray:(NSArray *)array];
[NSDate dateWithTimeIntervalSince1970];
[NSCharacterSet letterCharacterSet];

Since they’re so useful, let’s write one for the FISClass data model class.

Since custom initializers are foundational to writing class initializers, we’ll have to start by writing these. Here’s a quick refresher on doing this correctly, but a more thorough tutorial can be found on the RyPress website.

In the class’s interface section, declare all of the properties that the class needs to contain.

FISClass.h

#import <Foundation/Foundation.h>

@class FISPerson;

@interface FISClass : NSObject

@property (strong, nonatomic) NSString *name;
@property (strong, nonatomic) NSNumber *roomNumber;
@property (strong, nonatomic) FISPerson *instructor;
@property (strong, nonatomic) NSArray *students;

@end

Then declare the custom initializer that includes an argument for each property. This will become the “designated initializer.” If the designated initializer needs to be private, then leave it out of the header file.

FISClass.h

#import <Foundation/Foundation.h>

@class FISPerson;

@interface FISClass : NSObject

@property (strong, nonatomic) NSString *name;
@property (strong, nonatomic) NSNumber *roomNumber;
@property (strong, nonatomic) FISPerson *instructor;
@property (strong, nonatomic) NSArray *students;

- (instancetype)initWithName:(NSString *)name
                  roomNumber:(NSNumber *)roomNumber
                  instructor:(FISPerson *)instructor
                    students:(NSArray *)students;

@end

This method name will now autofill in your main (*.m) file. The method body should look like this:

FISClass.m

#import "FISClass.h"
#import "FISPerson.h"

@implementation FISClass

- (instancetype)initWithName:(NSString *)name
                  roomNumber:(NSNumber *)roomNumber
                  instructor:(FISPerson *)instructor
                    students:(NSArray *)students {
    self = [super init];
    if (self) {
        _name = name;
        _roomNumber = roomNumber;
        _instructor = instructor;
        _students = students;
    }
    return self;
}

You can then override the default initializer and even create a convenience initializer in the following manner:

- (instancetype)init {
    self = [self initWithName:@""
                   roomNumber:@0
                   instructor:[[FISPerson alloc]init]
                     students:@[]  ];
    return self;
}

- (instancetype)initWithName:(NSString *)name
                  roomNumber:(NSNumber *)roomNumber {
    self = [self initWithName:name
                   roomNumber:roomNumber
                   instructor:[[FISPerson alloc]init]
                     students:@[]  ];
    return self;
}

These call the designated initializer with default objects so that they are not initialized as “nil,” thus allowing more clarity later during the debugging process. You will notice that “[super init]” is called only in the designated initializer. If the default initializer is overridden, it is good practice to note this publicly by adding it to the header filer. This has no effect upon performance, but it is a nice indicator that to other programmers and your “future self” that changes have been made to the implicit code.

Before we move on, let’s set up the FISPerson class with initializers, too.

FISPerson.h

#import <Foundation/Foundation.h>

@interface FISPerson : NSObject

@property (strong, nonatomic) NSString *name;

- (instancetype)initWithName:(NSString *)name;

@end

FISPerson.m

#import "FISPerson.h"

@implementation FISPerson

- (instancetype)init {
    self = [self initWithName:@""];
    return self;
}

- (instancetype)initWithName:(NSString *)name {
    self = [super init];
    if (self) {
        _name = name;
    }
    return self;
}

@end

OK, great. Now calling these designated initializers would then look like this:

FISPerson *zachDrossman = 
    [[FISPerson alloc]initWithName:@"Zach Drossman"];
FISPerson *markMurray = 
    [[FISPerson alloc]initWithName:@"Mark Murray"];
FISPerson *anishKumar =
    [[FISPerson alloc]initWithName:@"Anish Kumar"];

FISClass *ios004 = [[FISClass alloc]initWithName:@"ios004"
                                      roomNumber:@4
                                      instructor:zachDrossman
                                        students:@[markMurray,
                                                   anishKumar]  ];

This ensures that someone unfamiliar with the custom classes will initialize all of the properties to some value and avoid the black abyss of “nil”.

Furthermore, if we already have a dictionary object containing the information for an instance of our FISClass object, then we can use a class initializer to pass the information to the class object, which then returns an instance of itself with the correct properties. The dictionary, for our purposes, should be formatted like this:

NSDictionary *ios004Dictionary = 
                @{ @"name" : @"ios004",
                   @"roomNumber" : @4,
                   @"instructor" : @{ @"name" : @"Zach Drossman" },
                   @"students" : @[@{ @"name" : @"Mark Murray" },
                                   @{ @"name" : @"Anish Kumar" }  ]       
                 };

Since this dictionary is nested with dictionaries for creating FISPerson objects that the FISClass object will contain, let’s start small by writing the FISPerson constructor first:

FISPerson.h

@interface FISPerson : NSObject

{...}

+ (FISPerson *)createFromDictionary:
                                  (NSDictionary *)personDictionary;
@end

FISPerson.m

@implementation FISPerson

{...}

+ (FISPerson *)createFromDictionary:
                                 (NSDictionary *)personDictionary {

    FISPerson *newPerson = [[FISPerson alloc]
                         initWithName:personDictionary[@"name"] ];
    return newPerson;
}

@end

Excellent! We’ll need to call this method when creating the FISClass object. You can see it applied in creating the “instructor” object and the “student” objects in the “students” array:

FISClass.h

@interface FISClass : NSObject

{...}

+ (FISClass *)createFromDictionary:(NSDictionary *)classDictionary;

@end

FISClass.m

@implementation FISClass

{...}

+ (FISClass *)createFromDictionary:(NSDictionary *)classDictionary 
{
    FISPerson *instructor = [FISPerson 
               createFromDictionary:classDictionary[@"instructor"];

    NSMutableArray *mStudents = [[NSMutableArray alloc]init];
    for (NSDictionary *studentDictionary in 
                                   classDictionary[@"students"]) {
        FISPerson *student = [FISPerson
                           createFromDictionary:studentDictionary];
        [mStudents addObject:student];
    }
    NSArray *students = [NSArray arrayWitharray:mStudents];

    FISClass *newClass = 
        [FISClass initWithName:classDictionary[@"name"]
                    roomNumber:classDictionary[@"roomNumber"]
                    instructor:instructor
                      students:students];

    return newClass;
}

@end

This class initializer can be called from elsewhere in your code, such as in a data manager or an API client’s internet request completion block. Simply pass the response object to the class initializer and it will create your data model instances on its own.

NSMutableArray *classes = [[NSMutableArray alloc]init];

[FISIronboardAPIClient 
           getClassesWithCompletion:^(NSArray *classDictionaries) {
    for (NSDictionary *classDictionary in classDictionaries) {
        [classes addObject:[FISClass 
                            createFromDictionary:classDictionary]];
    }
    completionBlock(YES);
}];

If, for example, the Ironboard API either changes the name of a dictionary element in the JSON response (such as altering “name” to “fullName”), or adding a new property to “person” objects such as a “studentID”, we can adapt to these changes quickly by altering the data model itself to the following:

FISPerson.h

#import <Foundation/Foundation.h>

@interface FISPerson : NSObject

@property (strong, nonatomic) NSString *fullName;
@property (strong, nonatomic) NSString *studentID;

- (instancetype)init;

- (instancetype)initWithFullName:(NSString *)fullName
                       studentID:(NSString *)studentID;

+ (FISPerson *)createFromDictionary:
                                  (NSDictionary *)personDictionary;
@end

FISPerson.m

#import "FISPerson.h"

@implementation FISPerson

- (instancetype)init {
    self = [self initWithFullName:@""
                        studentID:@""];
    return self;
}

- (instancetype)initWithFullName:(NSString *)fullName 
                       studentID:(NSString *)studentID {
    self = [super init];
    if (self) {
        _fullName = fullName;
        _studentID = studentID;
    }
    return self;
}

+ (FISPerson *)createFromDictionary:
                                 (NSDictionary *)personDictionary {
    FISPerson *newPerson = [[FISPerson alloc]
               initWithFullName:personDictionary[@"fullName"]
                      studentID:personDictionary[@"studentID"]   ];
    return newPerson;
}

@end

And to do this compliance update we don’t even have to touch the FISClass or FISIronboardAPIClient files at all. This is the benefit to using class initializers for this purpose.

Happening upon this cultural gem while researching another blog post, “Time” captured my attention and left me engrossed for hours. While I’ve been a casual fan of Randall Munroe’s web comic “XKCD” since I discovered it in college shortly after it launched, I had not discovered the profundity of post #1190 until just last night — and yes, it easily consumed over two hours of my evening.

“And as Time unfolded, readers gradually figured out that it was a story,…”
- Randall Munroe, xkcd blog

It consists of 3,099 individual frames which were updated hourly between March 25 — July 26, 2013. This turned the slideshow into a long-form moving picture, blurring the line between comic and animation. While the original post now permanently displays the final image, thankfully there were a few devoted XKCD fans who archived the entire collection as it was released.

These devotees were the first of an entire subculture among XKCD fans which spawned during the four-month course of #1190. These fans left the internet with stacks of theories about its meaning and assembled viewing tools including animated gifs and GeekWagon’s “Time — at your own pace” viewer, which allows stepping by frame, autoplay with intelligent pausing on important frames (such as ones containing dialogue), and even an option to render the differences between sequential frames.

“Time” is a stunning example of using the internet itself as an artistic medium. While XKCD at large has its own devoted following, I have quickly come to regard #1190 as a masterpiece of a new kind of art form; it’s vast, yet simple; beautiful in its devotion; and both universal and specific in its interpretation. Like all the best art, at its core, “Time” is about love — and life — and time.

Whenever you have some time to yourself, I highly recommend spending it on absorbing #1190. Afterwards read Randall’s blog post about it, and look into some of the fan theories about its possible meanings.

• xkcd Time - at your own pace
• xkcd Time Wiki
• 1190: Time

0000 0101 ( 5, or 5 * 2^0)
0000 1010 (10, or 5 * 2^1)
0001 0100 (20, or 5 * 2^2)
0010 1000 (40, or 5 * 2^3)

While this is nifty, it doesn’t explain the normal binary operands that computers use to run their processes. The simplest of which are, of course, addition and subtraction. As I began reading about binary operations, I quickly discovered that there really is a certain magic to it. However, the written expressions that I found for how CPUs solve these problem are fundamentally the same as the long-form arithmetic I was taught as a schoolchild. Addition (and subtraction) in the decimal looks like:

        128                      170
      +  42                    -  42
      -----                    -----
        170                      128

In binary, this would take the form of:

  1000 0000 (128)          1010 1010 (170)
+ 0010 1010 ( 42)        - 0010 1010 ( 42)
-----------              -----------
  1010 1010 (170)          1000 0000 (128)

Long form is strikingly simpler to operate by hand in binary than in decimal, since no single-integer arithmetic is required—only that each resulting bit be tested for “0", “1", and “carry”. Multiplication and division are a little more complex in current operating systems, but taking the long forms which employ addition and subtraction, these look like:

  0000 0000  1001 0010        (146)
x 0000 0000  0010 1010         (42)
----------------------
                     0  (0) 
          1  0010 010-  (1)   (292)
                   0--  (0)
+       100  1001 0---  (1) (1,168)
----------------------
        101  1011 0100      (1,460)
                0 ----  (0)
+    1 0010  010- ----  (1) (4,672)
----------------------
  0001 0111  1111 0100      (6,132)

And division using subtraction:

       ---0 1110 % 0000 0110  (14 remainder 6)
     _______________________
1010 ) 1001 0010  (146 / 10)
     - 1010 ----  (10 * 16 = 160, 160 > 146)
     -----------                (0 sixteens)
       1001 0010  (146)
      - 101 0---  (10 * 8 = 80, 80 < 146)
      ----------                (1 eight)
        100 0010  (146 - 80 = 66 remainder)
       - 10 10--  (10 * 4 = 40, 40 < 66)
       ---------                (1 four)
          1 1010  (66 - 40 = 26 remainder)
        - 1 010-  (10 * 2 = 20, 20 < 26)
        --------                (1 two)
             110  (26 - 20 = 6 remainder)
          - 1010  (10 * 1 = 10, 10 > 6)
                                (0 ones)

(146 / 10 = 14 remainder 6)

Well, that’s all seemingly straightforward. But how do computers do it? The answer is logic gates.

A logic gate is the concept of taking two (or more) inputs, and, based upon a specified comparison, outputting a conditional result. In electronics, we know logic gates by their physical form—transistors. Each three-pronged semiconductor element in a CPU represents two input channels and an output, or result, channel. The two logic gates required for binary addition are the AND logic gate, and the XOR logic gate.

The AND logic gate represents the function A * B or A & B.

Input       Output
A   B       A & B
0   0         0
1   0         0
0   1         0
1   1         1

While the XOR logic gate outputs whether A and B are different.

Input      Output
A   B      A XOR B
0   0      0 (alike)
1   0      1 (different)
0   1      1 (different)
1   1      0 (alike)

The simplest combination of these creates the Binary Half-Adder.

Here, the XOR gate is used to output the Sum of the input, while the AND gate is used to detect a Carry digit.

By including use of an OR logic gate, we can create the Binary Full-Adder, which can track the status of the carry digit.

Input      Output
A   B      A OR B
0   0        0
1   0        1
0   1        1
1   1        1

In the Full-Adder, first A & B are compared, then their result is compared to the Carry-in to find the final Sum. At the same time, if A & B equals 1, or if (A & B) & C equals 1, then the Carry-out results as 1.

  Input         Output
A   B  C-in    Sum C-out
0   0   0       0    0
1   0   0       1    0
0   1   0       1    0
1   1   0       0    1

0   0   1       1    0
1   0   1       0    1
0   1   1       0    1
1   1   1       1    1

The Full-Adder can be repeated to create multi-bit adders such as the Ripple-Carry-Adder (4-bit) depicted here. More efficient constructions of multi-bit adders are the Carry-Lookahead Adder and the Cascading Adder, which allow for selected skipping of the logic gates in the carry block (more on this here).

But wait, now we’re using a third input which transistors don’t have…

Well, this is a logic diagram which can built using transistors arranged in a specific way. In considering this, let me point out that there’s something special about another kind of logic gate called the NAND gate. The NAND gate, and its sibling the NOR gate, are referred to as the universal logic gates because either one can be combined with itself in ways to replicated the function of any of the other logic gates.

Input      Output
A   B      A NAND B
0   0         1
1   0         1
0   1         1
1   1         0

So, if we string together a set of NAND gates, we can create any kind of gate we want in order to perform any function we want.

Can you see the implementation of these logical principals in the TTL 7400 chipset?

Exactly how CPUs structure their transistors to perform the desired arithmetic is beyond both the scope of my current understanding and the scope of this blog post.

However, knowing now what we’ve learning about logic gates, let’s take another look at that binary addition.

  1000 0000 (128)          1010 1010 (170)
+ 0010 1010 ( 42)        - 0010 1010 ( 42)
-----------              -----------
          0   0 XOR 0              0    0 XOR 0
         1    0 XOR 1             0     0 XOR 0
        0     0 XOR 0            0      0 XOR 0
       1      0 XOR 1           0       1 XOR 1
     0        0 XOR 0         0         0 XOR 0
    1         0 XOR 1        0          1 XOR 1
   0          0 XOR 0       0           0 XOR 0
  1           1 XOR 0      1            1 XOR 0
-----------              -----------
  1010 1010 (170)          1000 0000 (128)

Neither of these examples illustrate use of the carry function, which in subtraction is reversed by using the NOT logic gate. However, I hope that I’ve successfully illustrated the connection between binary math and the use of logic gates in computer architecture. For further reading on these concepts, please follow my reference links.

Unless otherwise noted, all diagrams are sourced from Wikipedia and republished here under open content licenses.

• Logic gate
• Binary Adder and Binary Addition using Ex-OR Gates
• Microprocessor Design/Add and Subtract Blocks
• NAND gate
• Adder (electronics)
• Binary number

I was fortunate enough to grow up with two parents who fostered creative learning. I realize not every child has this. I didn’t know at the time, but all of the science kits, Lego sets, field trips, computer games, and patient explanations helped me develop what is perhaps my most cherished quality: a curious mind.

You see, I was allowed to wonder. And in that wonder, to discover. I can recall the satisfaction I felt upon assembling a crystal AM radio kit I had bought (or, rather, my parents had bought) at a Boy Scout camp: a spool of copper wire wrapped around a cardboard tube and frailly connected to a 9V battery, a tiny piece of quartz, and an ear piece which quickly became a science experiment of another kind.

It was rudimentary, and honestly it didn’t work very well, but I remember the first time I heard the ocean of white static crack and pop into the faint glimmer of a tune. Here was something I had made with my own hands—from raw, unconnected sinews—that connected invisibly to the outside world, to the infrastructure crafted by adults.

No longer just an ordinary child, I was now a participant. Not just an idle, unknowing consumer of the magic once called “radio,” I knew how it worked. And I knew why it worked. I held its secret in my mind. If the radio could be called magic, then I had become its sorcerer.

There was a time when I believed that to be somebody—to really be someone and to accomplish things and be worthwhile, I had to become famous. It wasn’t really the fame itself I craved (I’m ironically quite shy in public), but rather, I sought the affirmation I expected would come with it.

Perhaps it was all the movies that my family watched growing up that led me to look for a different reality inside the screen. I don’t fully know. But as a teenager I gave up my path of scientific sorcery to study acting and the humanities. I chose a Theatre major and practiced Stanislavski, argued over Strindberg, watched Becket and O’Neill, read Chaucer and Donne, Frost and Dickinson, performed Moliére and produced Brecht, all while immersing myself in the vast, rich depths of the English Bard.

From all of this, I learned a funny thing about stories: they’re very mathematical. The scansions of iambic pentameter betray the author’s intent. Beowulf’s 101 stanzas are perfectly mirrored rising and falling action. Every story, every act, every scene, every moment contains a beginning, a middle, and an end: perpetual, nested trinities to the Nth degree.

The very fabric of language is algorithm.

Messages or verbs, receivers or direct objects; past, present, future, pluperfect; predicates, descriptors, syntax, operands, and punctuation—a programming language is just that: a language. On a fundamental level, learning to write computer code is not so different from second-language acquisition: it is just another way of communicating thought.

Back in December I had the pleasure of seeing Mr. Nye speak in the Upper East Side right here in Manhattan. It was slightly unreal to me—here was this formative figure from my childhood, of whom I’d only ever seen flat images on a screen, now lumbering awkwardly onto stage in the form of a lanky yet delightfully bow-tied hominid.

He was there to discuss his recent book “Undeniable” which was passionately inspired by the importance to him of science education and fostering independent thought in schools. It was this same passion which had inspired his TV show two decades ago—the desire to make learning fun, to bring science and math out of the rigidity of a textbook and allowing it to intertwine with the whole complexity of the human experience.

Here was this man with a household name, simultaneously aware of and innocent from his fame, running off on tangents about how amazing dirt can be—about how everything we’ve ever seen or known or touched was at one time held in the crucible of a star—about how incredibly vast the earth’s biodiversity is—about how “we are, you and I, at least one of the ways that the universe knows itself.”

Those words were him paraphrasing his own mentor Carl Sagan, and they’ve echoed in my mind over the last year. Twenty years ago Bill settled upon his idea to change the world in a way that only he could.

Now, it’s my turn to settle upon my own.