CS 360 Homework 7

For this post, I will be responding to a few articles

The Magical Number Seven, Plus or Minus Two
Having taken cognitive psychology classes in the past, I was very familiar with topic-at-hand here. The article talks about how you can only hold about 7 things in your working memory at once (+ or - 2 depending on the person or situation). This feels like a pretty arbitrary schematic for detailing working memory, though. What would actually constitute one of these 'things'? A better way to detail working memory, I feel, is through detailing of the Central Executive. The Central Executive is an idea posited by Alan Baddeley to model working memory in 1974 (it has been refined since then). So instead of just remember 7+-2 things, you have three main areas in which you can process - the phonological loop (language), the visuospatial sketchpad (visual semantics - often abbreviated "the pad"), and the episodic buffer (short-term, episodic memory). This article refers to Miller's law; Miller's law has stood the test of time and is generally accepted, but there tends to be plentiful evidence against the 5+-2 from outside cognitive experiments. I believe Miller's law should just be taken as a rule of thumb for working memory, and not as actual factual evidence. Additionally, Miller's law did touch on things that Baddeley's working memory model covered, but Baddeley's model just feels more elegant and has a lot more backing.

Security and Privacy Vulnerabilities of In-Car Wireless Networks:
A Tire Pressure Monitoring System Case Study
It is a known issue that cars can be hacked and terrible things can occur. The most common example when talking about cars getting hacked is the tire pressure monitoring system. According to this article, these can be hacked from as far as 40 meters away. These authors, in their paper, clearly detail out how they conducted this experiment with ample graphs and descriptors. Also, they clearly followed the scientific method - they found a problem, tested it with two different tire pressure monitors, and reached conclusions which are all clearly outlined. Honestly, I wish the conclusion to this experiment was different. It is a little nerve-wracking knowing that the wireless signals being bounced around my car barely have any encryption (some signals having none).

Planning for Failure in Cloud Applications
Cloud applications. They're great, they're awesome, and they rock. You can access them from anywhere, anytime. If something seems this good, then there are bound to be some downsides. I have my own cloud-based application (Learn2Mine) and it goes down occasionally, but 95% of the time it goes down it is because we're relying on outside resources to keep our system safe and sound. Specifically, things as simple as Google APIs can sometimes take us down if their authentication causes a hiccup, which is known to happen. Other times, however, Portal (at CofC) will be down, which restricts users from 2/3 of the cloud application. This article does have me reconsidering our 'failure' pages for when services or certain operations do not work. It is a lot less shocking when you see a "this page is temporarily down and will be back up soon" type of page rather than seeing a "500 INTERNAL SERVER ERROR - HIDE YOUR KIDS AND WIVES, WE DON'T KNOW WHAT'S HAPPENING" kind of message. These different pages really give a different form of connotation. In my eyes, it seems like if developers have taken the time to customize an error page like that, then they probably know what they are doing. Also, I had not considered creating 'retry' blocks of code. I have  NoSQL database that I reference and if a call fails, we make the assumption that a user may not be created. We could probably run into some weird errors if this hiccup were to happen to our application.

Music listened to while blogging: J. Cole