Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
CoWeb Assignment One: Midterm Review
What is a class? A class is much like a blueprint of an object. It contains methods and state variables common to all objects of a specific kind; that is, it defines an object and how to create similar objects.
What is an instance? "Instance" describes a particular object defined by a class (this is the relation between class and instance). Instantiation allows for the creation of similar, but distinct, objects.
Example: The Clock on the wall.
Instance variables differ from class variables in that they are specific to instances of a class; they have the same name but not necessarily the same data. A class variable is one shared by all instances.
Instance methods differ from class methods in that they must be called on a specific instance since instance methods use instance variables specific to a certain object (instance). Class methods can be called without instantiating an object..
Message passing describes how one communicates with objects in Smalltalk. It describes a goal. You "pass" a message to an object, which can then trigger a method. Since the implementation of a method/code-unit is "hidden away" in an object and can vary object-to-object, the same message may be implemented by multiple methods.
Class-based inheritance implies that if a subclass receives a message, a method in the parent class may be triggered. Subclasses thus inherit their parents' abilities to respond to messages.
The advantages of message passing are obvious. Having messages means less knowledge is required of the intricate workings of objects and their methods and properties, which also plays well with the concept of late-binding. However, this connection leads to one notable disadvantage: generic message passing undermines the idea of parameter types (i.e., one could send a message with a parameter of an undesirable type/object).
CoWeb Assignment Two:
Monticello: A User's Guide
"Because Squeak is Already Confusing Enough"
Monticello is a facility, built in to most versions of Squeak, that enables changes to a given project to be saved regularly in a way that different users working on the same project are able to retrieve those changes through a GUI-driven browser. Some of us may be familiar with CVS, which is another program with similar functionality. Do not be deceived, however; Monticello and CVS have their idiosyncracies.
Trying to maintain a project via the use of Squeak changesets simply may prove too difficult for multi-member projects. Monticello streamlines the saving, retrieving, and merging of project changes. In fact, Monticello makes going back to a specific version very simple, and you can actually view the individual differences in code (line-by-line). Also, assuming that a user's code at one point existed as a Monticello version, Monticello can merge in any subsequent version.
Aye, there's the rub. If you're in no mood for deciphering the very small knowledge-base surrounding Monticello, here is a pretty straightforward explanation of creating and using for the first time a Monticello repository with a project.
Open the Monticello browser. This is accomplished by bringing up the 'open' menu in Squeak (the same place you'd go to open a Browser) and selecting, you guessed it, 'Monticello browser'.
Establish a new project. In the browser menu (on top of the Monticello browser), choose 'packages'. Now the key here is to name the project the same name as you named your collection of code (i.e., the category name apparent in the leftmost column of your standard Squeak browser). This is how Monticello knows where to look for changes to project code. You'll notice that on the leftmost column of the Monticello browser, your list of projects appears. The one you just created is at the top. Shazaaam!
Create a repository. This is where Monticello stores all of your version files, etc. Deciding on this location should be done as a group since every member needs access to the repository. Best bet: select some folder on your local network and enable permissions. In Windows, our group found that a network location needs to be mapped to a drive letter for Monticello to use it since Monticello does not allow you to manually type in a path (you must choose a location from a GUI directory). No single user has to go in and "create" a repository; really all you're doing is telling Monticello where to store and load changes. Anywho, once you've decided on a location, in the browser menu choose 'repository'. Then, for a networked drive, etc., select 'directory'. The directory with sub-directories option seems to be a little buggy and unnecessary for that matter (this option just forces Monticello to look in all subdirectories for project versions). In the window that appears, you simply choose the directory for your repository. You'll notice that on the rightmost column of the Monticello browser, your list of repositories appears. The one you just created is at the bottom. Voila!
Important: to avoid some very strange errors in the future, when you first establish a project, one project member with the most recent version of your code should first save their version, and the other members should all load this version so that Monticello knows that every member is on the same page, so to speak. How to do this, exactly, is explained in this and subsequent steps.
Saving a new version. You'll notice that as you make changes to your project, Monticello will flag your project name in the Monticello browser. Now let's save them puppies. First off, you click your project name. It gets highlighted. Second, select your repository (in case you're wondering, it's displayed as the directory name). Third, you guessed it, click 'save'. Monticello will prompt you for a version name, but the one that has been automatically chosen is probably adequate. A couple more 'okay's, 'save's, and 'insert comment's and you're good to go (this is pretty straightforward). It is important to note that one should usually merge in the latest version saved in the repository (explained later) before saving so that every version saved contains all of the changes up till that save point. If you don't understand this just yet, it won't take you long to figure out that one can easily lose code because not all versions have been merged together.
Retrieving those changes. Back in the Monticello browser, select your repository. Then, click 'open' on the menu. A new window appears with project names listed on the left and project versions from the selected project on the right. So, what do you do now? Well, it depends on what you had in mind.
Loading. This means copying a saved version over exactly. No merging, nothing. Be careful with this one, but as I said earlier, this is how you should start your project in the beginning (load in the most recent version and work from it). To load, select a version from the version list (you'll notice that information about each version is displayed as they are selected) and choose 'load'. You will, of course, be asked if you're sure. Duh. And that's all I got to say about that.
Merging. This means comparing your current working version with a saved version and merging the changes into a single working version. Follow similar steps as for loading, except choose 'merge'. You may ask how Monticello compares code and merges. Well, frankly, it makes you do some of the work. When you choose to merge with a version, a window appears displaying all of the differences between versions, distinguished by method names, etc. Ones without obvious conflicts are simply listed. Those that Monticello thinks are a little iffy are bolded. For these, you must manually decide on which version to keep, which you do by selecting the method, etc. and choosing to 'accept' or cancel. Again, pretty straightforward and a pretty good way of maintaining the integrity of your project. Once you've completed your cycle through the changes, you can click 'merge' once more to finalize the process. The coolest thing since sliced bread, my friend.
Just remember that there isn't much going back once you utilize Monticello in this way aside from loading a saved version.
Take some time to play around once you know the basics. You really should be familiar with Monticello if you're going to trust it with your work. As a safeguard, our team usually employed Squeak's 'fileout' functionality to create periodic, standalone backups of our work. One final tip, always make sure that you don't save buggy or outdated code to your repository, and at the very least, carefully monitor what you're merging. Consider this scenario: one member makes a number of changes to his code (hours of work) and saves a few times. A separate member has been working for the same amount of time but has never taken the time to save or merge in any of his team member's work; then, when he finishes, he saves without merging. The team member who'd been saving then goes to merge in this version. Depending on the changes and how well the changes are inspected before merging them, there is a chance that old code may overwrite new. Again, if you don't understand this, it won't take you long to figure it out.
I typed all of this stuff once, and it got erased. As such, I'm irritated and probably won't do as good of a job this time. :)
1. Ward Cunningham- key figure in creation of Extreme Programming. This concept revolves around the ideas of simplicity and feedback. In Extreme Programming, code starts off simple and then undergoes refactoring to improve quality. These improvements result from information gleaned from the customer's response to prototypes. Also, to maintain the code's integrity, unit tests are employed from the beginning of any project. Coding itself may involve pair programming, where one person codes while another reviews the code and contributes verbally.
2. Ivan Sutherland- creator of Sketchpad. This early piece of software demonstrated the power of the GUI and thus revolutionized human-computer interaction. Also, the way in which the software stored data is reminiscent of object-oriented programming.
1. An ordered collection differs from a set in that an ordered collection stores its data in an organized, directly accessible manner. Sets do not.
2. An ordered collection differs from an array because arrays are limited to storing a preset amount of data. One would use an ordered collection when the amount of data to be stored is unknown, but this may prove less efficient. Arrays are more efficient when the amount of data to be stored IS known.
3. One uses a dictionary via a "key." This key is an external "naming" of the data to be stored, so that the data can be referenced directly using the key. Dictionaries are fast because they employ the concept of a hash table (hence the idea of a unique key).
1. Static- versus dynamic-typing. With dynamic typing, variables have no well predefined type of data (i.e., the data type is not known until runtime). With static typing, the type of data associated with a variable is well defined (during compile time). Using static typing obviously limits a programmer's flexibility in coding, while dynamic typing assumes the programmer knows what he is doing. Unfortunately, with dynamic-typing, an object could be passed to a method that expects a different type of object. With static-typing, this would not be possible.
2. Prototype-based inheritance differs from class-based inheritance in that there is not a distinction between class and instance. The advtanges of prototype based inheritances surround the idea of flexibility; attributes of an object can be applied and removed during runtime. In prototype-based inheritance, all attributes of an object are passed to its child, whereas with class-based inheritance, only those attributes global to all classes are passed. One could almost consider prototype-based inheritance as making a copy of an instance. One could view the loss of this level of abstraction as a disadvantage.
Links to this Page