Journal Entries, Week #10

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

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

Journal number 10

Status:

· Some of the suggestions from the code review have been implemented. Specific classes have been optimized or made more concrete.

· I’m currently working on adding more relevant behaviors, an example of which is a non-random decision behavior.

· Also rudimentary unit tests have been completed. There will be more of them by the first of the week. These are important because one of the suggestions mentioned using visitors and changing structure for this without unit tests would be a bad idea at this point, or at any point, but especially now with so little time left for overhaul.

What seems to be working –

· VS .NET in the labs will be cool once it gets set up. I think it will be a huge help.

· The refactoring tool that Ryan found is a very good program. Props to that.

What seems to not be working –

· More problems with SourceSafe. It was having issues with adding or classes to the project. We don’t know why it started doing this but we found that if this problem happens: check out the entire project and check it back in and that should work.

Looking ahead

· Good luck to the AR team for implementing web services. I would start by getting a simple space to run on the PDAs and build from there. But since I don’t really know that much about remoting and services that’s just me talking.
Or is it more reasonable to just get the UI running on the PPC?

· If anyone has ideas of cool behaviors they might like to see added to the mall feel free to tell me.

Nice journal.

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

Status of Milestone

Gains Made: Jeff and I made some important changes. We are happy to report that the GDI error that gets thrown every 2 seconds is now gone, J we also made a bunch of changes that were suggested in the code review (for example closing the form actually does close the process now J). We will spend the rest of the milestone implementing nethub and working on a pocket pc gui.
Obstacles: Nothing especially challenging this week. Getting a development environment setup to get a gui on the pocket pc will be a challenge. Also, working on exciton has become too painful. I’ve switched to using my laptop for all vs.net development.
Proposed Solutions: We will have to read up on pocket pc development a little bit. Hopefully there is some decent documentation out there to work with. Using my laptop will be much easier, with wireless ethernet in symonds since the new install of vs.net turned out to not work too well.

Analysis of Development

Whats Working: Basic code cleanup is working well. If everyone goes through the code review changes, the project will look a lot cleaner.
Whats Not Working: We need to be realistic about getting something on the pocket PC. At the least we should get some GUI showing up. Whether its connected to the model or does something meaningful remains to be seen. We will need to work toward this, but time is running short.
Proposed Changes: With one milestone left after next week, we need to prioritize for the final stretch. Its almost more important at this point to get to a point where we can present something that looks nice, then actually getting it working underneath. We should make an effort to justify the purchase of our pocket pcs.

Nice journal.

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

· Status of Milestone

o Gains made: I have started to replace the current connection scheme (using RemotingLib) so that it uses the new NetworkingHubLib system. I have also started creating a cumulative list of things that will require a connection between stores to help in designing an extensible remoting system for the project. Examples of these “things” are passing people from store to store, passing spaces as proxies to the server to draw the entire mall, and passing proxies to clients so they can design the entire mall.

You should post this list to DevHood so that everyone is on the same wavelength and understands what needs to be done.

o Obstacles encountered: Replacing the old system has a considerable amount of overhead and completely breaks the project unless it works perfectly. This makes it very difficult to increment in small steps, testing as you go.
It’s important to think about why this trouble in replacing the RemotingLib is happening so you won’t repeat the mistake. In theory, it should have been a simple, behind-the-interface issue, but it’s not. What was wrong with the original API and how could that have been avoided?

o Solutions: Finding a large block of time to just do it. Also, pair programming would work very well on this, however we’re all tasked and it will be difficult to get two of us together to work the whole thing out.

· Analysis of Development Process

o What’s working: The design reviews were more helpful that I expected. Also, since we have 4-5 people on a group, some people can be taking care of issues brought up in the design review while others can focus on taking the next step in functionality. This prevents us from standing still for the rest of this milestone.

o What’s not: Coordination. There are lots of things to be done for every group (from rewriting the GUI and connection system to work on Pocket PCs to adding the behavior to people that will make them act intelligently) and it often isn’t clear who needs what from whom before each thing can happen. SW: Speeding up doesn’t mean throwing out all the communications protocols we’ve developed—it just means communicating faster and more effectively.

o Solutions: Write a list of what is needed. Don’t take into account what “can” be done by each group, don’t even consider what you think the other group can do. Just write a list of what would come from the other groups in your IDEAL world to get everything to work right. Then it becomes clear what needs to happen and we can start working out how to do it.
Note that this is what we’ve supposed to have been doing all along!

Nice journal.

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

Milestone:

I’m working towards my goals in the milestone by helping to clean up the code, working with TJ on renderer improvements, and starting to think about PocketPC and the UI.

Gains Made:

Jeff and I worked on applying the suggestions from Bryan’s (primarily) code review. We’ve been cleaning up the code. Most of the issues were general housekeeping, but some things will have to wait until we finalize things with the model group. I’ve sketched a couple possible interface ideas for the GUI (PocketPC). It’s going to be much different because the real estate is drastically smaller. Next week, I plan to work more with TJ on the renderer.

Obstacles encountered:

Getting back into the development mode was a little difficult. With spring break and the code review, we hadn’t been coding for a while. Now, struck with the realization of how little time is left, we have to re-prioritize again to meet our goals. It’s daunting, but I think we can handle it. We’ve talked a little about streamlining (ex, by getting rid of the chat capability that has yet to be implemented).

Solutions proposed:

Get back into a good work schedule as soon as possible and continue to communicate needs and problems.

Development Process:

What seems to be working:

Communication is actually pretty good.
Everyone seems to be ready and able to help if problems arise.
Tasking is a little more realistic (for UI).

What doesn’t seem to be working:

I really doubt much is going to happen with the PocketPC development. Also, not having VS .NET installed on the Symmonds computers is a drag. However, I hear that’s going to change soon. Hopefully.

Proposal for change:

No matter what we do now, we don’t have much time. We just need to buckle down and work on our deliverables. It would be nice to have something almost fully functional soon for the purpose of a user test so that we can catch and fix problems before we turn this in at the end. Working till the deadline is not going to work for this.

Nice journal.

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

Milestone: Code Review

Gains Made

Gains made this week were somewhat minor, but important to the overall success of the project. We finally got rid of the GDI error that was causing the program when running on Exciton and cleaned up a lot of bad variable names throughout our code (at the suggestion of Bryan in his 6 page code review).

Obstacles

In order to get rid of the GDI error mentioned above, we had to take out the VS.Net style menus and toolbars which decrease the aesthetic quality of the UI. We spent quite a while trying to figure out exactly what was causing the error since it could only be replicated on Exciton when connecting by remote desktop. We were never able to track down the exact problem so we ended up just removing the third party components.

Development Process

What's Working

In my last journal, I mentioned that getting back into the actual coding of the project might be a challenge after two weeks off. Fortunately, this did not turn out to be an issue and we were able to jump right back in. We’ve also done a good job of communicating with other groups to make sure there are no conflicting milestones. We ran into some problems with this early in the semester and at this stage of the project, it’s important that we all know what to expect from the other groups and when to expect it.

What's Not Working / Change

The major problem coming up I the development process is the limited time remaining in the semester. We need to really look ahead and prioritize what can and can’t be done before the project is over. There are some aspect of the UI that I have been working with to make it more customizable, but my time is better spent on making sure functionality is available, rather than bells and whistles. I suspect each group has similar issues.

Nice journal.

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

Milestone:

· Setup Server side interface (%50)

Gains Made: Ryan and I setup an interface structure we think will work, but we need to actually make concrete versions of the Adapters.

Obstacles Encountered:

· We started running into issues of security with the current IStoreAdapter, since that was what we would be passing to other stores. That adapter, however contains methods that allow you to add and remove Entities from the room, which a different store should not have access to.
Prioritize! Is this an important issue at the moment? Is the issue security or functionality?

Solutions Proposed:

Ryan and I are not sure what the project is doing along the routes of security. We have a few different solutions. I think we are going to serialize the objects, then they only have a copy, and can’t actually effect the original.
Make sure you are not running down a minimum-payback path!

Development Process

What’s Working: Starting to actually think about the final version. Getting rid of MS2blah and MS3blah, and just having the classes.

What’s not Working: Not having a project-wide stance on application security. Do we need/want security? If so, how much etc.? That’s going to be fairly important as we develop the server-client connection. Another issue is whether we are going to have client’s display the entire mall at once. Originally that was the plan, but now it’s sort of wishy-washy as to whether we can achieve that.

To Change: We are running out of time. I think we need an agenda for what we want accomplished, especially in terms of the extras. For the full mall, there is quite a bit to do, but if that is required by the customer we need to develop it. I think a priority list would be a good idea as it gets closer to crunch time.

Oh, group leaders?! I think there’s something you need to do!

Nice journal.

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

Milestone:

Exception Handling/Robustness for NetworkingHubLib (70%)
Closing HubLink/ServiceManager/IConnection (0%)
Gains Made:

Met with the Robby several times and mapped out how the NetworkingHubLib currently handled exceptions and what we need to change. Started implementing some of the changes and began testing a few cases through a small application to see what exceptions were thrown.
I began writing a more complicated chat program to test the NetworkingHub. It should be ready by the end of the weekend.

Communicate with the UI group!! They’re thinking of dropping the chat functionality! Note that this may not reduce the utility of the chat program as a Remoting test bed.

Obstacles Encountered:

I ran into a few issues when writing my chat program:

1.) We need a way to ping connections without throwing an exception.

2.) The NetworkingHubLib does not provide functionality to simply serve an object through the NetHub.

3.) I find that registering a channel outside of the HubLink constructor to be a little awkward and unnecessary. Although we probably cannot avoid it, it is a pain providing initialization information for the hub in every HubLink constructor even if the hub is already activated.
Be sure that this issue is well communicated with the rest of the AR group.

Solutions Proposed:

We may need to do a little restructuring to provide the above functionality, but it’s more important to get our current code integrated and working properly since the above issues are not immediate and may not even be needed. We may need to provide some kind of hard wired closing events for closing connections.

Development Process:

What seems to be working?

Everything seems to be moving along and it is nice that we have a plan for pocketPCs.

What seems to not be working?

I would have liked for there to be more integration between the model and the NetworkingHub at this stage, but we have all been busy. I’m still worried that we may not get to a good stopping point for the project.

Proposals for change:

We just have to keep working on our code. Hopefully someone from the AR group will get with the model group and we will get some integration done. (SW: Who? -- team leader!) At lab we should work out some times for these meetings and get them moving.

Nice journal.

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

· Milestone Status:

o Gains: It’s nice to get back to the project, and to coding. We’ve made a lot of speculation this week about hammering out a design for the pocket pc, and how it sort of code abstractions/separation need to be done in order to facilitate this process.

o Obstacles: Obviously the fact that we can’t use our existing Visual Studio .NET installations to develop for pocket pc – that will hinder us some.

o Proposed solution: Since most of the communications between the pocket pc and the rest of the system is going to be via WebServices, we should separate the development process, and develop for the pocket-pc separately (on the whatever newer versions of VS that we need to use). We can then test the simulation with a WinForm client, that which also uses WebServices (hopefully as similar as possible to the pocket pc, programmed with the same restrictions on the .NET framework, so that it would be mostly shared code).

· Development Process:

What’s working: I think that discussions in class are more constructive lately.

o What’s not working: Labs still seem very disjointed. Maybe it’s because of the environment in Symonds – that it makes it hard for one person to be the main focal point (because he/she may be obscured by the room layout).

o Proposals for change: I’m not sure exactly, I think whomever is addressing everybody in Symonds needs to be very clear that they want all of our attention. Otherwise, we often sit in our groups, and use the time to have meaningful correspondence.

Nice journal.

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

· Status of the student's milestones

o Gains made

Justin and I spent a number of hours this week identifying potential faults and failures of the net hub lib, and we have modified the library to account for such faults and to throw explicit exceptions in each circumstance. All runtime exceptions that we currently throw are either RemotingExceptions or subclasses thereof. This will allow other groups to catch RemotingExceptions easily. We will need next week to continue scouring the code and setting up different test scenarios to ensure that the net hub lib is as robust as possible.

o Obstacles encountered

One of the difficulties we have encountered is determining exactly what has gone wrong when we catch exceptions. There are less than a handful of unique exceptions thrown by the .NET framework which map to tens or hundreds of different circumstances. We are also concerned about how shutting down remoting will work, since any previously valid proxies will probably just crash our system.

o Solutions proposed

Based on the different exception strings for different test failures, we are attempting to isolate individual circumstances and provide developers with the correct information when problems occur. As for invalidated proxies, I don’t see any immediate solutions other than simply catching the RemotingException that is thrown.

· Analysis of development process

o What seems to be working

We are still having good AR group communication, and we have been able to find times to meet and work together on the milestones. I look forward to a fairly robust net hub library in the near future, and I just hope we have the time to quickly develop a solution for the Pocket PC.

o What seems to not be working

I understand where the code review suggestions about closing down remoting connections stems from, but I’m not sure the majority of our team has really thought through when such a capability would be used. I mean, if a store exits the simulation, won’t that affect the behaviors of people in the mall and therefore the reality of the simulation? I think we need to be much more focused on shutting down the system as a whole, rather than closing individual connections. This decision would have a dramatic impact on the work the AR group is planning for closing connections.

SW: It’s very important to understand what your solution is supposed to accomplish in a larger sense!

o Proposals for change

I’d like to hear Dr. Nguyen’s feedback about our product. The only time I’ve spoken with him was the initial customer meeting, and I’d like for him to direct our efforts for the rest of the semester. If he is more focused on an integrated UI with lots more behaviors and more variables, then we should drop the Pocket PC attempt. If he would rather see a fairly lame application that tries to run on the Pocket PC, then we could follow that path. I think we have the ability to create a pretty cool simulation here, and I think that the variety of behaviors and features of a well-built program are more important and more impressive than an half-written program that kind of works on Pocket PC.

In a sense, you’re saying that you need the customer to drive the priorities at this juncture. We need to set up a demo with the customer and get his feedback.

Nice journal.

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

Development Status

This week has been fairly productive for an interim week. Bryan and I have made progress on refactoring the code. We’ve renamed a lot of the classes and pulled out unused code, which makes the model easier to deal with. We’ve also been working on redesigning the adapters between the gui and the model, particularly the interface between client stores back to the mall. I don’t think we should have a problem getting the milestone completed, although we’ll have to work this weekend to make sure that we can get the new interfaces to the UI group in time.

Process Analysis

There’s a lot of stuff to get done in the next few weeks, especially as we try to get Pocket PCs to start working. I think that we have reasonable goals, but it also seems like we’re in danger of running into a lull in productivity. We’ll have to be careful to keep each other working – the group managers should keep tabs on their groups, and the three groups should keep asking the other groups for the code they need, to make sure that everything gets done.

I think that communications between groups is continuing to improve. More people have been working in Symonds lab, and it’s very useful to have people from other groups around when working on code – The project is getting large enough that no one can understand all of the code.

This prose style makes it difficult to accurately distinguish the working/not-working/solution issues.

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

Milestone: Clean up attributes and create useful behaviors using attributes w/ Ali

Gains:

· Started creating behavior and sub-behaviors involved with interaction with an item. Through writing the behavior, started implementing several other related behaviors and attributes that would be used in the shopping process.

· Discussed with Ali the best way to adjust attributes as a result of the buy (as well as any general) behavior. In this case the satiability of the person from buying an item affects which attributes will be modified and by how much. This will probably be generalized to include modifying any attribute such as hunger, tiredness, or excitability.

· Decisions to leave the mall were discussed.

Obstacles:

· Realizing that what I thought the specific behaviors would do was not exactly the same thing as what Ali thought they would do. (SW: how easy it is to lose communication!) We got it figured out though. J

· Trying to get Nunit to work again.

Solutions:

· We got together and discussed what our expectations were and sorted out the decision making process (again!).

· Basically, it just boils down to getting code out and seeing if it works. It is not obvious now whether one particular “shopping” process would be better than another.

Development process

What’s working:

· The discussion in class on Friday was informational, and a nice look into the lives of the AR people.

· More work time in lab and class is good.

· Code review was good – it feels like our groups are less isolated.

What’s not:

· I can’t really think of anything.

Suggestions:

· Perhaps we need a long-term deadline set for the whole class since there’s only a month left of class. (like we need this done in 2 weeks, that in 4).

· Do we need another customer meeting soon? I hope he doesn’t want the project substantially changed at this point, but I just want to make sure.
YES!

Nice journal.

----- TJICE -----------------------------------------------------------------------------------------

· Milestone Status:

Gains: This week was pretty much dedicated to getting a better understanding of how to build up to my last workable demo with the new framework. This was mainly discussion between the UI and Model Groups.

o Obstacles: Well since the model group has not yet implemented the new framework provided by the AR Group, there can be no substantial coding done.

Proposed solution: The proposed solution this time is to make a few classes and check-in some of the classes that I have already made over spring break.

· Development Process:

o What’s working: Everything is still working as it did before the code freeze. I have now started to try to merge certain aspects in. There has been a lot of discussion about what is to happen next and how things shall be implemented, but no actual coding of these ideas.

o What’s not working: Since the framework has not been implemented yet, there is somewhat of a stand-still. I still need to try to solve the GUI bug and try to get a handle on the refresh rate of the application.
Stand-stills means that there is a tasking error – programming talent is being wasted!
I thought Brian said the GUI bug was solved?

o Proposals for change: One change could be to do some unit test on the components to try and to find out where the GDI error and Out of Memory errors occur. Part of me feels that this problem has something to do with Remote Desktop, because I never witness these errors running the software on my home machine. As far as the frame rate issue, I just need to read the API more and find the methods that will give me this information. And as far actually writing code for the new framework. I just have to talk to Jim and the rest of the model group and hammer things out.

Nice journal.

----- WRPRICE ------------------------------------------------------------------------------------

Milestone 4 (is it MS4? Yes) Status:

Gains Made:

For the first time, I'm not worried about our implementation and whether it will work or not – because it does. J Justin and Robby should be making progress regarding the possible remoting exceptions in the NetHub code and making it more robust. Theo and I are working on PocketPC-related issues and I've mainly focused on the most-likely issues regarding our simulation and the limitations of the .NET Compact Framework. I'm reading MS Press' book on the CF and while there are definite limitations, I think we can work around all of them one way or another.

Obstacles Encountered:

Some of the online documentation is a little untrustworthy – for instance, one article listed the Compact Framework as neither supporting binary serialization nor the SoapFormatter class -- which would suggest that even accessing web methods would be impossible; I agree with Theo's statement in Friday's class that SoapFormatter probably exists (I haven't explicitly looked yet, but I know for a fact that web methods work.)

We've come up with a couple feature enhancements for the NetHub that the AR group thinks would be very valuable (e.g. The ability to host a specific object in addition to receiving connections.) in the near future. Time is a limiting factor and these are things we'll probably address in the next milestone.

Solutions Proposed:

For me, specifically, there isn't much of a “solution” to propose, other than make sure I'm getting factual information and passing it on to the rest of the class. Friday was a good start, I think.

Development Process:

What's working:

We're sticking with pair-tasking in the AR group; it served us well in times of need and I think we'll continue.

What's NOT working:

First, we found out in Friday's class that the model and UI implementations are rather tightly coupled such that they run in the same application domain. I thought we stressed at the beginning of the course that the UI should be separate (completely, in its own executable) from the simulation itself; I was either mistaken or the stresses of deadlines and complicated code led to the current result. They really must be separate.

Second, I had a slight problem with another group's member bypassing me and talking to other members of the AR group about future tasking. In this case, the issue was quickly resolved and there's no harm done (everybody's happy!) but I just wanted to remind everyone that inter-group communication really needs to go through the group leaders so groups can stay on-task without getting distracted or conflicting information. (Again, it wasn't a big deal this time... I need journal material.)
The group leaders are there to make sure that everything stays synchronized – don’t bypass them, let them do their job.

Proposed Solutions:

The NetHub was designed to make it very easy to connect two parts of the simulation – including GUI necessities. I strongly urge the Model and UI groups to separate their code; it will especially help when we try to port to PocketPC.
ABSOLUTELY!!

Nice journal.

----- SWONG ---------------------------------------------------------------------------------------

This week’s big issues:

· Communications – going faster means we have to be even more diligent on keeping the lines of communication open and flowing. We cannot afford to become disconnected or desynchronized at this stage.

· PocketPC issues -- Everyone needs to be thinking about how their code is affected by the PocketPC porting. Adherence to strict API rules that enables code to decouple is crucial.

· Separating the PocketPC development temporarily – This is basically to enable the groundwork for the PPCs to be laid without affecting the main development process.