|
|
|
1. Name
|
| | Derek Sessions |
| | | 1 (8%) | |
|
|
| | Brad Dodson |
| | | 1 (8%) | |
|
|
| | Matt Freeburg |
| | | 1 (8%) | |
|
|
| | Felipe Serrano |
| | | 1 (8%) | |
|
|
| | Kevin Le |
| | | 1 (8%) | |
|
|
| | Dave Eng |
| | | 1 (8%) | |
|
|
| | Jeeyun Lim |
| | | 1 (8%) | |
|
|
| | Sohum Misra |
| | | 1 (8%) | |
|
|
| | Aaron Cottle |
| | | 1 (8%) | |
|
|
| | Rae Alty |
| | | 1 (8%) | |
|
|
| | Hubert Lee |
| | | 1 (8%) | |
|
|
| | Yuan Gao |
| | | 1 (8%) | |
|
|
| | Corey Shaw |
| | | 1 (8%) | |
|
|
Total: 13 |
2. Milestone Status: Gains made (If possible, include hyperlinks to what you mention here.)
|
| |
Milestone report is here. This week I worked on moving sorting back into the SQL, collaborating with the Relationship and Backend teams. At this point the sorting is done by the SQL in the query, with basic sorting items only. We will be adding more functionality as we go along and adding UI integration as soon as we can. Also, I have become in charge of some testing, that will be beginning this coming week. I'll be focusing at first on security testing, then I will move on to normal testing. |
| | | 1 (8%) | |
|
|
| | See my milestone report from Wednesday.
In the meantime, I made sure we were good to go on the deliverables for yesterday, and I've been working on planning what the next few weeks hold for us.
|
| | | 1 (8%) | |
|
|
| | Milestone report is here. Besides that, I: - prepared updated features list for customer meeting - online/voice conference with the customer - tried to keep class meetings on track |
| | | 1 (8%) | |
|
|
| |
See my milestone report for Tuesday hereIn addition to these items, I have worked on profile updating, fixing the initial transaction bug, but still not being able to update content successfully. Tomorrow Matt, Sohum, Luke and I are meeting to talk about the front end of the site and the designs for it. |
| | | 1 (8%) | |
|
|
| | Milestone Report
- Worked with Aaron of the backend team and Derek of the search on how each team would split the task of sorting. The relationships team now handles the sorting parameters passed in the abstract search trees, and passes the ordered pairs of sorting values for entities and content that the backend supports.
|
| | | 1 (8%) | |
|
|
| | My milestone can be found here. Since Wednesday, I have worked on sorting out testng and following through on the details of tags (details found in the next section). In addition to this, I have been talking to Hubert to try and nail down a concrete design in terms of how groups are going to work. |
| | | 1 (8%) | |
|
|
| | The restructuring of the backend broke all of the search implementation. Therefore, outwardly there seems to be little gain in terms of advanced search but now advanced search works again, and in full capacity in terms of the search criteria currently being offered. Advanced search works now for:
- search by name
- search by tag
- search by creation date (created after a certain date)
- search by creation date (created before a certain date)
- search restricted within the trust network only
- combination of the above
Also instead of last week's implmenetation in which the UI had to know the search tree structure, now the UI simply delegates that to the search module. Basic search (typing in a keyword in the search box on the right top corner) was broken, but now that is fixed as well. |
| | | 1 (8%) | |
|
|
| |
- My milestone report can be found over here. Just kidding, it can actually be found here You are evil and deserve to be beaten with noodles.
- From the UI pov, we were able to implement a working search in the basic and advanced contexts.
- We developed a new logo along with Luke with an online GoToMeeting meeting + conference call with Luke, Bethany, the UI team and Matt.
- Comments were implemented on all levels (frontend, relationships, backend).
- Tabs were finally implemented, although with a few drawbacks that were addressed, for the most part.
- Most of the deliverables were met as per schedule. The remaining should be met by the new Monday deadline.
|
| | | 1 (8%) | |
|
|
| | My milestone report is here. My big wins were
- Adding ordering search results to the backend
- Adding substring searching to the backend
- Deploying the application to our production server (*ahem... server s)
Today I also wrote a simple program to yank everything we've written into a single large file for copyright reasons. It's a 10,803 page word document. I can't say I'd recommend opening it unless you've both got a really good reason and a lot of RAM.
|
| | | 1 (8%) | |
|
|
| | -It's only been two days since my milestone report, and since then all I have really accomplished is to add three-level trust network searching and test.
What have you tested? What exactly is "three-level trust" (i.e. why is it limited to three levels?) More detail would be helpful. |
| | | 1 (8%) | |
|
|
| | Milestone is here.
- Access control is now implemented, I think I ought to make a branch and then integrate it
- I've been working on getting an appropriate hierarchy of objects in the backend with Dave, we have a draft of how it might look (here), but Dave is still unsatisfied with it.
|
| | | 1 (8%) | |
|
|
| | Mile stone report can be found here: Link After Wednesday I was trying to fix the bugs of WYSIWYG editor. |
| | | 1 (8%) | |
|
|
| | Here's a link to my Milestone report for the week.
Summarizing, I'm very pleased with the amount of work my team got done in the past week. We have a very good amount of support for relationships, and we added the ability to sort search results, and a testing framework. |
| | | 1 (8%) | |
|
|
Total: 13 |
3. Milestone Status: Obstacles Encountered
|
| | I have had two obstacles, neither which were major.
First was just working with multiple teams. This has become heavily streamlined and was actually quite efficient, but as in any system, coordinating teams is always takes the longest. To be honest, however, it worked out very easily and well. So I can't count this as a complaint.
Second is ongoing, which is I want to try to get the match percentage out of the backend match. For now it is impossible but I'll be talking to the backend team to see if we can ever pull this information out. |
| | | 1 (8%) | |
|
|
| | We've encountered a string of issues with bugs relating to deployment (as expected of course - actually it's great sign that we're working through these things now instead of in some kind of huge end of project deal). We also had to push back a proof-of-concept on payment again as the access control system is taking a while to implement (actually I was surprised they didn't give us more flack about that at the meeting).
We need to come to an agreement about how we'll be able to implement algorithms on relationships, as the current system isn't cutting it really (although Corey and I have a pretty serious miscommunication here that needs to be settled).
If this isn't settled I think this will become more and more taxing on us. The current system is twisting search trees to do things they are really designed for, and I think we're going to run into problems here unless we address the issue shortly (that's my project for the weekend before sunday actually).
|
| | | 1 (8%) | |
|
|
| | There have been some technical issues with transferring the database and application to Skynets 1 and 2, but nothing that hasn't been solved. Milestone obstacles continue to be surmountable hurdles, only requiring time and manpower rather than being things that are difficult to figure out. |
| | | 1 (8%) | |
|
|
| | Javascript is a pain to work with. It's very hard to make it work, and in addition, there are browser incompatibilities. I think it's working for now, but if there's even a minor name change in the future, things will break.
There seem to be so many features missing and so little time left. It was way worse earlier in the week and I didn't think that we were going to pull it out at all, but the fact that we did gives me some certainty that when we work hard as a team, we can achieve the milestones and more. |
| | | 1 (8%) | |
|
|
| |
- I was hospitalized on Monday to test whether or not I had appendicitis (I do not!). Glad you're okay. Which set me back in terms of getting into contact with Aaron and Derek about how the relationships model would handle sorting.
- Adding new features to the abstract tree parser was very difficult for me, as I had not originally written it, and so had to talk to Corey extensively on what the implementation of sorting would entail.
|
| | | 1 (8%) | |
|
|
| | As stated in my milestone report, I have encountered two obstacles in terms of getting what I need to get done, done. 1. As stated prior, after performing testing, it became clear that there are a few things in backend that still don't make sense. All of this is detailed in the ticket for this task. Matt clarified today that the OneTrustJump, TwoTrustJumps, ThreeTrustJumps methods are all hacks, so I hope those will be going away soon. Beyond this, I still need to talk with Matt since he implemented Tags in the backend - there is still a lot of confusion over implementation as there are TagTarget, TagSource, and Author relationships all being used right now, and I'm fairly sure that TagTarget isn't being used in any of it. 2. I really want to get the group info done as soon as possible. The design should've been accounted for a while ago, but it's more complicated than we estimated, and it's ultimately been charged to Hubert and I. Now, this is perfect timing, since Hubert and Jee-Yun both have the malloc project due on Tuesday. In light of this, I told Hubert and Jee Yun to work on it Thursday night and Friday, and schedule some time on Saturday morning to work this out. |
| | | 1 (8%) | |
|
|
| | When I was not getting any search results back, it was hard to track down where the error was occurring. I understand that there is a lot of communication and "translation" that occurs from the UI to the backend and I don't think it's up to any particular module to facilitate this but it is the only obstacle I can think of that I had to deal with this week. |
| | | 1 (8%) | |
|
|
| | There were no real obstacles this week. The team was working well and the biggest challenge for our team was really getting on top of our tasks. I think we did well in terms of getting a working search interface, and we also worked extensively with Luke getting a logo and UI that was appreciable.
That's not to say there's not a lot to do. There's still the payment system, access control, administration and lot's of other big things to come. Our milestones are well directed towards these issues, though. |
| | | 1 (8%) | |
|
|
| | Skynet 1 does not have ASP.NET. I did not know that until about 2am on Thursday.
|
| | | 1 (8%) | |
|
|
| | -I had some difficultly with the multi-leveled trust, but only b/c I was being stupid and forgetting something basic. Once I figured it out, it was very easy, and didn't take much in the way of debugging. |
| | | 1 (8%) | |
|
|
| | The database has been purged a couple times, hindering the testing of my code. I now need to figure out where to put the access control checks when integrating. Dave and I could use a little more input on how we might restructure the object hierarchy. |
| | | 1 (8%) | |
|
|
| | 1. When I put text editor in user control, it was not working and when I tried to submit the content: there always be a popup window saying some value in AJAXControlToolkit is not valid. I tried to find the error but there seemed nothing wrong, so I searched the error message by google and found that was the bug in AJAXControlToolkit and there's no way for me to fix it.
2. The WYSIWYG editor couldn't find the ID of textarea. Since we are using user control, the ID of the components changed and when we call the element by ID in javascript, there always be an error saying there's no that element. |
| | | 1 (8%) | |
|
|
| | One issue that we ran into is that the search results would not be sorted correctly if there were any OR nodes in the search tree. This may require some extra work, or a redesign of some components. Unfortunately we discovered it late Wednesday night, so I decided to bite the bullet and leave it as is for the milestone and beta, and make plans to fix it for the following milestone. |
| | | 1 (8%) | |
|
|
Total: 13 |
4. Milestone Status: Proposed Solutions
|
| |
I really can't complain about anything. Inter-team integration and work has become very efficient and simple. I would recommend putting your solution to the match percentage problem here rather than above. That solution may also need some fleshing out. --Chelsea |
| | | 1 (8%) | |
|
|
| | We need to continue aggresively finding and posting bugs and work hard to fix them quickly.
The access control system is becoming a focus for the backend team and I think the increased pressure will get us going quickly.
I'm going to spend the next couple of days digging through the system as well as looking at various future scenarios to try to propose some sort of algorithm hook (basically a VisitorHost interface to the relationship model) that will allow us to do things like shortest paths, traversal of trust networks, calculation of implicit trusts, etc. I'll then have to sell it to the relationship model. |
| | | 1 (8%) | |
|
|
| | Milestone issues are solved by the delicate juggling of personnel between the critical tasks. Perhaps that isn't how everyone is seeing it, but it's definitely my perspective of things at the moment. |
| | | 1 (8%) | |
|
|
| | Sohum found a great article for how to get around the ASPX renaming of elements in the page and I will soon get down to working that into our site for easy Javascript access in the future.
For the second milestone, my solution is to enjoy the work and make it your own. I think that's the best way to get someone excited or committed to something: if you let that person own the project and make their decisions on it and add what they want (with input form others of course). |
| | | 1 (8%) | |
|
|
| |
- Had I pressed the point of meeting with Matt/Aaron on Sunday, I would have been in a more comfortable position on Wednesday to finish work on sorting in the AbstractTreeParser.
- I think working on somebody else's code turned out to be a fruitful experience. By working in Corey's code, I helped him determine certain aspects of it that needed to be reworked, and having that outsider's perspective is a good test of when others will be taking over our code, and whether or not we make it easy for them to use and change. Very good point.
|
| | | 1 (8%) | |
|
|
| | 1. I'm going to keep maintaining the testing project for the relationship model. I'm confident there's still a lot more that needs to be checked - and when Derek has opportunity to work on testing himself I'll be able to help him get accustomed to the current project. I'm also going to nag Aaron and/or Matt to get the deletion of database content interfaces ready and rearing to go.
2. Just because I'm waiting on Hubert to get some work done doesn't mean I can't work on my own on it. Very true. I'm in the process of brainstorming ideas, using markers and making use of the windows in my room (glass markers + window = amazing whiteboard). I'll hopefully have something to go over with Hubert by tomorrow in preparation. Great! |
| | | 1 (8%) | |
|
|
| | Continued communication between different teams will lessen this problem. Aaron, Corey, and Rae have been available and willing to answer questions for me this week and that has helped tremendously as it would have been harder for me to step through their codes and try to understand where it's breaking. For example, after struggling for a bit trying to understand why the search tree wasn't being generated correctly (I thought it was on my part), I had asked Rae to take a look at her code and she was able to find out the bug. |
| | | 1 (8%) | |
|
|
| | See above. On a personal front, I have tried to divide up the milestones between Jeeyun and I and assign them with two separate completion dates (Sunday/Wednesday) to get them done. |
| | | 1 (8%) | |
|
|
| | I had gotten SQL Server to run on Skynet 1, and I was planning to run our application on it as well, but failed. We needed something running for a production server, so I just moved our application to Skynet 2 (which worked instantaneously), keeping the database on Skynet 1. I think this is a blessing in disguise, as now our processing is split between two machines, so hopefully we're much faster.
|
| | | 1 (8%) | |
|
|
| | -none to be said
|
| | | 1 (8%) | |
|
|
| | I'm planning on re-writing my testing code to be independent of any entries in the database (i.e. have it insert rows into the database before testing and then remove those rows after testing). It'll be trickier to get it to use a different table because currently the SQL queries are hard-coded.
The majority of access control should be in the backend, but there are some key parts that lie outside, for example search permissions on objects, or write permissions on content. I'll need to think more about this, talk to others that might be involved (search team?), and decide if it might be possible to keep it all on the backend (probably not).
These are great solutions, but I'm a bit concerned at the passive attitude here. These are exactly the things that need to happen, so make sure they do! --Chelsea |
| | | 1 (8%) | |
|
|
| |
1. The only way to solve this problem is put the editor in .ascx page instead adding it later in .cs file. This means we can't add the editor dynamically, and we have to remove the editor if we found the user is not the author.
2. This problem is solved by using ClientID. Sohum emailed me an article about control ID which is really helpful.
|
| | | 1 (8%) | |
|
|
| | The goal of having the search results ordered was to do it in the SQL statement so the database could do it for us, and ideally be more efficient. However the current handling of OR nodes splits the query into multiple queries, and just unions the results. We'll have to either find a way to specify OR in the query (since this can't currently be done), or manually sort the results when we get them back. The second solution is easier, but may be less efficient. |
| | | 1 (8%) | |
|
|
Total: 13 |
5. Development Process: What seems to be working and why?
|
| | Team integration has become exceedingly easy and fast. Things are coming together at a fast rate and meetings are finally becoming short and excellent. Milestones are lining up with deliverables, and things are just going well in general. |
| | | 1 (8%) | |
|
|
| | Our teams are working together quite well. The communication channels are becoming more effective (if less formal - it seems a lot of the most important communication happens through aim or face-to-face). We do need to watch that we still have formal and hard-copy documents of what our timeline and milestones are, although we've had trouble with these being ignored (mostly because they are tedious, disorganized, and hard to find). People have too much to do to dig through the site to find what they're supposed to do next, and informal communication is working more effectively. Agreed. Plus, you can talk things out face-to-face and hammer out miscommunications much more easily. |
| | | 1 (8%) | |
|
|
| | There is a lot of cooperation between teams that is working wonders right now. Not only are people using the bug tracking site that Corey set up, but they are taking more ownership of the code and modules, and really pushing to make sure that their features work for the user. Even beyond that, they are checking up on other people's features and both logging bugs and helping to fix them. |
| | | 1 (8%) | |
|
|
| | I have communicated a "pep" message to Yuan about the text editor and what I would like to see, but letting her make the choices that SHE thinks would be cool for the editor. I think this is good both for me (less micromanagement) and for her, as it allows her to design a big piece of the site instead of following simple milestones. Sounds good to me.
The TRAC system is working very well. At first I was sort of skeptical, thinking that it would be a clunky system to use that would slow us down more than anything, but it turned out to be of great use in the crunch time when there were bugs that I needed to fix.
Team intercommunication (at least for my team) was excellent this past week. We got a lot things done together that brought the system to the much improved state that it was in at the meeting. I admit I was on the skeptical side here as well and am still a bit hazy on this tools capabilities, but if it's still helping after another week, congrats to Corey for finding something good. --Chelsea |
| | | 1 (8%) | |
|
|
| |
- Working on a problem that involved three teams made me really appreciate good communication in the integration process. (But, as others have brought up, should the problem have really involved three teams in the first place?) By sheer coincidence, Corey happened to be lurking around when I met with Aaron to discuss how the relationship model would interface with the backend. He sat in on the discussion and had as much to say as Aaron about how to the AbstractTreeParser would function with the sorting pairs. While I was working on the Parser, I had access to Derek and Aaron via AIM while Corey talked to me on the phone, making integration that much easier.
|
| | | 1 (8%) | |
|
|
| | More or less the site! I was really impressed by the presentation Thursday - not so much the presentation itself, but the fact that the website looks...useable. Disregarding the placeholders, it really looks like it's a finished product. Or at least the parts that are finished have a very nice polish to them.
Teamwork - I know it's been said a lot, but I really like all 12 of you. Like a lot. I'll spare the same old song and dance, but I mean it has to be said.
Also, I said this last week, but I'll say it again - Trac is wonderful. |
| | | 1 (8%) | |
|
|
| | Everyone seems very comfortable and confident in their areas. Corey has only recently been put into the relationship team, but I can tell that he has put a lot of thought into the trust network system, how it was going to work and what we need to do to implement it. Some of those ideas have been implemented already. The same goes with the search team. Things have been evolving but they are quick to accommodate the recent changes in terms of sorting and getting search results back. I like the stability level that we have come to reach; we have come far since the beginning of this semester. =) |
| | | 1 (8%) | |
|
|
| |
- I think I'm still delegating far better. At the risk of sounding precocious, I think delegating the whole search shebang to Jeeyun allowed me to make more progress on other areas such as comments and such. She's done a great job working with Rae, as well, so some of her next milestones concentrate on search, while I have also assigned her more "coding-intensive" milestones. Just make sure she thinks that you are delegating well, since she has noted that she's got an overwhelming amount of work to do before Sunday.
- People have generally been coming to class and meetings on time and contributing well.
- Luke seems more confident of our progress--I guess this is an artifact of us delivering some of the things we promise in a presentable format (i.e. frontend-wise).
- Trac has worked beautifully to keep track of bugs and monitor their progress. At this moment in time, I would estimate that Trac is approximately 7.8 million times more effective than Sharepoint. Kudos to Corey.
|
| | | 1 (8%) | |
|
|
| | Trac is the single greatest boon to our productivity that we've ever had. Future Comp 410 classes should start using it from day 1, now that it's installed on Skynet 2. While it's possible to record milestones and bugs on Sharepoint, the information easily gets lost within its enigmatic interface. The Sharepoint issues still sound like user errors to me, but it's great that you've found something that seems so unanimously supported. Go with what works and all that. --Chelsea
Teams are well separated from each other, independently churning away at their code, yet remaining in close communication to unblock each other quickly. |
| | | 1 (8%) | |
|
|
| | -I've talked to Brad about the direction of Search, and we agreed that search may need to take on some new, different roles, as the majority of the previously defined tasks are wrapping up. I feel it's good we recognize and discuss such issues, and my team was assigned something (visualization of trust networks) somewhat beyond our previous scope. This means the talking isn't just talk. |
| | | 1 (8%) | |
|
|
| | Trac seems to be helping everyone. It's nice to have it there to notify people what needs to get done and have it all in one place as well. Our customer seems to be looking forward to opening the beta. |
| | | 1 (8%) | |
|
|
| | The communication was good in the past week. We were using AIM and email a lot and got a lot bugs fixed in time. Felipe had emailed me a lot about the bugs as well as the cool features we would like to implement in the future.
The Trac is also working wonderful. It helped us to find bugs and fix them. |
| | | 1 (8%) | |
|
|
| | I'm very pleased with the amount of use Trac has gotten over the past week. It's nice to take a look at the Roadmap section and see where we stand (in general, and on a per-team basis) for finishing a milestone. It's also easy to perform triage, that is to go down the list and ask 'Is this fixed?', and it gives everyone a good perspective of where others are in terms of progress and bug fixes.
Also, some comments were posted in my journal questioning my decision to use Trac instead of SharePoint. Trac is designed to be used specifically for projects such as this one, and it was easy enough to setup so there wasn't enough overhead. Pretty much everyone I've talked to prefer using it to Sharepoint. I generally don't like using Sharepoint, it feels crufty (to use one of Corky's words) - and I don't have a very good explanation, but I think others' feelings about Trac state more than my own. Fair enough. It seems like everyone really likes it and finds it to be a useful tool, so it's good you set it up.
Also, as a Team Leader I've historically managed communication with other teams myself, but I made a whim decision this week to put Kevin and Dave in contact with certain members of other teams to work towards shared goals. This actually worked quite well. Dave worked with Hubert to get groups set up for the access control system, and Kevin worked with Derek and Aaron (so he got both ends) on sorting of search results. |
| | | 1 (8%) | |
|
|
Total: 13 |
6. Development Process: What does not seem to be working and why?
|
| | The search team is probably getting less than its fair share of work right now, but otherwise things are going well. Being reassigned to do some testing should even out our workload however. Do you really need to be reassigned to do testing? Shouldn't "making sure it works" be part and parcel of doing a component of the project?
Also, Fun Fridays are being Work Fridays. :-(
(kidding of course) |
| | | 1 (8%) | |
|
|
| |
- As mentioned above, the use of formal documents has declined (sorry staff) and we need to watch that we still produce and use these documents where necessary.
- I think that in some ways our teams are too interdependent because they've never defined adequate abstraction barriers in certain places. If the interfaces had been written flexibly enough, it wouldn't take the involvement of 3 teams to make changes to the way we display trust networks. I believe much of this has to do with adequately defining a separation between relationship models and algorithms that run on relationship models, and applying design patterns to insure the modularity, extensibilty and flexibilty of the two halves.
These are both important issues. The staff doesn't mind the flux that comes with finding a balance between effective communication and documentation--feel free to experiment a bit, keeping in mind that posting milestones and things requested by the customer are not optional. --Chelsea |
| | | 1 (8%) | |
|
|
| | Other people have been pointing out better ideas here than I can think of. One thing I've noticed is that meetings are hard to keep on track lately. And, as far as the milestone strategy mentioned above, it is not simple at all to allocate personnel to tasks correctly. Not only is it hard to estimate the number of people and the amount of time required for a task, but finding the right person for the job is extremely ephemeral but it makes all the difference. |
| | | 1 (8%) | |
|
|
| | This was actually a great week for me, but I heard of a few issues in other teams with milestones being incomplete when we needed them.
The only issue that I ran into that I would like to bring up and I should have probably talked to Yuan about this earlier is the bugs that I was running into with the WYSIWYG editor. It's still not working and there's some naming issue that she's working hard to fix, but the first response I got when I posted the bugs to trac was that she set them as resolved with "worksforme". The fact that it works on one computer means that something was done right, but the fact that it doesn't work on any others means there's something very wrong, and it doesn't help to just dismiss an issue when it doesn't come up on a local build deployment. |
| | | 1 (8%) | |
|
|
| |
- As was pointed out today, as we get close to our testing phase, there becomes a problem as to how we add new features to the project and what shows up to the testers. Clearly, we can't going to work directly on the build the public sees, which should not be exposed to untested features, but then how do we decide when the version we are working on is adequate for public release?
|
| | | 1 (8%) | |
|
|
| | Two things immediately come to mind:
- Adherence to interfaces with regards to relations. This is with extra emphasis on tagging. Maybe I'm confused and my implementation is screwy, or maybe Matt's is. I don't know, but that's a very bad thing that I don't know. What's the best way to fix this problem? Well that brings me to point 2.
- DOCUMENTATION. I would love to have a lolcat with "My documentation, let me show you it.", except it'd be a complete lie since there's no documentation! Firstly, on behalf of the relationship team, I'd like to note that we need to get our code commented and properly documented. Every tiny detail. It's trivial, but important to generate javadoc in Eclipse - it's not as easy apparently in VS, but JUST AS IMPORTANT. Yes! It makes it much easier to go back and edit your own code when it's documented, and since this will obviously passing into other people's possession, this is a must. Plus, you don't want to be trying to document everything during finals week--not a fun task. Beyond this, we need the documentation updated in the documents within our documentation folder on sharepoint. That's really essential.
|
| | | 1 (8%) | |
|
|
| | We have A LOT to do by Sunday. I am worried that we might not get things done as I tend to get most of my work done Sunday through Wednesday. Other than that I don't have any major issues with the way we are working as a team. |
| | | 1 (8%) | |
|
|
| | I cannot really find anything, especially from my personal point of view. Any development errors from my end have come from misunderstanding the specification, but that is a problem from my front. Otherwise, the UI team is kind of lagging behind the other teams, though our progress helps them figure out their errors.
One thing I would like to point out from the meetings, and something I know I have been guilty of doing in the past, is going too quickly. I got the feeling that Brad was trying to demo too quickly, especially since Luke wasn't watching for most of the time (:@). This is something we may need to address for future demos.
What about the problem of people generally coming to class? Seems like some people aren't or aren't contributing well when they do. |
| | | 1 (8%) | |
|
|
| | I've got no particular qualms with the development process this week. I guess if I had to complain, meetings can be a little lengthy and sometimes off-topic, etc, but these are minor things and seem to be getting better from week to week.
|
| | | 1 (8%) | |
|
|
| | -The exact new diretion/role of search is still not completely clear. |
| | | 1 (8%) | |
|
|
| | The class meeting today was interminably dull.
There are still a lot of features that we want to implement (notifications, an admin interface, user tracking, error logging), but very few have actually been thought about, much less have anyone dedicated to. The other teams seem to be pretty busy getting their own portions done and I know the backend will not have anyone to spare (we'll need to be working to provide support for any new features we want to implement). |
| | | 1 (8%) | |
|
|
| | There are a lot of testing work should be done, and I think we have to test under all kinds of conditions. Felipe reported several bugs in WYSIWYG editor, but everything worked on my computer. So there's no way to debug since I didn't even encountered that problem. I have no idea of how to locate the bug.
This is a good place to ask for help. I think there are ways to debug. Firstly, if it's in the Asp.net scripts, you can login to the webserver and browse to the page there. Then you'll get the call stack for any crash. You may also be able to debug by attaching to the server process, but I recommend this only as a last resort. For javascript, you can also use the above method, or just try different browsers. But in general, if you get stuck and can't debug something (or can't reproduce the bug) ask for more help - either a better description of how to get it to happen, or how to debug it. -brad
Brad has good advice here. Make sure you don't just ignore bugs because they don't happen on your individual environment. This system is going to go into production, meaning it has to work for a multitude of different environments. Check out Felipe's journal for more on this topic as well. |
| | | 1 (8%) | |
|
|
| | Rae mentioned this in her journal last week, and I don't think it's improved much since then: The assigned milestones often don't have much in common with what is actually worked on. They're usually posted later than I would like, but somehow get out of date. Also, features (or bug fixes) requested by other teams and not by Brad aren't included here. So the milestone list isn't an accurate list of what we're actually doing in a given week, and the completion percentage may not be an accurate measurement of how much work we actually got done. I don't think this is causing any problems in terms of getting work done, but it can be confusing and sometimes we're not sure what to do. I'd like to point out that it does cause problems grade-wise. As promised, we grade milestone reports based on the completion of what's posted. --Chelsea
Also, I was very concerned by Brad and Felipe's comments during class today that essentially belittled one of the major points of having specified milestone dates. I think that on one hand, milestones are a list of goals for new features that we'd like to have included by the target date (this is an alpha mindset). On the other, milestones are target dates for people to try and get as many of their bugs fixed as possible, so that releases are somewhat bug-free (this is a beta mindset). This is absolutely crucial, since we are now in beta testing, with real people using the site. As you approach a milestone, you should be more and more careful about check-ins, because of the fact that adding a feature or fixing a bug has the possibility of introducing new bugs. Features are usually added towards the beginning of a milestone, so there's plenty of time to test them, and then there is a big push of bug fixing right up to the milestone. At some point you have to cut your losses, because if you fall into the "one more" syndrome, you'll never have a release that's stable enough to bring new users in. |
| | | 1 (8%) | |
|
|
Total: 13 |
7. Development Process: Proposals for change--issues addressed and why the change will help.
|
| |
We definitely need to focus more on testing, which we're beginning to work on. Otherwise, I think we are mostly on the right track. Again, this does not solve the problem you described above. The lack of focus on testing should go in the problems section, and you've failed to offer a solution to either of the issues you've presented. These are important problems, so offering solutions is important. |
| | | 1 (8%) | |
|
|
| |
- I personally need to continue to keep priority on making sure formal documents are updated, and use a combination of communication channels to keep everyone together. My experience has been that miscommunications can happen in both scenarios (although informal face-to-face or im conversations allow for these to be settled more quickly, but conversely don't have permanent records), so I think if we can find a compromise between the two that will be best. A good starting point might be considering what kinds of documents are helpful and then the frequency at which these documents are still helpful.
- I'm going to look at this problem and determine how we can apply the principles of good design to fix it. I think many class members are too focused on the problem at hand to realize what's causing us the difficulty (despite repeated warnings by Dr. Wong).
|
| | | 1 (8%) | |
|
|
| |
I hate to be too strict about censoring discussion, but that may be the only way to go over all the information that needs to be gone over. Class meetings just aren't long enough. It's bad when there isn't time for fun on Fun Friday.
Yes, I think we need to more strictly stick to an agenda. Having it openly known would help. I think we can actually work together to do a better job here (and we really need to). -brad
For assigning people to tasks, I think it's just a work in progress. Part of it is research about what people are interested in, part of it is just observation of which tasks they seem to take to. I think we have a good idea of that by now, but it's always improving. The other thing is just trying to be better about estimating the amount of time and people for a given task. That unfortunately is a continuing battle. The best thing I can think of is to keep learning from the decisions we made before, and how they worked out. It is difficult to estimate the time needed for various tasks even when you've had some practice, but there are some things you can do to help yourselves. The best guess you can make is based on the opinions those who are close to that part of the code base. Basically, ask the team leader over that part of the project! Beyond that, sometimes tasks are uneven, but that's where communication comes into play. --Chelsea |
| | | 1 (8%) | |
|
|
| | I hope this next week is as good as the last one. We'd be done with the project by December if that's the case :-)
For the second issue, the solution is quite simple, which is to remind everyone that even if a build works on your computer, to understand that you may have coded something that works in your environment but could be completely broken for a similar but slightly different system. It doesn't hurt to try your code on multiple browsers (I've tried Safari and it works seamlessly btw) and possibly on multiple systems (remote desktop is a great blessing for this). |
| | | 1 (8%) | |
|
|
| |
- The group is creating a new team devoted to testing (headed up by Derek...don't let him near your tables!) which allows us to internally test our builds before deploying it Skynet. (Can you make sure this team is documented somewhere for the staff? Thanks.) This allows us to better control the quality of the builds before the users get to handle it. There is, of course, the issue of diverting manpower when we have so little to spare, but this is a critical issue that demands the extra burden.
|
| | | 1 (8%) | |
|
|
| |
- Really, the best way I can see to fix this (in the future) is improve the documentation and maintain open lines of communication. I admit, Matt, I know how you feel when e-mails are not replied to at the very least now so let's all try to
- always respond to emails/voicemail/im's even when you have no initial response. Wait. Scratch that. You should always have an initial response, and that's to at the very minimum acknowledge that you received the message.
- make yourself available as much as possible - OR we should at least make sure other people who may or may not need us know when we are/will be available. A good idea might be some "hours available" list on sharepoint. I think that's been juggled around a bit before as well.
- Stated simply: everyone needs to make sure that their code is well documented. We need to make sure the documents on sharepoint are up to date. Weren't we going to use Sandbox or something named similarly to generate the documentation? What happened to that?
My suggestion: Assign a person to take 2-3 days (I know we're hard pressed for manpower, but this really is necessary) - give them a whip and have go through the documentation on sharepoint, ready to reign terror down on any team leader whose documentation isn't up to date. Also have them figure out how to get Sandbox/whatever working. |
| | | 1 (8%) | |
|
|
| | Here is my less-than-realistic "Start earlier and get more work done" solution again. I don't know what else I can do other than to do my part. I could probably encourage other team members to do their parts if I need their parts to make the whole system work. I have not gone to the last coding party but I think I will make sure to go this week so that I can feed off of other people's energy and motivation and motivate myself to do more work early on.
I agree; this is slightly less than realistic, although your problem is a bit difficult to have a concrete solution to anyway.. |
| | | 1 (8%) | |
|
|
| | The main problems we faced had to do with interaction with the backend. This was addressed very well by Aaron's announcement, which I believe he will be turning into a document very soon, that described exactly how to use a backend object.
We cannot really address Luke when it comes to paying attention to the demos. It is a little hypocritical that he is not paying attention during presentations when he points out the same in us. However, we can slow down presentations a bit. This will be up to every presenter to implement, and I guess for other attendees of the meetings to vocally point out when it is happening. |
| | | 1 (8%) | |
|
|
| | We could probably have a more forceful Time Czar, but I don't think he can really do much if the meeting agendas aren't published ahead of time. That's something we can change, though.
|
| | | 1 (8%) | |
|
|
| | -I think talking/assigning new things, as Brad is doing, is the best solution Though the problem ma not be solved, I think we're trying to work on it. |
| | | 1 (8%) | |
|
|
| | I think Matt kind of ran out of steam towards the end of class, and it being a Friday and all, people were just exhausted.
Corey asked when we will freeze features in class today. This is actually an important date for us. With product delivery coming up, we have to be able to say which features do work and which features we won't implement or don't work at all. Not only that, we need to have documentation on all of it (which is still lacking). I think everyone has been too busy trying to get features to work to write documentation (I have been trying to comment new methods that I've added).
Brad has begun the notifications features, but we can't expect him to complete it by himself. I'm not sure how we can get people to work on these new features, other than waiting for them to finish their current ones (and it seems like the search team might almost be done). |
| | | 1 (8%) | |
|
|
| | I will discuss this with Felipe. It would be good if he can bring his laptop and show me the error. |
| | | 1 (8%) | |
|
|
| | As for the first point, I'm not really sure that there's a good way to address it, since we're on such a rapid development schedule that our task lists never stay steady for very long. I certainly don't expect Brad to update the lists on an hourly (or even daily basis). Why not update them yourselves when you realize that your tasks have changed? Perhaps a blanket milestone should be to clean out all tasks/bugs in Trac that are listed as critical or blocker for that milestone, and try to close as many lower priority ones as possible.
The second point -- I could have pushed harder in class but I didn't want to belabor the point when some people wanted to move on. I'll try to keep pushing this, for main reason that this is a standard development cycle that has worked for many, many people and companies, and there's no sense defying that, even if we're under strange circumstances. We should really try and have all features added by Monday at the latest, with bug fixes happening on Tuesday and Wednesday. Wednesday should also have a focus on testing, and anyone who checks something in should be diligent about testing it and making sure they don't break anyone's code or any part of the site. Then at midnight the snapshot is deployed to the server for beta testing, and that's it - any bugs that pop up will have to wait until the following week so the fixes will have ample time to get tested. It's a good sign that you want to stand on the shoulders of giants on this issue--to take it a step further, I don't think you're really in that strange a position. Real-world programmers constantly divide their attentions among various projects. |
| | | 1 (8%) | |
|
|
Total: 13 |
8. Peer review: Positive or negative feedback for other class members
|
| | This week we pulled together and got stuff done.
I'm so proud.
We are a team.
[I will say more about individuals later, but I don't have time now - needless to say there were a lot of stand out performances this week] |
| | | 1 (13%) | |
|
|
| | I'm really proud of everybody for the things I've seen that I mentioned in Dev Process: what is working.
Also great job to everyone for getting the site ready for beta.
Felipe is doing a great job lately, taking care of all kinds of other tasks besides authoring stuff. Lots of initiative. I think he's after a raise.
Aaron did an awesome job of compiling up a huge code compendium. Thanks!
Sohum is the red ninja. |
| | | 1 (13%) | |
|
|
| | Thanks to Derek and Aaron for walking me through the sorting process from their sides of the project and Corey for lurking around fortunate places, talking me through the AbstractTreeParser, and reviewing the code after it was written (catching two bugs in the process). |
| | | 1 (13%) | |
|
|
| | Rae - your game is evil...EEEEEEEEEEEEVIL! I think the controller singed my hands when I was playing around with it, it's just that cruel.
Derek - Sorry again, for hitting you in the eye with the noodle thing today :( |
| | | 1 (13%) | |
|
|
| | Everyone in this class has been working really hard for this class and it shows in our weekly progress. I want to thank everyone for their hard work, and some of their works are not necessarily visible but I know that we're working well as a team. Without each part we wouldn't have what we have now. Yay go team! |
| | | 1 (13%) | |
|
|
| | I'm pleased with how everyone is doing. Things are coming together very well.
I don't think there's much I can say badly about people. Well, Felipe is ugly, but no one can really do much about that.
Damn it, Aaron, why do you have to make this public knowledge?!? I'm gonna have to add you to my noddle target. --Felipe |
| | | 1 (13%) | |
|
|
| | -Jeeyun did a great job getting search to work. I was really happy with how she was willing to step through problems and try to find the source of problems, and not just assume it wasn't her. She did a much better job of this than I. |
| | | 1 (13%) | |
|
|
| | Kevin and Dave, you both did great working with other teams and getting your work done. If you could start a little earlier next time, it will cause me less stress. :) |
| | | 1 (13%) | |
|
|
Total: 8 |
9. Additional Comments
|
| | Sparse and a touch disorganized. |
| | | 1 (9%) | |
|
|
| |
Argh, ordering hosting without asking.
Should have figured as much. Good journal. |
| | | 1 (9%) | |
|
|
| | Good journal. |
| | | 1 (9%) | |
|
|
| | YAY for 410 toys. My first targets: Chelsea and Kristin. Those evil TAs are going down! Not if I get you with my pipe first... That won't fly in 25 years, you know. |
| | | 1 (9%) | |
|
|
| | Beware the noodle! |
| | | 1 (9%) | |
|
|
| | We need to have a noodlefight tournament (edit: with goggles!). Help the TA's rack up them fantasy points too, eh - just like the Finals, right?
Good journal. |
| | | 1 (9%) | |
|
|
| | I agree with Matt - Sohum is a red ninja. The last picture on sharepoint where he's attacking a teammate with a noodle is my favorite picture. |
| | | 1 (9%) | |
|
|
| | Damn straight I are a Red Ninja. |
| | | 1 (9%) | |
|
|
| | I like my noodle. |
| | | 1 (9%) | |
|
|
| | -My tablet just crashed...and I have to restore from whenever the last recovery-thing was done, which is probably right before I got it. So I get to deal with that. It just happened about 10 minutes ago, so I'm on another computer to do my journal whilest I figure out how to try to recover what I can. yay. Arggg!!!!! (Sorry if the journal is short, with my tablet crashing, I'm a bit frustrated...)
Understandable, and I hope you get it fixed soon. You are right though--your journal is definitely short and sparse compared to previous weeks. |
| | | 1 (9%) | |
|
|
| | Ring ring ring ring ring ring ring... Bananaphone! |
| | | 1 (9%) | |
|
|
Total: 11 |
|
|
|
|
|
|