Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
2006Spring: MusExMachina: Cases: Team Productivity Practices: Standardized Platform
We jointly created a squeak distribution customized for our needs, and required it's use in development
We jointly participated in creating a single squeak image we all would develop under. We agreed on things to the finest detail (like how squeak appears when you first load it) to channel team efforts and limit problems varying between squeak running instances. This image also included related items likes picture files, which provided us with some consistent resources to test our project with.
- Creating a joint squeak image was a little treakier than it sounds. Although we eventually agreed on a group of common tools (in particular Montecello and Shout!), the actual layout of the initial windows was a bit annoying. One of our members (namely me) would always kill all the initial windows in the squeak window. Of course, with a little more communication, and less clutter we would have easily reached a better compromise.
- Despite the fact each member ends up tweaking the joint image, having everybody start each coding session with the same core image was critical. A lot of different things can go wrong in a platform users have recently begun working with. Without a consistent Squeak image, it can be tricky for two different members to trace and examine a bug that only "shows up" in one team member's image. A specific example is when I thought we had something wrong with the XML parsing. Because we all used the same image, me an my team member were better able to do a quick pair programming session to decide whether the props or xml was at fault. Futhermore, when a team member's image does get corrupted (which happens every few minutes) it is a time saver to have a clean, stable, and useful image that can quickly grab and restart with.
- A side effect of requiring the use of a joint image is accountability. By providing everytime member with an image that you know work with the current build of the project, you can invalidate any excuses that sound like "my image keeps crashing," or "I don't have that problem in my image," or "I haven't found a clean image yet." As always, fewer excuses = more accountability = more time to get work done.
For the curious Squeaker, here is the image we used, which used the following:
- Shout. We used Shout! workspaces because of its lovely syntax highlighting
- TestBrowser. We used TestBrowser to run our Sunit's all at once and Lint to check for buggy code
- Refactoring Browser. We installed a refactoring browser to help us quickly reorganize all of our (meaning my) messy code
- Preloaded Monticello Configuration. Finally, we had the settings for the Monticello browser preloaded, so that the we could immediately download the latest revision without having to remember silly server settings or passwords. (Our private repository information has been removed from this image).
- Squeak Archive. Should one find the need to install additional stuff for Squeak, the option to do so is available. The member of our team could then re-release the image to our team.
Here is a copy of our team distribution files: mus-ex-machina-image.zip Note: This is released for the 3.7 Squeak distribution. We hope our suggestions will be adopted and incorporated into course materials (as an enhanced option to complement the currently released image), securing its maintenance for newer Squeak versions.
For the proactive Squeaker, please encourage Squeak developers to update their projects.
For example, there is a package called "BrowseUnit" available on SqueakMap. BrowseUnit integrates SUnit development, method stubbing, and refactoring all into the current browser. One of our team members has seen some screenshots and saw a significant advantage in the ability to quickly switch between coding a method and automatically going to its corresponding SUnit. The only problem with BrowseUnit is that it hasn't been updated for our version of Squeak. So for projects like "BrowseUnit" or any other useful (but incompatible) project you find lying around on the internet, consider sending the developer a polite email like the following, and they might (or might not) help you out:
To: "'Romain Robbes'"
Romain Robbes wrote:
> Hi Roland,
> What is the problem exactly? Have you tried to load it or was it
> only based on the description given by the package loader? (In that
> case, I have forgotten to update it ... so it can still work).
I'm using Squeak 3.7 and when I loaded in BrowseUnit, I didn't get any of the additional browser buttons. I tried tweaking with it, because there was something I could toggle in Preferences about addAdditionalButtons or something, but that didn't help either.
Do you want to know where I got my VM? I got it here-
I'm using the Georgia Tech squeak distribution. So a lot of students can benefit from this package. =)
> should try the latest version (BrowseUnit v4), which depends on
> Services-All (this package depends also on a few things, this is
> mentioned in the release).
Thanks for the tip. I loaded in multiple versions of BrowseUnit that I found (one was a ChangeSet the other a filein, and still didn't get the functionality).
> Tell me if this work this way.
> I will do an updated version for squeak 3.9 soon, but I have been
> distracted by a lot of other stuff lately.
> Anyways, thanks for the feedback,
Link to this Page