Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Bears with Lightsabers
Hello everyone. We are a group who inexplicably managed to get great grades on our milestones despite an atrocious style of teamwork. What follows will shock, offend, and maybe even enrage the professors and TAs who work so hard to instill in us good programming and teamwork practices. To all of you, we are sincerely sorry. To future students reading this page for help on your milestones or just those looking for some advice on life, enjoy the show...
This class is easy. There, I said it. Compared to the other CS 2000 level courses that is. I'm sure if an IE took this class he or she (funny how I don't have to make that "or" qualifier for CS majors) would cry. Taking CS4400, I've seen just what kind of rigor IE majors go through :-). But for us hardened by the CoC's coursework, we should already be well prepared for this course. It's not a "weedout" by any means, so don't go in dreading it. The milestones aren't ridiculously large or impossible, but you will learn how to navigate other people's ridiculously undocumented code - a skill very useful for your future career. You'll also be on the bleeding edge of a developing language, which is somewhat exciting, or frustrating depending on your view.
Here's a tip: Take this class after 2335 (or whatever it may be numbered in the future). CS2335 teaches you a lot about design and group work, so when you take 2340 its basically all review. The milestones in this class are graded 50% on design, so you should be able to count that as a full 50% closer to an A.
How To Succeed In CS2340 Without Really Trying
Note: To Jeff or whichever TA is grading this, that title is a joke. We really did try and fully deserve the excellent grades we're sure to earn!
Other cases pages will tell you to communicate regularly with your group, hold timed meetings, start early, go to class, etc, etc. Boring! Everyone knows that's the ideal way but not the actual way, and that's our intention of this cases page: to bring you the actual. Some groups will say that they regret not meeting and not planning more and not coding more, but we have come to the realization of what is required to succeed. We never talked to each other about Squeak until we were coding, never held meetings except for doing the prelimimary design, and we didn't even code as a group until the night before every milestone was due. Furthermore, we coded (not physically together, but in the comfort of our own homes) and talked online using the magic of AIM chatting. Sure it made us pull the famed "allnighter", but which CS major doesn't do that on a regular basis? We were able to get A's on every milestone except one (where we got a B), so it seemed to work fine for us. Were we probably incredibly lucky? Maybe so, but luck can get you places. Look at our current President for crying out loud. I digress, but this leads us to another tip:
Tip #2: Demo every single milestone with your TA. A required demo is usually for the design milestone and for the last milestone. But you're a rebel! Demo every single one. Why? Because when you can show your TA what worked, it will get you more points than having your TA figure it out through the coldness of a README file. Secondly, when things don't work, you can show your TA just how close you came to it. You will then earn more partial credit for it than otherwise. So just spend half an hour every two weeks to meet with your TA and demo your milestone. You'll keep them company during their office hours, and you'll get better grades on your milestones. Everyone wins!
Pulling those all-nighters can be tough, especially towards the morning. You have to avert any possible code disasters. What better tool to use for code coordination then CVS? If you already took CS2335 like I told you to, then you know and love this tool by now. Unfortunately, unless you're an experienced Linux hacker, Squeak is best used with Windows. How did we get around this, you ask?
Another tip: Use Tortoise CVS. It's a great little tool. To make sure it plays nice all the time, we found it best to change some preferences. Once installed, right-click anywhere on your Desktop, then choose CVS->Preferences. In the Main tab set the Progress messages to loud because the Quiet option isn't very compatible with CVS servers. Then in the Advanced tab, choose to use Unix Line Endings. The horrors that occur otherwise are unspeakable: every bit of code in your project ends up mysteriously double-spaced, and you'll have serious CVS conflicts. There's also a Squeak tool downloadable from SqueakMap called DVS that's supposed to make .st files "CVS friendly". Boy do we have an amusing story about that...
So, the first code exchanging system we came up with went as follows: Make one big .st file, filed in and out using DVS, which everyone would use. This led to total chaos and disaster (tm). Its a good thing we weren't together in the same room when the meltdown happened, because it might have gotten really ugly. Code started reappearing and disappearing without much rhyme or reason. Blocks of code. Hours of work. So whatever system you come up with, please don't use the one-big-.st-file method.
To fix our problem, we decided to file out individual .st files (one per class) and use those. We dropped DVS because our experience with it was so negative that the very thought of ever using it again became blasphemous. Using one file per class makes sense, because usually one person will be working on a class at a time, even if we're all working on the milestone at once. It's not the most elegant solution, but it never gave us any surprises, or any conflicts for that matter. Look at other Cases pages to see how to use changesets as a way of code coordination.
Our Team Website
For some random reason, one of our group members decided to make a group website. He likes to be distracted, so my theory is that he did this because maybe he feels HTML is more fun to code then Squeak. I tend to disagree because Squeak is the greatest language ever created! I should mention now that my name is Luigi Montanez and another extra credit point to my final average would be great. Anyway, I'll leave the description of the website to its creator, Mr. Joe Yeager.
Hey all! How are you today? Let's get right to it. I spent about 4 1/2 hours one night and threw together a group website. The idea was simple: have a place where we can get development code if we do not have the resources at our disposal to get it from the repository. Also, we could get old milestones code if needed. I spent a couple hours here and there keeping up with the site despite never using it. I figured it would come in handy at least one or twice. I also thought that I would put the group's cases pages on it. Lemme tell ya, don't make a website for your group. You will not need it. I decided recently (towards the end of the semester) that I do not want to host that site for much longer after the class is finished, therefore this cases page must go on swiki (try to forgive me if the site is down when you read this...). That's just about all I have to say on that matter. Time for what everyone is waiting for...individual milestones!
BwL ECoDE Cases
Links to this Page