jsulz

I’m over halfway through Oregon State University’s post-bacc computer science program. It’s a (mildly) grueling gauntlet of 15 courses, made more grueling by the fact that I’ve been working full-time and taking two-courses a quarter (with an exception made for this past summer when only one course was on the docket to give me some time to get married 🙂 ). To-date, I’ve taken, or am currently taking, the following courses (in no particular order):

• Introduction to Computer Science I
• Introduction to Computer Science II
• Discrete Structures in Computer Science
• Data Structures
• Web Development
• Introduction to Databases
• Computer Architecture & Assembly Language
• Analysis of Algorithms
• Operating Systems (currently in progress)
• Software Engineering I (currently in progress)

Another week of reading, lectures, and confused Googling and skimming through videos is in the bag. This week was all about NP-complete. It has been fun to experience an “aha!” moment in each course I’ve taken so far, and this was an especially fun one. In large part, because seeking answers to these questions is seemingly beyond the reach of computers (in a reasonable time).

We’re accustomed to computers being incredibly fast. So accustomed that we forget just how fast they are. They’re really fast. I’m writing this on a 4-year old computer. It has a 2.5 GHz Intel Core i7 processor. That number equates to how many cycles the system clock of this computer runs in a second. So 2,500,000,000 cycles in one second. The version of the CPU  running on this machine is quite powerful. It should execute around 9 instructions per cycle for a single core in the processor and there are 4 total cores running.

This all adds up to a lot of numbers and those numbers represent commands that we expect the computer to execute for us so that we can….. I dunno….. watch videos of cute cats.

I should note that I continue to remain positive about the direction of the Gutenberg project (the new WordPress editor, coming to you as of WordPress 5.0). My feelings on this are numerous and expansive, but the long and short of it is that I believe WordPress core needs a major shakeup to help the community (re)develop focus and draw in engaged and effective technical participants. Gutenberg represents a wonderful opportunity to do that as it brings a new paradigm to the core editor (and likely elsewhere as the foundational technology expands into other areas of site management) and has the potential to draw in a new wave of web developers.

That said, the introduction of Gutenberg into core has been an interesting thing to watch. From afar, the concerns of the Accessibility Team seem to clearly show the divisions between WordPress as an open source project (WordPress.org) and as a commercial one (WordPress.com). Here is a report from the WordPress.org team on the current state of accessibility in Gutenberg.

Having just finished my midterm in Analysis of Algorithms (yes, the class is as dry as it sounds), my brain is still sharp on a few topics; one of them being dynamic programming, which I mentioned in my last post. In that post, wherein I tried to find motivation for forcing myself to relearn calculus, I used the classic example of trying to calculate the nth term of the Fibonacci sequence.

I thought it would be helpful to see this example running with some real code. Below, we have a JavaScript function – fibRecursive – that takes an integer as a parameter. This integer represents the term that we want from the Fibonacci sequence. For example, a call to the function like so fibRecursive(6) would return 8.

This is a question that is plaguing me at the moment as I force myself to relearn calculus for Analysis of Algorithms at Oregon State University. In moments like this, where the concepts are abstract and I need to learn even more abstract concepts so I can understand the first class of abstract ideas, motivation is key.

Well, the short answer is that you don’t need this body of knowledge to develop a wide range of applications and features to applications. In my world, many of the concerns that common sorting, searching, and general optimization algorithms address are not real concerns because they’ve been abstracted to parts of the language or framework. I’m able to do my job because someone else has figured out how to do other parts of my job that normally would need to be created from scratch. So while learning merge sort and analyzing its complexity is a fun exercise, I’ll not be writing it from scratch anytime soon.

Updating LexBlog.com’s aggregation engine was no small feat. Scott Fennell and I spent months testing all of the various components of our new aggregation engine that powers the vast majority of the site, but something that was hard to prepare for was the shear scale of the site. Now that it’s up an running, we’re learning a lot about how to manage a site like this, and what sorts of features are necessary for it to be a successful publication from the perspective of an editor or reader.

One thing that I’ve recently keyed in on is search. Normally, I would tell a client that on-site search is not important. Most visitors are coming to a site from a much better search engine (Google), and are more apt to click around the site once there. LexBlog has layered in some nice features to the standard WordPress search, but most of those are around making sure that readers can search by an author’s name when they’re on a blog or website. This seems like a thing WordPress should do by default, but the generic WordPress search is “dumb” in the sense that it only looks to the post content and post title when running a search. Authors are not in either, so some work had to be done to support searching an author’s name and getting their posts.

This was one of the most eventful summers in my life both personally and professionally. In July, Garry (LexBlog’s COO) and I had a chance to go to Chicago and spend some time talking about LexBlog’s future product line and general opportunities for integrating with our platform. It’s not often that I get an opportunity to do face-to-face meetings of these sort, and it was nice to get back in the saddle. It was also my first time visiting Chicago, and Garry seemed more than happy to drag me around.

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.

Like many technical specifications on the web, RSS (which stands for Rich Site Summary or Really Simple Syndication depending on who you talk to) has a confusing history that seems to only get more confusing as time goes on. The format became popular in the late 1990’s as the need to standardize information held on websites became a pressing concern with the rise of blogging and dynamic websites. The influx of information and content, all organized in different ways, was exciting, but without a standard way to consume the content, you were left with just a few options:

• Bookmarks, and lots of them
• Memorize a handful of URLs and visit only those sites
• Build a custom web scraper

The goal of RSS (as I see it) was to provide each site that created dynamic content a specification to follow to make that content available at some address so the rest of the internet community could easily monitor this address for updates. For example, this blog’s RSS feed is available at https://www.jsulz.com/index.xml. You can take this URL and drop it in Feedly or your RSS reader of choice and every new post I publish will end up there alongside any other blogs you regularly read.

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.