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

Team SashKeDa

Cases and general advice by Dasha, Sashmit, and Kevin

Introduction:

Hello and Welcome. These pages contain information about our design, implementation, and, of course, Squeak.
Back to the top
If you are one of those people who likes to know why and how things work (which, by the way, is a tremendously useful trait to have in this class), feel free to dig through the included code. Most of it is well commented, the rest is really self-explanatory. By downloading in steps (milestone at a time), you can observe the gradual progress and growth achieved by the team. And as for some active browsing, most of our classes have excellent class comments with bits of code that you can test simply with "doIt".
Back to the top
On another hand, if you're simply looking for a quick demo or a peek at our code, downloading the latest submission (M5) should suffice. It would also be worth your time to check out the cases for each individual milestone at least for the key points.
Back to the top
...before you download or, even more importantly, run our code, please read the instructions carefully. You can find detailed run/download instructions for the milestones on the respective cases pages. Some brief comments may be found in the README files included with each archive, and as I mentioned before, class comments can also be helpful.
Back to the top

Team Work:

The team name is quite simply a composition of the three of our names, Sashmit, Kevin, and Dasha. The way we came to be was also fairly unoriginal, we met through the class newsgroup (git.cc.class.cs2340). I had known various people from other cs courses but I made the mistake of waiting too long before taking any action. By the time I was emailing people to be in my group, most of them had already gotten together with other people. Which should be a fair warning to you, newbies, if you're reading this in the first week(s) of the course. Be proactive, do not waste any time, and most certainly do not postpone finding a good team.
Back to the top
This is a design class, and putting forth the energy to develop a good design will pay off. Trust me! When working in a group environment, designing software can be frustrating, because there is no “right” way to do most things. For this reason, it is probably a good idea for each group member to throw their egos out the window, at least temporarily, while designing the group’s application. “Every good design is not the best design and the best design is not the only design.” ((c) Kevin Legette). Understanding that there are many different ways to reach a common goal makes it a little easier to accept the ideas and design proposals presented by each group member. This understanding should also make each member more willing to contribute their ideas with little fear of that idea being rejected. We were fortunate enough to agree on a design that required very little significant changes throughout the course of the semester. We did need to add variables here and there, and also added a few additional methods to our main classes, but ultimately our design was able to support expansion and increased functionality with little to no changes in the overall design structure.
Back to the top
The importance of version control really cannot be stressed enough. We started using Monticello about halfway through the semester, a change that made code integration much easier. Until that point we were endlessly exhchanging changesets (.cs) or fileouts (.st) and kept getting confused in versions and sometimes even overwrote a thing or too. However, if you don’t spend some time to actually learn its usage, capabilities, and limitations, you may find yourself doing more harm than good in the early stages.
Back to the top
Some Important Differences?
The first thing to note is that though Monticello offers many of the same features we’ve become familiar with through other CVS systems, especially those offered through the Eclipse and Netbeans IDE’s, there are some differences in terminology and functionality that should be noted.

The process of adding your changes to the repository in Monticello is called a “save”, rather than the “commit” many of us are accustomed to. Another difference is that instead of “synchronizing” with the repository, what we want to do is “save” our changes to the repository. One neat thing about Monticello’s interface is that when you are viewing your project on the repository, it displays a list of all the most recent changes, allowing you to look at everything that is different from your working version. Though this feature is available in other CVS systems, most of these generally only show the most recent version of the project, requiring extra steps to be able to readily access and view version histories. Though it is very easy to view differences in code versions, it is less intuitive to actually merge these changes into your working code. When the changes have occurred in a class that you haven’t been working with, merging the repository code is harmless, because there is no worry of overwriting important changes. Things become a little more difficult if you want to merge repository changes into a class that you’ve also made important changes to. From what we’ve experimented with, it seems that you either have to keep your local changes or accept the repository changes (or overwrite your local version), a troublesome situation any way you look at it. There may be a way around this problem, but if there is, it should be much more apparent to a new squeak user.
Back to the top
A few lessons:
  1. Always refresh and load or merge the repository changes before you start making changes. This ensures that you don’t miss any important changes, prevents duplication of work, and is much easier for your team to merge your changes (because you’ve already merged theirs!).
  2. Learn how to use the merge feature before you blindly click the merge button. It’s tedious and irritating trying to revert back to your old versions after accidentally overwriting all of your changes with the repository version.
  3. Be sure you haven’t broken anything before you save your changes to the repository. We’ve all had moments of perceived greatness where we “know” that what we are changing is correct and won’t harm any of the other stuff. The bad thing is that we’re not always right when we have these flashes of greatness. Don’t create more work for yourself and/or your team by saving incomplete or incorrect code to the repository.
Back to the top
In general, when it comes to team issues, be it division of responsibilities, scheduling a meeting time, emailing a TA to set up a demo or dealing with problematic teammates, action is essential. Procrastination, never-ending juggling and prioritizing between classes will always be there and no matter how nice or hard-working or responsible you and your teammates are, you all need to keep yourselves in check. Make sure that progress is real and not imaginary a la "90% rule" (hearing/saying things like "I'm almost done", "just a little more left", "just a finishing touch away" over a week+ period of time will lead to a sleepless night at best, a pathetic grade at worst). Design first, that will give you a chance to come up with some goals and deadlines (and will -definitely- score you some points with your TA's, after all, it is a course on design), and stick to them.
Overall, just be aware of team progress and of any problematic behavior that might be going on. Having said that, try to enjoy yourself, the course is quite reasonably paced and if you keep your focus, you will be able to keep your sanity and what's even more important, SLEEP!
See also Tips for working in groups
Back to the top
Please note that I thought this to be so important as to devote a completely separate section to it. Demo-ing your projects is absolutely essential! Whether the entire team meets the TA or just one person, demo time gives you an opportunity to show the project in the best possible light. Even the most detailed README file and the most intuitive user interface could never substitute a real-life person willing and able to answer any and all questions and deal with problems that might arise during the demo run.
Back to the top

Cases and Downloads:

Assignment Description/Cases File(s) for Upload
M3 "Rough" SqueakPoint, with Layouts/Templates/Widgets In a .zip archive
M4 "Polished" SqueakPoint with Extra Feature and a Presentation In a .tgz archive
M5 SqueakPoint goes Global! Networking with Comanche In a .zip archive|-|Presentation

Back to the top

Howtos:

Here are some howto's that might be informative for you, written by us:

Back to the top

Word of Advice:

The sheer volume of information contained within these pages and their contents as well as this Swiki in general may seem intimidating and perhaps even unnecessary, but the best advice I could ever give you is to tell you to get yourself acquainted at least briefly with everything. Yes, I did say everything. How, you wonder? Easy! By searching the Swiki, Squeak, and the web (repeat after me, "Google is my friend!").
When you just begin working with Squeak, you may be apalled by the seemingly lacking documentation, comments, and that lovely API we have all grown to love and cherish. However, in such assumption you would be completely mistaken because there is a wealth of documentation around and it is WAY better than that stuff you had to literally dig up and decipher about Unix and/or C (does any one else remember the 2110 TA chant "read the man pages"?). You can search the student cases (and browse their code, learn from their mistakes), the countless tutorials, should I even have to mention Google? And you will most absolutely certainly and totally have to search the Squeak library. Whatever project you may be working on, do be sure to check all these pre-existing resources first. The great thing about Squeak code is that it's very readable even in the absence of good comments, the search functions of the MethodFinder and SystemBrowser (or WhiskerBrowser or any of their counterparts) will make browsing through Squeak libraries even more intuitive. In other words, USE USE USE. Use what already exists to save time and to help you do more with this class and the projects.
Back to the top
Please also take a look at our General useful Squeak stuff HOWTO

Useful Advice:
Back to the top
In particular to networking:
Please also take a look at our case on Dynamic Content with Comanche
Back to the top
Do whatever you have to do to remember these links, tattoo them onto your skin if you have to, it will be worth it once you realize how many sleepless nights and moments of panic and stupor they save you from.
Honestly, I cannot emphasize enough the fact that these links are truly your best of friends in this class!
THE Squeak Swiki An essential source of tutorials, how-to's, and documentation
Terse Guide to Squeak Print it out in multiple copies

Other useful resources that you should definitely visit on a constant basis:

Recent Changes Never miss the latest TA/Prof announcements or other events of this Swiki's life
Criteria for Good OOA/D This is a design class, need I say more?
Midterm and final exam review page Again, pretty self-explanatory
WWW.GOOGLE.COM hmmm... no comment
Back to the top

Links to this Page