Journal Entries, Week #5
Quick jump to: alio, beowulf, jamesmcd, jkdot, jsegars, lipinski, localguy, othello, rjmorgan, ryanaip, thewang, tjice, wrprice, swong. ----- ALIO
------------------------------------------------------------------------------------------- Journal for Milestone 5 Status: · 100% completed · The first thing I did was to document the handshaking method exhibited by the Behavior class o This
can be seen at exciton.cs.rice.edu/users/alio/Milestone2/Behavioral
Flowchart o This is the current flow of the model. · I went through the current model code for behaviors and restructured the Behavior class into a linked-list implementation. · In addition to implementing a linked list architecture, hooks were added so that a visitor class IBehaviorAlgo could be used for greater modularity. o A future use of this is for easily deciding on a decision mechanism for people. o The UML can be found in my folder on exciton.cs.rice.edu/users/alio/Milestone2/Milestone2ListBehavior.JPG Obstacles encountered: · I was sick during the middle of the week and couldn’t talk with Dr. Wong about a different implementation of visitors that may have been helpful to the Behavior class setup. o Lesson:
Try and get meetings out of the way as soon as possible so plans are less
likely to be disrupted. Solutions proposed: Analysis of development process ·
There is a lot of good documentation that has
been generated. This is very helpful
from the standpoint of implementation in that there is no single person that is
required for specific parts of the project. ·
A lot of new problems are going to be realized
when we start to integrate the many parts of the project, and we should talk
about what each group needs from another so we don’t have milestones assuming
one group is doing something when in fact it isn’t. What seems to be working – · Once again there is excellent communication between groups and the inter group milestones seem to be well distributed, no one so far has complained about being completely overwhelmed. · Props to the AR team for finishing their milestones a week early. What seems to not be working – · While we have been re-organizing to improve communication and efficiency there has been a re-cropping of common problems. We are still doing better on defining non-vague milestones but this is an area of improvement. Proposals for change ·
If we are going to make the milestones over
the weekend (which is an idea I agree with) we take a little time on
Monday to make sure that milestones between groups are compatible. ·
I think it is a good idea that we integrate
code, that will show us what problems we have to overcome, but I think
making a release be the next milestone is a bit premature. There is no
leeway if something goes terribly wrong and if we don’t have a functional
simulation we may lose customer buy-in.
Nice
journal. ----- BEOWULF
-----------------------------------------------------------------------------------
Nice
journal. ----- JAMESMCD
--------------------------------------------------------------------------------- Status
of milestone: · Gains made: Using the remoting library provided by the AR group I implemented a connections that allow you to transfer people between rooms, either on a single computer or multiple computers. This allowed for testing of the object transportation system and gave ideas as to what a version 2 of RemotingLib should look like. ·
Obstacles
Encountered:
The current remoting
library does not offer much in term of flexibility. It took a fair amount
of pounding to get it to work, and it is not implemented in a way that
even closely resembles a final version. · Solutions Proposed: Closer work between the AR and Model Group to design a system that has the functionality required. Wrap the current RemotingLib in an easier to use, more “final” version 2. Analysis of Development
Process: · What’s working: SOURCE SAVE! The model group added all our code, as well as the remoting library to Source Save. It’s really nice once you get it working. Much more user-friendly than CVS. · What’s not working: Inter-group communication, in some cases. In several instances there was very good communication between groups. In other cases there was very poor communication between groups. Also, intra-group work. I know some groups don’t even see each other except in class. ·
Solutions:
Initiative. Everyone has different knowledge and
getting input on your work is all most always beneficial. Meet with your
group.
Know what they’re working on, even if they don’t need help. Realize the
magnitude of this project and understand how much it’s going to take to
get everything working. ·
What to
Change:
Do presentations every week on what has been accomplished in your
group. We
have lots of class time on Fridays and making people get organized and
ready to present will encourage communication between groups and group
members sooner that the last 2 days before the milestone is due. Nice journal. ----- JKDOT
---------------------------------------------------------------------------------------- Milestone: Research of
usability cycle, user testing, documentation
Gains made: For this milestone, I was to look more into the details and structure of the steps we should be taking to make a good interface. Based on my previous HCI classes and the books we’ve been reading in those classes, I was able to construct some guidelines and a “usability game-plan”.
Obstacles
encountered:
Development
Process: What seems to be
working? :
What doesn’t seem
to be working? : There are still a few little issues with making specific information known to the rest of the team. It’s still too easy to just internalize stuff and assume that “everyone will find out eventually.” However, we might find out about something when it’s too late (and has reached crisis level). Everyone remember this one! Proposals for
change:
Nice journal. ----- JSEGARS
------------------------------------------------------------------------------------- Milestone: Dummy
UI (Mall and Store
Creation Wizard, Store Management, Usability Testing) Gains Made After spending most of last week working on the wizard-driven interfaces for mall and store creation, I spent the initial part of this week creating the UI for store management. As you can see in the screenshots on the documentation page, it’s very similar to what we created for mall management, with the addition of a competitor watch list. Toward the end of the week, Kijana and I began testing users on the mall management interface from milestone 1 and the mall creation wizard that we had just developed. For the most part our interface worked as the users expected it to and they had little trouble completing the tasks we gave them. Obstacles The main obstacles that came up this week were the errors we discovered in user testing. Kijana goes into more details on these issues in our write up, but we basically discovered that some of our wording for tabs and controls was too vague to allow the user to know what the control would do when activated. Development
Process What's Working Communication within the UI group still seems to be going very well. We were able to integrate TJ’s rendering code with the mall manager GUI without any problems, which was a relief. Now we’ll see how things go integrating with the model next week… What's Not Working / Change As we learned today in class, communication between the groups is where all our problems lie. We were obviously not on the same page with Brian and had no idea he was expecting to integrate the model and UI for this milestone. There are several ways we can keep this problem from popping up again though. Being more explicit about what we need from other groups and reading everyone’s milestones for potential would both be helpful. It could also be very beneficial to roadmap where we want to development to be several milestones in advance. If Brian had known we weren’t going to add functionality to the UI until milestone 3, the problem could have been averted. Hear ye, hear ye! Nice journal. ----- LIPINSKI
------------------------------------------------------------------------------------- Milestone:
· Work with the UI group to define the interface between the UI and the model. (Make the controller). (100%) · Use the interface to connect to a mock UI. (100%) · Work with Jim on creating factories. (100%) Gains Made: I created the abstract and concrete factories to be used in the creation of people, items, and stores. I made the controller, and adapters to connect the UI to the model. I hooked these up to the model groups demo UI. Obstacles Encountered: ·
How to communicate between the model and view ·
How to set up factories Solutions
Proposed: ·
I decided that adapters would best be used
in the communication. Since C# does not allow anonymous
inner-classes I had to create concrete adapters to pass between the UI and
Model.
·
We set up the factories, as very basic
factories, which act more like adapters to the model then anything
else.
This will change when the View actually will set fields within the
factories. Development ProcessWhat’s Working: SourceSafe. It’s nice to be able to access all the code, and have the flexibility of changing it with other’s without having to worry about erasing modifications. What’s not Working: Lack of “group” interaction. To Change:
What I mean by this is inter-group interaction. I know that
for the past 2-weeks I really haven’t known what anyone else in the model
group was doing, aside from Jim. It seems that at least the model
group should all get together, because what everyone does in each group
can effect the entire
group.
I’ve already proposed a “pizza” night with the model group to get
together and talk about everything, and strategize. That will
promote better inter-group communication, and help all around. I guess I would have called this
“intra-group” interaction. I may have funds for “pizza
meetings” – talk to me about it. Nice journal. ----- LOCALGUY
--------------------------------------------------------------------------------- Milestone
(Commenting RemotingLib 100%
done and more):
§
I have had a lot of trouble working with
events and remoting. Events are not
serializable so when you try
to pass anything by value while referencing an event you get an
exception.
Sometimes when I am trying to do something complicated with remoting it becomes hard to tell
what I am passing by reference and what I am passing by value. This can cause
problems when you need a reference but get a value or vice-versa. This must be
paid attention to closely whenever you pass anything with the remoting library! § While testing the remoting library with my application I found that the HTTP_FACTORY does not work. Theo and I talked about it a little but still could not figure out why it does not work.
§
It would be nice if we added something into
the remoting library that
catches exceptions for trying to pass objects that are not serializable. Currently an
exception is thrown if a user tries to use a port that is already in
use. We
should probably catch this exception and run some kind of dynamic port
allocation. Development
Process:
I think all the groups are making a lot of progress and are beginning to have better communications with each other.
Nice journal. ----- OTHELLO
----------------------------------------------------------------------------------- ·
Milestone Status: Gains: RemotingLib has been refactored to include event
listeners thanks to Justin’s efforts. In addition, it’s been fully decoupled
from the server/client hook objects in exchange for Singleton pattern
Client/Server managers. o
Obstacles: Shortly
before writing this (within a couple of days), we discovered that HTTPChannels don’t function as the
documentation suggests. I’ve diverted the remainder of my
attention for this week towards this obstacle, but haven’t found anything
constructive yet. I made sure that the HTTPChannels use the same constructor
calls/formatter calls as the TCP Channel, but for some reason HTTP hasn’t
yet functioned even though TCP has been rather tested by now. o
Proposed solution: I’m going
to suggest this as my next milestone: find a working example of Remoting via HTTP/SOAP, and get it
working in my own environment and on exciton. Then, I’ll try to adapt it to the RemotingLib interfaces, as it’s
pretty abstract thus far. ·
Development Process: o
What’s working: Our group seems
to be making useful contributions to the others, and the other groups
(namely the model group) has been coming to us, seeking information. o
What’s not working: I’m not
completely aware of what the rest of the group is doing, or what I should
be doing specifically at times. I think there’s an insufficient amount
of group interaction/communication at this point. Friday labs
are as inconvenient as always, but if CTS/OwlPC is going to install Visual Studio .NET in
Symonds, then the payoff for using Symonds and running VS locally will be
probably worth the inconvenient time. o
Proposals for change: I think
that the AR group should meet more frequently, to discuss tasking and
maybe help equalize tasking distribution more often. Nice
journal. ----- RJMORGAN
-------------------------------------------------------------------------------- ·
Status of the student's milestones o
Gains made My demo application is working and is located in rjmorgan/demoapp folder on
Exciton. The application reflects the design of
the remoting library in that
any process may designate itself as a server for a port/service, and then
any other process on the same or a different machine may connect to that
port/service.
Each app instance creates a Room object that is remotely accessible
via pass-by-reference, and each room is capable of holding pass-by-value
Persons which can be transferred between rooms. o
Obstacles encountered Originally I was required to poll the library to
receive new connections and objects. Since Monday Justin has added event
handling mechanisms for these events. There were still a number of
obstacles/missing features that would be very useful: ·
The ability
for a server to know who the client is (hostname, port, service) ·
The ability
to close a connection ·
The knowledge
of what exceptions to catch and handle ·
The
connection should be used as the source of events, not the associated
queue. The above list is exactly the type of specific information that is needed to get
over the obstacles encountered. o
Solutions proposed These are fairly minor changes to the library that
will make a big difference to the stability of our application. I suggest that
Theo or someone else take care of these items as part of the next
milestone. ·
Analysis of development process o
What seems to be working The AR group is doing well at getting our tasks
completed.
We have fairly good communication when we are able to meet, and we
all know what tasks we are responsible for completing. o
What seems to not be working On the flip side, we need to make sure that we work
together with other groups as well as with each other to ensure that we
are not duplicating work. This milestone I was responsible for
working on a demo app that was similar to how the model group would use
the library.
Just this week however, I found out that Justin had also built a
demo and that Jim was working on another demo target explicitly for the
model group.
My demo, although cool and useful for seeing some of the features
of the library, now seems unnecessary with all these other demos
available. o
Proposals for change I propose that we work more closely with Jim and other
members of our group to work on projects that will directly benefit them
while allowing them to concentrate on other areas of their projects. If I had known
what Jim needed, I could have easily built a system for him to tie into
the rest of his code, freeing up his time for other model decisions. Nice
journal. ----- RYANAIP
------------------------------------------------------------------------------------ Development StatusMilestone ProgressMy milestone involved implementing attributes, which are pieces of data associated with entities (for example, gender, ethnicity, location, user-interface icon, shopping basket, etc.). The documentation is in SourceSafe, linked from the main project in the Model/Documentation/AttributesDocs directory (right-click Solution_Solution1.htm and select “View in Browser”). For the API look there. Attributes fall into two general groups:
Attributes in turn are placed in AttributeCollections, which serve as a hash table that holds attributes. Each IEntity contains one of these AttributeCollections (called Attributes). People interested in storing data in an entity should use it. We will likely also at an AttributeCollection to ISpace in the near future. I had one problem in making AttributeCollection serializable. I discovered that this is because the Hashtable class (which it extends) uses custom deserialization – when a Hashtable is received by the server and needs to be deserialized, it’s done through a custom constructor. The AttributeCollection class didn’t originally implement this constructor. Solution: if you want to create a serializable class that extends a class which uses custom serialization, it should have a constructor of the form protected
AttributeCollection(SerializationInfo info, StreamingContext context) : base(info, context) {} which passes reconstruction data to the super-class. This info
needs to be moved to a permanent location. Process AnalysisI think that we were much more organized on this milestone. It was clearer from the beginning what people needed to have done, although there’s still room to improve (particularly in inter-group communications). Hopefully having time to meet on Monday will allow the three group leaders to get together and figure out exactly what the different groups need from each other for milestone three. I that we need to do a better job of keeping track of
the code that’s being written during the milestone. That way we’ll
be able to know which pieces of code are coming along more slowly and may
be holding things up. I plan on asking my group to give me
updates whenever they work on their code. Then I’ll be able to pass relevant
updates on to Brian and Will so that the other groups will know as soon as
code is available. Having SourceSafe working should also help people find the code they need. Nice journal. ----- THEWANG
---------------------------------------------------------------------------------- Milestone status
·
We have discussed and have outlined how
attributes are to be implemented and how they figure into behaviors and
the decision-making process. ·
The general framework for attributes has
been written.
The necessary adjustments to
the various entity classes has also been made. · I have also started writing sample attributes and behaviors that use those attributes to make decisions. I was going to complete them and test them this afternoon before lab, but I guess the exciton server is down. I’ll complete that this weekend, or whenever the server comes back up. Obstacles encountered
· Not a lot of code has been put into SourceSafe as of last night (either that, or I’m just accessing it wrong). It was hard at first coordinating with the other group members to make sure that I was editing the correct version (since current Entity and Behavior classes would need to be modified). They are stored in different group member’s directories, each with their own directory and naming structure. · It took me a while to familiarize myself with other people’s code. It’s hard enough understanding your own code, but to understand four or twelve other people’s codes simply takes time. ·
I can
easily see the amount of code exponentially increasing. I’ve realized
how necessary it is to keep track of changes and making changes available
to read, instead of “BAM! Here’s the model, have fun.” ·
There are lots of attributes that don’t
seem to fit neatly into a particular attribute mold, and behaviors that are very different,
though all fundamentally behaviors. So shouldn’t the code for these
attributes and behaviors simply be written out with the necessary elements
and then common elements extracted or repetitive parts removed later
on? Isn’t
that what refactoring is in XP? Solutions proposed
·
I guess we simply need to start putting
code into SourceSafe. From what I hear, it sounds like lots of
people have stuff that works for at least some small cases, but are just
stored somewhere in the depths of their folder on exciton. This would also mean that we can
continually understand other people’s code, instead of spending hours
catching up. ·
Maybe we could spend a few minutes together
in class whenever a large chunk of code is checked into SourceSafe. This would
also give us a good overview of what we still need to do and of the
changes in relation to the whole project. ·
I still don’t like Friday afternoons. What if
milestones and journals were due on Monday when we actually have Symonds
and lab time would simply be designated times when each group would meet
separately or together? Actually, possibly Wednesday s would
work, since we could discuss new milestones in class on Fridays. You’re missing still the “what’s working” section
of your analysis of the development process (not the milestone status,
which you have). ----- TJICE
----------------------------------------------------------------------------------------- ·
Milestone Status: Gains: I have made a Mall/Store Renderer. I have made the interfaces for rendering
entities and spaces. This week was focused on finishing
rebuilding the renderer and
getting it to a point where the layout of a mall could actually be
rendered.
Communication between the model group and the UI group has been
achieved but much needs to be worked on. o
Obstacles: The only true obstacle in this process is the
communication between the groups. For example, on Friday, the UI group
became fully aware of |