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

Collaboration and Visual Works - Jeff Drasher

As you'll find out, Smalltalk is a language without a large user base and so does not have the most up to date IDE, or a significant amount of documentation. Visual Works has not had a major overhaul in quite some time, and as such still has a UI designed for the 1970s. While learning a purely object oriented language such as Smalltalk can certainly be fun and challenging (in a productive way), fighting with Visual Works(VW) will never gain you anything. Here are some tips on to work around Visual Works and turn your Smalltalk project in a great collaborative learning experience.

Visual Works set-up

Learn the various windows and how to navigate the IDE early. It is an unfamiliar layout and it will take you time to find all the useful features (like the transcript, do it, run it, etc.). Actually pay attention during the initial "How to use VW" lectures. Understand image files, how to revert changes quickly, and how to file in/out code.

Image files and filing out

Our team spent more time re-working our code after merges than on some milestones. For groups using both OS X and Windows, using the same image file is difficult. If an image file taken from a Windows system is opened in VW on a Mac it will show up as "decompiled code". Because of the specifics of implementation on the two different OSes, VW won't be able to recover your comments or variable names, so it will make them up. This makes your code, much, much harder to read, even though your methods and classes will remain intact.

Third-party tools

In the professional workplace, there are many tools to aid in team collaboration. Our team found BaseCamp particularly helpful. It allowed easy task assignment and communication. Even something as simple as a Google Doc is far better than only using IMs and emails.

Communicate in person, in/out of class, and online

It's not just a good idea, it's an absolute must. Communication is the key to any team oriented project, and with this class, early, frequent communication can save you lots of time later on.
An example of poor communication:
Billy has been working on his user classes (Student and Professor) independently all week long, and plans to have them ready for his demo tomorrow. He pushes his changes and calls it a night. Sally has struggled with the implementation of logging in. At the last minute, she changes the process drastically, and due to some poor design decisions, Billy's classes are broken. During the demo the next day, Billy is baffled as to why his classes don't work and scrambles to rewrite his code on the fly.

Beside an obvious problem like this, if your team doesn't have a clear and concise design, merging your code will become a significant problem later. Follow these common sense, but often overlooked, tips and an A will come that much easier.

Links to this Page