Journal Entries, Week #7

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

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

Milestones

Status:

· Today’s milestone is finished as far as the revised milestone is concerned.

o The behaviors are implemented using a stack and queue implementation.

§ Sequences of behaviors are able to be placed within people objects via the InsertSequenceBehavior(IBehavior) method.

§ Turn behaviors are inserted via a InsertTurnBehavior(IBehavior) method.

o Behaviors are inserted into the appropriate structure and removed as they are implemented

· The list of rules for dealing with the behaviors is finished, while the design chart is still in progress.

· On Monday the interface IEntity is going to be slightly changed such that a call to get Behavior will return an IList rather than an IEnumeratior.

(SW) Devhood is a better place to announce this.

Obstacles encountered:

· Changing the behaviors for the new process caused the change in MilestonePerson3 which propagated changes all the way to the interface

o This caused a bad choice in changing the interface so that it messed with other people’s stuff. That was a bad thing.

Solutions proposed:

Analysis of development process

· The tasking we are using is showing its convenience because we were able to tell as a class that we would get our milestones done, but the integration would be more realistically completed next week.

What seems to be working –

· The new IPaqs are really cool.

· Demo where people run around rooms, buy stuff, and talk is showing a lot of progress. Good for us.

What seems to not be working –

· Not so much as what isn’t working but a question about how easy it is to put the .Net platform on the IPaq. Does the program need the .Net platform to run? Could be something for the AR team to look at when they get bored.

Proposals for change

· Once we finish the next milestone I suggest that we should take a “what now” look at the project. This way we can discern if anything needs to be streamlined or given greater functionality and see how what we have done fits in with the big picture of the simulation.

I intend for the class to run a full blown code review (which will include a “what now” analysis when we get back from break.

Nice journal.

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

Status of Milestone

Gains Made: We made some important progress on this huge milestone including:

Presenting wizards and manager to customer and also running them through more user testing (and making refinements based on this feedback).
The model and UI have been integrated! How they actually integrate is likely to change somewhat down the road, but what’s important is that we sat down and actually coded them working together which has improved understanding for everyone of how model and UI interact.
People and items are now rendered in a store.
A wizard can be invoked to add a new product to the store and the tabs and renderer update appropriately.

Obstacles: Meeting times were difficult with the model group. Also, the adapters they wrote were changing here and there throughout the process (but they communicated well with us on that so it went pretty smooth). The IRenderable interface was only partially implemented on the model side. We were limited (slightly) by how much of it the model group had actually rendered.
Proposed Solutions: Changes on the adapters will not be as frequent now, and the model group’s communication with us helped out. Further implementation of the IRenderable interface will allow us to render entities more appropriately (shape, color, etc) so we will work with the model group down the road on this.

Analysis of Development

Whats Working: When we get everyone together in Symonds to work, then progress speeds up. The pair programming and having the group together helps solve problems quickly.
Whats Not Working: There are still some problems with people checking in buggy code to CVS (I’m not going to name names J).
Proposed Changes: Check in with caution. Also, it occurred to me while writing this journal that our journals might be a bit long. It really is a big task to read through them all each week, and I’m sure most people just skim them anyway. One idea I had was for ONLY the group leaders to write journals that summarized the concerns/progress/etc of their group. This would be a manageable size to read each week. Just and idea…
The main purpose of the journals is pedagogical, not project management. That’s why everyone needs to write a journal every week. But they are also presently serving as a vital weekly communications link for the project. The question is should it be serving this purpose?

Nice journal

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

Status of Milestone:

Gains Made: COMPLETED! YEA! Thanks to some fast changing on the AR groups part, and some late night working on the Model groups part, we have people moving from an arbitrary number of stores running on an arbitrary number of machines. People, items, stores, and connections can be added at runtime.
Obstacles encountered: Changing code and unsubstantial test scenarios. On several instances people changed important code, such as an interface, without properly notifying everyone affected (i.e. EVERYONE). Also, I spent quite a bit of time banging my head against IConnections because I was told they could do something that hadn’t been tested.
Solutions proposed: Again, unit testing, of some sort. I know this isn’t possible when working with remoting, but some standardized test must be available to check and make sure all features promised work. Also, common sense. Don’t change something and then not look through everything to make sure it all still works. This is especially important when changing things like interfaces or overall design patterns.

Analysis of development process

What’s working: Overall feel of success. Things may not have come together as we had planned for this milestone, but people seemed happy with what had been accomplished in general. Also, people have found what they are good at and are working hard on those things while at the same time not being so specialized that they have no idea what’s going on everywhere else. Most importantly: FUN WITH TOYS! Source save is also working very well.
What’s not: People are not coming to class time. This is the only time we get everyone together and it is very important that everyone be there. More importantly, looking at the big picture. The first few weeks we spent designing and coming up with systems that were abstract, simple, and extensible. We’ve started to forget about those practices in the last few weeks and we’re just coding things in as needed.
I’ve noticed this. Hopefully we’re not to entrenched that a code review can’t get us back to where we need to be.
Solutions proposed: A week spend reviewing and re-abstracting existing code: making it clearer and more flexible.

Nice journal.

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

Status: For this milestone, I worked with my team to get some functionality into the GUI. Aside from that, Jeff and I iteratively re-worked the interface to incorporate fixes to issues that came up in the second round of user testing. Our group has focused on the massive integration for this milestone with the purpose of looking ahead to the next step of functionality.

Gains made:

Met with the customer last week to discuss the interface and gain feedback and answer questions. The meeting went well and I got even more suggestions from the customer on what functionality he wants.
Completed documentation for last week’s user testing.
Jeff and I worked on implementing the improvements to the GUI that arose from the user testing.
Worked with Jeff on making the elements in the application window resize with the window. We also added the icons back above the map area.
Met with UI team to finalize integration of model with UI for this milestone.
Getting stuff that we need from the model group.

Obstacles encountered:

Wonky code. Jeff and I had some problems with code that was “working before, but doesn’t seem to work now”. It’s sometimes hard to tell whether the problem is with the code itself or if it is an outdated version.
Slight communication issues with the model group. We were able to work this out by talking to them in and out of class and making our needs (and addressing theirs) explicitly.
We were getting a little scared when TJ didn’t show up to the integration party last Sunday and when he wasn’t in class on Monday. Fortunately, he had his stuff close to completion and was able to come through at the second integration party Thursday night. It’s a little unnerving when we are depending on someone and we lose communication for a while.

Proposed solutions:

Keep talking within groups and to other groups. The communication seems to be improving.
Be flexible when problem solving. We had a couple instances when a better or alternate solution arose where we thought one way was the best. Be open to other’s suggestions.

Development process:

What seems to be working:

Working with the model group.
Most of the API for the code. The basic interface seems to be working well (besides the hard coding done for the milestone which will eventually fade…hopefully).
Team communication on a whole. We seem to be loosening up and talking to each other, which is helping a lot when it comes to putting code together.
Checking code in and out (for the most part).
Anti-gripe Jim – When we were freaking out Thursday night because suddenly nothing worked, we called Jim and he came right over and helped us out. We didn’t have to wait on the rest of the group to show up. Now, that’s service. Good work, Jim-who-never-sleeps!

What doesn’t seem to be working:

We’re still making assumptions about what we will be getting from the model group (or the AR group). We need to be very explicit about what we need and expect early on.

Proposals for change:

Problem: We also need to make sure we don’t “bite off more than we can chew” in subsequent milestones.
Solution: We’re tasking early in the cycle, but early in the process, we should assess what has been done and what needs to be done so that we can re-task, re-prioritize, or re-schedule the milestone. Perhaps something could have been done this time if we had not only realized but verbalized that we may not hit the milestone sooner.

Nice journal!

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

Milestone: Connecting GUI and Model, Usability Testing

Gains Made

After spending last week on usability testing, this week was devoted to actually connecting the GUI and the model. We got together with the model group on Sunday afternoon and were able to display product information in the appropriate tab in the GUI. This gave us a good start on the integration and a better understanding of how we were connecting to the model. Kijana and I then spent some time Tuesday refining the user interface based on the results from our user testing: labels are now a more intuitive and the GUI actually resizes when the window size changes. On Thursday, we were able to get the store creation wizard hooked into the model, showing that both of the major parts of the UI can communicate with the model.

Obstacles

We ran into several problems this week in trying to complete our milestone. Resizing our GUI intelligently turned out to be much more difficult than expected. It’s easy to anchor or dock a single control along an edge and have them resize automatically, but we wanted “My Store” tab and “Other Stores” tab to each resize equally along the same edge. We could never get this to work out right and in the end decided it a minor issue not worth the time and implemented a simpler version of resizing for this milestone.

Often this requires putting elements you want to resize together into a pane that they fill completely. Then the pane does the resizing and the elements within it simply size to the pane.

Development Process

What's Working

I feel like communication between groups has improved from the previous milestone, which was a necessity given relatedness of the model group’s milestones to our own. I have a much better idea of what is going on in the milestone now from simply working with their code over the last two weeks. Scheduling meetings early was also very helpful, because as the milestone deadline neared, it was difficult to find a time when everyone could get together. Scheduling the meeting early, made the last minute meeting less essential.

What's Not Working / Change

I know its coming soon, but the sooner we can get VS.Net installed in Symmonds, the better. Many times, Terminal Services on Exciton becomes slow or unresponsive and is really a hindrance to the development process. We also had some issues with code checked into CVS that would not compile. It was in a separate project so we were able to get around in, but things like this could become a real problem later on.
I’m still not getting any response for IT on the status of the install.

Nice journal.

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

Milestone:

· Implement the appropriate rendering interfaces on entities and spaces so that they will correctly draw when passed to the UI.

· Remove the test UI and replace it with the real UI (e.g., make sure the controller works correctly, and put in the necessary adapters). Work with the UI group.

Gains Made: Redid the ISpaceAdapter and created an IEntityAdapter to allow for the full functionality of the GUI. Hooked up the Client side GUI to a space. All interfaces should pretty much remain what they are now. I think in this revamp we (Ryan and myself) took care of everything. We still need to implement parts of the interfaces on the model side, but the interfaces do exist and that’s what we will be using.

Obstacles Encountered:

· How to instantiate the initial GUI and model and tie them together.

Solutions Proposed:

· I don’t know what exactly UI needs at the very front of the application. I suggest that someone from that group and I spend an hour or two setting up the controller to properly instantiate everything. I’ll need to schedule a meeting sometime…How about NOW? See the above journals as to why.

Development Process

What’s Working: Having set interfaces to work with. Knowing what we have, and what we have to do is making the UI/Model integration much easier. There are still a few details, but having what we need to get done establish makes actually doing it a lot easier.

What’s not Working: Lack of time.

To Change: As we get more and more into the project, at least for my milestone, the programming is taking up more and more time. That leaves less time to just meet with other groups to discuss what needs to be done, and how to do it. Ryan and I really only had 1 meeting with the UI on Sunday, when we really should have had multiple meetings to ensure the MVC is set up properly, and making sure that our (the model group) plans for M-C connection isn’t completely different from theirs (The UI group). I know that currently they instantiate factories inside the wizards, and that needs to be changed. The problem was that Ryan and I weren’t there to figure out with them how to go about doing everything.

Nice journal.

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

Milestone:

Provide a means to detect and create processes (100%)
Add several items to RemotingLib(100%)
Work with Will on actual RemotingHub implementation (50%)
Gains Made:

I have been working a lot on comp421 programming so I have not has as much time as I would like to work on my milestone but I managed to find some time. I finished up the improvements that I wanted to add to RemotingLib ie(getting connection information, making IConnection the sender). I also fixed a big event handling bug that Jim pointed out. I implemented a RemotingHub using the existing library and began testing it. This code can be found in localguy/RemotingHubTest on exciton. It has some interesting functionality and routing capabilities, but I immediately ran into several problems.

Obstacles Encountered:

When testing my RemotingHub implementation I ran into two big problems:

1.)RemotingLib does not provide a way to register a service on a server without registering a port. Services are always registered with ports. Theo did some research and found that ports and services are completely separate on a server. This is not how we had been previously envisioned ports and services working.

2.)RemotingLib does not provide functionality to start multiple servers in the same process. This is because of some static fields and methods in RemotingLib.

These two problems have led the AR group to completely restructure our design of the Hub and RemotingLib. Ultimately we are going to have to redesign a lot of RemotingLib code to provide for this additional functionality. We have met to assign tasks and define the interface for our code and hopefully we will get started on the implementation this weekend.
Do you think that these problems were avoidable? Was there a fundamental design flaw that should have never been there? Static entities tend to kill a design’s flexibility and extensibility.

Jim created some unit tests on the existing RemotingLib and found an error that I had left in some of the event handling. I fixed it, but it would have caused Jim a lot less trouble if I had unit tested in the first place. I had tested my code using a small application that did not cover all of the problem cases.
Full coverage is crucial in unit testing! Remember back in the days of Comp210 how you had to write test cases with full coverage?

Solutions Proposed:

The AR group has already met and discussed the issues with the problems in RemotingLib and the Hub and we know what we have to do. We just have to make the time to do it.
I have to do unit tests! NUnit wasn’t installed when I wrote my original code, but from now on I need to test everything.

Development Process:

What seems to be working?

The AR group did a great job of acknowledging our problems and setting out tasks to deal with them. I feel that we can have a new solution ready in a reasonable amount of time if everyone works together.
We have iPAQ’s! Mine is up and running and in-sync with my computer. I don’t know anything about it yet, but I can’t wait to try it out.

What seems to not be working?

Finding times to meet with members of the AR group. We could have found out some of our problems a week or so earlier but it is very hard to get an AR meeting together. It seemed that when I was free everyone else was busy or vice-versa.
Gotta make the time.

Proposals for change:

The AR group has a weekly meeting time, but we are going to have to plan extra meetings further ahead of time to work with everyone’s schedule.
Good idea.

Nice journal.

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

· Milestone Status:

o Gains: My milestone was re-tasked pretty early on this week, so that I’m with the rest of the AR group in its attempts to revamp the RemotingLib. We’ve gotten a significant rehaul of the design, so it should be easier to interface with. In addition, I think I finally figured out how .NET IChannels work, in that IChannels are shared across the entire Application Domain, irregardless of what services you set up. Then it would only follow logically that all services are available to the channels registered for this Application Domain (basically, the .NET version of a Process’ environment).

o Obstacles: Aside from not really completing the group milestone, I didn’t get to finish off the original HTTP-fix milestone, since I was re-tasked.

o Proposed solution: I think the problem with this milestone was that we may have bitten off more than we can chew. I think with group/pair programming, it’s not necessarily twice as efficient “programming-wise” (in regards to sheer code generated), but it may be just as efficient/more efficient in the long run. So maybe the key is to estimate how long it would take to code up the solution (with just 1 brain, not necessarily the time for 1 brain, then divided by 4, to account for the group size). I mean, group/pair programming is effective, in that it generates “better” code per unit time, so one spends less time debugging – even though it takes longer to write code than for 4 people programming in parallel.
Very good point! It’s important to see programming in a larger light.

· Development Process:

o What’s working: I think that the group programming is quite effective, in that whenever one of us is stuck, then the rest usually chime in with an idea. It certainly beats just 1 or 2 minds at the keyboard.

o What’s not working: We’re not really meeting our milestones, at least not completely.

o Proposals for change: I think we need to improve at tasking our milestones, to provide a more conservative guess, rather than a optimistic guess. Probably other groups would rather that we exceeded a conservative milestone, than for us to not meet a optimistic one, in case they were depending on it for their next step.

Nice journal.

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

· Status of the student's milestones

o Gains made

As mentioned last week, I completed the task of verifying that proxy objects can be transferred properly from one client machine to another. My other tasks for this milestone were superceded by the discovery of major issues with RemotingLib. Since Wednesday the AR group has met three times to hash out a redesigned remoting framework with the requirement of a hub in mind. We have identified the issues that model group needs resolved and we have created new stub projects in SourceSafe.

o Obstacles encountered

Since the redesign was necessitated so late in the week, we were not able to assign specific tasks to individuals. This kept us from working in smaller groups to accomplish more on the redesign.

o Solutions proposed

We need to hammer out the way that the client code will communicate with the hub process so that we can split into two pairs and develop the client code and the hub separately.

· Analysis of development process

o What seems to be working

Our two meetings on Wednesday regarding the redesign were very productive, with all sides identifying issues and limitations with the design until we agreed upon a fairly robust solution. The polarity of programming personalities in our group worked in our favor by analyzing and criticizing even the smallest issues, which ultimately resulted in us making very far-sighted decisions. What a nice way of putting this!

o What seems to not be working

The meeting on Thursday was less productive for two reasons. We were all split or clueless on the best way to approach the implementation of the interface we discussed on Wednesday. Most of us looked to Theo to provide insight on what we can/cannot reuse from the RemotingLib framework, and Theo was unable to give us specific answers. Will has done well in moving us ahead on some issues, but he hasn’t been as forceful on getting the task of the client/hub communication hashed out. Ultimately the group (or “gang”) of four setting does not lend itself well to active progress on implementation issues.
A leader steps up and makes a decision on which way to go, not so much in that the leader actually knows that it is the right way to go, but rather for the purpose of keeping his/her team together and working towards a common goal.

o Proposals for change

At this point I see three major tasks for us to complete the redesigned implementation of the remoting code. The first is of course the communication mechanism for client processes to talk with the hub. The other two tasks breakdown into the client process code and the hub code, both of which rely on the first task being complete. Instead trying to complete the first task with four people collaborating together, I propose that we designate a pair of programmers to complete the first task, while the other two write some test applications. The former pair can then split and pair up with the other two to complete the second and third tasks.
Good idea, though this doesn’t negate the need to deal the issues of APIs.

Nice journal.

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

Development Status

Milestone Progress

We bit of more than we could chew this milestone, but the problem was mostly in terms of integration between groups and not with the actual functionality that needed developing. My milestone was to create factories and connect them to the UI group’s view. The factories have been created (except people factories, which still require some work in terms of configuring demographic data) and can create people, items and spaces, but they’re only partially connected to the UI group’s interface.

For the delayed milestone (next Friday, March 7^th), we should have factories more fully integrated into the view. This is basically dependent on finding time to meet with the UI group and putting everything together.

I actually spent a lot of my time during the last couple of weeks working with Bryan and Jim on building the UI adapters and on connections. It seemed that those items were a higher priority – we really have no need for factories until the rest of the system is ready to accept the objects we’re creating. I think that we’ve now gotten to that point.

Process Analysis

We underestimated how much time it would take to get together with the other groups and get our milestone done – In some cases, it was just the issue of having to get so many people together at the same time. We also didn’t realize quite how much work was left in the model (adapters) before it was ready to integrate with the UI, so we couldn’t get started working with the UI group quite as early as we’d have liked. I think that we just need more practice in estimating what we can finish, which will come with experience.

We also ran into some issues with code/interfaces fluctuating as the milestone progressed. While these changes are necessary, I think we’re at a point where most of our interfaces should be finalized. By the next milestone, I’d suggest that we put together a set of documentation of every interface in the project and post it. That way the groups should be able to see the full API they need to interact with each other.

It remains apparent that we need unit testing. I plan to spend time during spring break on developing tests, and Ali and Gilbert should be able to work on some next week since most of their milestone was completed.

Nice journal.

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

Milestone status:

Gains made

· This week I finished redoing the attributes so that they would accept comparators that are not specifically part of the actual attribute.

· I made IAttribute into AAttribute in order to simplify and clean up much of the repeated code and provide for needed inheritance. Now, all references to the general attribute should be of AAttribute. AComparableAttribute no longer exists since it is simply AAttribute. BoxAttribute now simply overrides AAttribute with the same properties it had before.

· What was previously attribute.Value has been replaced by attribute.Pref. Pref sets or returns the preference value of that particular attribute. Value now sets or returns a designated generic object field specific to the attribute.

· Any new comparator should implement IAttrComparator.

· Items should now be able to have attributes and should be able to compare them with other attributes. Behaviors can use attributes in generating a decision at any point.

Future tasks

· Now different people can have different comparators, but it still remains to be worked out how a person can have different comparators for each attribute (or even if that will be allowed). The original plan was that attributes could need to be compared in different ways, so we would also need some sort of comparator collection. This seems like just an added level of unnecessary complexity to me, but I guess this is just the point of extensibility.

· I now need to build people with behaviors that use attributes and create a wider collection of attributes. This has a little to do with the comparator collection, but should be easily accomplished.

Development process:

· It seems like it’s going well. I still need to write lots of unit tests, but I finally figured out how they work.

· It’s great that stuff is breaking all over the place cause it shows how either the different groups aren’t thinking all on the same page, or that stuff just wasn’t working to begin with, especially since it’s hard to come up with exhaustive unit tests. Gilbert makes lemonade from lemons!

· Honestly, I have no idea where the pocket PCs are going to figure in to the project. Are we just going to run our program and allow people to set up stores on the pocket PCs? Is this just supposed to model different customers running the program on their own computers? Are we doing any development on them? Weekly gripe about Friday afternoon labs: Does this mean that we can just bring our pocket PCs to class on Friday and eliminate the need for an extra lab meeting? But I would like at least an overview of what we would want to do with our pocket PCs.
The customer said he wanted the program to run on the Pocket PCs (PPCs). That’s a bit vague. What is feasible to run on the PPCs? Does anything more than the UI need to run, or is it reasonable to run a whole store? We need to help the customer clarify what he really wants.

Nice journal.

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

· Milestone Status:

Gains: This week showed more productivity than last week. People have been rendered in a space using the adapters that the model group has made. There has been UI / Model integration. This is a huge accomplishment.

o Obstacles: There are still some hidden communication issues lying around. It is hard to actually voice concerns about these issues because the issues themselves are elusively, small ( the issues tend to creep up right before a milestone is due. ) Luckily everything worked out for this milestone, but these hidden issues might want to be corrected before other major milestones.
Small issues often make for big problems. It is important that one make the effort to articulate every issue, no matter how small. If you cannot articulate the problem, you cannot solve it.

Proposed solution: Well at first I thought that people could voice their issues that they find. This communication would help problems to be detected early on in our coding and could be dealt with in a timely fashion. Now I think otherwise. It is hard for concerns to be expressed when everyone is still in the design process. A better solution would have been to have each group come up with a theory on how things would work. Get diagrams flowing showing potential abstract connections between the two major pieces ( UI and Model ) before any coding was done. I think that an earlier butting of heads should have taken place. Now that we are so far into the project that is not feasible, but I think that after this milestone it will be easier to voice new problems because the code has finally reached a base structure ( or so I think. )
What you’re saying (or at least my interpretation of it) is that in the beginning, we must focus on how the pieces of our system interact, and not on how they are implemented.

The above discussion really belongs in the development process section below.

· Development Process:

o What’s working: People are successfully rendered. They are rendered using the information given from the adapters. Items are also successfully rendered using the information from the adapters as well. This was pretty huge in my opinion. On the UI end, when the wizard is called to create a new store the new store’s items are rendered as well.

o What’s not working: Right now the renderer cannot distinguish between a person or an item ( this is basically for actually telling one item from a person on a screen. ) This problem stems from the model group not fully implementing the IRenderableEntity interface that was given to them. Only one function, getPosition(), is implemented. The rest of the interface is commented.

public interface IRenderableEntity

{

/* Currently, we are only giving position. Yay for little dots on the screen...

/// <summary>

/// Get Key Method

/// Gives the key of the entity being referenced

/// the key is a unique identifier for the entity.

/// </summary>

/// <returns> object representing the key</returns>

object getKey();

/// <summary>

/// Is Dirty Method

/// This methods tells the renderer whether the given

/// entity is dirty ( meaning it's position has changed )

/// </summary>

/// <returns> true if the entity is dirty, false otherwise</returns>

bool isDirty();

/// <summary>

/// Get Type Method

/// This method tells the renderer what kind of graphic to

/// display ( i.e. for a person, pizza, etc. )

/// </summary>

/// <returns> returns the type of object being represented</returns>

string getType();

/// <summary>

/// Get Position Method

/// This method tells the renderer the CURRENT position

/// of the object

&nbs