Fall 2007

• Milestone can be found here
• Completed the interface for tags on the backend
• Created tables in the database to store tag data

1. I was able to properly draft a method (at least numerically, which should give some insight functionally) of calculating trust and ratings, etc. according to the user case provided by Luke. The notes have been uploaded here. Not so well named...but...eh okay I'll change it after I'm finished with this journal. -changed.
2. I wrote up the stub code for the relationship model, sent a copy to Rae and Matt, and checked it into the project.
3. I would have loved to have gotten some integration done between the relationship model and the backend, but so far we're still missing the interface in the backend. Once I know how that's being done, or at least have the names of the functions/methods that will be used, this part will be able to begin to move.

• My milestone report can be found at this nifty location.
• I was able to make a lot of progress at the beginning of the week working as the sole UI person. In particular, I was able to implement the skin on most of the basic pages on the site.
• In particular, I implemented ASP.NET's master layout feature. This is basically a template that will easily allow us to change the page structure without going into every page. Good. That's what we did in 415, and it got rid of a lot of duplicated code and made editing much easier. --Kristin
• I implemented cookie-based authentication. This is probably not a long-term solution since we may move in to the database to store session data, however it sufficed to show the customer how things will work.

• Created a registration page with backend functionality
• The upload page now automatically generates a thumbnail for image uploads and uploads it with the content to the backend.

• A User Guide draft for the Authoring/View team
• Some bug fixing for the customer demo.
• Knowledge transfer from Corey to my team and Sohum
• Beginning to transfer my updated branch upload code to the main branch

1. Integration has still not begun yet, since we're waiting on the backend to give us a proper interface. This is the big thing. I'm glad to see this is at the top of your list. --Chelsea
   Stop waiting and start getting! Passiveness will only hurt you here.  Go tell the back-end group what you need in this interface and help them design it.  If they are taking too long, make up the interface yourself and start using it, telling them that you are doing so.  Drive the process, don't just follow behind.
2. The relationship model will need to be moved out of SearchNavigation into its own project. This will require coordinating with Rae, since there may be some code in the Search model that refers to the Relationship model, and it might not be a seamless move as desired.
3. It's still ambiguous as to whether or not Corey and Kevin have an idea as to how familiar they are with the inner workings of the relationship model right now. I know Corey's been sick, so chances are he hasn't gotten the chance to really take a good look. But I was hoping that we'd get this sorted out today(Friday) at 3, since we planned to meet as a (sub)team then.

1. It took me a while to figure out how to use localization easily (within ASPX pages, rather than the codebehind file). In fact, I still haven't figured this out.
2. I wasn't able to skin a couple of the features because they were still being developed (for example authoring documents).
3. This is an obstacle that I will encounter... Silverlight. Taking over the view team will involve me and my team (aka Jeeyun) picking up some Silverlight knowledge quickly from Derek.

1. video and image conversion will require some sort of outside calls, which is a deployment issue we need to address
2. the relationship system has been fallow for most of the week since everyone was pointing fingers and no one knew which part they were supposed to do
3. we've still not got the process exactly right for dealing with deliverables and how the timeline of lock-downs, milestones, etc. should be established
4. personally i worked a too much this week on this class - i'm guessing about 30 hours, and in many ways didn't find time to accomplish everything that I would or could, so I need to figure out how to restructure things to spend my time where it is most valuable. I miss sleep. I think we should have 410 parties where we all try to catch up on work from other classes. I have 410-ers in all of mine. - Matt You're right, this is too much time. If you didn't finish everything you wanted to finish in that amount of time, the problem lies with your goals (which either aren't posted or need to be linked to) and with a lack of effective delegation. Fight the urge to take the burden upon yourself and work for hours on end. Make sure you are delegating tasks that the PM shouldn't necessarily be doing.

• The way the upload page was designed while I used it was not very extensible and made it extremely messy to add thumbnail functionality.
• I could not find the controls used for serving images. While the designer files were present in the authoring project, the aspx page was missing.

1. I will talk to Matt during this meeting and hopefully coerce him into giving us what the interface will be (and hopefully soon) so that we can continue working. Coercion is probably not necessary, but I do take bribes. Bottled root beers are always good, but only frosty. On the coding front, I think if we can get the Query method sorted out by Sunday, then we will be able to address this interface together during the coding party. The best way for me is really if I can sit down with you and go through it. - Matt
2. I don't know if Rae will be able to attend the meeting, but if she can, I'm going to talk to her about this as well. If not, it's e-mail time.
3. Likewise with Corey and Kevin.

Good that all of you are communicating more! --Kristin

1. My current solution is to load it from the the code behind file. I will have to investigate further to see how I can make a call to resource objects from within an ASPX file. Reading the section on it on asp.net multiple times did not ease the confusion, unfortunately.
2. I think these features are up now. I'm counting on a coding party this weekend to make quick progress. (What if this doesn't pan out? Such questions are a pain to consider now, but doing so will save you time in the end--even if you only have to resort to plan B once or twice. --Chelsea) I will also have to be more proactive in asking other teams to generate stuff, especially given that I have been given the responsibility of leading the UI team.
3. That's how the cookie will crumble. I think working with and understanding the video player will allow me to get a handle on Silverlight. Using Derek as a resource will obviously also be the correct path to take. Excellent call.

1. We'll just have to talk to luke and dr. wong about this; I hope it won't take too much time away from other pursuits for the now smaller content view and authoring team
2. we had an extremely productive meeting this afternoon that I believe converged all of our viewpoints. I believe the backend knows exactly what's expected of it now, and we'll have a concrete interface that the relationship team can start coding against very soon. Likewise I'm impressed and happy that Dave is actually contributing his knowledge and experience to the process, and I think he'll guide our work in the right direction.
3. Matt's working on that mostly, although I think we may need to think about it a bit and then just make a decision and formalize it (and enforce it).
4. Delegation works, but you have to be smart about it. I think matt's journal has a good point, and I should probably spend my time just trying to distill the standards information for people. I wish I'd done 3 weeks ago what I did this week (reading lots about RDF and SPARQL, digging through an implementation, and then telling other people what that means about how to design the system). Speaking of delegation, is there a reason that someone else couldn't have done exactly this? Certainly big decisions need to involve you, but I don't think you need to be the one doing all the research. I am fully confident that you could have given this task to any person in the class and they could have given you comparable results to communicate to the rest of the team. The difference would come from the milestone assignment--ie, "research SPARQL and RDF" versus "find out how to do x, y, and z, and make recommendations for me to give other teams on such-and-such". I really believe you've learned enough about what goes into concrete milestone assignment that you can safely do this, thus freeing yourself up to spend your time communicating the results rather than finding them.

• Use IE7 and Visual Studio to debug. With these tools it's easier to locate the errors. I'll also let the program output some variables and check whether they are right. Derek has done a lot of work with javascript for the video player, so he may also be able to help. I've found Firebug (a Firefox add-on) to be an awesome tool for web development for just these problems. Check it out.
• Do research on this problem. I will create a branch and try to use javascript/AJAX to replace the <embed> tags with content, and use the similar technique to show preview content in WYSIWYG editor. "Do research" and "try to" are both too vague. Set yourself a goal and promise to obtain it. Tell Felipe you want to add it to your milestone (this helps with communication and adds accountability).

• Felipe used the visitor pattern to make a more extensible approach to uploading data. This is something I need to learn how to apply. A quick talk with Felipe about this will probably help you immensely.
• It turned out the file was moved over to the webapp portion of the project. This is indicative of a larger problem we have recognized, in that we have started migrating files to the actual web app while still maintaining files in our segments of the project. We need to determine when files are to be migrated to the webapp, and how they will be kept up to date with the latest developments in the separate projects.

• I am happier with the team restructuring than others because it is allowing me to work on a part of the project that I am really interested in. This is great experience for me. I also think once the teams figure out their exact goals, we will be more productive since the teams are more defined (i.e. one team is'nt handling two unrelated things). I would like to put more people on the parts that really interest them. This isn't easy, when there are plenty of uninteresting things around that need to be done. Be on the lookout for these opportunities, and let us all know when you see them - Matt
• Matt and Brad (and possibly others in the background) have stepped up to the challenge of communicating with the customer effectively. I feel we are doing a better job and proof of this is that 24 hours have past our customer meeting and we have not received a not happy email.
• We have scheduled a coding party (I think) for tomorrow. The coding parties were where I got most of my work last week because it was dedicated 410 time.

• Our customer meeting is better this time.
• I'm glad with the flexible team structure. Although our Authoring team has only two people now, I feel the communication is improved. Is this a result of flexibility, or have you happened to have landed on a great team?
• Felipe's idea of daily report improves the communication.

• The teams are being restructured in a way that seems to better distribute our limited resources across projects. The transition seems to be going fairly smoothly thus far with teams passing on their knowledge before handing it off to a different team.

• Brad feels that some of us are still somewhat apathetic to this project.
• Integration between groups and getting everything ready for the customer meetings is still an issue for us, as well as getting to the customer meeting on time.
• Sohum is currently stuck finding and working out bugs when he prepares the presentation for customer meetings.

1. More people need to be there at the coding party, I feel. At least one member from each team should be there. I understand last weekend was tough given that it was a long weekend and many people had gone out of town. Hopefully this will not be an issue in future weekends. Again, what if it is? I've found that college students tend to pretty possessive with their weekend schedules...
2. Like Matt, I also gather a sense of apathy towards the project from the class. You can't force someone to like something but at the same time, this project cannot be treated the same as a project for any other Comp class as one will be quite unproductive then. For example, in 314 the first and last projects were fun and exciting and most of the class produced great final products in that. In contrast, the Gzip project was dense, complicated and boring, and seemed like a waste of time for a lot of people.
3. Being on time to meetings is still a problem. We need to address this problem urgently.

1. Despite a new focus today, we still do have some degree of lack of committment from a number of members
2. I continue to realize how much work we have left, and how many things I need to add to my already massive Gantt Chart. Just don't get bogged down trying to adhere to a really specific long-term plan. Pick the important goals and stand firm on those deadlines.
3. This week was the week of excuses about relationships: Backend that search hadn't defined what it needed, Search that backend didn't provide support, lots of people that the RDF and SPARQL implementation was confusing and not clearly relevant. At least we now know how to avoid this in the future - see Milestone proposed solutions, last item
4. We also dealt with the customer letter this week, which did take a lot of effort to sort through.

• As Matt said in class, most of us were late for the customer meeting.
• We can't get everything work by the milestone due time. Most people can't finish their milestone by Tuesday, but there are still lots of testing/intergration work need to be done after we finished our milestones.

• We've been accused of having the wrong attitude by our customer, and the general feeling is that this accusation is reflected in a feeling of apathy about the project (people generally not going beyond the scope of their milestones, to which are some extraordinary exceptions). The problem is that maybe we aren't committing to the project the way we should be.

• Brad has suggested we have fun Fridays, with team building activities every week. Interesting idea.
• There is an ongoing debate on whether or not milestones should be moved to Wednesdays. This can give us more time to work on our milestones, but reduce the time we have to integrate our code and work out bugs. Some people have suggested that we incorporate integration into the milestone. The problem with that is that it requires everyone to have already finished the rest of their milestone first and then collaborate with others to get the integration done. This may not be a reasonable expectation, given people's differing schedules and the fact that people like to wait to the last minute to complete milestones. This is a problem in itself. It would help the whole team if people didn't procrastinate so much (haha, I know, wishful thinking, right?), since you could then have time to integrate. I think the best solution may just be to ask people to test their code more thoroughly and make sure that it behaves according to specification. This may be the easiest solution, and it is a reasonable request, but is it likely to succeed? This sounds a bit like "try harder with the same strategy", which leads me to believe it may not really be the best solution.
• Any bugs Sohum finds should be reported to the appropriate team and that team should be responsible for fixing it. The biggest problem then is to get each team to respond and fix the bug as soon as possible

1. We could set a fixed time during the weekend for the coding party. That way, people could plan their weekend around that party if need be. Deciding a coding party on Friday makes it difficult to find a time when everyone is free.
2. We just have to get excited about it. Treat the project as if it is our own personal project (which it is because we are basically setting the limits of what we want to do, with a few restrictions). Above all, this project is not something that is just going to be ignored after completion--it is something that is going to be actively utilized--if even for just a very short period of time.
3. What can we do? To start with, we have to ensure that we all arrive to class on time. Even this is a problem and I don't think getting food is too much of an issue there. With regards to the customer meeting, it seems we are tied down as far as the time is concerned. Perhaps we could move it 15 minutes later as that would be enough time to sort out the food issues. Otherwise, it just becomes a call of whether you want to sacrifice one good meal a week (replace it with a quick meal, that is) or you want to test the patience of the customer and the members of the team who are on time. Sohum, you were working on the demo, got food, and still got to the meeting ahead of time. Thank you thank you thank you. From my own 410 experience, there will always be a reason to be late (for example, last year, I learned that 10 am is apparently an ungodly early hour). It sounds like the issue is one of excuses being accepted and a lack of respect for one another's time. How can this problem be solved?

1. Matt and I are taking a new interest in inclusivity and I'm personally hoping to give everyone some peice of the system to own. I can only think of my own experience coding on a big project and loving to be able to say "I did that part."
2. We need to be realistic about the tremendous amount of effort it will require to bring our system to a useable point.
3. I think I actually found a way to strike a balance between hands-off managemet (which wasn't working) and hero-coding (which got results but at a cost). This was to actively investigate and design an interface so that I could set more concrete requirements for the different groups. Furthermore, we got lots of input at the meeting today and reached a consensus that will work from here on. At the same time, I feel it's appropriate to say that this week we're taking a HUGE risk with the project, definitely the biggest yet. We are redesigning the system around a model of relationships, which while it has been shown to work by outside verification, hasn't been implemented in our system yet, so if it turns out to be extremely difficult to implement, test, and make perform well, we will have essentially wasted a week (or possibly more). I feel we have no choice but to take this risk, and I've carefully evaluated the possible outcomes and likelihoods (to the best of my ability), and I think we'll be ok. Bbut it's fair to say that this is our first big adventure out into the unknown. This is a definitely a healthy and worthwhile risk.
4. As much as we disliked the letter, and the fact that Luke played such a Dr. Jekyll and Mr. Hyde with us in this instance, for the most part it moved us toward the right track I think, even if we were moving that way of our own accord already. There are puppet strings running around all over the place. It's amazing we aren't tripping over them all the time ;)

• For me it's because the dinner, but I think it is not a problem for me to finished dinner 5 minutes earlier. I know that it is annoying to have a meeting a 6 when the servery only opens at 5.30 and there are long lines, but it is probably a good idea to finish 5 minutes earlier to avoid another "not happy letter." Plus, sandwiches can be quickly made and eaten on the run. 
• I think move the deadline to Wednesday is better. We can include testing/intergration as part of the milestone. If we really need all the work done before intergration, we can have midweek milestones, like the milestone Felipe assigned to me this week. It has two parts: deliverables by Sunday and by Tuesday. This sounds like a great plan. I think it would be great for you work with Felipe to figure out a good system that works for the two of you, and then report your results to the rest of the class. The two of you work well enough together that you can really help out other teams that are struggling to communicate.

• Some suggestions have already been proposed, including team-building exercises in the form of games (WIKI RACING) as a way to build enthusiasm for the project and cohesiveness as a team. The question as to whether or not this will actually increase productivity is dubious at best. Really the limiting factor on what we can do with this project has a lot to do with our other commitments, and balancing the needs of this class with others. Perhaps prioritizing assignments would help us move away from trivial tasks (the fateful progress bar comes to mind) and towards the core of our project requirements.