Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
CS2340 Survival Guide - Matt Shorrosh
CS2340 Survival Guide - Matt Shorrosh
CS2340 is a great introduction class to many important concepts that will help you in the future when dealing with teams, software development, design decisions, and many other object oriented related things. This is one of the first CS classes that deals with working in a team and this can be really hard to cope with it at first without proper team communication and cooperation. The class also introduces the some say "esoteric" language of smalltalk. This guide will try to help give you some advice/tips to tackle these dilemmas.
o Surviving working with a Team
o Coping learning a new language
o How to attack the Milestones in the class
Surviving working with a Team
This semester I joined up with a random team not knowing any of my partners or their skill in smalltalk or programming at all. The first thing you need to recognize is your team is going to have varying skills in programming and adaption to a new language. It is important to recognize though that there is a difference to someone who tries and can't do it and someone who doesn't do anything because they don't try. If you have a partner who does nothing the professor allows you to submit a peer evaluation at the end of the semester. You are also allowed to talk to the professor in private and solve any problems as soon as possible is recommended.
Communication is key to working efficiently and solving / identifying problems. To communicate as effectively as possible I recommend setting up weekly meetings with your group. This is not totally out of line as you will basically have work to do throughout the semester and it very very important to have communication within your team. I also recommend setting up a Google Group (groups.google.com) here you can setup a msg board, share files, setup a mailing list and several great group features. I have used this in every CS group work I have encountered and it works great.
Although it is important to have good communication sometimes someone has to take initiative. This may have to be you. If no one in your group initiates any conversation or meetings or gets the group moving step up. This is an important skill to gain from this class is initiative. In my group it really took me sometimes calling people and emailing to get things going.
Coping learning a new language
This will vary from person to person depending on background experience and other factors. The important thing in this class is MAKE sure you can do the individual smalltalk assignments. If you fail this you will be behind when working with your team because you will not have anything to offer. Spend time working on M1/M2 and go meet with the professor or TAs if you need help. If you get good grades on these first two milestones you'll be set up better for the remaining ones.
As far as smalltalk goes it is actually not as hard as people seem to make it sound. Everything is an object which is an important thing to keep in mind. The only way to pass things between objects is by messages. To pass data between objects you need to pass a "model" of an object. Also I recommend getting familiar with the collection classes as they are used very often. The best thing to do is view the sample code given to you by the professor and the previous projects available on the smalltalk postgresql server. Those two sources are all you need to find good examples of code.
How to attack the Milestones in the class
The first two milestones were covered in the previous section. This leaves the following makeup of your grade:
Grades are based on:
2 Exams (40)
o Midterm - 18%
o Final - 22%
o M4 Individual UML - 6%
6 Group Project Milestones>Fall 2008 Project Milestones (44)
o M3 Domain Design -10%
o M5 Application/Gui Design - 10%
o M6 Domain Implementation - 6%
o M7 Gui Implementation - 6%
o M8 UI Evaluation - 7%
o M9 The Twist!!! - 5%
The design milestone is probably one of the most important parts of the project because you are essentially designing the project that you are going to implement. This is important to remember that you are going to implement this project in smalltalk (A language you aren't very familiar with). Our team got a little carried away at the beginning to create this great big project but in reality when we got down to coding it we bit off more than we could chew. I recommend going for the bare minimum design and then if you are successful in implementing it then edit your design to include more features and so on.
This is testing to make sure you can do the UML on your own. The best advice for this is to go to the lectures where the professor shows you how to do this in the visual paradigm program and explains UML diagrams. They are not very hard to grasp but it is easier to have it shown to you. Also the professor will show you how to use the visual paradigm program which saves time on your part trying to figure out everything on your own.
This is doing the UML and other architecture/design choices for the actual project. This is an important phase because this is the phase that we used to break up and split up our programming work. Remember whatever you do in this phase will probably change when you get to coding it unless you have setup a very nice design. Our group had to redesign our whole project because we had made it way more complicated than necessary.
This part is probably the most grueling part of the class. This is the part of the class where I wish we met up more in person than alone. Our group got 5x as much work done in person than apart. With people modifying other parts of code that could potentially affect yours chaos ensues if good communication is not in place. I recommend meeting at least once a week and get started early as you can on this. While you are programming the project it is EXTREMELY helpful to look at previous semesters code for how to work with smalltalk. M1/M2 are not thorough enough help to get you doing some stuff for the project.
The GUI implementation is most likely best to be done in parallel with the programming. Its a good idea to go ahead and connect the gui up to the backend so you can test your backend and your getting a majority of the code done. Splitting up the work between domain coders and gui coders isn't always the best idea. We found it better for the person who coded that domain class to do any related gui code because they were the most familiar with it.
The evaluation part is not that hard if you went to class about these lectures. It is important to edit your reports for grammar and spelling errors and have your whole team there when you write the reports. This will have your reports end up in the best quality possible.
Use the sandbox code. This was so helpful as the professor gives you an almost fully working example. If you have had any previous web programming experience you can finish this with the sandbox code in about an hour. We had to modify some things in our actual code to get this working properly but after dealing with it so much in M6/M7 this shouldn't be hard to figure out.
Best advice: Review the exam reviews on the wiki! This and go to the review session before the test and you should be good to go for those. Also on the final you can bring a piece of paper with notes written on it. Don't put off studying for the exam though, the final was actually harder than I had anticipated.
Things to pull from this guide:
How to work/communicate with a team
What to expect working with a team
Advice for the Milestones
Adaptation to a new language.
Good luck in CS2340!
Links to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu
- Most Helpful Cases last edited on 11 December 2010 at 4:57 pm by res-128-61-90-36.res.gatech.edu