I’m about halfway through Oregon State University’s (Go Beavers!) post-bacc program for computer science, but feel like I’ve just entered the belly of the beast. On the docket for the summer is CS 271 – Computer Architecture and Assembly Language; a fine relaxing course to take in the months before and during my wedding, right? Not so much.

The material is dense as we learn to program how to move memory around on a computer and perform basic actions on the contents of said memory.  The class is focused on the IA-32 – a 32-bit version of the x86 instruction set architecture found in early IBM workstations and personal computers, and then later in embedded systems for phones, aerospace tech, and electronic musical instruments.  I’m only a few weeks in, but already it’s painfully obvious to me that assembly is not like any other language I’ve used.

There is clearly a steep learning curve and I’m at the point where that curve seems daunting, but I’m confident there will come a point in time where the syntax and concepts click. Now is not that time, but the beginning never is. In these moments, I tend to search for papers, blog posts, and Youtube videos that help motivate me or explain the concepts from a different angle.

In a late night search, I stumbled across the following set of Computerphile interviews with Matt Phillips, a video game programmer from the United Kingdom (Manchester, to be exact), who is working on building a SEGA Genesis/Mega Drive game (Tanglewood) in assembly:

I would strongly suggest watching these videos in this order as they lead very well from one to the next and you can marvel at the effort it takes to string together a game in such a low-level language.

It was especially interesting to see how the language on the boards Matt is working with differed from what I’m currently learning. It’s one thing to hear about how machine-specific assembly is and quite another to see the different syntax, memory registers, and peripherals throughout the videos.

Check out the game trailer here:

Engineers make hardware and software for humans. It should go without saying, but remembering and staying true to that axiom is complicated depending on where you’re standing. With each passing year, it seems that things get more complicated, more random, more uncertain. This year was no different, especially in the realm of technology.

Facebook and Twitter are defending their platforms amidst allegations that they were used for interfering in America’s 2016 Presidential elections. Net neutrality seems to be going by the wayside with nary a peep from the so-called “Big N”, many of whom participated in protests in 2014 when the issue first came to the public’s attention. Uber dug itself into a hole as scandal after scandal rocked the company; the first of which was a female engineer lifting the veil and exposing a misogynistic and Darwinian culture, followed by revelations that the company had written software to avoid local law enforcement agents in areas where Uber was prohibited from operating. Meanwhile, the threat of automation and the looming specter of artificial intelligence have every working professional worried about the future of employment in this new economy.

The list could go on and on, and doesn’t end when last year began. As long as corporate greed and bad company culture are not only allowed, but praised, problems of this ilk will continue. The problem as I see it, is that it’s most troubling in the context of computers.

Continue Reading Make Technology for Humans

This title speaks to my life for the past four months. For years, I’ve known that JavaScript is the language of the present and future on the web and for years, I’ve avoided learning it. It’s easy to chalk this up to a myriad of reasons, but ultimately, the two largest factors were intimidation and motivation.

Intimidation because my entire programming experience is on the server-side using languages that support classical object oriented programing practices. JavaScript is the antithesis of both those paradigms. A language that is compiled in a completely different fashion and relies nearly entirely on the client to interpret and run the code, while also seeming to generally laugh in the face of OOP and passes around functions like it was going out of style.

Ultimately, I had to admit that I didn’t know JS.

Continue Reading JavaScript JavaScript JavaScript JavaScript

One of my more interesting decisions in life was to major in History (yup, with a capital “H”). Today, the only time that degree gets use is when flipping to one of the many books about the birth of the computer that are stored away on my Kindle.

Recently I’ve been reading The Idea Factory: Bell Labs and the Great Age of American Innovation – if you’re interested in the birth of the communications age then this is the book for you. Bell Labs is a research facility that, at the peak of its influence, helped determine the outcome of World War II, gave us the transistor, and launched the first communications satellite. The way that we live today is in part owed to the people that shuffled through all the various research labs owned and operated by AT&T during the heyday of the company. Today, it is but a shadow of itself, run by Nokia (who, given the resiliency of their older products, are undoubtedly looking for ways to make a phone that can survive the crushing pressure of a black hole), operating mostly in obscurity.

Continue Reading Ma Bell and Fostering Innovation