View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Squeak Busters

Members of the Team
  -JD Courtoy
  -Peter Reale
  -Arun Sharma


Welcome to the Squeak Buster's Cases page. These cases are meant to help you in the design and implementation of any future Squeak projects you come up against. Learn or just rip off our code–it's no skin off our backs. =]

There were seven Milestones in total (2 of which were purely mono-e-mono and merely set the stage for what was to come). Milestones three through seven represented the bulk (really, the extent) of what would eventually be a fully realized Squeak implementation of the commercial app, Quicken (albeit probably Quicken 0.1b).


The purpose of this project was to create a realistic monetary account system for creating/removing/updating accounts of all types, complete with web-enabled functionality and time-based report tracking. Though our UML may seem to prove contrary, this wasn't as daunting a task as originally deemed.

The system was to eventually have the following attributes:

Gleefully, or rather caffeinated, our team successfully completed the entire assignment in under two days (no, just kidding)–but, interestingly enough, did manage to do it in under three months. Hey, we programmed this thing in SQUEAK... though an amazing development environment, I think the abysmal lack of decent documentation (which deservers a rant in its own right) is a testament to the fact that design matters. I know for a fact that if we hadn't designed this thing correctly, first thing, we would have been hard pressed to deliver a decent app in six months.

/Useful Tidbits/

Project Design
First major point (let me underline this): DESIGN FIRST. It will save you soooo many headaches in the long run. Though I know this course is titled Object Oriented Programming and is hell-bent on teaching you proper design methodologies, you would be well advised to look up 'Design Patterns' on the internet before even attempting your project. Proper use of good design methodologies will save your brain countless meltdowns. I tell you, we only spent one all-nighter on this thing (that's far more complimentary than in any of my previous CS classes); and it really ups morale when you actually get things accomplished on time.

Second major point: REUSE. I know that the most logical thing doesn't always end up being the best practice; however, this class will not 'doc you for reusing code. In fact, you may gain extra points if you can reuse someone else's existing code. I can almost guarantee you that you won't find another person out there who's written the program you're attempting (yet, if you can, more power to you if you can figure out what they did in their undocumented hack attack). Still–there are decent developers out there in the Squeak/Smalltalk scene that spend the time to write up documentation. These people should be kissed and smacked lightly on the butt. Though, my point remains. Code re-use is like having your headaches placed in someone else's head... gone are the days of CS 1 and 2's wheel of reincarnation; here are the days of actual programming practices.

Other, less significant, almost minor, but not to be taken lightly, points: RESEARCH. Though you'll probably forced to do this at some point, doing it as soon as possible will allow you to focus more on my first point, design, while tying in my second point, reuse. Also, always remember to practice safe sects and don't give in to the peer pressure to hate squeak. Though many secular movements of hatred towards Squeak arise from this class, all of them will hurt your morale and fuel the fires that will consume your soul (or grade, whichever).

Development Dogmas
  -Write clean, manageable code. There's a utility built into Squeak that will let you add code colorization/formatting to your squeak code with the push of a button. I suggest either using that or manually putting in spaces and tabs. Squeak does not, by default, require specific spacing or tabbing rules (neither do most languages); however, since Squeak is an IDE, it would be nice to default to one of the auto-tabbing/colorizing modes (!).
Here's a screenshot of Squeak's Source Formatter

  -Document! I don't know how to stress this enough. There is rarely documentation in squeak source code. I suspect this is mainly a bi-product of its not-so-readily-apparent class documentation button. This does not mean that merely putting strings of English words in the Class Documentation will have any affect on anyone's coding; however, it does guarantee a quicker return on the research side of things. Don't forget to comment confusing methods, either. Squeak is a typeless language–let's not forget to remind future developers what the parameter (message) 'aMessage' semantically is... it's difficult enough writing SUnit tests; you don't need to spend an hour trying to figure out how to create MockClasses that will work correctly with someone else's code (I'm looking at you #HttpResponse... apparently whoever wrote Comanche didn't hear my sobs after 2 hours of trying to unit test some code). Which brings me to my third point...
Here's a screenshot of Squeak's Class Documentation Frame

  -Unit Test as soon as possible. Unit testing is one of the last things you learn in class (in mine it was, at least), but one of the more important aspects of keeping bugs out of your code. Write them as soon and as often as possible. Though I know it's nearly impossible to crank out silly unit tests every ten minutes (they seem to take a proportionate amount of time... say... 100 times longer than actually writing the code), but they have real potential for saving you when you're up to Milestone 6, change a few lines of code, and everything breaks.

Development Tools
When developing, there's nothing better than having good tools to use. These are my personal recommendations. We used them in our project, and you could possibly use them in yours (depending on need).

Group Management
Okay, first of all... do not, I repeat, do NOT start meetings late. It's much better to have an early meeting, if at all possible, than a late meeting. And by late, I mean time of day. Getting together at, say, 9PM means you miss CSI:Miami and a whole heap of useful time. Getting together at, say, 2PM means you get the meeting out of the way and you're able to work on what you talked about that night. Besides, caffeine works better when you're coding... not jabbering (you'll believe me when you're at the CoC late at night and stop to listen what other people are actually saying).

Second, make sure everyone gets a say in what you're working on. There's nothing more frustrating than having someone write conflicting code... or code that doesn't work... or code that's invisible.

Third, Share Code. If everyone's on the same page and everyone's updated... low grades are a lot less likely to happen. Cohesion is not simply a programming term–broaden it to team cohesion as well. Two heads are better than one only if they're not pointed at each other and breathing fire (old chinese proverb).

Fourth, Changesets are Divine. It's difficult to get CVS up and running (even more so if you don't know what I'm talking about). Take my advice and use changesets. Even better, create Project FileSets (Here's a picture of the browser). These allow your team to easily import code without destroying what they've been working on. If need be, just roll-back... ahh... what power!

Fifth, Stay in Touch. Though you may dislike your partner (which I hope you don't), your common link throughout this class is your grade. Keep in touch in any way possible... when you're working on things, tell someone... when you modify the design,
tell someone... when you need to go to the bathroom, just go... and don't raise your hand to speak in groups, that's just embarassing.

Sixth, Schedule Appropriately. This could also have a subpoint: Stick to the Time Frame. Though in the development world you may be able to push a release date back (...sigh...), but in this class you've got THIS (pulls arms out from sides) much time... and that's it. So, deal with it and make time for silly things you may not think of:

And, lastly, make sure to Maintain Responsibilities. Flexibility is also key, of course, but thinking through all scenarios and creating a flawless design first off makes coding one one-hundredth the task. What follows from design are each group member's responsibilities. Following your original guidelines will help maintain unity within the group as well as unity in your own mind, grasshoppa.


3: Design System
4: User Interface Design and Implementation
5: Monitor/Track stock activity from Web
6: Handle basic queries on system
7: Web-Enable the application

/Additional Information/

Links to this Page