As soon as you have the slightest doubts about a teammates ability to produce, kick them out. It don't matter how often they apologize for not producing, it won't help your grade.
Demo your stuff. Its alot easier to explain what you did and why in person than in a readme file. In addition, if something breaks and you're lucky to have a great TA such as Ellie Harmon, you might be able to quickly fix your code and only lose a point or two, instead of all of them, because not TA, no matter how good is going to sit there and debug your code for you. If you can demo your stuff in advance to get feeback, the caveat is that you have to have something demoable before deadline. If none of this convinces you to demo, than know this: you get your grade right then when you demo. You don't have to wait for weeks to have your TA get back to you. Plus you get instant feedback so you don't avoid the problmes in the next phase.
This portion of the project was individual. We used the M1 submission prepared by Michael Natkovich when constructing our future submissions.
Michael says: "Milestone 1 was probably overall as hard for me as any of the milestones, even though looking back, it is one of the easiest. What makes the milestone difficult is that apart from doing the coding, you are also learning the language and programming environment. Expect to make mistakes when coding the first time that are due to straight up ignorance. Don't foreget as well that this milestone is worth just as much as any of the group ones, so do a good job. Plus, if you do, your code will be used in later milestones and that saves you time in having to read and learn someone else's." Top
During our semester, milestone 2 was where we got acquainted with the gui elements of squeak. For us it was a critical milestone in term of laying the groudwork. While we were told that this gui would be thrown out for later milestones, it turned out to be the gui we built on to. So again, the fact that we did a good job on this part, we were not forced to redesign and redo a new interface for later milestones, but rather we were able to add on to it.
There were several options in what we could use for our gui. You could use morphic, pre-fab, or bob's ui. We went with bob's ui. I don't know why we chose it, but I know that we stuck with it because it was simple and straight forward to use. Bob's ui is quite limiting, but if you can work within the limitations and do what you need, I recommend it. Morphic is more powerful. With great power comes a really long time in trying to figure out how to use it. Pre-fab is also supposed to be easier than morphic and more powerful than bob's ui. I don't know much about it, but there are several tutorials on the case's page from every semester. Top
For our design, we were required to use ECoDE, a pet project of one of the TA's. ECoDE tries to assist the design process by forcing consistency between scenarios, CRC cards, UML, and other tools. Though it was an interesting concept, it was buggy and supported only "a subset" of UML. Also, due to the heavy integration between features, minor design changes often had to be review ed in three places. Although ECoDE is still in development, and future versions are likely to improve, we would suggest doing design using more traditional tools. (Pencil, index cards, and a drawing program.)
UML: The class diagram was the most useful of all the design elements, when it got down to programming. I would frequently look over the diagram and figure out how we envisioned everything working, and then follow suite. If you are forced to use ECODE, still do your class diagrams in something else. While ecode generates UML for you, which is great, the UML is jumbled all in a corner. Even if you lay it out properly, the next time you open it up, its jumbled again. We got points of on it because we weren't able to show everything we needed using ECODE. We experienced no such problems when we switched to Visio.
CRC cards: I found CRC cards helpful in initially laying out how things were working. I definetly used them to build the class diagram. If using ECODE make sure to do the scenarios first, otherwise problems will ensue.
Scenarios: These I found to be useless. I'm sure if you're trying to figure out how your system is going to be run, this is useful, but when all the requirements are already outlined in the guidelines for every milestone, these lose their value in my mind. For the sake of getting points though, remember that scenarios should be in the language of the user. Don't talk about classes, buttons, servers, or any other technical jargon.
Test Plan: Testing is important, but I can't say that I utilized it that much. Although, a formal plan that I actually followed would have likely reduced some errors that I encountered when demoing.
Timeline: The most useless, because we never even looked at this thing while working. We set up meetings when it seemed appropriate. If things were going poorly we met more frequently and earlier on, if things were going swell, we met less frequently and later in the week.
Design was very important in our development process. While the first couple of milestones there was lots of time for, the later milestones are harder and all seem to have less and less time alotted for them. Thus the better the initial design, the less revision had to occur later. In addition, if you don't use any tools that do integration, I know we didn't, then you need to have your classes be fairly independent, meaning no god classes that everyone in the group needs to edit to get their stuff to work. The more seperate the classes are the more delineated everyone's responsibilities are as well. If a person is given a vague assignment like code the parser, they might not know if they do just the parser, the gui interface for the parser or any other extra stuff. However, if you tell everyone which classes they are responsible for as well as a general purpose of their part such as the parser, then everything will flow smoother. We had to learn these lessons the hard way.
Don't forget that design is usually worth half of each milestone, and you turn in pretty much the same thing for all the milestones after the design milestone. Thus if you do a good job the first time, you'll never have to modify the design and you'll reap the benefits on all proceeding milestones. Now if you don't give milestone 3 its proper time, then you will be stuck updating for all the following milestones, like we were. It is a huge pain to have to go back and change up scenarios, because once you do that, you have to change up the crc cards and then the UML and finally the testplan. You'll hate yourself, as we did, when you have to do this. Top
Our GEDCOM importing system is not integrated with the rest of our classes. This was not a deliberate decision. The system we (ahem) appropriated from the cases page included its own person-family-etc. classes, which were not compatible with ours. This should serve as a useful lesson for anyone intending to "save time" by re-using someone else's code: be very clear on exactly how you intend to integrate theirs with yours. It might have been useful to create "translator" or "wrapper" classes to facillitate integration without having to modify unfamiliar code too much. Another lesson learned is don't integrate on the last day, because you might find out that the code you've been handed, while doing its duty, is utterly useless. Top
Our biggest problem with regards to parsing are inconsistencies in the formatting of the results returned by the web servers. Some genealogical websites allow for extraneous information in their records; this information makes parsing very difficult. In the future, I would suggest trying to make things easier by picking web sites that use a consistent format for things like names and dates. Although many different genalogical sites exist, very few were available at no cost. (Also annoying are the multitude of sites that rely on CGI scripts or ASP to conduct searching. These require an HTTP-POST request, not a simple URL-style HTTP-GET. Frankly, I don't know how to do that.)
If you are reading this section of our cases page that means you may be having some questions regarding SUnit. While the name sounds like JUnit and is quite similiar to JUnit, which you've probably used in CS2335, it is actually simpler to use in Squeak than in Java. Just as with JUnit, SUnit is employed to perform unit tests of testable methods for every class. Whether you like using SUnit for testing or not, it is a requirement for every milestone. Thus, it is better to embrace SUnit and utilize than to half-heartedly put it together and waste your time.
While I never found much use for JUnit while taking CS2335, I have come to embrace it more and more as the milestone wore on. Unlike in CS2335, where you make a design and then proceed to code everything at once, in this course, you start with a foundation and build the rest of the program on top of it. Meaning it is critical to make sure the foundation is working before you add on something new. With every additional milestone, I was forced to either add on to previous classes. My constant fear was that by adding something new, I had broken something from before. With SUnit, I was able to alleviate my worries by simply running my tests for all the previously established functionality.
How To SetUp SUnit
When doing M1, I had no clue initially now to setup the SUnit tests, because it was late at night and there wasn't much mentioned in class. I had to resort to looking through the case pages and just downloading someone else's SUnit tests and copying what they did. For that reason I decided to do a little SUnit tutorial to help the clueless, like myself, during M1.
I'm assuming you have some classes written by the time you want to start your testing. They should look something similiar to the FooBar class and helloWorld method I have in my example.
Add an additional category for the corresponding tests if you would like, or simply add the classes on to the already existing category you have. It doesn't make a difference one way or another, but for this example I'm going to have them in seperate categories.
Select a name for you category, or simply skip this step if you're going to just stick in with a pre-existing category.
Make sure to sublclass from TestCase, instead of Object. Name your SUnit testing class whatever it used to be called with Test appended at the end i.e. FooBar –> FooBarTest.
Now you are ready to create your test modules. You need to have a setUp and tearDown methods in your test class. You don't have to have anything in them, but you must have them. I typically used setUp as my initialization class for the instance variables I would be using throughout the testing. On the otherhand, tearDown I never used. Make sure to have your method names start with test i.e. helloWorld –> testHelloWorld. When writing the tests, the two methods I tended to use were deny: and assert:. If the two items being compared are equal, then assert will evaluate to true, but if the two items being compared are not equal, then deny would evaluate to true. So in the example below, assert is true when 3 = 3, and deny is true because 3 != 2.
When you've written your tests and want to run them to see if everything is working or not working, just open up your workspace and type "TestRunner open." and select "do it".
The gui below will pop up (although without the green). Select a test case and press "Run" or hit "Run All". If everything evaluates properly the gui will say that you passed and turn green as it does below. On the other hand if it doesn't pass, due to your tests not passing, it will turn red.
Well that is my tutorial. Hopefully, if you have read this far, my tutorial has been of some assistance to you. If not . . . well . . . sorry. Top
Link to this Page
Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu