






Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
Michael Cook
I am a second year CS major. I just finished my second Co-op term with Synovus Financial in Columbus, Georgia. I am not sure what I want to specialize in yet. However, I do know that I want to take at least one networking class. I am also interested in learning more about SQL databases and Visual Basic .NET since I have used those previously in Co-op terms.
Future Dream:
- Get another computer (most likely build it) and use my old one as a server
Extra Credit - Articles
When Bugs Become Features - http://www.jnd.org/dn.mss/when_bugs_becom.html
A common saying is "That's not a bug, that's a feature!". Sometimes when people find bugs in their design, they simply put it in the manual and label it as a feature. The better solution is to fix the bug. The example used is a door that has the same types handles on both sides and only opens one way. I chose this article because it is common practice to try to hide bugs or make them look like features instead. This saves time (which is huge when you are taking other classes that have other homework/projects). But it also doesn't eliminate the problem, which would be the ultimate solution.
Commentary: Human Error and the Design of Computer Systems - http://www.jnd.org/dn.mss/commentary_huma.html
Sometimes human error is used as an excuse of why something didn't work. The truth is that humans are prone to making erros, so how can we deal with this? The solution is to design around human error. Spend time designing solutions to human errors by making them less serious or detecting and stopping them. Here is why I chose this article: One thing I remember being mentioned in one of my CS classes is never to trust user input. Not only could the user have a sinister intent but the user could simply make a mistake. The fact is that human error is not going anywhere, so we have to learn to deal with it as CS majors.
The truth about Google's so-called "simplicity" - http://www.jnd.org/dn.mss/the_truth_about.html
Google's home page is simple because it is hard to find more advanced options. To do somthing other than use the standard search bar requires finding the catagory it is under and searching through possible choices throughout different pages. Other search homepages look complex but are easier to use becuase they clearly present the available options on the homepage. I chose this article because I was running out of good choices and CS majors use Google a lot. It is a very helpful search engine. However, the article shows some of it's usability flaws.
Co Web Assignment 1
Mini Java-to-Squeak Tutorial
Since I am familar with Java, as I am sure many others are, this case is particularly helpful with getting into programming in Squeak. It contains code conversion examples including assignments, logical operators, and loops. A couple key differences are: := is an assignment operator in Squeak as opposed to = and the logical operators used in Java (such as &) are just one character in Squeak (such as &). I would suggest people either take notes about this page or bookmark it so they can go back to it easily. I know I will be going to it a few times as I start programming in Squeak.
Proper CRC Card Creation
Since CRC cards are going to be new to me, I thought I should at least get a glimpse of how to make a CRC card. This case explains how CRC cards are different from UML. It shows a picture of a bad CRC card and comments on how it could be imporved. It then shows a "proper" version of the same CRC card and explains how it is better. The idea the case stresses is to not overcomplicate CRC cards so they can be easily understood by people.
How To Complete Your First Milestone
The title of this case sounded interesting so I looked at it. It has some useful pointers for getting started in Squeak, including how to find classes and methods. The case shows how to open a new morhpic project so you can keep everything for a project in one place. It sounds like this could be a good idea once I learn more about using Squeak. Possibly the most helpful information in this case is having this link: http://minnow.cc.gatech.edu/squeak/. This site looks like it could continue to be useful throughout the class.
Video Professor: Because reading is HARD.
I don't know about other people, but I learn best visually. This case has some very useful videos that show you how to do a number of things. I recommend this case to anyone becuase it shows things visually. A couple of the features I found most useful are: how to file in and how to swap the alt and control keys so you can control-c and control-v like normal programs.
Team Modulus Cases
The first page of this case is somewhat useful. It gives an overview of the importance of design, CRC cards, and UML. The How to test page I found very useful. It gives step by step instructions (inluding pictures) of how to not only install SUnit in Squeak but also how to set up test cases and run them. This information can be helpful if you want to get a head start on writing test cases or to just supplement the eventual lecture on SUnit.
Co Web Assignment 2
Refactoring
- Refactoring is basically reorganizing the code; you take bad code and reshape it to good code. Refactoring is done because it makes code easier to extend and read. When someone needs to go back and change the code, you don't want them to have to spend a long period of time trying to figure out what it is doing in the first place. One sure sign that you need to refactor your code is that you find it hard to add to and can't understand it very well just by looking at it. Another way to tell that code needs refactoring is if classes or methods are exceptionally long and powerful. For example, if you have a "god" class.
- Unit testing can be very helpful when refactoring code becuase you can run the tests after each change you make to make sure you aren't breaking anything. In the case that everything breaks, you can use the tests to chart your progress and know when everything is working again.
Scoping
- In Smalltalk, all methods are public and all variables are private. The fact that all variables are private encourages good object oriented design because you can't mess with the insides of a class. The slight disadvantage to having variables private is that you can't get their values directly, but this is easily overcome by adding accessing methods that simply return the value of the variable. Having all methods public encourages making methods that the user can use to get the object to do something. In theory, you should tell an object what to do and have the object figure out how to do it, rather than tell the object how to do it. The fact that all methods are public in Smalltalk can be a disadvantage if you have helper methods that are suppose to deal with the guts of an object and are not suppose to give the user access to interfering with the object's functioning. This disadvantage can be overcome somewhat by stating that a method is supposed to be "private" in a comment in the method.
Co Web Assignment 3
Extreme Programming
- In pair programming one person actually writes the code and another person thinks about the general problem, double checks the code for error, and thinks about how the code fits with the rest of the program. The two people switch roles at times so each person adequately experiences each role. Pair programming is used in Extreme programming becuase it produces code with less errors (less time debugging) and code that is designed better and fits well with the rest of the project. Also, if someone leaves the project you have another person who is familiar with the code.
- Unit testing is designed to help produce robust code that is well tested throughout the development process. It is easier to maintain code when you know immediately when something breaks. Also, unit tests are written before code is written so it gives more direction to your code and helps define requirements.
Object-Oriented Programming
"Objects do the work. The work is done in instance methods in the appropriate class. Good objects have clear responsibilities and clear interfaces."
- "Objects do the work." The idea is that you give objects input and they give you output. If the objects do the work the code is easier to test in parts and resuse. For example, you might give a graph object some data points and it would graph the information visually.
- "The work is done in instance methods in the appropriate class." If you have your code in class methods, then you basically are just organizing code. You are not having objects do the work. For example, you don't want to ask the integer class to parse a string; you want to ask the string to give you its integer equivalent.
- "Good objects have clear responsibilities and clear interfaces." What good is an object if you can't figure out how to use it easily? The answer is it is not as useful as it should be. One point of object oriented code is that it is easier to maintain and understand. Therefore you want to design your objects so that the methods make sense and can be used basically intuitively. You also want to make sure people can tell clearly what your objects are supposed to do. If someone doesn't know what an object is supposed to do how is that person going to use the object?
Links to this Page