|
||||||||
Journal Entries, Week #8
Quick jump to: alio, beowulf, jamesmcd, jkdot, jsegars, lipinski, localguy, othello, rjmorgan, ryanaip, thewang, tjice, wrprice, swong. ----- ALIO
------------------------------------------------------------------------------------------- Journal number 8 Status: · Milestone is completely finished. 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 model group understands how these behaviors work, If there are any questions the rules for behaviors can be sent to them, or found in the model group’s documentation folder that will be made for the code review. Analysis of development process · We are doing very well with the project. We have people moving and deciding what to interact with, stores linking to the server remotely, and actual simulated behavior being shown. What seems to be working – · The demo is so cool!!! What seems to not be working – ·
Lack of documentation, For instance not everyone
knew how to start the app running. This
is going to fixed by the code review. Proposals for change · There may be assumptions in the code we are to review. Detailed documentation is very necessary for the process to go smoothly for everyone. This way it will be faster to learn what is happening in the code. Nice journal. -----
BEOWULF -----------------------------------------------------------------------------------
Nice journal. -----
JAMESMCD
---------------------------------------------------------------------------------
Nice journal. ----- JKDOT
---------------------------------------------------------------------------------------- Milestone: For the revised milestone, I was to have had differentiated between types of entities when rendering and
implemented type system while more fully implementing Irenderable
(especially getType()). On my part, I completely overlooked the
revised tasking and did not get together with TJ to do this. Since our part was mostly completed last
week, I was just going to work with Jeff on getting the last of the hooks
implemented. I should have read the
revised tasking, but completely forgot (was thrown off track by the abbreviated
schedule). Gains Made:
Obstacles encountered: Besides dropping the ball and not achieving my revised milestone, I didn’t really face obstacles this week. Overall, though, the group seemed to be in good communication with the Model group and we were able to get what we needed from each other. Solutions proposed: I suppose the glitch in communication this week between my group and me came from my lack of communication with Brian. I knew he was turning in revised tasking, but we never discussed it (at least I didn’t discuss it with him) and therefore I assumed I’d just be working with Jeff again. This is not the norm – the previous milestones have been more clearly and collaboratively designed. I guess the solution would have been to talk to Brian before he submitted the tasking. Notice how quickly communication can
break down and how fast it causes big problems. Development Process: What seems to be working:
What doesn’t seem to be working:
Proposal for change: As always, practicing communication will take us a long way. If the group (or team members) decides to get together to code at one time, the group members, if necessary, should make an effort to attend. Everyone has distinct knowledge of the problem that will help us to reach a solution sooner. Nice journal. -----
JSEGARS
------------------------------------------------------------------------------------- Milestone: Connecting
GUI and Model, Usability Testing Gains Made This week was basically a continuation of work from last week. The mall manager has now been connected with the model at about the same level of completeness as the store manager was last week. The wizards also have very basic connections to the model, which will be developed further in the next milestone. In addition to the model / UI connections, I also spent some time trying to further refine the layout of our interface. I’m working with making the interface more configurable so that the user can choose what information they want to display and hide things that they deem irrelevant right now. I’ve just been working with this on test GUIs right now but dockable panels will probably be in the real GUI by the next milestone. Obstacles The biggest obstacle I ran into in this milestone trying to figure out how to abstract the data that we’d hard-coded into the GUI in order to prove it could talk to the model. Currently, customer demographics and product information are not extensible at all so I spent some time trying to figure out how we really want to store this information. In the end, I think we’ll end up passing the buck and let the model tell us what information we should allow the user to enter. We need to get with the model group early next week and nail this down, though. Development Process What's Working Communication between groups was better this milestone than any previous one. We’ve said this before, but its amazing how much easier it is to connect your separate components when the person who made the other component is in the same room. What's Not Working / Change It may have been a combination of
a short milestone (or an extended one if you prefer) and a busy week before
spring break, but I didn’t feel that the UI group communicated very well this
week. We weren’t able to meet any
outside of class to work as a group and I’m not sure how closely the pairings
on our taskings were followed. That said, we had basically completed our
milestone last week so it wasn’t that big of an issue, but if not corrected ,
communication could become a problem in the next milestone. Nice journal. -----
LIPINSKI
------------------------------------------------------------------------------------- Milestone:
· Finish connecting the UI with the model, so that we can run the client and server programs with the UI group’s interfaces. (%100) · Implement more of the rendering interfaces so that people and items can look different on the screen (IRenderable.getType). (%100) Gains Made: Working with Ryan, we got the UI group’s Server and Client applications running with our test UI. We also got the vast majority of the model successfully implementing IRenderable, although that isn’t entirely complete yet. Each object should now have a type, and position. The position is randomly assigned as of now, but TJ said he’d have something that would help us figure out position within a given set of points. The Client and Server actually run, although the client seems to throw two different types of exceptions both of which are from UI stuff. Obstacles Encountered: · Everything seemed to go smoothly. Had to decide exactly how to get a unique id. Solutions Proposed: Ryan and I think
that each store will have a unique name.
Items within a store are then given an id with the stores name, or part
of it, in the front. Some things may
come up if we allow duplicate store names.
For people, since there is only 1 person factory we just need a counter. Development ProcessWhat’s Working: Having a great group to work with. We had good communication and got a lot done this week as far as actual application functionality. What’s not Working: Stockpiling obsolete code. Make sure that it is at least well
identified/labeled. To Change: I know that the model group has to go through our code, and get rid of a few classes which aren’t used anymore. Looking through some of our files I see commented out sections and sometimes cryptic messages, about this is temporary. As we’ve changed implementations we’ve been afraid to delete code, but it seems now we are pretty much set, and a major re-haul of the code isn’t feasible. I think a general code “house-cleaning” is in order, to get rid of useless code. This might also involve changing code so that methods don’t need to typecast to a concrete class right now. Interfaces and Abstract classes need to be re-evaluated and re-hauled. Nice journal. -----
LOCALGUY --------------------------------------------------------------------------------- Milestone:
1.) Get Remote Events working! 2.) Continue testing the NetHub with applications, fringe cases, error cases. We should try to use NUnit, but I’m not sure it’s possible with all of the Remoting Issues. 3.) Comment code, inform rest of group how to use our interfaces. 4.) Help the rest of the group integrate the RemotingHubLib into their existing project. Development Process:
Nice journal. You
said what needed to be said – good job. -----
OTHELLO
----------------------------------------------------------------------------------- ·
Milestone Status: o Gains:
The entire AR group is pretty much working on the NetworkingHub
App and Lib projects (the App is not very useful without the Lib, and the Lib
doesn’t do anything without the App).
Our group estimate is that we’re around 80% done with the whole thing. I’ve contributed in the main-programming of
the remoting guts, and the porting of the old RemotingLib over to the new framework. Particularly, it doesn’t try to recreate
channels, like the old lib. In addition,
clients connecting to a server don’t try to register the same service over and
over again, the library assumes that the client channel and service has been
registered already. We can check if the
service has been registered or not, but that seems like it might be an
unreasonable cost for each initiated connection. It would be more sensible to document that
this needs to be done first, or your connection initiatations
won’t work. o Obstacles:
The obvious shortcoming this week was the incompletion of the NetHub App/Lib, but I think it’s better classified as an
extension of last week’s “biting off too much”.
There still remains so much about Remoting
that needs to be discovered, as the team is very small (or at least meager in
man-hours) to both develop and become experts in Remoting
at the same time. o Proposed solution: Not to sound too much like a re-iteration of last week, but
smaller milestones, and more time researching than actual coding. Either that, or lower expectations, as
expertise requires a certain level of time commitment. ·
Development Process: o What’s working: Group programming is
probably still the most effective part of this process, we’ve found that a fresh pair of eyes is
definitely the fastest debugger around :-P. o What’s not working: Insufficient man-hours,
partially due to spring break anticipation, other classes’ midterms, etc. We’re meeting pretty regularly and putting a
good amount of time in, it’s just that programming as a group is probably
slower than just as 1 person, as the code input rate is the same, but the
coding decisions take longer than a single person (arguably, this is better). o Proposals for change: Maybe we can devise a
better (more time efficient) way of juggling pair/group programming. What if we were to as a group, make method
stubs / defined interaction of code bodies, and then implement them in pairs,
rather than in the whole group. At least
those two pairs could be working in parallel.
I dunno, just an idea. Nice journal. -----
RJMORGAN -------------------------------------------------------------------------------- ·
Status of the student's milestones o
Gains made Similar to last week, the AR group met together in and out of
class to work on our remoting network hub
implementation. Although I was out of
town over the weekend, I helped the rest of the AR group complete our task by
utilizing my knowledge of the details of .Net Remoting
and of C# events/delegates. We currently
have a 60% complete hub, and we have made steady progress in the last day or so
in identifying and correcting bugs. o
Obstacles encountered We have run into
several problems in executing our test application, but we have identified and
corrected almost all of them (including one that required a hack detailed in a
MS KB article). We are now getting a
strange exception saying that a method call on a proxy is exposing some other
type. o
Solutions proposed We need to continue working together to solve these issues, since it often takes more than two of us to
grasp what is really happening in remoting. The current bug is related to the remnants
of Theo’s RemotingLib framework so he should
definitely be present to help debug. ·
Analysis of development process o
What seems to be working Justin. Justin has been the
workhorse of the group, spending lots of time out of class and out of meetings
writing and testing our library. He has
done much for our group, even though he doesn’t have a good grasp on the
innards of .Net Remoting. Our group meetings have been effective simply
because Justin, and Will to an extent, show up with code they’ve written, and
the entire group sits down and debugs and corrects it. o
What seems to not be working We didn’t really get tasks down for this week, even though it was
clear to everyone in our group what our goals were. This resulted in some slacking off by members
of our group, and it made analyzing my contribution to the milestone all the
more difficult. o
Proposals for change We definitely need to sit down and write our specific tasks for
next week, since we have completed the group-centered library design. That should put responsibility back on the
shoulders of each group member to ensure that overzealous (justifiably zealous! J ) people like Justin don’t
end up overcommitted. Managers: watch that the
success of your team doesn’t hinge too much on a single person. Nice journal. -----
RYANAIP
------------------------------------------------------------------------------------ Development StatusMilestone ProgressWe got a lot of work done this week. All of the infrastructure for factories is currently in place, including the creation of people based on demographic data. People factories contain IPersonBuilders, which in turn contain a SetUpPerson(IPerson person) method. When a person is created, the factory passes it to each of the person builders it contains. The builder then adds attributes and behaviors to the person. Currently, there is a GenderBuilder, a EthnicityBuilder and a IncomeBuilder (along with a MS3DefaultPersonBuilder). These builders are configured with demographic information by the wizard and then used to create random people. Currently, the most visible test of this is the GenderBuilder, which gives people a name based on their gender. This is essentially a modified
Builder Design Pattern. Check it out to
help you get a good articulation of what you are trying to do. The factories are currently integrated into the wizards. Once the UI is completely integrated, we’ll have set it up so that the controller makes factories and passes them to the view, which could then configure them. One must resolve the rather sticky
issue of where the model ends and the UI begins here and what the APIs are. Look in the source files for documentation. Over break I’ll compile documentation for the whole project and post it. Process AnalysisChoosing to take more time with this milestone was a good idea. We have much better integration between the UI and the model than we did a week ago, and I’m actually happy showing our demonstration to Dr. Nguyen. We’ve had better communication between the model group and the UI group this week (mostly a function of available time), and that’s helped us to get things done. Most things are going really well right now. We still need to work on making sure everyone stays up-to-date on what’s going on in-between milestones. Perhaps we should adopt the policy that when people accomplish something that could affect/enable someone in another group, they should post to the listserv, or just e-mail to the appropriate person. Thoughts? I’d go with posting to DevHood. Sending to
a single person keeps people out of the loop when everyone needs to be aware of
the issues. Nice journal. -----
THEWANG ---------------------------------------------------------------------------------- Milestone Status · The milestone is complete. Some unit tests might have to be done, but possibly not because they were already done for the old representation of attributes, and still held up with the redesign. · Now I’ve got to get to building necessary (and even unnecessary) attributes that can be compared. · This was a short week, and since much of the work was already completed last week, there wasn’t much to do. Development Process · The code review sounds like a great idea. It’ll be a great opportunity for us to get involved in the rest of the code from the other groups, thereby more clearly understanding what theirs does, what they might need from us, and why they need it. · A lot of the kinks seem to be worked out by now – either that, or we’ve just learned to deal with it. · [Insert weekly Friday afternoon lab gripe here] What obstacles were
encountered? What proposals for change
do you have (other than your usual Friday afternoon gripe)? ----- TJICE
----------------------------------------------------------------------------------------- ·
Milestone Status: Gains: This week
was slower than last week due to the fact that I was absent in NYC for 4
days. However, impressive gains were
still made. People are successfully
rendered chasing items and leaving spaces.
( There is light at the end of the tunnel. ) o Obstacles: Aside from
normal coding obstacles, there were no truly huge obstacles aside from a
shorter week for me. Proposed solution: The
proposed solution this time is to just work as hard as I have been
working. Everything else will be worked
out. ·
Development Process: o
What’s working: People are successfully rendered
chasing after items. The UI and Model
Group’s code have been truly merged now.
It’s cool to see a pack of people in a store chase after one item like a
pack of wolves. Now things are starting
to look up. o
What’s not working: So the Mall Manager’s renderer is not working, because I haven’t worked on it (
sorry. ) Was this part of the milestone?
I focused on having the clients.
I focused on this because I felt that being able to see multiple stores
having people pop in and out was more important than seeing the one screen on
the server. This problem will be fixed
by code freeze time. There are also some
quirky memory errors. It’s hard to
pinpoint the source of this error, but we think that it is in the toolbars used
in the GUI. o Proposals
for change: I need to fix the bugs
in the GUI. I need to make smoother
animations of people moving. I need to
actually have different pictures for people, items, etc. This will be done with a library class. I also need to add the zooming
capabilities. Another thing I will work
on is some functions for AI. Since I am
very knowledgeable in this area, I will write functions for picking a point in
a random shape w/ holes and for determining whether a given point is within a
given shape w/ holes. Nice journal. -----
WRPRICE ------------------------------------------------------------------------------------ Milestone (3)
Status: •Completeness: 80% •Gains
Made: •The NetHub,
its common classes, and the developer API have been implemented. •The HubLink
API (used to connect to the Hub) will automatically start the Hub if it isn't
already running, and multiple processes on the same machine using HubLink can connect to that same HubLink
at the same time without any problems. •Applications, using the HubLink, can successfully expose new services through the
Hub and receive a ServiceManager in return – which
will then notify the application of incoming connections. •Applications can also use the HubLink to initiate outgoing connections to services
running on other machines (or the same machine). •Debugging and documentation is
starting. •Obstacles
Encountered: •Notification events are having
trouble. The remote application is
looking for the local application's assembly in order to process the event. •It seemed like we found a new problem
around every corner of this milestone.
It took a long time to decide on an implementation method because of
opinions on how objects should be structured and varying theories on how remoting works (no one is an authority yet). The biggest obstacle was/is time. There’s nothing like
life on the bleeding edge! •Solutions
Proposed: •Microsoft has posted an errata document
regarding their own documentation on remoting events;
we have an implementation of their “working” means of remote events, but it is
still having some trouble and is receiving the current focus of our debugging
efforts. •Again, our
initial tasking should be more realistic with regard to the deadline. Development
Process: •What's
working: •The pair-/triple-/quaduple-
programming really worked well as this milestone came to a close. Our implementation finally started to gel
over the course of a couple nights and we made it to the “debug” stage. •What's
NOT working: •TermServ'ing into Exciton
still remains troublesome in two ways:
First, I still don't like how my interface in VS.NET is never the same since we all have
different preferences for our IDE and we all share a common user space. Second, the lag times on the remote desktop
from Symonds II or elsewhere can be very disruptive to the development process
when you're trying to make specific changes and have to wait every other line
for the screen to refresh and cursor to move. •I was slightly disappointed at the
criticism the AR group received at one point in the week because of our VSS
habits. We have been working in such a
way that multiple people were working on the same project at the same time
(just different parts of the project) and when one part changed significantly
the other people needed to synchronize that file. At times, this meant that the “NetworkingHubLib” and/or the “NetHub”
projects would not compile properly if someone tried to build the entire
project. While it is unfortunate, I
think it was an acceptable trade-off in return for the VSS functionality of
managing multiple checkouts. We
purposely placed those two projects outside of the “MallSimulation”
(don't recall exact name) project such that they would not affect the other
groups. •Proposed
Solutions: •Only checking-in code that compiles is
a good practice that should be achieved as much as possible, but I don't think
it should be a rule set in stone. By bending
the rules slightly, the AR group was able to be more productive. Furthermore, if a group only builds those
projects they're actively working on (or that are dependencies of the current
project) then other groups' projects won't cause problems. Instead of clicking on the “play” button or
pressing CTRL+SHIFT+B to build the entire
solution, all you need to do is right-click on the project and click “Build.”
That will build that project and any other projects it depends on,
without trying everything in the solution.
That way, “if you don't use it, it won't bother you,” and it's a faster
build since you're not wasting time with code you don't care about. Nice journal. ----- SWONG
--------------------------------------------------------------------------------------- It’s clear that working in a group has tremendous benefits. Slower perhaps on a per-line basis, but the code is better, so there’s a net win. Communications can be lost in a heartbeat. Always program with your eyes—and ears—open. Realistic tasking and time management are crucial. It’s looking good!! J |