I want to review the points in my last article about object-oriented JavaScript, hopefully in a less rambling fashion. My big insight is that inheritance is inheritance. More specifically, class-based inheritance and prototypal inheritance are different mechanisms for accomplishing the same thing, namely single inheritance. Both mechanisms have the same strengths and limitations.

I love Vagrant. It’s a great tool for configuring and deploying identical development environments across different computers and platforms. I’m currently toying around with the concept of using a virtual machine (deployed using Vagrant, of course) as my main work environment, and just leaving the host OS as the host. I also want to get more familiar with Red Hat (Ubuntu has been my distro of choice in the past), so I started building a new Vagrant box on Fedora 23. The problem is that Fedora’s kernel upgrades don’t play nicely with the VirtualBox Guest Additions, but I found a solution.

This fall, I started working toward an MS in Information Security and Assurance at George Mason University. My career goal with this degree is to become a researcher in the information security field. In particular, I am very interested in applying data science and machine learning to information security, and I plan to complete a thesis in this rather broad area. Unfortunately, I don’t currently know very much about either field.1

I think that machine learning is a subset of data science (although I could be wrong about this), so “data science and machine learning” is one field, in my current naive understanding.
[return]

If you spend any time reading about REST on the interwebs, you’re probably seen the ugliest acronym outside of the government: HATEOAS. That charming tongue-twister stands for hypermedia as the engine of application statement. If you’re anything like me, that raises two questions: (1) WTF does that even mean? (2) HTTP is stateless, so why should I care?

Kindly allow me to explain what HATEOAS means and why you should care.

Ok, I admit it. I used to think that JavaScript was a toy language. I think we all did. But even now that I’ve started treating it as a serious language, it still carries this stigma that it started life in Santa’s Workshop. For example, my approach to JavaScript for many years was to treat it as a serious functional language that had “prototypes” tacked on as a toy-like way to mimic classes and class-based inheritance.1

With that attitude, I was naturally excited to see JavaScript getting more Java-like classes in its latest update, ECMAScript 6 (commonly shortened to “ES6”). At the end of his excellent article, Dr. Rauschmayer writes, “I would have preferred [classes] to be prototypal (based on constructor objects, not constructor functions).” I thought to myself, Why are constructor objects better than constructor functions? And so, I started to do a little research.

This is commonly referred to as “classical inheritance,” which always sounds to me like “classical music”—like it’s really old or the only proper way of doing things. I use a slightly different term to clarify that there’s nothing particularly old school about classes.
[return]

I’m working on a virtual tabletop for traditional adventure games, including roleplaying games and miniatures wargames. I’m currently referring to it as “Project Adventurology,” and it started as much as a learning tool as a project that may eventually see public release. I have certainly learned a lot in the months that I’ve been working on Adventurology, although sometimes it’s been more of a struggle than a frolicking adventure. The area that I’m currently struggling with is designing the REST API to enable manipulation of server-side objects.

“Loose coupling” is the software engineering principle that says components of a software system should only interact with one another through well-defined interfaces. If one component changes, other components should not also need to change. The interface should remain the same. The operations of the component should be hidden inside a black box, so that when there are changes, those changes don’t impact other components.

Loose coupling is often articulated as the Law of Demeter, the principle of information hiding, separation of concerns, and a number of other related axioms. Usually, it is applied to functions and object methods, but it also applies to a REST interface. In fact, a REST interface separates concerns in two different ways.

Why should you use REST in building your web service or application? That’s what we’ll look at in this series. The first reason is our old friend, “loose coupling.” But first, let’s discuss what REST is, so that we have a solid foundation before diving into why you should use it.