Fall 2007

- We are able to query the backend and given the proper guid, display a silverlight video player with the video file; our video player can play/pause, stop, and has a volume control and a seek bar. (link)

- Theoretically image files should be output to the browser. Currently there are no image files in our database so we haven't been able to test this. This seems like a pretty simple problem to solve; perhaps you can be the proactive person on this issue?

- Search works with exact substring match. You can search for "boomerang' and "basketball" (http://www.skynet3.cs.rice.edu/comp410f07/atelier/SearchWebApp/Default.aspx)

- We created a video player in Silverlight
- The content page self-selects a layout and user controls based on the type of content, using a visitor
- I started writing a spec for the video player

As a class, we made huge gains this week. We now have a backend that can store, retrieve, and update content as well as a front-end that can store and retrieve both text and video, and a searching functionality to browse any content in the DB. Personally, this week I published a document on the backend architecture, created all of the tables in the database, created registry scripts to allow any machine to automatically add necessary values for connecting to the database, and set up new milestones for the backend team for next week. I also attended all of the normal weekly meetings (Team Leader, Customer).

We implemented enough backend architecture to integrate with front-end video players and file-upload.

Look here for testing links.

My milestone for the week was a working video player in Silverlight, which was completed. Basic functionality is working, such as seek and seek bar, volume slider controls, play/pause/stop and a loading bar (which works with the seek bar.) Some of the code needs to be cleaned up a bit (the Javascript for the sliders isn't great,) but otherwise it should be a pretty solid piece of code. Documentation is lacking and will be added as soon as some of the code is replaced (I don't like the way that sliders are handled right now and would like to upgrade it to a more elegant solution if possible.) As much as all of us like to say, "I just want to add this one thing then I will go back and comment everything," it's generally a better idea to comment as you go. Then, you won't have the problem (which I know I've had way too many times) of "Oh crap, it's only two days later and I want to add something, but I can't remember for the life of me what this code was supposed to do." --Kristin

This week's individual milestone is here.

In addition to this, as Customer Relations Manager:
- created a customer meeting presentation
- organized and ran the customer meeting
- created deliverables list on customer site
- started work on features list

-As a group, we flushed out full model with specifc classes/interfaces, methods, fields, etc. including what used what in a UML style drawing. They are sketched here in a OneNote document.

-Assigned each person to add and fully comment parts of the stub code (which could be relatively easily generated from our UML diagram) to the main project. This was completed.

-Split up the group milestone into parts. Sohum and Dave  were able to get searching for tags implemented and working. Sohum did the interfacing with the back end, and Dave modified our classes to return the results in a desired form. For now, that form is merely a linked list of results, but that will be converted to an iterator or sorts. Sohum made a nice visual interface to type in searches (defaults to purely tag searching) and bring up results. The results are in link form and when you click on them, if the data is marked correctly/can be viewed, the content comes up. For this, see the search page on skynet.

-I created a document reperesnting what type of information and table we will need the backend to implment specifcally, what their purpose i and how we will need to access them. This includes basic trust variables and various index tables. The document can be found here.

-I created a pros/cons list as per the request of the customer for the Thusday meeting. This list including the pros and cons of various features related to ranking authors, content and tags. This document can be found here.

-Met with the main team leaders (minus Brad) for lunch Thursday to see what everyone had working and what we didn't. We went through the pieces and saw that they wrked, and checked for bugs in connecting the pieces. Attempted to do the process from start to finish (upload a video, tag it, search it, view it), but there was some sort of break-down in the SQL connection after uploading the video where the tags couldn't be added. The rest could be done, however, and this was fixed by the  customer meeting.

-Met with the customer Thursday evening. After getting a few "bookkeeping" tasks done with, we showed our progress (in the form of the different pieces-authoring, searching and displaying content) to the customer. We discussed the pros/cons list and came to a some basic conclusions (or he decided that I could make a decision from where we were, for some parts). The specific details of the meeting can be found in the minutes.

-Redefined Search to a tree-form, which allows for more complex searches easier. Currently, the design has the operations of the tree (and, or, not) done in the top-end, but this will soon change to just formating into a way the backend can parse our "complex search" requirements. It will be done in the backend instead of the from as computations and then sorting lists in the from is very slow, and will not be suffient in the long run. The diagram for this is in the same as the first, but look the the last three pages of the section (Overall with Types, Search with Types and Search Trees). This stub code was commented and added by me.

-Had Sohum fill in the stub code to connect the local and global trust indexers to the trust model, and the related indexer to the related data model.

-Filled in the complex search tree (in the form of combining lists in the front end) classes and tested them to make sure they combined as expected.

-Met with Brad as we discovered a difference in definitions of "indexer", or so we thought. Upon looking more carefully, we found that we had similar ideas. He did, however, point out that doing computations and sorting in the front is way too expensive, and so we discussed the alternative. This was just done today, and is still a somewhat "loose idea" in my mind. I plan to flush that out by the end of Saturday and have UMLs posted.

- We have implemented the same for text files, but there are minor issues with encoding and we will figure this out soon. Corey has a better idea of what's going on with this. I don't know the specifics of it as of yet.

- I need to find a more flexible way to pass in the guid's to the user controls. Right now, they are pulled from the id parameter of the querystring. I think this is a pretty standard way of passing request information. -Sohum

- The user controls only display content based on the ID parameter in the URL. This needs to be made more abstract and accept a parameter.
- Yesterday, Brad assigned my team a large amount of work that is completely different from what I had already assigned and planned out ahead of time.

This seems to be focused on the development process; what about your personal milestone? If you don't have any obstacles, please specifically mention that.

We still have a long way to go as far as effective delegation of tasks by myself and team leaders, learning to manage effectively, and seeing things through to conclusion.

I have hovered perilously close to hero-coding a couple of times this week (it's not hero coding if you enjoy it right? WRONG! Is this a precedent you want to set, either for yourself or for the rest of the class? Once I start tinkering I can't pull myself away, even if it is like 4 am). While on the whole I'm absolutely sure this was the right decision to enable us to meet the milestones, and I have a lot of faith in my own immune system, we need to improve the process so that people do their own milestones in the future. Define "future"...I can only hope you mean "present" here. I'm pretty sure that throwing yourself fully into someone else's milestone will almost always suffice to get the job done, but it's not an acceptable solution. I agree with Chelsea here, and had written the exact same thing before I tried to save and realized that Chelsea was editing this journal at the same time :-P Even if you do enjoy "tinkering," is it really a good idea to set the precedent that "Well, if you don't get it done, that's ok, I'll do it for you"?

We had, and still have, a major issue with the search team not having a well defined picture of what they're supposed to do. I'd hoped they'd come up with an effective design on their own, but I that didn't happen, and as a result a good amount of work was wasted.

I have a great fear that a tremendous amount of stuff was uber-hacked to meet the deadlines, and if we don't do some sweeping code reviews soon, we will have serious problems soon. I know for a fact that my first version of the backend wasn't implemented in an ideal way, as I felt it was most important to get something working as a proof-of-concept (although on that note, I have essentially finalized a fix of this in a branch that I'm about to merge in). Good that you're fixing this, but wasn't this part of the code Hubert's in the first place?

We mentioned developing a feature specification of the product, which I think is an excellent idea, but I haven't had time to work on this yet, and I have the distinct feeling that it won't happen unless I am a driving force behind it (sort of like the draft architecture that got us moving). The question now becomes, where will your energy best be spent--taking up others' slack, or driving big-picture tasks like this?

Overall no real problems were encountered, besides lack of native support of sliders and the fact I have to use Javascript to do complex things (such as adding sliders)

I don't feel very invested in my milestones in the data management team. This is not good, since this is one of the teams that everyone has been commenting on being behind this week. I am accomplishing the milestones, but I think an improvement can be made.

As an after-effect of being sick last week, I didn't really get started on anything this week until Monday. This made organizing everything for the customer meeting difficult and also prevented me from utilizing my customer relations team and the other team leaders effectively.

-Group milestone not posted until late, thus giving us less time to do the milestone. (More in development process)

-Major issues with the backend not having tags implemented until the very end of the milestone week, thus it was very difficult to implement "tag searching".

I agree with Matt

This is key. I think if we get the long term deliverables up it will help because we will have essentially mapped out the milestones for the long term - Matt

Even though I had met with Hubert and went over his milestone with him for an hour last Friday, and felt that he was confident he could finish it, I didn't talk to him again until Sunday evening. I will keep a closer eye on the work being done. Hopefully, any questions or difficulties people have will come out early and often, especially if I'm asking. Although people should be proactive and point out any trouble they are having as soon as possible. It will be critical to strike a balance to not seem like I'm nagging or watching over anyone's shoulder, though.

I will try to use managerial oversight more effectively while avoiding micromanagment (this is a tough one). Agreed, it is tough.

I will transfer ownership of all the code I've written to others and mentor them into developing on it effectively.

I'm making it a personal goal to see that search comes up with an effective design that will serve us well for the rest of the project.

I'm laying down the law on code review soon. It's fine that the class has decided to do code reviews, but keep in mind that it will take time away from the next week's current milestone. You'll need to put forth some serious effort to improve milestone completion while adding overhead. Especially with the customer wanting concrete deliverables every week, it will be very difficult to get people to rewrite code that is currently functional.

I'm going to draft a feature specification, and a more complete design document this weekend. These will be sizable documents, but should prompt discussion on future problems and enumerate the boundaries of our burgeoning feature set.

1. Now we have the progress bar as a team milestone and Kevin and I will work on that and we are supposed to finish the progress bar by Sunday.
2. Kevin and I will do more research on it. We have made a decision to follow the example we found. If backend modification is needed, we will contant the backend team to figure out a solution.
3. It seemed we should have a meeting to discuss the image standard. At least we have to work out the information needed for image content.

I'm not sure it's the best idea to leave anything lingering on a milestone--odds are that your time will be needed for a new milestone more than for fixing up old ones. This is also an argument for never trusting yourself to go back and comment later (at least in my own experience). --Chelsea

Part of the problem with my coding work is that I have other responsibilities (Customer Relations) which take the major share of my thought-effort, since I'm the one ultimately responsible for that part (whereas in coding I just follow my given milestone). That part is not likely to change, and really it shouldn't. What does need to change is the ownership of the code which Brad mentions in his journal. I think the lack of ownership stems from the fact that Brad and Aaron really did all the design and fundamental coding of the backend. I think the way to improve this situation is to work together as a team more (maybe at the sunday coding party, though I may not make that depending on the time) and as I create more of my own pieces (I'm excited to work on the User Authentication). I am not sure, but wonder if Hubert is having the same problems. Expand on this solution a bit more--how exactly will "working together" fix things? I'm not sure if you mean you should work together to clearly delineate tasks or actually do the tasks as a group.

The meeting planning needs to start earlier (I hope to have a tentative agenda for Monday). Also, I will be working with the Customer Relations team to ensure that a responsibility hierarchy is established (so that if I'm sick, it is clear who is next in line and what needs to be done). What will go into planning meetings earlier? I'd say it's a great but nontrivial goal.

-Sooner milestones...again, see development for more, as I'll beter describe this there.

-Ended with brad hero-coding much of the backend, and Sohum going in to write some of our tag searching himself. The solution seems to be more developmental so...later.

We need to make note of this, and look for more areas that need concrete, written documentation

- My team is working really well together. It's too bad that things are going to have to change around pretty soon, though.  
- The coding party was a great way to get me, and a lot of other people, focused on the project and to get some work done. I think we collectively got more work done in that timespan than we had over the two weeks prior to it. We should definitely do this again this weekend. It seems to be a bit of a problem that you all got more work done in one coding party than in the last two weeks. What can you do to fix this?
- I heard a lot of positive things about my attitude of getting code written, and I think it paid off. My philosophy is that you always have to write something once to figure out how it actually works, and then the next time you write it it's much better. Starting with some code got this out of the way and I think with last week's milestone we have a lot of solid code that will remain in place for a while. While I certainly can't argue with your positive results, I have to wonder a bit about your hope that code remains in place "for a while." The class may need to figure out the line between getting something in place and getting it perfect. You're in a unique position of being at the less popular end of the spectrum, but remember that there's merit in initial quality as well. --Chelsea

Interesting that you think so; there may be some disagreement within the class on this point. Perhaps a topic for discussion at the next team leader meeting?

A lot of this fit into my milestone stuff since I'm a manager, but I'd like to say that the definition of concrete goals that create visible results was extremely helpful in driving the team forward (this is probably part of the reason backend is having a tough time: fewer visible results).

Having a Sunday afternoon coding session was a great success, as it falls at just about the right spot before tuesday deadlines and many people are free (although I'll miss it this week).

I'm really looking forward to see what Jee Yun does with the Sharepoint site in terms of organizing it. I do feel like we've made better use of it this week, at least in terms of keeping lists and making sure we know where our milestones are at the very least.

All the teams have made progress. Now we have many working pieces of the whole project, and our uploading code can works well with other teams' code.

How about class-level development issues? This is a bit narrow...

I get the sense that we are in a critical period right now developmentally, especially given the events of today's class (some criticism about the quality and amount of code output, also comments on disorganization of meetings for which I rightly take some responsibility). The answer of "what is working" is "the same stuff as before." I didn't see any big developmental gains this week (the progress we made was more the ultimate culmination of developments in previous weeks). The major previous development was splitting into teams. I think the challenge now is that we can adapt to recover from new problems we are facing.

Uh-oh!

There seems to be a minor issue in the way our teams are created and today we discussed about moving people around to different teams. As we have worried in the beginning, it's hard to gauge the amount of manpower(or brainpower..?) needed in each team. Is this really all that minor of an issue? It seems pretty important to me that some teams have not been performing as well as they should...

- I still haven't seen much from the Backend team, and this is when we need them most. Brad has apparently done most of their work for them, and it's not his job. Good call.
- I've yet to see any draft of our requirements document, and we need that as soon as possible.

Some inter-team communication seems to be lacking. The preparation for the customer meeting seems like it could be better broadcast to not only the team but to the customer. Point well taken. It is a work in progress - Matt My management and leadership does not seem to be working. This seems to be a bit of a broad statement. Surely there are some things about your leadership that are working?

The managment of backend has not been effective, partly just because of illnesses and such, but also because some people weren't open about when they were churning without understanding how to accomplish their tasks, or without the necessary resources.

Search and Navigation has been a pretty monumental failure of communication as I should have been more involved in overseeing their design process and being a hub between what was going on in the backend with what it would take to meet their needs.

It seemed Felipe had three milestones last week and Kevin couldn't work out a solution for progress bar since it is so hard, but I finished my milestone in just one day. This may be a common problem since it is hard to estimate the workload. Just make sure you let Felipe know as soon as you are finished if the workload hasn't quite been divided fairly, so you don't end up sitting idle.

Certain areas are falling behind far more than others, and we need to try to catch this and balance it early in the milestone. Hopefully the team reworking will handle this. This is a bit vague. Which certain areas are falling behind, and why?

There are several big problems.

One is organization. There are still problems with the sharepoint site (despite its shortcomings I think we can forge it into a useful tool Yay! As frustrating as it can be, there's probably a reason it gets used year after year (besides brand loyalty)). There are still problems with things not being written down in a clear manner, and in a location that can be found (the time and location of the team leader meeting is not documented anywhere (the calendar on the front page is very useful for this and can be set up for recurring meetings--the S&N team has done this already), nor is the time and location of the coding parties (again, see previous comment); furthermore we are still missing some architecture and design documentation, though it is improved from early on).

Two is willingness to step up. I am pretty guilty of this myself. My role as back-up PM is very ill-defined, and instead of waiting for Brad to define it I need to come up with some ideas, approach him, and try to get on the same page. (Being proactive = good.) I need to be able to start meetings and stand in for Brad when he is not around or late or whatever. (Yes, most definitely. A lot of people have mentioned the lack of a backup plan when Brad has gone missing.) I need to take initiative to rectify this problem. In a similar vein I have heard several people, both this week and previous weeks, state "I can't do X until Y is done" or "... until so-and-so does Z." This is an attitude we all need to fight.

Three is that the team structure is starting to fail. I think there are leadership issues, or needs not being met (UI), and other problems which aren't being addressed by the current team structure.

-Group milestone's being posted on time.(Repeat from above). They were late last week (not posted until Friiday) and marginally better, but still late this week (briefly/vagely discussed Wednesda, posted Thursday). This is not acceptable! Yes, as a tema leader I can given my group milestones without needing Brad to tell me what he wants, but its a big part of his job to look to the future and know what needs to get done. I am weary of giving them my own milestones, for fear of them being in a different direction as Brad is thinking/feels is necessary. It results in  me needing to decide to put my milestones on hold or put his on hold. Once in the middle of mine, its not a good idea to switch gears with half-done work. Them again, (hopefully) Brad has a better idea than me of what will be needed by when, and can deletage tasks as such. Good points. Agreed, yet again. It's imperative at this point that whole days each week are not being wasted, as seems to be the case with the Tuesday milestone due date and the Friday assigning of milestones.

-Less vague milestones...again. This was fixed for the last milestones, but this one is again on the vague side.

-Miscommunication with Brad. We're still having issues communicating what things mean and how things should be done. What I thought Brad meant by much of the search design was completely different, as is going to result in a revamp of some code.

-Loosing Sohum to be the View lead when we are already understaffed.

Sohum has been delegated to work on the view of our web app. We need to find more people to work on the search team. Derek has been delegated to help with the search team but I think there should be more people, if possible. I know that Rae (search team leader) is a very abled and hard-working developer so it leads me to conclude that the amount of work needed in the search team is perhaps too big. They have to work on the trust issue as well so I imagine more help will be appreciated. This seems to be more stating what happened rather than coming up with other solutions. What else can be done to help the search team besides throwing more people at it?

We just need to get this document written up since we've pretty much decided what features we want to support. Sharepoint lists are very useful for feature lists, especially since it allows you to see what has/has not been implemented.

I agree that the team leaders can help Brad out. In the interest of taking the load off Brad, do you have any ideas on how to help him out?

I would be more dependent on interaction as a motivator than on an existing code base.

See the milestone proposed solutions above.

Additionally, I plan on watching very closely the situation in backend with task delegation and getting everyone working at a higher rate. How? With Search and Navigation, I'm going to play a more active role in overseeing design decisions to avoid further miscommunication and lost work. Just make sure you don't try to do everything and burn yourself out.

Is it a good idea to be altering milestones midweek? Perhaps the research team can tell you ahead of time how long to expect various tasks to take? I'd come up with a different solution than mid-week shuffling.

I think we need to try to figure out how much/how well people work and divide up teams based on that to some regard. It is still a bit early to figure out everyone's skill levels and coding styles, but in the long run we need to find a balance so we don't have major disparities in talent/other coursework load/motivation. (A few things here--firstly, I don't think that halfway through the semester is "too early" to know anything, development process-wise. Also, I'm going to guess that a group of Rice students in an upper-division comp course can be assumed to have a high enough level of technical skill to do whatever needs to be done. I wouldn't waste time worrying that someone doesn't have what it takes to complete any given task. How to tap that potential is of course a different story. [Sorry, I meant it less as a matter of "do people have the technical skill" and more as "how hard is it to tap the potential." I realize reading it now I kind of missed my point and came off a bit condescending - Derek]) Also, we should try to make sure people are doing what they like to do (to some degree; not everyone can be happy.) In general, people tend to do more, better, and faster work on things they enjoy rather than things that don't interest them very much, and if we can get the teams split up in a way we take advantage of this, it would most likely be very helpful.

This is a possible solution, but is it feasible? This isn't a rhetorical question; I'm actually asking. While such a shuffle may solve your problem, there will be a certain amount of overhead involved (as you know from previous weeks). Is it worthwhile/possible at this point?

-In the future, I feel group milestones MUST be POSTED no later than the time that the old ones are due (tuesday). (Yes! Make sure this is brought up in class, the sooner, the better.) But sooner is better, at least a few days sooner. I think a lot of the reasonfor the late ones this time was because Brad was pre-occupied getting the backend to work. While I appreciate that it got done (and thus allowed us to do our job), Brad has other responsabilities that must be met. Milestones is one of them. He can not just go off and hero-code whenever something is behind, as that gets everything else behind (in a way). In the future, I recommend more forcefully getting the people who's job it is to do something rather than just doing it yourself Brad, as this will help allow you to do your ther tasks. True, true. What method of "force" can the class wield?

-Keep reminding Brad to be more specfic in milestones?

-Better and more frequent, specific discussion with Brad. Talk with him about how I think things are working, what the flow is, what happens where, etc. That way, I can get feedback from him. Doing this now, at the beginning, relatively frequently seems like it will save from as much future revamping and rethinking of things. This allows us to get another, seperate input on how we are doing things, and allows for better design, I think. Perhaps a code review by Brad once we get the new design implememnted would be a good idea as well. (Already talked to brad about this) Interesting role for the PM; I think I like it.

-He will be replaced by Derek, but this will not be immediate. For now, at least until the next milestone, I plan to keep Sohum around and use him as long as I can. Also, there will be some outsourcing to the backend(possibly, may be more futuristic) and advanced researching teams to help. For the backend, this would entail putting more in the backend (as Brad and I have decided is the best model anyway) and thus giving us slightly less work. In the long run though, Derek (and in the real long run, much of the backend team) will be added to pick up any slack. I think we can survive as a two-man team for the half-week in-between stage.

Don't be too hard on yourselves here; there's a reason every 410 class has a Really Evil Week. It's good that you recognize the tension and want to proactively counteract it, but keep in mind that the reason the warm-up project was "nicer" is it's scale. Maybe that realization will help you find a solution.

I'm really pleased with the work my team put together this week. The customer was happy with our demo and I hope to impress him again next week.

Sohum, thanks for all the work on doing the customer meeting minutes and posting them to the customer site. It is an "unsung hero" job and not mentioned enough.

Hubert, you should talk to me as soon as you run into difficulties or find something that's unclear. Be proactive; don't wait for me to come to you. As a general rule that's probably applicable universally, managers don't like surprises.

This is very helpful. Indeed.

Rae - when all is finished with this project, you will be the patron saint of patience

Brad is not afraid to speak up when he sees things that could be problematic, which is good. I think we can do a lot to make the class meetings more productive, but I need to help organize that.

There were a couple people who were criticisized over progress (in a fairly constructive manner). I don't know the specifics of who was supposed to do what, so I can't really speak to that part. However it seemed like there was some communication breakdown over what was expected. Both sides should work to try to improve the communication next time. I also wanted to remind everyone that if you have a problem/concern/gripe/etc., you can always come to me. Just fire off an email or voicemail or whatever. As back-up PM I think one role I can fulfill is that of a sounding board.

-Although I'm sad to be loosing Sohum, I think it was a good descion on Brad's part to pull him out to get started on the view (and I think he choose the right man for the job too).

-I've said this before, but I am very weary of Brad coding. It worked out (I think) this time, but it would be a bad habit to get into. (Yes, and a bad example to set for those that don't get their code done on time.) Hopefully the backend will be more capable now that Matt is back into comission, and that won't be an issue there. Stil, Brad should try to avoid jumping in whenever possible. I know for my group, if Brad has an issue I would rather him tell me and I fix it (or get someone to fix it) than have him just jump in and fix it. Him playing with the group's code could cause confusion in the code, and as we have seen, him to be preoccupied with coding rather than other tasks.

I'm pleased to see a bit more productive tone in your journal this week. Good job.

I decided to get this one in early before I forgot.

 

Ohmygod 5 hour flight, 2 hours traffic, sooooo tired

It does feel a bit redundant; one possibility is to link from one entry to the other. Also, I'm a bit concerned that you have other non-milestone tasks. Is this a common theme for the class, or is it unique to you as the customer relations lead?
Late; -5 pts

Late; -5 pts