Woops, it’s not really week 12 any more… I skipped this lecture because of the crazy week 12 assignment load. I did attend the week 13 lecture in person before listening to this lecture, but I’ll keep the order for the sake of nice looking web archives.
This week’s lecture is on system interfaces, that is, places where your system talks to other systems/things. Last week we covered Human Computer Interaction (HCI) but this week our focus is on removing the human as much as possible because humans spew errors every time they touch a computer. We can make the system accurate by leaving the human out of it and focus on electronic things talking to each other. I’m not saying “computer to computer” for a reason because a computer-based system may talk to a not-computer system, like a temperature probe or other kind of sensor. (An example of this is something fun I’d like to play with: Home Automation.) When electronic devices talk, what they are doing is passing data around. We need to make sure we format the data we send and understand how to read the data we get. We can find out where the system interfaces are by looking at the Automation Boundary on our DFD or structure chart.
The other big focus here is the Database. Systems need to store data, and a database (DB) is the way to go. While Object Oriented Databases exist, Relational databases are the industry standard, the big names are Oracle Sybase, DB2, SQL server, Ingres, and MySQL is really big on the web. (MySQL is where this post gets stored, where the comments get stored, and WordPress pulls the posts out when it shows you the website.) We learn about Databases in FIT2010 (or FIT1004) and for me that was a few years ago, so I needed to review some of the key concepts in order to understand a bit better.
POD really emphasised how important it was to at least know the names and the trends to help us in our jobs, (at the very least to impress the pointy-haired management, or clients), so I’ll point out something interesting: NoSQL Basically SQL can be pretty nasty if you’re trying to build a web application that scales nicely (that is, grows from a small user base to a large one without loss of performance or functionality.
(twitter had visible issues with this in 2007, particularly around big spikes of traffic such as MacWorld, some bloggers pointed at Ruby on Rails, others at the database. coding horror’s take, radical behaviour.com interview with Alex Payne of twitter and Ryan Tomayko (of GitHub) says it must be Twitter, because he doesn’t have issues with Ruby+DB.)
Back to NoSQL: it moves away from the relational database model to effectively deal with a more “write-heavy” environment that comes in a more social media world. Paul Stamatiou has a good link collection about NoSQL in his write up about a NoSQL conference in Atlanta. (conference recap.)
Let’s get back to FIT2001, eh?
The other big concept in this lecture was that of SECURITY. This includes the obvious like encryption, passwords, (which users hate) etc, but also checking the data. We’ve got:
- integrity controls (ie customer is real person?):
- field combination control (you put “USA” as your country, your post code isn’t going to be a four digit one, but a five digit one),
- value limits (oldest person alive today is just under 115, so age shouldn’t be 300 for a living person)
- completeness (everything there? house number, street, suburb, post code?)
- data validation (is your phone number 8 digits long, not missing digits)
- output integrity
We can also detect things like fraud by looking for patterns. This isn’t error-proof though, as you card can be cancelled if you inadvertently trigger a pattern. My bank always rings me if I book a holiday-related thing such as a flight, hotel, etc, or if I make a lot of online purchases at once, which is nicer than cancelling my card point-blank!
The big hint with security is to think about it at the ANALYSIS PHASE, and to not try and tack it on just before the system is delivered. The other hint is to know enough about security to ask a real professional when you need to.
POD also referred to UML design patterns (such as the 3 layer business model) which are important to know about for the future. I think Clayton (and Sunway) students get to meet design patterns again in Software engineering: architecture and design.
Reports! Reports are a really really important system output and help the managers understand what is happening and keep their business turning over a profit. We’ve got to care about formatting the reports, presenting the data graphically (or not), what data to present, and making the report GOOD. (Security wise these might be printed to a secure printer.) Reporting is where IT gives real tangible value to the organisation, and is an important field.
The tutorial was a bit crazy. I wish I had more of my assignment completed to ask questions about, as it was I was swamped with two other assignments. I wish I had done this as going over my assignment for revision purposes in week 13 was a bit scary, as I couldn’t change anything! I didn’t attempt the tutorial exercises but will probably use them as exam preparation.
I had a good go at getting the multi-choice answers correct based on my existing knowledge, a few terminology questions on reports let me down a bit. EDI (electronic data interchange) was something I didn’t know, it is just the “structured transmission of data.” A little bit of confusion about “completeness control” that I’ll need to be careful of remembering for the exam. Oh and I didn’t guess “smart card” or “access control list” but I know them now.
This was a fun lecture. I liked the video from Apple, crazy to think that the stuff they were dreaming about back then has (kind of) come to reality. This is an area that wasn’t so important to the “sit down and draw a diagram” part of the unit, but it is important information to file away for the future.