Surprises

Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007

Surprises

For Newcomers:

Here are tips from previous 2340-ers about how to get started.

For Oldtimers:

You've finished your first assignment. You're thinking to yourself, "This isn't what I thought! If I only knew..."

Quick! Hold that thought! Write it down here! Tell the next group of 2340-ers what they ought to know or do in the first three weeks of class that you wished someone had told you.

Spring 2005

Spring 2003

Summer 2002

When splitting up work amongst teammates, atleast as much time to integrate the parts as to create them. Just because each person thinks they´re part is done (and it very well might be) that means nothing about how it will work with the other parts, that are also "done" - Hank Wilde

Creating an ImageMorph from a Form, e.g.:

myImageMorph := myForm asMorph.

will do something somewhat surprising if the Form is monochrome (bit depth = 2). If it's monochrome, then when it's turned into an ImageMorph, all the white is changed to be transparent! This makes sense in hindsight, but imagine my frustration when I was trying my code and nothing was happening, only to later realize I had put about 10 transparent Morphs on the screen...
Jim Gruen

Trying to run Squek in Windows ME will also do surprising things such as not accept methods. - Caitlin Bovee

Having trouble with focus (especially keyboard focus)? Remember that the cursor is called a HandMorph. The current active cursor is called ActiveHand, and you can also get the HandMorph for MorphicEvents by passing the 'hand' message. The HandMorph controls focus, so try this message on a HandMorph:
releaseKeyboardFocus
HandMorph has all sorts of focus methods!
Too bad it took me a while to find this stuff.
The HandMorph is all-powerful in the Morphic world. The Order of the Hand will rule! Jim Gruen

After working on the first project, I realized that I didn't know Squeak as well as I thought I knew it. Let me explain. I went to all the classes and read the book, and it still took me about 20 hours of playing around in Squeak to figure out how to go about programming in Squeak. This became a problem when I only allocated 24 hours to work on the first project.

Also.. the first design you do will suck[1], to put it in simple terms. Allow enough time to design your first project or two, twice. (Too bad Guzdial tells us this now.. 5 or so weeks into the semester. :)

As far as groups go, when someone keeps delaying their part of the project after they said they were going to have it done a few days earlier, realize that this is a major problem, and that the person who hasn't finished their part is probably lost at this point. Don't count on them to finish their part by the deadline. (People lie... as McCracken likes to put it.)

Chris Haire

[1] prove it. –RG

Tree Milestone:
Ok...ok...I was surprised by something :)
I had trouble when working on P1: I attempted to re-use the LinkedList class to hold the list of child nodes for each node. Unfortunately, I encountered problems due to a nextLast:? or nextLink:? message not being understood. So, I gave up and wrote my own LinkedListNode class (I know OrderedCollections could perform the required functionality, but I wanted to get more experience coding in Squeak.)

Also, I had problems changing the color of a DisplayObject prior to telling it to displayAt:... I found that I had to set its color prior to any width/height queries to get it to work.
Matthew Wolenetz

You can't insert just any object into a tree... Incredibly, you have to subclass Link and teach it to hold your data. This actually turned out to be fairly convenient for my implementation of the tree milestone... I created class RenderingCell to be a subclass of Link. Not only did each RenderingCell know its corresponding Tree node, it also knew a bunch of temporary variables related to the logic of display calculation.
Stephen Bennett

Here's a great surprise...
You code and code and code and it is getting late...You think you have it working, so you run it, fogetting to file out first...SURPRISE!!!...It gets stuck in an infinite loop!
Oh no! How can you get out of it AND still have your code???
Never fear... ctrl-alt-dot is here!
If you need to break your code, ctrl-alt-. will stop execution!
Now that's some good info...
The day is saved; you quickly file out your code and breath a sigh of relief...time for a coke:)
Yisrael (Lushi) Lowenstein
(P.S.it may have been another key in the same vicinity as '.'...I knd of started to hit them one by one and am not totaly sure which one did it... also try these:
; ' , /
one of them will work!)

So, don't do this:
Scamper openAsMorph.
and then pull up www.persiankitty.com as a joke. it's pretty funny, though. you can rotate the individual images. however, it crashes many things (including the jpeg decoder and html parsers).

ctrl-break stops an infinite loop, so you can squeak happily ever after
Harper Maddox

If you're doing the team meeting thing, don't do it in the computer lab. An open webbrowser quickly screws any chances of focussing on the project when everyone would rather be looking at portalofevil.com. If your team decides to move to somewhere else, say, a bar, for a few drinks to help th brainstorming process, don't pick a sports bar, a location with TV's, people who are hanging out for fun, or anything else distracting.

Don't slack off on test cases. Even if you think you've made a test case to fill every conceivably displayabe node of your n-ary tree display, you're still not through. Mix up the object types, and don't depend on strings as sample data of nodes- that's way too slack, and will cost you later on.

This may be a personal preference, but when designing a UI, start off simple, get it running, and THEN throw all the pretty bells & whistles on top of of the working foundation. The corollary to this is don't start on the simple ugly UI version too late or you'll end up turning in a VERY ugly UI.

Thorough CRC cards & UML diagrams are VERY useful, but ONLY after much rigor is put forth in listing all services & attributes. If you're successful with this, you and your teammates won't get screwed over your code using selectedSource: vs. selNewsSource:, or any other confusing stuff like that. CRC cards are incredibly boring to do (so I suggest doing them at a bar), but really prove to be a big timesaver later on in the coding phases of your project by avoiding confusion. Slack CRC cards & UML are about as useful to designing your project as UML & CRC cards made after you're through coding.

Never hard code initialization/accessor/modifier algorithms for dynamic data when iteration is the right thing to do! Not only are you going to annoy your teammates (grrr) when they have to rewrite your bad code, but it's bad style, and an iterative loop is less code anyways.

Kyle Randolph

Kyle, could you please clarify your last 'surprise'. i.e., post some bad code, then some good code? Matthew Wolenetz

I'll get around to it.... no squeak on this machine.

Anyways, more surprises.
Let me reiterate how important proper implentation of this CRC stuff is. My group sat down one night and rigorously (Nick Bronn style?) went through our whole design, anally noting every detail of all classes. Doing this as a GROUP with all 3 of us giving input and minimal distraction, I'd say that the task proved to be a success, and not only that, the new, improved CRC stuff we now have is proving to be a very useful tool (I must admit I thought the concept was lame before). There's a few cool aspects of the CRC thing, and perhaps it'll sound a bit more convincing coming from my student-witness report ranting than some silly pink textbook.
Lifechanging? No, but I'll remember this when future large OO projects come along in life. Really, it seems insulting to everyone's intelligence to need to resort to a stack of index cards that state what seems to be the obvious, but that's not the key. The true value of these is only found when done properly, with all of the team interacting. Let's see why the second CRC thing was a success:

Thorough. We stepped through all scenarios, pulling the CRC cards involved and updating them on the fly when necessary. The first time we did these, each person picked 8 or so proposed classes of of our jot list of 2 dozen or so candidates. This approach did in fact make CRC cards seem pointless, but hey, no wonder, we weren't doing it properly. Our first set of CRC cards were incomplete, incompatible with one another, cryptic, and... well, they weren't worth the less than adequate effort put into them.
Precise. We were all discussing the responsibilities/collaborators in detail, with one person writing. With one person as the scribe, there was one distinct format that all of the cards adhered to, and should make debugging code MUCH easier later on in this design process. The first time, class names, method names, argument headers, functionality, and other things were all often incompatible with one another because each of us went off & coded our own stuff from scratch.
I can't remember my third reason now. perhaps later. But the important thing here is that the investment of adequate effort in to CRC cards definately pays off with better organization later on.

Now, we have UML. UML seemed alright, we used Boost, a simple UML kinda tool. It's not the nicest piece of software in the world, but it does you right aside from the inevitable tediousness of typing all the info in. UML is nice, it obviously helps visualize layuot of medium-to-large OO designs, but the CRC cards are still far more helpful in my opinion. You would think with 20something classes, a UML diagram would be great for understanding class relationships. There's a problem here, maybe I'm just not hip enough to Boost or something, but our workspace for our diagram was quite small, resulting in a diagram that was WAY to crammed together, and the lack of readability defeated any hopes of a better visualization of our class layout. This kinda kills the hopes of doing the UML layout of a large system properly in Boost from what I've seen. Perhaps rational rose would work better. All boost needs is the 2.4 square mile layout or whatever of that Sketchpad thing and it'd be cool.

Okay, so then there's the group thing again. I don't like working in groups, and I don't think my partners do either. So here I am in a situation where neither I or my teammates are inspired, thoroughly interested in the subject matter, or prepared to work as a team. I am in a group with 2 friends of mine, which makes it more personal when someone slacks off. Easy solution? Let the stress kick in, and everything falls into place a bit better. Working with friends makes it harder to get people organized and do their part, but after stressing, it becomes easier to correct group difficulties.

On slackers: there's too damn many of them in the world, and you're bound to have one in your group or some other group project(s) in life. If you're a slacker, I'd like to slug you. The rest of your teammates are just as uninterested, bored, restless, and wanting to go home & do whatever as you are. A group project should imply close to equal effort on everyone's behalf. There is no justification that you can magically conjure up for leaving group meetings several hours early, writing poor & sloppy code, or avoiding work. Sometimes, when everyone takes on

Link to this Page

Using this CoWeb last edited on 4 January 2006 at 7:08 pm by penguin.cc.gatech.edu