Journal Entries, Week #4

Quick jump to: alio, beowulf, jamesmcd, jkdot, jsegars, lipinski, localguy, othello, rjmorgan, ryanaip, thewang, tjice, wrprice, swong.

----- ALIO -------------------------------------------------------------------------------------------

Journal for Milestone 2

Status:

· 30% completed

· The Milestone that is completed so far was to document the handshaking of the behaviors.

o This can be seen at http://www.owlnet.rice.edu/~alio/Behavioral Flowchart

o This is the current flow of the model.

· Currently I am going to meet with Gilbert this weekend to discuss the structure for the attributes that people will use for their decision making process

· During the early part of next week I am going to systematically go through the current model code to comment places that need more explanation and point out “hacks” that were done for the first milestone.

· Once I have completed Operation Cleanup I am going to implement the linked list data structure that was originally considered.

Obstacles encountered:

· Now that we are at a point with our planning we have to rely on other people for their knowledge.

o For instance we must know things about the UI as well as some information about remoting from the AR group.

o We all know that we need “something” but actually pinning it down has been difficult. Absolutely. Drive the issues from your needs. Sometimes this is the point to actually try to write some code that does something real—your needs will rise right to the top when you do this.

Solutions proposed:

Analysis of development process

· The group structure is working out very well, people know who to talk to and we have mirrored that in our MS2 documentation for the Model group.

What seems to be working –

· The meetings between the group leaders seem to be very helpful. People from each group seem to be more knowledgeable of different parts of the project than they were even a week ago. Though this could also be attributed to the current status of the project. However, the fact that there is still such good communication is a very good sign about the health of the project.

What seems to not be working –

· People know ambiguities about what they need, and some groups are asking for the same things from each other. I think this will be made more concrete when we try and port our stuff together for MS3.

Proposals for change

· Milestones are a good idea but if they had a date posted to when they were due, I think that would help us plan better. I know a couple of us were confused about the due date. Done.

Nice journal.

----- BEOWULF -----------------------------------------------------------------------------------

Status of Milestone

Gains Made: The UI group has made some important progress on our milestones. The manager has been improving with input from DXN that is coming from Kijana. User testing is going to improve this further. Further mockups of a store creation wizard and client UI are on the way. Additionally, the renderer is maturing along with an IRenderable interface. Hopefully we will be able to plug the renderer into the UI very soon and clearly define an API for the other groups.
Obstacles: Conflicting schedules for partners to meet.
Recommendation: Find a regular time and stick with it as it was a regular class time—that’s what it is after all.
Proposed Solutions: Just being flexible and working odd hours of the night. Structure does wonders however. Too flexible means that nothing will actually get done.

Analysis of Development

Whats Working: Devhood is working. Communication between the groups is improving, especially now that the group leaders are providing a single point of communication. Its going to be exciting to see the different pieces come together into one actual program in the upcoming weeks (hopefully!). I’m also anxious to get CVS going.
Whats Not Working: Tough to set hard goals for milestone. User tests and input from DXN provide ambiguous ways to improve the user interface.
Proposed Changes: User tests are going to be an ongoing process for the UI group. It should almost be assumed that this will be a goal for every one of our milestone. As new pieces of user interface come out they will continually be evolving. Unit testing may help some of this, but we need to analyze how effective unit tests will be for a continually changing UI, as opposed to user tests.
Look back to your stories for guidance. Can you make your stories more specific?

Nice journal.

----- JAMESMCD ---------------------------------------------------------------------------------

Status of this week’s milestone:

·Gains made: We constructed a task breakdown that will work very well for making progress. It breaks down our group’s goals into very defined, manageable pieces. I have come up with a model for how to move people between rooms and Will and I are getting together to compare that with the API for the remoting to see if it will work. Bryan and I have begun work on a nice temporary GUI that will allow for very precise testing of the system. Keep the UI people in the loop for this. You could save them a lot of work. We are focusing our attention on making our model extendable for any interface. Creating one is really helping us do this.

·Obstacles encountered: A lot of time was needed to actually break down the tasking for this upcoming milestone. We have reached a point where we now have to make very specific decisions that will affect systems already in development. For the last milestone everyone was more or less waiting on our structure before they could do much. Now they have systems developed and what we do may force them to change that. It also just a very hard system to define.

·Solutions proposed: Lots of discussion as to generate a design that is well thought out. Lots off work, and when it comes down to it, just making a decision and sticking with it. Keep your eyes open!

Analysis of the development process:

·What’s working: The time we spend in class just talking in our groups and talking with members of other groups. We’ve gotten beyond the need for abstract, large group discussions and letting the groups work nicely uses the time we are all together. Devhood is working very well also. With that addition I think we have finally formed a good communication system.

·What’s not working: A CVS system. No one wants to figure one out and deal with the hassles associated with it, so no one has. Fixed. Thanks Ryan.

·Changes proposed: Just task someone to do it. None of us want to, but someone has to. Someone also has to maintain it. This will give each group the ability to integrate the other group’s code into theirs more easily. Hello group leaders?

Nice journal.

----- JKDOT ----------------------------------------------------------------------------------------

Milestone:

Milestone 1 is complete. I am moving on from that into the second milestone. Again, I'm paired up with Jeff to continue work on the second phase of the prototype. We will continue by making revisions to the first model (as per the customer - however, there were very few suggestions) and work on a mock-up for the shop owner interface and the set-up windows ("wizard" that guides users step-by-step to setting up the simulation). My tasks include:

· Improve the interface based on the customer's comments and the UI group's discussions.

· Continue research and analysis for interface design.

· Begin to put together task analysis for user testing. Actual user testing with the interface will come after the interfaces are prototyped.

· Document and broadcast my findings/testing/research.

· Help with identifying where the work from other groups will hook into the interface.

Gains made:

After meeting with my team in class this week:

· I feel more comfortable about the project and the communication.

· I'm finally set up on DevHood and have posted a couple of announcements (I'm getting over my fear of talking/posting).

· In our group, we discussed the status of the renderer and what should happen next (since this is the first thing we've got to put into the interface).

· I demonstrated the mall manager mock-up for Dr. Nguyen. As he played with it, I observed his actions and any difficulties/good things he encountered. We also discussed features that would be present that weren't in the first prototype. He also clarified some things (see customer meeting update on Projects page).

Obstacles encountered:

I didn't encounter too many this week. I've just got to buckle down with my research material and figure out a good, consistent way to inform everyone of my thought processes. Post, post, post!

Development Process:

Seems to be working:

· The UI team seems to be on the same page. I like how we can discuss things and find the answers to problems. I guess that's the advantage of a small group.

· Meeting with the customer - he's fairly open to meeting as often as we wish. (Having Dr. Wong around helps, too!)

· Communication in our team is getting better

· Communicating to the rest of the "company" - Dr. Wong gets my stuff online fairly quickly. I don't know if anyone reads it, but hey, it's there... Of course they read it….right?!!!!

Doesn't seem to be working:

· I think there are some integration issues. First, we were too big and nebulous and it seemed as if we weren't communicating at all. Now, we're segmented and talking amongst ourselves, but not really to one another (outside of class). I think the DevHood idea is a great idea and will facilitate this.

· Lab times. I still can't come in on Friday, but my team is willing to catch me up on what I miss.

Suggestions for change:

· Problem: Gap in communication (we're still not sure what we need from everyone else and what they'll be capable of).

· Possible solution: Perhaps we could mesh the groups a little on a temporary basis. One person from another team would sit in on a team's meetings/design sessions and be able to give instant feedback. He'd also be able to discuss limitations that his native team has and perhaps provide solutions. He would go back to his native team and share the knowledge. I have NO idea if this is plausible or not. Hello group leaders?

Nice journal.

----- JSEGARS -------------------------------------------------------------------------------------

Milestone: Dummy UI

(Mall and Store Creation Wizard, Store Management, Usability Testing)

Gains Made

The early part of this week was spent tasking the UI for the next milestone. My specific task is to continue with creation of dummy interfaces. Specifically, I’ll be working on mockups for the mall creation wizard and store creation wizard as well as the store management UI. In the later part of this week, I decided on a wizard framework and was able to get the mall creation wizard running, although it still needs some tweaking. I also found a user control that I was not previously aware of, the PropertyGrid, which I think will be very useful in allowing the user to edit complex information such as demographics. This control is the one used by VS to allow you to edit the different fields in a user control when you’re building GUI (in the bottom right hand corner of the screen).

Obstacles

One of the obstacles I ran into this week was the lack of documentation on the PropertyGrid. Searching Google yielded the same articles over and over again, along with many message board posts complaining about the lack of documentation. I think this control is something that could be very useful though, so I’ll probably be spending some time early next week trying to figure out how it works. Another obstacle came up in reading Dr. Nguyen’s comments on the user interface we provided at Milestone 1. Specifically, he thought the mall map should always be in “zoom mode” so that you didn’t have to select a tool to zoom in or out. This seems like a bad idea to the UI group members because it would break right click functionality that we see as very useful. If the customer wants it, I guess that’s what we’ll deliver but we may try to steer him back toward a zoom button.

Can you get events from the mouse wheel? Some programs tie zooming to the wheel, along with a button on the UI.

Development Process

What's Working

The division into teams in last week is still working well. I have much better idea of what’s going on inside my team and I also like having a designated leader who can meet with the other groups and give us an overview of what’s going on. It was also very helpful to take some class time to determine what we needed from every other group.

What's Not Working / Change

The main issue that I’m dealing with right now in the development process is tasking of the UI. As we talked about in class today, Kijana and I need to tighten our milestone so that “improve the mall manager interface” is not so vague. Tasking certain parts of the UI development process brings up some complication that I’m not sure how to deal with. At each stage of the development process, we plan to perform usability testing on subjects and then make refinements based on those tests. Since we don’t know what usability problems our tests will turn up, it’s difficult to determine what improvements will be me made in the UI for a certain milestone. We could always split our testing and improvements across two milestones and be able to detail exactly what improvements we will make, but this seems to be avoiding the issue. How can we come up with a concrete task (improving the some part of the UI) when that task depends on another part of the same milestone (usability testing)?

Remember that code is an evolving entity. Improving the UI, code and feature-wise is one step, usability testing is another. Then the process cycles back to writing code. Task one cycle at a time, i.e. one set of code improvements and one set of usability tests.

Nice journal.

----- LIPINSKI -------------------------------------------------------------------------------------

Milestone:

· Work with the UI group to define the interface between the UI and the model. (Make the controller). (20%)

· Use the interface to connect to a mock UI. (20%)

· Work with Jim on creating factories. (0%)

Gains Made: I am done with most of the planning phase of how to create the control object, and more importantly how to connect the model and view with it. I also created a UI for testing multi-store interaction on the same-machine.

Obstacles Encountered:

· Determining how to set up the interaction between GUI and Model. Should they be directly linked? How do we deal with dynamic factories? Push or Pull?

Solutions Proposed:

· Knowing that a high amount of flexibility is wanted in the system, I knew that using interfaces to communicate between the two would be ideal. I’ve talked to the UI group, and I know what kind of system they are expecting, for the most part. The model will be controlling movement and such, and when an object moves, or changes shape etc. a dirty field will activate on the object. The GUI in the mean time is asking the model for a list of all the “dirty” objects, and then repaints them, or does whatever with them. Furthermore objects will have an “attributes” index, in which the UI can shove whatever it decides, possibilities include graphics etc., or nothing at all.

· After talking with Dr. Wong, I’m going to try and push a factory/interface controller. The plan is for a set of “UI” factories, which can make panels. These panels in turn are directly linked to the “Model” factories: personFactory, storeFactory, and itemFactory. This allows for the factories themselves to be very flexible, in that the control panel is made in an easily adjustable factory. Furthermore, after the creation of a store, the store will return a concrete interface class, which acts as a gate through which the actual store can be accessed. The objects and people will be directly deposited in the store, and can be accessed through the store, which in turn is accessed through the interface. I’ll try and have a UML diagram to detail the specifics, and set the API.

Development Process

What’s Working: Working in distinct “groups”: Model, UI, AR. By doing so, we can concentrate on a specific part, since trying to examine everything all at once, currently, is quite overwhelming.

What’s not Working: Getting my milestone so late in the week didn’t really give me much time to think about it, or even do anything with it.

To Change: Have the next milestone worked out completely either the day the previous one is completed, or shortly there after, so that we can get to work on it. My weeks can get pretty hectic, giving me the odd night and weekends to work. Not knowing my particular milestones until half-way through the first week drastically limits the amount of time, I am able to devote to the task.

That means a lot of work on the Friday that the previous milestone is due and the weekend that follows it. But you’re right, that up-front work makes the rest of the time much more efficient.

Nice journal.

----- LOCALGUY ---------------------------------------------------------------------------------

Milestone (Commenting RemotingLib):

Gains Made: I commented the RemotingLib code and generated the documentation using Visual Studio. I found a really nice document at: http://msdn.microsoft.com/msdnmag/issues/02/06/xmlc/default.aspx that explains the various existing C# comment tags in detail.
This is the sort of info that needs to be moved to a permanent, easily accessed store.

Commenting the RemotingLib really helped me to understand what was actually going on inside the library and I plan on writing a small tutorial to post on the web site. I also met with the AR group for a few hours and we discussed how the RemotingLib works and how we might want it to work at a higher level. We also discussed how the network may eventually be laid out.
Obstacles Encountered:

o We never came to a complete agreement about the network layout. Initially I was thinking that everything would run off of one central server as a star with several clients branching off of it. This implementation runs into scalability problems and it seems that we might be better off with several “mall corridor” servers for a group of stores. This method would releave any mall server of having to deal with all of the traffic. Theo also introduced the idea of running the customer AI off of separate machines to further take some of the load off of the client machines.
I would not recommend worrying about load balancing for computations within a single space at this time. Remember that a mall corridor involves minimal interactions between its entities, so the computational load may not be that high. I would take a “run it and see” approach.

o Visual Studio would not let me generate comment pages on the exciton server. I copied the folder to my home directory and everything seemed to work fine with my own copy so I guess it may have been something to do with permissions.
More specific error info please!

o I am not exactly sure what I should be working on next with this project. Hello group leader?

Solutions Proposed:

o I think that the AR group needs to start working on some specific tasks instead of purely researching. It is hard to feel like I am contributing when I am reading up on web services or playing with remoting. In class it was brought up that we might want to start working on a general beta. I think that this is a great idea. For the short term I am going to look into NUnit and see how it works so we can start testing our code. I plan on meeting with the AR group several more times and possibly working with the model group on working with their code.
Think of this issue in terms of the AR group delivering turn-key solutions to the other groups. Thus the AR group needs to take the other groups’ usage stories and implement them.

Development Process:

What seems to be working?

I really like how the groups have split up and are having meetings about what needs to be done within the groups.

What seems to not be working?

I would like to see some more direct interaction between the groups. Perhaps someone from our group(AR) could sit with someone from the model group and get some networking task underway that the model group would like to accomplish. As far as I know Will and Jim are working on this right now. It would be nice to have something solid to show for our work.
Is there an echo in here?

Proposals for change:

I would like to see more demo code in class. It’s nice to be able to run the GUI on my own, but I would like to hear someone from the UI group talk about future options for the GUI or what might change in future versions etc.
Good point. The demos don’t have to be perfect, just enough to show where the group is going.

Nice journal.

----- OTHELLO -----------------------------------------------------------------------------------

· Milestone Status:

Gains: Appreciable change has been done to RemotingLib. The actual RemotingLib projects works now, contrary to my last journal post. The problem was with WellKnownObjectMode.SingleCall, which I was using to give a hook to either side of the Client/Server handshake. Since the local/remote queues were returned by the SingleCall queues, the backend (realProxy) was being re-instantiated each time a call was made to it, so what would happen is that each time you sent something, the queue would be remade, and hence the old objects thrown away.

The solution was to make the objects use WellKnownObjectMode.Singleton, which would allow the object to persist. However, the previous edition of the library had assumed that these objects would only persist for the session between the client and server, so measures had to be made to decouple the session from the Singleton hooks. In addition, these hooks were renamed to “Managers”, since these objects now persist, to manage the handshaking. A unique ID is generated whenever a call to createQueue() is called, one that is unique across the application domain. The current algorithm for generating unique ID’s that are non-guessable is pretty straightforward. It looks in the current table that maps ids to queues, and creates random ints until it creates an int not in the table. It should happen in nearly constant time if the table is small, and I think we can assume that it won’t be *too* big – at least not seriously approaching 4,294,967,296 (which is of course 2³²), as one would have grave concerns regarding memory representation at that point.

So now both sides manage unique ID’s for their queues, and they ask the managers for references to these queues in the Connection creation process.

I also added the ability to use a “push” model mentality, as well as a “pull” model. It seems immediately obvious that a “pull” model would function correctly, as in a Remoting connection, if the server you communicated to is handing you back a reference (marshaling by reference), then it can also return references to objects as part of function calls. In order to send objects are return values though, you’d either have to pull them by user demand, or you’d have to have a thread automatically pulling them in the background. The extra thread idea seemed a little too heavyweight, as it would require an additional thread for each side, for each connection. Or, actually, we could use a static thread that swept continuously through all the instantiated connections so far, and pulled any objects as necessary.

The “push” model is more intuitive to users – whenever an object is sent through “sendObject”, then it is immediately put onto the other side’s queue, ready to be dequeued as demanded. The only problem is that it’s not immediately obvious that if you have a remote object’s reference, that you can immediately pass in a reference to one of your local objects to it’s method call (which would be necessary to enqueue a reference to one of your local objects). However, for some reason, it works when I also implemented this model. It seems that since a remoting connection has been instantiated from both ends to the other end, then it knows how to juggle the objects.

The model used for the remoting connections is abstracted in the IConnectionFactory, which is internal to the remoting library. This allows us to swap out the factory quite simply (just by changing CONNECTION_FACTORY to PUSH_FACTORY, or PULL_FACTORY) as needed. Since the factories don’t do anything except take in two queue references (and the handshaking is still private) then it wouldn’t be too bad to expose the choice of factory to the user. However, it would require both sides agreeing on what type of connection to use.

The newest version of RemotingLib as of this journal entry is at http://www.owlnet.rice.edu/~othello/comp410/RemotingLib.zip

o Obstacles: There is still no way to close existing IConnections nor is there a way to stop listening on a port, as a server. In addition, RemotingLib exceptions should be thrown, instead of the underlying Remoting framework. None of the underlying Remoting framework is really exposed, so their exceptions should be handled / rethrown differently.
Nice. It’s just as important to document what your code does not do.

o Proposed solution: As part of this milestone, I’m supposed to read up and research more on Remoting. I’m hoping that this will give me a means to “close” remoting connections, an the like. I figure that all of my “obstacles” can be resolved with enough digging around.
You will get more directed results by using a more directed approach of being motivated to implement a specific task requested by the other groups.

· Development Process:

o What’s working: Believe it or not, I haven’t really been working with a partner and I haven’t experienced any severe drawbacks. Then again, it could be very possible that a partner would have found out the answers to my “Milestone obstacles” already. I also enjoy the milestone nature of this development process, as it doesn’t feel like I have too much work, but my schedule doesn’t always allow me to work little-by-little on a consistent basis. However, a reasonable amount per week (such as a milestone) can be juggled by a couple of hours here and there, not necessarily one or two hours per day.
Please work in a team. One of the important things generated by team work is group cohesiveness and better communication.

o What’s not working: I feel like classes are somewhat unproductive, and a lot of time is still used for communication.

o Proposals for change: I think group leaders should meet outside of class, since they are supposed to have diminished work-loads since communicating is supposed to be part of their duties. More time in class can be used for work tasking, and meaningful information exchange.
An implicit issue here is that everyone needs to come to class with questions that they need answered by someone else.

Nice journal.

----- RJMORGAN --------------------------------------------------------------------------------

Gains made

I have developed the front end for an application that will demonstrate the ability of the AR group’s remoting library. Currently I am able to make connections between processes, but I must revise and test this application to remote objects between two different servers. I also must work with Theo (Hello Theo?) to add more functionality to the remoting library.

Obstacles encountered

The remoting library does not seem to be receiving objects correctly. I am able to send objects to another process’ object queue, but for some reason the other process will not read correctly from the queue.

Solutions proposed

I will work with Theo to ensure that the remoting library is fully operational. This may include comparing my code with his test code to determine what I am doing wrong, and additionally what other people might do wrong.

Analysis of development process

What seems to be working -- why?

The AR group is working well at determining specific milestones for each member. We have not been pair programming, but the majority of our tasks do not lend themselves well to pair programming. I disagree. Regardless I believe that Will is doing an excellent job managing the team and the other members are working well with Will.

What seems to not be working -- why?

The model group was quick to dismiss our need to work with them on designing the layout of the distributed network. I think they believe that there will be few programmatic limitations with our remoting framework, but they fail to realize that we are also concerned about the system requirements for running our application. How we design the network has a direct impact on the number of servers our customer and his clients must have in order to see benefit from our application.
An interesting issue – how do you convince someone that they need help when they don’t think they do. I think you’re on the right track—try to build what they say they need and then approach them when the problems you knew would come up, actually come up. Then you’ll have something concrete to show them.

Also it seems like our group has very few tasks in the upcoming weeks. This is leading to very small milestones for members of our group, which is not good in the broader picture. We really need to know what else other groups can demand of us, and whether we might eventually change our focus away from AR.
Focus on delivering those turn-key solutions. Part of the reason for “lack of need” is “lack of code”.

Proposals for change

The model group and other groups need to communicate with Will and with the rest of us about the requirements they have for us. After this week our group will need to sit down and discuss our future milestones in order to determine whether we might present ourselves back to the class for assignment to other tasks. These two steps should start the ball rolling on solving the issues described above.

Nice journal. Please switch to a bulleted format however, as it is more consistent with the layout everyone else is using and thus makes it easier to read.

----- RYANAIP ------------------------------------------------------------------------------------

Development Status

Milestone Progress

This week has been spent primarily on organization and planning. I put together a milestone plan for the model group and helped get different members of the group assigned to tasks. Additionally, we’ve started talking to members of the UI and Advanced Research group about what we need from each other – I think we’re at a point where we can sit down and define the adapters between all of our different pieces of code.

Along those lines, I’ve also put up a code base project in SourceSafe. The project contains sub-projects for the model, view, controller and tools. I’d suggest that each group add their code to the repository over the weekend. I think that this will help us out with communicating what’s available between groups – especially if each group links documentation for their code directly from the project. I’ll post instructions for viewing the project on DevHood.

As far as the coding aspect the next milestone goes, I’ve been concentrating on projects for other classes this week, so I’ll put in extra time coding next week.

Process Analysis

I like how our breakdown into three groups is working. We’ve started communicating more closely between groups and figuring out what we can do for each other. In fact, I’ve felt busy this week just in getting the right people in my group talk to the right people in other groups.

I do think that we need a faster method for disseminating persistent information – Stuff that’s longer term than DevHood. In particular, I’d like a place where it’s easy for each group to post status updates and links to documentation. Would it be possible to give each group a folder on the web site where they can post and organize their own information? That can also help to lessen the load on Dr. Wong to post everything.

I will try to set something up.

Along the same topic of faster information dissemination, I felt that we took a little long in assigning milestone two tasks after finishing milestone one. If we continue like this, we’re basically setting ourselves up for a work for a week – plan for a week process. I think that it should be the job of the group leaders to post new milestone tasks over the weekend after a milestone is completed, perhaps after meeting with the other group leaders during lab time to coordinate.
Exactly. See my comment to Bryan’s journal where he discusses the same issue.

Nice journal.

----- THEWANG ----------------------------------------------------------------------------------

Milestone goals:

· For the upcoming milestone, I will have attributes/properties and behaviors that will be executed depending on some combination of attributes/properties.

· After talking with Dr. Wong on Friday, we will make a decision about how similar attributes and behaviors are and how they will be represented.

· The code will work with the code that has already been written to simulate people, items, and spaces.

Milestone gains:

· Discussed attribute implementation with group, making decisions about various issues involved in implementation, specifically accessor methods required by the UI group and role of demographic data.

· It was extremely helpful in having a group discussion about the various needs of the model, and then breaking it down from there. Having a glimpse of the overall big picture is important in understanding the needs for your individual part.
This is part of programming with your eyes open, isn’t it?

· Communication (both among group members and across groups) has greatly improved, especially thanks to the leaders.

· I was sick for the first half of the week and hadn’t written much code for my milestone yet, though.

Future concerns:

· Integrating code among group members and among other groups (although, there shouldn’t need too much integrating among groups). It’s just that we’re learning technologies at the same time as creating code for our project. There’s just lots that could go wrong (though I don’t think it will).

Proposals for change?

Using a journal format consistent with other people’s (i.e. bulleted breakdown as to the journal requirements) makes it easier to compare what people are saying. It was hard to find all the pieces in your journal.