Tuesday, September 3, 2013

Homework 7 – Software Engineering – CSCI 362-001

I'd heard previously about the 7 +- 2 rule. I heard that it meant someone could only do around 7 things at once – though I wasn't told this was between 2-3 bits of information. It certainly seems interesting that short term memory isn't based on bits but by chunks – certainly encouraging people to specialize instead of being a jack of all trades.
In regards to failures in cloud computing, I suppose I previously always defined “uptime” as time that the service is available and working correctly – though I suppose this time frame may differ depending on the software. I think the distinction between accessibility and availability is an important one. Having a feature that presents a users with a descriptive screen of what's going on when the service is not available can be critical to keeping users content, happy, and informed.
Degradation instead of failure is a wonderful idea. Nothing is perfect and everything will fail eventually – it's better to plan for these events. This also helps encourage a healthier state of mind and development practices – to not assume you're design is perfect. I've always felt that redundancy of middle-tier equipment has had an edge over singular high-tier equipment – it's less presumptuous and gives multiple failure points. The points on being able to detect failures was basic but important.
The point on making sure a “re-try” is included in exception handling seems obvious but probably often forgotten and critical. I hadn't previously thought of all the uses of request-buffering though – I'll certainly try to remember it for later projects.
Capacity buffering seems like a basic good design, and dynamic resource accessing seems like a good idea if even for security reasons. Automating responses to failures as much as possible seems like a normal step as well – as does seeking out problems and solutions which may pertain to your system.
After reading the title of the paper on tire's and mandatory wireless service, I'm immediately concerned. I don't particularly desire for my car to be communicating with anything else other than me physically – that way I'm more secure from being remotely screwed with. It seems rather obvious that a particular network can be tracked with some work – while not a particular concern for me at the moment – could easily be for others. Another rather disgusting feature is the mandatory requirement for it as opposed to letting it be voluntary.
I'm not sure if I should be proud or concerned that some of the experiments done concerning privacy were done somewhere I drive regularly. While I wasn't shocked to learned that the range of picking up packets was large, and that it was not difficult to force trigger and capture it – I was concerned. There seems to be very little to no security on the system as well – which is even more concerning. The later experiment that forced warning lights to go off brought everything into perspective – you could force someone to stop in order to render them more vulnerable.

No comments:

Post a Comment