|
|
|
1. Name
|
| | Brad Dodson |
| | | 1 (8%) | |
|
|
| | Derek Sessions |
| | | 1 (8%) | |
|
|
| | Felipe Serrano |
| | | 1 (8%) | |
|
|
| | Aaron Cottle |
| | | 1 (8%) | |
|
|
| | Hubert Lee |
| | | 1 (8%) | |
|
|
| | Yuan Gao |
| | | 1 (8%) | |
|
|
| | Kevin Le |
| | | 1 (8%) | |
|
|
| | Jee Yun Lim |
| | | 1 (8%) | |
|
|
| | Sohum Misra |
| | | 1 (8%) | |
|
|
| | Corey Shaw |
| | | 1 (8%) | |
|
|
| | Rae Alty |
| | | 1 (8%) | |
|
|
| | Dave Eng |
| | | 1 (8%) | |
|
|
| | Matt Freeburg |
| | | 1 (8%) | |
|
|
Total: 13 |
2. Milestone Status: Gains made (If possible, include hyperlinks to what you mention here.)
|
| | We've done a lot in the past week in a half. A whole lot. You can read my milestone report (which I'm going to write right after this), for more details, but here's some high points:
- The backend was switched from SqlServer to PostgreSql so we could host on GoDaddy (or anywhere else for a reasonable price as far as I can tell).
- The site was put onto GoDaddy, still a few glitches but it's mostly working, although I don't think Bethany believes me.
- Access control is integrated into the system and is now functional.
- The payment system works with a null payment interface (it doesn't actually do any transactions, but it could, once we link in paypal).
|
| | | 1 (8%) | |
|
|
| | Milestone report can be found here.
Milestone report basically covers everything I wanted to talk about here, but here's a quick summary:
- Browse is pretty much done, just cosmetics left pretty much
- I've started video tagging but there is still much to be done.
- Only a little bit remains for trust sorting. I just need to make sure the proper node appears in the search tree, which shouldn't be very difficult
|
| | | 1 (8%) | |
|
|
| | Please see my milestone report here:
milestone
In addition to these "large" milestones, I also fixed some bugs in the backend, removed some TODO's, commented code and improved on some of the UI. |
| | | 1 (8%) | |
|
|
| | You can see my milestone report for a detailed description of what I've done for 410 this past week. My big accomplishment was adding transaction objects, which are essentially a way to implement a shopping cart. |
| | | 1 (8%) | |
|
|
| | Milestone found here.
- Finished access control and merged it into the trunk
- Finished the poster for our presentation
- Began documentation of the backend
|
| | | 1 (8%) | |
|
|
| | Milestone report : [ Link]
The profile blurb, section for custom display of content and its editor are done.
I've started working on profile picture, author editor and author citation. |
| | | 1 (8%) | |
|
|
| | Milestone Report
- Added UI Controls to the webApp allowing for the adding of new authorities as well as the viewing of the current authority levels.
|
| | | 1 (8%) | |
|
|
| | - We finally debugged the multiple search results; I had a few bugs and with help of the relationship team we are able to get entity results.
- Message UI is still a work in progress but in theory you should be able to view a list of received/sent messages, read them, and mass delete them. |
| | | 1 (8%) | |
|
|
| | Milestone report can be found over here.
Basic gains made were to set up the UI for Admin and waiting on that, setting up the shopping cart UI, trying to make the UI a little more friendly, yet "tech-y", adding a view for purchase-able content before purchasing, adding an "account" view that allowed you to view your transactions. |
| | | 1 (8%) | |
|
|
| | My Milestone Report
Sorting queries that contained OR nodes should now be fixed, and this was a high priority.
Also, the implicit trust (and sorting on other relationship values, such as rating etc.) is all ready to go, except for the Search Trees don't have specification for it. |
| | | 1 (8%) | |
|
|
| | |
| | | 1 (8%) | |
|
|
| | Friday:
Um...all the stub code (as far as I knew needed to be in) is in. No functionality still. Too many days being taken up by No. Theory, Stat, and GREINER(!).
Sunday:
Holy crap all sorts of gains made. Most all of the functionality of the the Admin Functionality Adapter is in, discounting the new tickets that are being created to add further functionality. That kind of discounts what was done, but there are quite a lot of methods in that class.
All of the original functionality for reports are done - new functionality still needs to have the signatures added and functionality added. This is to be done by the time I sleep.
I figured out how notifications are being done (more or less), and that is being used in one place so far, to be added thrice more in resetting/retrieving passwords and report deferral.
Everything's the way Sohum likes it - and that's the most important thing because if Sohum is happy, I'm happy. Or at the very least, that's what the Admin Functionality Adapter is supposed to do - make his life easier and happier.
Further details can be found here. |
| | | 1 (8%) | |
|
|
| | Milestone report is here.
I also did some customer relations duties during this time period, mostly forwarding emails to their correct destination and sending a couple responses to the customer. |
| | | 1 (8%) | |
|
|
Total: 13 |
3. Milestone Status: Obstacles Encountered
|
| | Mostly my own time constraints. I've worked myself passed the limit this week, and crashed more than once. This weekend I will finally have time to really finish everything up I think. |
| | | 1 (8%) | |
|
|
| |
- No real problems here, biggest problem will be getting categories from the backend, which should be trivial
- The new video framework seems slightly confusing, but it looks like it was designed to be easily extensible and should mesh well with my old code. Biggest obstacle will be learning the new code base
- Search code is complex, so adding even simple stuff can take a while sometimes
|
| | | 1 (8%) | |
|
|
| | The big obstacle these weeks was the amount of work at the end of the semester. With 482 project and homeworks looming over my head in addition to tests, it was hard to sit down and concentrate on 410.
Another obstacle was the fact that this week I delved quite a bit into the backend/relationships code to fix a couple of bugs and to implement replies. It was clear eventually, but at first it's tricky to follow. |
| | | 1 (8%) | |
|
|
| | This past week was insane for me with work in other classes. I've been pushing a lot of stuff off all semester to work on 410 and it all caught up with me. On Tuesday I had a paper, a presentation, and a tournament to attend, on Wednesday I had a quiz and an exam, on Thursday I had an exam which prevented me from attending the customer meeting, and on Friday I had yet another exam. I've hardly touched 410 since Monday. I think my week was similar to other peoples'. |
| | | 1 (8%) | |
|
|
| | People have been extremely unresponsive to my e-mails. Getting a poster up this morning would have been great for publicizing our presentation on Tuesday, but I needed help finishing the poster and absolutely no one replied to my e-mails.
Printing the poster on the plotter is surprisingly difficult and non-intuitive. The people at the operations desk weren't especially helpful either, but the helpdesk people were extremely helpful. Also, I apparently can't charge the department directly for printing but instead will have to be reimbursed by the CS department. |
| | | 1 (8%) | |
|
|
| | I don't have time to work on the project. This week I had lots of homework/report/project/problem set due and an exam. There are also lots of work need to be done: some are new features and some are uncompleted milestones from past weeks. |
| | | 1 (8%) | |
|
|
| |
- I was moved the UI team to implement the UI for the relationships methods. I am very unfamiliar with designing components for the UI, primarily ascx controls. This made creating controls a slow process that mainly involved deriving code from already implemented controls for my purposes.
- The last week of classes was quite hectic, the flurry of projects and papers set me off balance.
|
| | | 1 (8%) | |
|
|
| | I tried to debug the backend side of messaging system before crying for help to Brad, who wrote the messaging system. I got lost and couldn't progress forward. I could have worked on the aesthetic side of what I have so far while waiting for his help, but I had a lot of other things due this week and decided to halt for a bit. |
| | | 1 (8%) | |
|
|
| | The main obstacles were finding bugs in other people's code, that I had expected to have found working and testing. For example--the Access Control system seemed to have some glaring bugs when I tried to integrate it with the shopping cart.
The second obstacle was waiting on other people. There is a communication disconnect which I will get to later, but this affected getting basic interfaces and functionality working. For example, I wasn't able to develop any of the actual UI for reports in the admin section because I wasn't sure how reports would be represented. Contacting people by email has yielded no results. |
| | | 1 (8%) | |
|
|
| | As mentioned in my milestone report, the Authority Level Adjustment system is probably getting cut from the final product. It turned out to be just too complicated, both with the fact that it used the late-finishing notification system, but also that the formulas were way too complex and I'd have no idea how they'd work. |
| | | 1 (8%) | |
|
|
| | -When Jeeyun and I were debugging the entity searching, we had to try to figure out the relationship group stuff in order to debug. this caused some difficulty, but together we managed to pinpoint the problem enough so that it didn't take long for Corey to find and fix it.
|
| | | 1 (8%) | |
|
|
| | Biggest obstacle: Time.
Second biggest obstacle: Finding the people that I need right now.
I hate to be short on this section, but with so few days left, it's all that's blocking me right now.
For what it's worth, earlier by Friday a big obstacle was communication through the week. But we were all on tight schedules, so I feel that even if problems were worked out, we wouldn't have had time to work on them anyway. |
| | | 1 (8%) | |
|
|
| | Finals and real life issues are the big things that were obstacles this time. As people have said before, you can't really avoid them. |
| | | 1 (8%) | |
|
|
Total: 13 |
4. Milestone Status: Proposed Solutions
|
| | We're getting down there. I think the main answer for now is just to keep chipping away and soon we'll have this heap of bugs left behind. Until then, lots of work.
Also, especially after tonight, we'll need to be in better communication, and it should be possible to be, since we'll have no class or homework. |
| | | 1 (8%) | |
|
|
| |
- Just need to get the data from the backend. Should be a simple task.
- I need to read over the documentation and guidelines for the new code base. After that it should be relatively simple.
- I'm going to talk to Rae as I do this, which should speed things up a lot.
|
| | | 1 (8%) | |
|
|
| | I think the obstacles are just part of the normal process of programming. I don't think that people should know the whole codebase because that is the point of uncoupling things and making it simple to work on one module while keeping another intact. I think the reason I delved into the code was more to get it done quickly instead of waiting for the backend because we can no longer "wait" and complain about depending on somebody else. |
| | | 1 (8%) | |
|
|
| | The good news, at least for me, is that I'm basically done with all of my other work aside from 410, so I can devote almost all of my time here until the presentation.
|
| | | 1 (8%) | |
|
|
| | Well, I'd like people to be more responsive. If it's not too late at night I could call people, but I don't want to be calling each and every person in the class. |
| | | 1 (8%) | |
|
|
| | Next week I won't have too much time since I have to prepare for the exams, but there are not too much work left except there are lots of testings need to be done and bugs to be fixed. |
| | | 1 (8%) | |
|
|
| |
- I did not stay in contact with Sohum as much as I should have. Had I kept in touch with emails and meetings, I probably would have made a smoother transition to working with UI controls.
- I was aware that major deadlines in other classes would coincide with this week, but did not alter any plans we had in comp410 because of it. Had I been more conscious of my schedule constraints, I would've began the transition to the UI team much earlier to alleviate the acclimation.
|
| | | 1 (8%) | |
|
|
| | I think I will try to debug it some more today/tomorrow. As for the other parts I will work on it some more so that we have a functional messaging UI soon. |
| | | 1 (8%) | |
|
|
| | It's the fag end of the project and we cannot really overcome this obstacle. For the future, though, we should employ more of a XP-driven approach and test out everything as we program it. I think we have been so inundated by the amount of work that we have to do that we have sidelined testing a fair bit.
The idea would be to get the interfaces in, but since we have successfully managed to separate the different teams so that they shouldn't have to rely on each other, I'm not sure where to put in an interface if I have one. Otherwise, we can use the approach described in the following section. |
| | | 1 (8%) | |
|
|
| | I'm not too happy about leaving out the feature, because it's an important one, and it's one that we told the customer we could do. I don't think he'll be very happy either. Although, I honestly believe that we are better served putting our efforts into making what we have now work properly, rather than trying to throw together some new features at the last minute. I think now is far too late to start working on this, and even Wednesday would probably have been too late. |
| | | 1 (8%) | |
|
|
| | -While it would have been nice to have all three of us working on it, everyone is so busy right now I'm not sure that was the practical solution. I think we managed well enough. |
| | | 1 (8%) | |
|
|
| | For the biggest obstacle? Eh...can't do much about that really.
For the second biggest? I've been going through the tickets as much as possible, using AIM for communication, phone if needed, and tickets as well. Tickets make for good reminders as to what I need to do - oh thank God for trac. |
| | | 1 (8%) | |
|
|
| | I did a couple of things to handle these obstacles that worked out really well.
First, I delegated a lot of tasks. This was great not only because of my own difficulties, but because they were able to solve these problems very quickly (in a matter of minutes) whereas it would have taken me a lot longer to figure out. It was just a matter of finding the right person for the job (who the bug is assigned to is not always the person who knows best what is going on).
Secondly, even though I had other projects to work on, I came to the coding party when I could. I was working on my other projects, but I could answer questions and such from the team, and I think it was good for camaraderie as well. |
| | | 1 (8%) | |
|
|
Total: 13 |
5. Development Process: What seems to be working and why?
|
| | We're coming together as a team.
It was pretty cool how we worked last night. Sohum and I were on aim before the meeting. I was debugging the notification handler service and he was debugging the payment code I wrote. Basically I was fixing bugs in nofitications and also fixing them in payment as he'd paste stack traces into the aim window and I'd be telling him, try this, try that (or even on like 3 occasions, checking in some code to fix various things). This cut the total time it would take me to do something like this by half pretty much, as so much time is spent with me starting up the debugger and such, that with too people going at it I could debug two things at once.
Anyhow, I'm pretty happy with the way people are working rather independently on their tasks. We've got a lot of work left, but nobody has so much they can't do it, so I think we'll be ok. |
| | | 1 (8%) | |
|
|
| | Things are coming together as the semester comes to a close. Even with the massive competing workloads we were able to get a decent amount done for the presentation. |
| | | 1 (8%) | |
|
|
| | Again, TRAC is a beautiful thing. It has improved our communication immensely. People can no longer say that they don't know what their milestone is, because it's very clearly delineated and easy to follow.
Communication with Luke and Bethany seems to be a little better and kind of funny but good, Luke and Bethany were playing "good cop, bad cop" during the customer meeting. Bethany was just throwing things out there (sometimes unreasonably so) and Luke would be on our side on keeping it simple. Also, Bethany has graciously agreed to work on the text for the site (I'll be meeting with her tomorrow to work on that). |
| | | 1 (8%) | |
|
|
| | I think everyone knows what needs to be done before the end and is working to make sure it happens. We've been having pretty constant integration for a while now, so things are starting to come together in their final form.
|
| | | 1 (8%) | |
|
|
| | People seem to be on track with what they need to do now. We've only got a couple days left, so it's crucial that we all stay focused. |
| | | 1 (8%) | |
|
|
| | We are almost done with everything. |
| | | 1 (8%) | |
|
|
| |
- We're now entering the final stretch until our presentation of PlanetTeach and everyone survived relatively intact! There don't appear to be any crippling bugs that kill the experience, and what bugs there are said to be easily fixable (assigning default access controls to users for example).
|
| | | 1 (8%) | |
|
|
| | Even though we weren't able to implement everything that we had hoped to by the end of this project, we are still going strong and trying to do as much as we can. People have been readily accepting the tasks that's tossed at them. |
| | | 1 (8%) | |
|
|
| | Trac is still working. I think Aaron and I handled the transaction interface pretty well. I put in a temporary class in my transactions UI and programmed against it and then he took a look at it and implemented it as required in the Backend and replaced my code to make it work. It worked seamlessly when I implemented transactions into shopping carts.
The growing UI team has allowed me to delegate tasks to others, and concentrate on specific things like developing the admin UI and the shopping cart. I've also tried to separate the non-trivial coding from the UI with the admin section.
|
| | | 1 (8%) | |
|
|
| | I guess I'm glad that the whole thing didn't fall apart completely at the last minute, even with lots of finals, projects, papers, and the like happening during the last week of class. |
| | | 1 (8%) | |
|
|
| | -I think everyone is back into the mode a bit more and working, as we see the end in sight and a lot of work to do to get there.
|
| | | 1 (8%) | |
|
|
| | Coding party was VERY successful for me. Being able to talk with the people that I needed to was key - Brad was helpful with notifications, Aaron with various backend stuff, Matt (albeit with email) worked out Reports with me, and yeah. Also the stat party downstairs helped nourish us/keep us sane - why don't we do that for comp sci? Dangit...
Oh, and trac helps me keep organized/sane. No joke - it's proved its worth one too many times already, but now is like a lifesaver in an ocean of stuff to do. |
| | | 1 (8%) | |
|
|
| | Delegation is working wonders. Not only are things getting done, but I have seen every person in the class become a leader in their own right. I was not joking at all when I said during the meeting that I'd like to do this again with a team of 3 or 4 underlings assigned to each of us.
I think this change has come about through all of our achievements and experience during the semester. Even though there were assignments of PM and team leads, we have all learned together how leadership works, and what both the leaders and the team members should do. I think this is what makes it very easy for us to switch roles instantly. |
| | | 1 (8%) | |
|
|
Total: 13 |
6. Development Process: What does not seem to be working and why?
|
| | We didn't do well with the publicity stuff. I just didn't have time to deal with it (and I don't think anyone else did), and I hoped by delegating it, it would get done. Should have made more people responsible I suppose. Perhaps it's also because I'm a believer in word of mouth anyway, and we'll have time for that after today.
I'm also very worried about integrating paypal with the site, because we haven't started it yet, and I really highly doubt it'll actually get done. Even if paypal approves our site, it could be a couple of days before we have the stuff we need to do it, and it'll take an all out team effor to fully integrate it (on top of everything else people are doing). |
| | | 1 (8%) | |
|
|
| | We completely failed at getting the poster done on time and even letters were running slightly late. Overall we needed far better organization on it and less reliance on word-of-mouth assignment of responsibility and less forcing one person to do all the work. Friday class was also very disorganized even though we had a pressing concern, but that's to be expected to some degree on the final Friday of the semester, especially with pizza.
|
| | | 1 (8%) | |
|
|
| | Brad's having a hard time rallying people or actually, even paying attention in class. I think all of us, including Matt, got used to the fact that Matt ran the meetings, so it took us a while to get organized without him there. At some points I took over a little and at others Dr. Wong had to prod Brad to get back in the game.
We lost a huge bunch of people to 440 and other work this week. The end of the semester is horrible and it was very hard to make this final push. Hopefully the meeting today will help. |
| | | 1 (8%) | |
|
|
| | Some of the non-coding things which need to happen seem to be slipping away. The poster was critical to get accomplished, and I think we pretty much failed on this. At the absolute latest we should have ended class today with the design finished so that all we needed to do was print it, but people weren't focused enough to make decisions. Felipe and I tried to work on it and redirect attention to the issue, but people wouldn't listen to us for very long. since Matt wasn't there, it should have been Brad who kept things on task, and he did occasionally try, but he was also one of the distracting factors from time to time.
To be perfectly honest, though, I think the biggest factor was that today was the last day of class and we had pizza during class. People really felt (deservingly) like they've earned some time to unwind. |
| | | 1 (8%) | |
|
|
| | Except for people not responding to my e-mails, nothing seems to be not working. |
| | | 1 (8%) | |
|
|
| | Hubert asked for help when making the poster, but no one response to his email. |
| | | 1 (8%) | |
|
|
| |
- There seemed to be an issue with our chosen hosting not supporting Microsoft SQL which meant that all our code using SQL commands had to be changed. This was an indicator that database access had not been properly decoupled from the system designed, and it was quite late to do a revamp of the architecture to solve the issue.
|
| | | 1 (8%) | |
|
|
| | We have been a bit unresponsive with regards to making of the posters for Duncan for our presentation and I could sense a bit of tension in class on Friday. |
| | | 1 (8%) | |
|
|
| | Most people on the UI team do not know HTML/CSS. Thus, there is still one point of contact when it comes to implementing the actual UI--me. This can be a little stressful at times.
Coding parties have still had low attendance and I am disappointed. At our last coding party, which was supposed to be our final one for the year, we had a grand turnout of 4 people. I understand that people have other classes and commitments but it seems that 410 is the one that is consistently shafted?
A few people were left with doing too much work, though that was expected in an unexpected sort of way because it was the last week of classes. |
| | | 1 (8%) | |
|
|
| | First of all, I'm a little upset that Derek didn't add the trust level sorting to the search trees - I talked to him on Wednesday night and he said it was pretty quick to do, and he could do it that night. I would have expected it to at *least* get done by the milestone deadline on Friday, but it's still not done, and we can't test it. At this point I have little idea if my code even works, and there is very little time left to test.
Also, it seems like a lot of people are blowing off the class right now, and I can sympathize because at many points over the last few weeks I've had to put other classes ahead because of projects and tests. But when everyone is doing it at once, it causes other people to not work either.
Thirdly, I don't think that Kevin or Sohum were very proactive about talking to each other about Kevin's transition to the UI team, or what he needed to get done, and that lost a lot of time. |
| | | 1 (8%) | |
|
|
| | -Some people seem a bit more overloaded than others, such as Sohum and Felipe, and others I'm sure (as the overloaded ones).
-Everyone has been overworked with it being the last week of class and such. Many people ad tests and projects in other classes. This has slowed us down some, as expected. |
| | | 1 (8%) | |
|
|
| | I do not like this late assignment of presentation roles at Sunday at midnight, with the practice on Monday. Come on, we need time to prepare an actual presentation! I understand the reasoning for this (as Brad explained to me), but still it would have been nice to have had a rough idea of subjects for presentation by Sunday afternoon at the very latest. |
| | | 1 (8%) | |
|
|
| | There are still a lot of the same old problems creeping around, but things like communication and such are always a work in progress - especially when people have finals going on. |
| | | 1 (8%) | |
|
|
Total: 13 |
7. Development Process: Proposals for change--issues addressed and why the change will help.
|
| | Not much time left to really change. Getting everyone together in one room may help. It may also hurt since, as far as I can tell, only a few people are really getting a lot done on the project. We'll see how all the people who spent the last week doing 440 or whatever else are able to get their stuff done when then come back. |
| | | 1 (8%) | |
|
|
| | We just need to use Trac and Sharepoint to assign tasks like that, and ensure there are enough people with enough time on important tasks rather than throwing the work at one very busy person. |
| | | 1 (8%) | |
|
|
| | The semester's over now, so there's not much reason to change, but for future classes I think the project leader needs to keep in mind that he's the leader of the class and needs to concentrate on that responsibility ahead of anything else. Even if there's an important bug that hasn't been put on Trac, or if an e-mail to the customer needs to be responded soon, it is, in my humble opinion, much more productive to tell someone else to do that and instead lead discussion in class/meetings. I think for people who want to be project leaders in the future, you must keep in mind that your responsibility should make you do less coding/minor things and instead you should have the ability to delegate to people without hesitating or taking a long time. The faster you can learn to do that, I think the quicker you will get your team together. |
| | | 1 (8%) | |
|
|
| | We only have three more days before the end. We all have the willpower to hang in there for that long! |
| | | 1 (8%) | |
|
|
| | Any changes that happen now will be too late, considering that we only have a few days left. In any case, the only change I would like is for people to be more responsive. |
| | | 1 (8%) | |
|
|
| | The poster is finished now. |
| | | 1 (8%) | |
|
|
| |
- Brad went into the system and changed every instance of the SQL command to the GoDaddy sql database compatible command, which seemed to work fine, although it smacks of a temporary solution as hosting will likely change again if it the project becomes even slightly successful.
|
| | | 1 (8%) | |
|
|
| | We all should've been more willing to help out. The help Hubert asked for wasn't massive but we all probably assumed that someone else was going to respond. In the future I will not make such assumptions and try to be helpful in the best way that I can. |
| | | 1 (8%) | |
|
|
| | For the future, we should have been more forward-thinking in the past and tried to get people these skills. However, we didn't even have a real UI team until a couple of weeks into the project, so it would have been miraculous if we had shown that much more forward-thinking ability.
Different people have different priorities. People in college are grade-motivated. In a course like 410 where no one has any clue how the grades are handed out, they tend to prioritize towards things that they do have an idea about. I feel that this is the main reason that people are spending more time on other classes than on 410.
Again, it was a case of only a few people having time to work on 410--something that we cannot really change. |
| | | 1 (8%) | |
|
|
| | I guess I could have been more adamant in getting on Derek's case, but from the few times I've talked to him he's seemed like he was working on it. I've also commented on the ticket in Trac and raised its priority but I don't think he's noticed - after some of his comments during class it seems like he just deletes the automatically generated emails, and that defeats the purpose of them.
I don't know how to get around the people blowing off the class bringing others down, mainly because there seems to be an attitude that "working on COMP 410 means blowing off other classes". I sort of feel the same way too; when I was most productive in early November (for the beta push, remember that?), my grades in my other classes started slipping. After I realized that, my work level in 410 was never the same as the beginning of November.
With Kevin and Sohum, if I had realized this was going on earlier, I would have talked to Sohum about it and have him give Kevin more concrete tasks. |
| | | 1 (8%) | |
|
|
| | -Its hard to change too much at the end, but we have been trying to even it out. When Derek said he didnt have enough to do, he was given plenty to do, which took a load off of others.
-There isnt much to be done about other classes. But classes are over, and hopefully people can now dedicate themselves to finishing this project, as it is the looming project" of choice right now. |
| | | 1 (8%) | |
|
|
| | Well, it's kind of too late to do anything now. Future references for 410 classes: plan presentations EARLY in advance as much as you can. It hurt us on the HP meeting, it's gonna hurt us now - Corey showed a good example of what happens when you prepare for a presentation in his trust-levels presentation.
Also, now we're gonna have like 8 presentations with no unified theme...oy, we should at least have them all look the same (visually). I guess that's what we're doing Monday night. |
| | | 1 (8%) | |
|
|
| | What's the solution to all these issues we already know about but are hard to keep on top of? Well, since we don't have any more time, this is more for future classes than us, but the solution is: start early, and develop good, consistent habits before you really need them. I know you almost certainly won't do that, but hey, at least we told you. |
| | | 1 (8%) | |
|
|
Total: 13 |
8. Peer review: Positive or negative feedback for other class members
|
| | Everyone's done a great job this semester. I'm sure that with all of our continued hard work we can bring everything together in the next couple of days so that the people in the audience can appreciate it as well. |
| | | 1 (17%) | |
|
|
| | Hubert - Awesome job on the posters! I saw them in Duncan this morning. Hopefully it'll attract some nerds to come see our presentation. =)
Brad - I feel like you've taken on so many tasks as end is approaching. I hope everything is manageable and that you won't get burned out if you haven't already. |
| | | 1 (17%) | |
|
|
| | Brad did a phenomenal job of getting things done, this week, it seems. He concurrently managed to move the site to GoDaddy, move our databases over to Postgre (which featured a lot of refactoring, as I understand), implement notifications and only he knows what else.
Yuan's getting stuff done in a quiet sort of way. It seems that whenever she checks something in, it works perfectly until someone changes something in another module to break it. But she really tests her stuff before checking it in. |
| | | 1 (17%) | |
|
|
| | I don't remember if I mentioned this in my journal last week, but seeing the improvements Sohum is making to the UI are the most inspiring thing to keeping me going at this point. |
| | | 1 (17%) | |
|
|
| | All you guys are workhorses. Thumbs up! |
| | | 1 (17%) | |
|
|
| | I had a great time with everyone, and being a transfer student I met more CS people than I ever knew before (and I suppose the ELEC people too ;p ). Thanks for a great semester, and I'll see you in 460, 415, CAAM 353 and PHYS 102.
For everybody who isn't in those classes, please drop by 415 from time to time. Take care and see you next semester! |
| | | 1 (17%) | |
|
|
Total: 6 |
9. Additional Comments
|
| | THERE IS A CODING PARTY ON SUNDAY AT 12 PM AT "THE FISHBOWL" THAT EVERYONE SHOULD COME TO. |
| | | 1 (50%) | |
|
|
| | Apologies for lateness, again (if you read the milestone first). My schedule has just been awful for this in that I spent literally all of Thursday and Friday devoted to Greiner, took Saturday day as a time for some rest followed by a night taken up with Will Rice Will Skate (woo!), followed by coding partying-Sunday with ticket-fixing up until now. Oy, I can't wait for finals to be over! |
| | | 1 (50%) | |
|
|
Total: 2 |
10. Advice for future Comp410 classes
|
| | Be honest with yourself and with your team. Don't pretend you can get everything done when you know there are a million other things you need to do. Even if you think you can squeeze it in, in 99.9% of the cases it doesn't happen, and everyone is hurt by the illusion that things will get done (you, your team, and the customer). Everyone needs to know exactly what the expectations are for each milestone for everyone, and these milestones need to be assigned in such a way that they are completed to 100%. And if they are not, then LET EVERYONE KNOW EARLY ON!! Even if it's a classwide e-mail or a post on Sharepoint, it really helps to know where you are.
Communicate often. Along the lines of the last part of the last section, report progress OFTEN. We tried it for a little bit this semester and the times that I reported to Brad what my team was doing it helped my teammates to summarize exactly where they were and judge their progress daily, it helped me to know where my team was and what I could do to make it better and it helped our project leader figure out where my team was so he could see how this would affect other teams daily and possibly adjust his management on a daily basis. Communicate when you finish something, when you're having more trouble than you thought, when you need something from a team or someone.
Along with that, I think that the project manager's role should be 90% a communication facilitator. I think a good way to keep communication going would be a daily digest of what's happened. Get a 4-5 sentence report from all the class members, compile it into an e-mail and add your own comments, ideas for progress, change, congratulations, etc. and send it to the whole class. It may also be useful for the project manager to meet with teams/leaders individually and figure out EXACTLY what's going on where and how to fix it. Even if you lose a coder to the role of project manager, I think it's more beneficial to have someone who can coordinate everyone's work.
Ask for help when you think you might need it. I didn't do this nearly often enough because I thought it would take more time to communicate my problem to someone than simply try to sit down and fix it, but the truth is that the few times that I did ask for help or advice, it turned out to be more productive than anything I could have done.
Check your code often and check in your code often. DON'T BREAK THE BUILD!!!
Other than that, have fun! Enjoy the project, enjoy working on it with your classmates. Nothing will spur the project forward more than if you are having fun. So even though the class is hard and sometimes you'll want to kill a classmate, take a deep breath and enjoy what you're doing. |
| | | 1 (20%) | |
|
|
| | In planning my semester, I talked with ex-Comp 410'ers about the workload. The impression I got was that it was significantly easier than 314. Having had time now to reflect on both, I'd say that, depending on how you look at it and what your role in 410 is, that's probably true. 410 isn't as intense as the last few days before a 314 project is due; on the other hand, 410 is a pretty constant level of high work. Overall I put in more time on 410 than I did in 314, but 314 seems worse in some ways because all the work happens in a short amount of time.
For those of you taking 410 fresh out of 202/212, well, prepare to have your eyes opened. The sort of programming you may have been able to waltz through in the intro classes resembles very little what it takes to create a system as complex as what you'll do in 410. Take as few other classes as you can in the semester you take 410. As a word of warning, at least a third of our team dropped at least one class during the semester to allow more time for 410.
I'd argue, though, that 410 is much more important to your education than whatever other CS classes these people dropped, and in many ways the sooner you take it the more valuable to you it'll be. As a graduating senior, I've been in dozens of interviews. I'd say that in at least 75% of them I was asked about what sort of experiences I've had participating on and/or leading a team. Employers know that theories, languages, and technologies can always be learned, and chances are good that you won't know what your future employer needs you to know to do a job, so they'll train you once they've hired you. The key aspect here, though, is getting hired, and being able to show that you know how to be a good team player makes you infinitely more valuable.
One thing that software companies know is that hero coding is bad for everyone. It's a very difficult thing to overcome, especially when almost all other CS classes force you to work either individiually or in very small groups. Hero coding is bad for the heroes because their workload becomes too great and eventually they'll crash and burn under the pressure. Hero coding is bad for the rest of the team because they won't understand what the code or design does and thus won't be able to help code, fix bugs, or take over when the crash comes. It might seem harmless, and indeed it seems nice to let others do your work, but eventually you'll be held accountable for bugs and upgrades to the things that are supposed to be your components, and if you can't understand the code, you'll be the one that gets the blame. Hero coding is not only not-productive but anti-productive, since it takes more time to understand and fix someone else's bugs than it would to fix your own. That's probably my biggest piece of advice: resist the temptation to hero code, but more importantly resist the temptation to allow others to do it.
You should also not be afraid to throw away code. In fact, professionals constantly throw away code with great fervor. For a program of any considerable size, no one does it right the first time. Some people occasionally get it right on the second or third try, but it ususally takes me at least four or five times to understand it. The only way to realize that your design is bad, though, is to actually sit down and try to make it. At the beginning, quickly write proof-of-concept code of low quality and try to create something that has some aspects of all of the needed functionality. You'll quickly see functionality you didn't realize you needed and that renders the old design totally inadequate, and when you have to start over you'll be glad that you did as soon as possible and with as little effort wasted as possible. Strive for a design that allows you to continually flesh out and add to an existing working program rather than one that forces you to build a huge code base and at the last minute flip the switch to see if it works.
In the end, you should have fun with 410. It's a valuable and unique experience. Don't be afraid to make mistakes, because, really, that's why you're here: to learn things that can't be learned any other way than by doing it wrong yourself.
|
| | | 1 (20%) | |
|
|
| | Ah... the time comes for me to patronize you! Comp410 has been done and dusted for 3 weeks now but there is so much that has been learned in this course. The first thing you have to do is respect this course and your teammates. If you picked up this course after taking the same ones I did (210, 212, 311, 314) chances are that you have no idea what it's about. It's not like the others. It's not just n hours of coding a week after which you can go back to your other classes. Comp410 is more like a job--you will be thinking about it all the time. So make sure you go into this course with the correct mentality. Secondly, respect your teammates. An unhappy team-member is one who is going to be spending more time griping about you than doing work. You are going to be dealing with real people and real people have emotions. The project isn't going to be small enough that you can lose one, or even half the functionality of, a team member. The project will be such that you will depend on other people in the class before you can get stuff done. Thirdly, organize "coding-parties" early on in the semester and at a standard time. Since it's going to be hard to get everyone together at the same time, it's strongly suggested that they are held on weekends and covering a large time span. Coding parties will become essential to getting your project done, especially towards the second half of the course. Fourthly, communicate. Communicate well, communicate a lot. Don't be afraid to email someone. If people aren't responding to emails, call them up. Use Sharepoint to its full potential and when you realize that there is so much that it doesn't offer, don't be afraid to go use third-party products. *cough* Trac *cough*. I would go as far as to suggest there is no such thing as over-communication, unless you actually decide to buy a 15-way walkie-talkie system with your pizza money (yeah... you have pizza money). Finally, enjoy yourself! If you get into the project, you're going to have more fun doing it and you're going to be doing it more efficiently. If anyone of you have done personal projects for fun, you will realize how it's easy to work feverishly for weeks without really feeling bad about it. If the project sounds boring, think about things you can add to it to make it more interesting. Often, thinking about such additions will also help you make a more flexible design. You will be surprised at the end of this class. The same team that seems afraid of their voice during the warm-up project will be screaming at each other to get stuff done right before the final presentation. You will change. It's an exciting journey. Oh, and there's a customer as well. Even while you're learning and enjoying and all that, don't forget that you have to do work. You have to translate your code into something that can be understood by the customer. |
| | | 1 (20%) | |
|
|
| | First and foremost: listen to all the advice in these journals! And don't just listen, soak it up! Comprehend it, live by it, eat it for breakfast, etc. If you don't, then it's really your own loss.
Beyond that, I think the most important thing to do is keep constant contact with as many people as possible. One of the keys to success with the warmup project and the main project is knowing who to go to when you don't know what you're doing (and this won't happen, so don't try to hero code through it!). Moreover, beyond knowing who's doing what, it's good to have just a team. These people are the ones whom you depend upon, so if anyone ever rubs anyone the wrong way, make sure you get that fixed - the team dynamic is essential here! Late on the night before the final presentation, Dr. Wong questioned how when one of our teammates was absent, if we could really afford being a man down. While this was especially pertinent in our situation, this is a mantra that should be held throughout the entire project. Keep that in mind, especially when people get sick - which DOES happen.
Also I mentioned it briefly, but don't hero code. Never. If your workload is beyond your capabilities, it's only more of a detriment to productivity to insist on getting it done when the offset work can easily be accomplished to some one else.
Oh, and if there are box solutions out there to problems that you're working on, don't be afraid to suggest it. More than likely your project will be big enough that any additional time gained is nothing short of a boon.
Ah, that reminds me - don't count on your schedules to go as expected. Try to nail down expected times for completion of different things during the warm-up project. If anything they'll still be terribly off up until the latter parts of the main project - but that's probably not too big of a deal in the eyes of your customer, so long as you keep in constant communication with your customer, and let them aware of unexpected delays or gains, prior to expected milestones.
Finally, be organized! Have dedicated people working with your customer, have dedicated people being scribes during meetings (which is absolutely essential early on), and know your roles within the team. Organization helps. A lot. And sharepoint may fight you on this, but there are solutions.
Beyond all of this, have fun! This is an experience that you cannot get anywhere else. Enjoy it, and above all appreciate it. |
| | | 1 (20%) | |
|
|
| | I'll be adding more to this later - there is a lot I want to say.
Okay, so maybe it was much later. Here's what I have to say for future classes:
First thing, on your notebook, tablet, cell phone - wherever is convenient for you - make yourself a list. On this list put all the advice you receive from these journals, from the staff, and from Dr. Wong. Everything you need to know for this class should fit on a single page (maybe with references to more detailed explanations elsewhere, but you get the idea). You need to constantly refer back to this list and make sure you're covering all your bases, certainly when everything is going wrong, but especially when it seems like everything is going right.
That brings up another point - make sure you schedule regular sanity checks and question your own assumptions. It is so very easy to get turned down a false path and everything seems okay. Try to detect this as early as possible.
Plan for not getting it right the first time. You will make mistakes on all levels. Design your development process so that you can learn and adjust from them.
Communicate. Integrate. Document. Delegate & VERIFY. Learn what these things mean (ask Dr. Wong and the staff) and do them. Write them down and keep checking that you are doing them. If you aren't, make changes. If you are, ask if what you are doing is working.
Lastly, remember to have some fun once in a while. Write that one down too. |
| | | 1 (20%) | |
|
|
Total: 5 |
|
|
|
|
|
|