Home Up Java Resources C++ Resources .NET Resources DevHood Search

Journal Entries, Week #11

 

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

 

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

Journal number 11

Status:

·        All done with this milestone. The suggestions given during the code review have been implemented. Including a visitor type structure that increases the robustness of the code to a large degree, no longer are we assuming that the proper IEntity is activating the code.

·        Also some new behaviors are in development, they would be further developed but there were problems when the production server appeared so this was delayed a bit. Browse and wander behaviors should be done by Monday.

What seems to be working

·        Symmonds is so much better now that we can work on the project without remoting to exciton.

·        Good work to Ryan, Bryan, and Jim, For their work with adapters and moving the model to implement NetHub.

What seems to not be working

·        We are working well, but don’t forget the importance of communication. We don’t waste to spend what little time is left because we mis-understood what another group needed.

 

Looking ahead

·        If we are serious about getting the project to work on the pocket pc then we need to recognize it as the next priority of the project and concentrate how to support the AR group in their endeavor.

 

Nice journal.

 

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

  • Status of Milestone
    • Gains Made: We are now able to see stores being added to the manager, and there is a window to select which location you want when a client logins in and starts a store.  It still needs to be refined, but it is essentially working.  Double buffering is causing us problems for some reason.  TJ and I spent a few hours looking at it, and were unsuccessful, but the gains made above took most of our time.  Making the transition to nethub was a major part of this milestone and the code appears to be working correctly with nethub.  Jeff and I managed to get rid of those two exceptions, GDI and out of memory, it was related to the toolbar package we were using.  Kijana made some nice mockups of the UI for pocket PC.  Using the now implemented mall adapter, we were able to get more tabs populated, and we are now able to set fields in the gui, and those changes are reflected in the model.  Finally, we were able to implement most of the changes suggested in the code review.
    • Obstacles: Mall adapter didn’t get implemented until near the end of the milestone so this held us back until near then end.  Similar problem with getting nethub code working.  We couldn’t get much farther until this was done.
      This sounds like a mis-tasking.   Be very aware of these sorts of dependencies and task such that one group isn’t put in the postion of waiting for another.
    • Proposed Solutions: We expected this, and worked to get these “bottlenecks” done as soon as we could.
  • Analysis of Development
    • Whats Working: I enjoyed the talk by Fulcher, and I would be interested to get more guest speakers (for other class and in the future).  I think it’s a great way to learn and find out about new things coming up in the industry.
    • Whats Not Working: It was unfortunate that the audience was small for Fulcher’s talk.  Many had to leave after 1 hour, and we spent the first half hour getting food and talking about unrelated things.  The food was really good, but it turned out to be more of a distraction than anything else.
    • Proposed Changes: In the future maybe we can have guest talks from 4-6 so there is plenty of time and more people can stay.  Or make sure the speaker knows that we have only one hour, and get right down to business on time.
      You’re right that the food ended up being more of a distraction than expected.   Perhaps an evening time would be better—I wanted everyone to feel relaxed and be able to enjoy and interact freely.

 

Nice journal.

 

 

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

  • Status of Milestone:
    • Gains made:  The connection functionality that existed using RemotingLib has be re-implemented using the NetworkingHubLib which significant improvement in functionality, simplicity, and flexibility.  Additionally, allowing the client to select his location in the mall before he begins running has been implemented.
    • Problems Encountered:  Waiting.  This is was an especially big problem this time.  Since every group had tasked things that depended on what other groups are doing it often happened that one group was waiting on another (sorry TJ).  I think everyone worked it out well together though.  Also, since so much was changing this in this milestone it became very difficult to develop and have your changes still work the next day.  I didn’t want to check in my work until it was fully functional.  This caused problems because other members of my group were changing things constantly that affected my work.  This made it very difficult to merge differences.
    • Solutions Proposed:  Waiting is always going to be a problem.  I think we handled it about as well as possible.  Since each group is so small it should be possible to communicate with one another what is being changed.  We all know what each other are working on and should be able to figure out what code that uses.  Simply asking “If I change this, will it affect your changes” would solve a lot of problems.  As to source save, bomb Microsoft until they make it work better.
      This is where everyone working in physical proximity can really make a difference.

  • Development Process:
    • What’s working:  Lines of communication.  For the most part everyone has worked out to whom they need to talk to figure out the solution to a problem quickly.  This is thanks to the specialization each member has taken in a particular area of their groups work.  In general this speeds things up.
    • What’s not:  Time.  Too much to do, not enough time to do it.  We’ve got a lot of functionality that we are trying to finish on this and I’m not convinced there is enough time to do it all.
    • Solutions:  Decide what’s most important and focus on making that “perfect” rather than making it work and then having a lot of other things too.
      Did you mean to say it the other way around?   I.e. “make it work rather than make it perfect”?

 

Nice journal.

 

 

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

Milestone:

 

90-95% completion.  I made some concept sketches in Illustrator for the interface for the PocketPC version.  Over the past two weeks, I also worked with Jeff on implementing changes from the code review, getting the model to update from the GUI, and code cleanup.  I did work a little with TJ, but the priority shifted to him getting rendering stuff done with Jim.

 

Gains Made:

 

  • Mock-ups of PocketPC interface – from doing these, I realize how little real-estate we’ll have to work with and how the usability issues will increase.  I don’t know if we’ll get to this point, but the tabbed-pane interface was something that Jeff and I thought would offer a clean, but usable design.  It’s definitely not as glamorous as the regular interface, but it would serve the purpose.
    Such are the engineering trade-offs.
  • Still some double buffering issues, but Jeff and I worked on getting the model to update from the fields in the GUI.
  • Code cleanup

 

Obstacles encountered:

 

Double buffering (as stated) is still an issue.  There were some weird things happening in the GUI code when we tried to abstract some classes out.  Be specific! However, I think most of these have been ameliorated.  The looming deadline and time crunch have made this an increasingly hurried experience.

 

Solutions proposed:

 

Split up the work again.  It seems that PocketPC development is again a priority.  If we think we can get something done, then Jeff and I will probably split our time between MallAdapter stuff in the GUI and coming up with an interface for PocketPC.

 

Development Process:

 

What seems to be working:

  • Communication seems to be working.
  • Working between groups
  • More of the actual application

 

What doesn’t seem to be working:

 

  • More of the nifty idealistic features (like chat) may end up getting scrapped
  • We haven’t communicated with the customer for a while.  I guess we should have been informing DXN of the changes to the game plan (we’re sort of deviated from what we promised we’d deliver). 
  • PocketPC – still don’t know what’s going on here.

 

Proposal for change:

 

I think in the last 3 weeks of this (that’s basically all that’s left) we should continue to focus on what’s working now (refining and finishing it).  We can start to think about PocketPC, but not if it takes away from completing the main app.  Perhaps we can devide labors (again) within the groups and devote a few people to PocketPC development.  I think we also need to talk to the customer…

 

Nice journal.

 

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

Milestone:

 

Gains Made

I spent this week working on adding more functionality to the GUI.  Specifically, I worked on the “Other Stores” tab in the Manager and the Client as well as the Watch List functionality for the Client.  Kijana and I also spent some time working on custom controls.  The list view that we’d been using to display all our store information didn’t allow editing, so we extended ListView with a new version that would allow editing.

 

Obstacles

The main obstacle I encountered this week was having to go out of town unexpectedly on Thursday afternoon.  I was able to continue working from home over remote desktop, but I could not run a server and client on Exciton simultaneously.  Why not?   Aren’t you supposed to be able to do this?  This meant I couldn’t test the new code that using the IMallAdapter.  Testing will be done as soon as I get back in town to ensure that this works….

 

Development Process

 

What's Working

Communication between groups has been a strong point over the last milestone, in terms on knowing what to expect when from other groups.  This is encouraging because early in the project communication was always in my “What’s Not Working” section.  I think everyone has learned how to work as part of a small team and part of a larger project group.   J

 

What's Not Working / Change

Having to leave town unexpectedly puts a kink in the development process.  We’d done most of our work earlier in the week so it didn’t turn out to be that big of a deal.  Solution?  Someone find me a job so I don’t have to leave town the night before a milestone is due ;)
Be sure to always tell prospective employers about this project.   They’ll be very impressed!

 

Nice journal.

 

 

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

Milestone: Construct MallAdapter (%100 complete)

 

Progress:

 

          This milestone I constructed the MallAdapter and IMallAdapter classes.  The milestone actually entailed coming up with how the UI and model should interact in all parts.  To do this we (Ryan and I) created the ISpaceAdapter class.  This class is the generic behaviors for just accesing information about the particular space.  The IMallAdapter and ISpaceAdapter extend this interface, and furthermore add the ability to change the space they connect to.  The IMallClient adapter allows the client to see the mall without need of an IMallAdapter, and with a bit more functionality then ISpaceAdapter.  ISpaceAdapter still allows certain small changes to the entire space, so we decided it should not extend ISpaceAdapter, but instead should be a separate class completely. 

 

            Ryan and I redid the basic model components for spaces, creating IMall, and fixing some inheritance issues (basically having a mall extend a space, instead of containing a space.)

 

            I also worked with Ryan on retooling the factory setup (Mall Factory and builders), and Jim on turning in his code.

 

Development issues:

 

            SourceSafe is giving us a lot of problems.  While it is a bit late to change the setup, I suggest finding a more reliable code management system.  We have had troubles ranging from not being able to turn in stuff, to turning in stuff, but the system not actually updating the files.  I don’t even want to get into what happened on Wednesday night, when Jim and Ryan and I tried to turn in our stuff.  Suggestion for next time, would be to find something else.  I suggest taking the latest copy of the code and creating a brand-new database.    I suspect that something has gotten corrupted in the current DB.

 

            Things went smoothly except for that.  I think that the most important thing is to be able to be at a point, where we can all work independently.  There should not have to be much interaction between UI, and Model.  Since we want independent systems, the interfaces, after this milestone should be setup.  Everything should now only have to go through those interfaces, allowing for independent sections.  While this shouldn’t stop communication, it seems that now all the groups need to do is work within the setup for everything to connect properly.  This may be optimistic, we should be approaching this point.

The question is, should you have reached this point earlier than this?   What does this say about coupling in the original design/implementation?

 

 

Nice journal.

 

 

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

Milestone:

  • Exception Handling/Robustness for NetworkingHubLib (95%)
  • Closing HubLink/ServiceManager/IConnection (85%)
  • Gains Made:
    • Robby and I worked a few hours on making the NetworkingHubLib more robust and we think we have caught just about every possible exception.  There may be a few things that we missed since it is very hard to detect when a remote program has shut down so if anyone runs into any SocketExceptions or other odd exceptions tell us! 
    • I worked on closing HubLinks, ServiceManagers, and IConnections.  I believe I have a pretty good scheme set up such that a HubLink will close all of its ServiceManagers and a ServiceManager will close all of its IConnections.  I added close events to IConnections so if an IConnection is unexpectedly closed from the other side then you have some way of acting upon the closed connection.
      This sort of cascading clean-up is a standard technique.   Just be sure to rigorously follow a bottom-up shutdown or you’ll run into problems.
    • I fixed a couple of small things that Jim needed for his integration and helped him with making sure that he was doing the right things to integrate with the NetworkingHubLib.
  • Obstacles Encountered:
    • Although the closing code is implemented it currently does not physically stop remoting from working.  I think I’m calling the correct remoting code, but it does not seem to do anything.  There may be something wrong with the way I am physically disconnecting remoting objects, but more likely it seems that remoting channels do not close instantly.  I read several articles on the internet documenting this problem and no one seemed to have a solution.  The best answer I could find was at : http://discuss.develop.com/archives/wa.exe?A2=ind0202C&L=DOTNET&P=R23033

It appears that Microsoft delays the closing of these channels for some reason.
Can you detect if a channel has been closed?   If so, then you can simply wait for it to happen.

    • Microsoft has not provided us with a way to deregister a type that is served on a network channel.  Essentially you cannot deregister a service.  In order to do so you have to close down the entire channel.  So, when ServiceManager.Close is called I disconnect all of the connections that are registered on the server and I disconnect the underlying queue, but the service still exists on the port!
      Be sure to document this issue!
    • There is still no way for anything in the RemotingHubLib to detect if a remote service/connection/hub has closed on the other side.  I’d suggest some kind of pinging, but it seems too late in the project.
      Be sure to document this issue!
    • I ran into a ghost error on my chat test program.  Robby and I started going over it, but quickly ran into kernel code.  Robby is currently investigating.  The problem doesn’t necessarily affect our project, but it might spring up at some point.
  • Solutions Proposed:
    • I may need someone to look over my closing code to verify what I am doing works.
    • Hopefully Robby will be able to track down our “ghost error”.

Development Process:

  • What seems to be working?
    • Everyone is intent on getting our application up to release level so there has been a lot of cooperation.  If someone is running into a problem we all need to help them as soon as possible since we’re getting closer to our deadline.
  • What seems to not be working?
    • Things seem to be going well, but we need to really question weather we are going to get anything done for the pocketPC’s.
  • Proposals for change:
    • I think we may need to have a class meeting where we lay out everything that needs to be done to finish this project.  We need a universal group of tasks so we all know where the project stands and what needs to be done.  We may have to break down the group structure in the final weeks to get our product ready.
      Tasking is critical at this juncture!

 

Nice journal.

 

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

·        Milestone Status:

 

o       Gains:  I’ve pretty much completed what I feel is a solid plan for bringing this system to the Pocket PC, given the constraints of only using Web Services.
Be sure to get the link posted to DevHood

 

o       Obstacles:  It was a lot of code to gaze over – basically ALL of the UI code (to check to see if they need model interaction), and a lot of the model code, to figure out exactly what the model interfaces do.

 

o       Proposed solution:  A solution for reorganization of certain interfaces / namespaces will be proposed in a document, which I will link off of DevHood (And probably e-mail the class too, since the topic will cover both Model and UI, and might need people from all the groups to help implement).  Another nifty idea I thought of tonight is the idea of writing a C# Web Control Library (basically like an ActiveX control, but in the .NET world).  Users could then go to a web server and view their store without having to install an application.  For businessmen on the run, using commercial kiosks or the sort, this may be a very appealing solution, and might have similar constraints to the Pocket PC.
Are you saying that it might be possible to produce a PPC implementation without ever programming the PPC?

 

·        Development Process:

 

What’s working: I can’t believe that this is Journal #11 (I’ve never done anything this reliably systematic before… then again, my first journals were pretty unsystematic in regards to their arrival date :-P).  I also can’t believe we only have 3 weeks left in this project, but yeah, getting onto the real “what’s working”…

 

I think working with the UI group (having them help explain to me what they use from the model) has been constructive.  In addition, getting VS .NET in Symonds East was nice too.

 

o       What’s not working: Symonds East is used a lot more than Symonds West.  Especially for other classes like Elec220, etc.   That gets in the way, or makes it difficult, because we often want to come in and randomly work on 410 (it’s not always good to work at odd hours… 1-3am).

 

o       Proposals for change:  I think it wouldn’t be too much to ask for some of the other classes to move to the West side when not in use.  I know that Elec220 did that for us today, so maybe it can get some sort of collaboration at the professor level, or something like that.
Try to get me some specifics on times and classes that are affected and I’ll see what can be done.

 

Nice journal.

 

 

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

·        Status of the student's milestones

o       Gains made 

I was unable to make much progress on my milestone, since I spent the majority of the week in bed or exhausted from fever and illness.  I spent some time trying to investigate an issue Justin had shown me on Monday.  I successfully hooked up a kernel debugger to my system, and using the public Windows debug symbols I was able to locate the problem thread and gather some debug info.

o       Obstacles encountered

Relating to the above issue, which was an obstacle to the stability and robustness of the Net Hub remoting, I had difficulties following the stack trace through portions of the .NET framework since the Windows debugger supplied by Microsoft does not support/is not aware of the framework.  This made any conclusion about what the thread was doing impossible for me the consumer to determine.

o       Solutions proposed

I’m confident that this problem is a bug in the .NET framework relating to Forms and/or Remoting.  Our only option at this point would be to contact the Microsoft .NET team to allow them to analyze this easily reproducible, yet very obscure bug.  Other than that, keep our fingers crossed that the bug doesn’t creep up in the simulation.

·        Analysis of development process
 

o       What seems to be working

Over the past milestone, we’ve done well at identifying the areas we need to focus our efforts on, and then focusing our efforts.  I’m still skeptical about any Pocket PC app, but I feel like we are taking the steps necessary to accomplish it.

o       What seems to not be working

I think people including myself are starting to feel like the project is winding down (as the semester is winding down), and they are putting a little less effort forward to finish with a great product.  Our product is nearing completion, but it is nowhere complete (no could it ever be), and everyone needs to try to keep up the effort they had at the beginning of the semester and try to make the product as superb as possible.

o       Proposals for change

This isn’t so much for change, but it is a proposal.  As the product nears completion, I think we need something that will bring the entire class closer together so that we feel that we as a class created this product.  Right now and throughout the semester, those of us who aren’t group leaders haven’t had a great deal of contact with more than one or two people outside our dev group, and I think that’s disappointing for a group of 13 students in one class working on one project.  When Dr Wong says “look what you guys have done”, it seems like look what 1/3 we’ve done and look at what 1/3 the model group’s done and what 1/3 the UI’s done.  I’m not sure how it should be done, but I’d like to see some more inter-group bonding as the project nears completion/shipping.
Don’t short change yourself.   It has taken 100% of everyone’s efforts to get us this far.   The success we’ve had is due to everyone’s participation, not just the group leaders.   Not everyone’s work is glamorous or even visible at times.    But if that little hidden bug hadn’t been solved, then none of the more showy achievements could have come to fruition.

I would suggest that if you want to know more about what another group is doing, then sit down with them and ask them.   During class is a good time to do that.

I’m open to more “bonding” activities too.      Let’s plan some pure fun stuff too.

Nice journal.

 

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

Development Status

I’m happy with the success of this milestone.  The model group got a lot of things done, including getting the new networking code in place.  I worked on several different things:

 

  • Factories: As per my individual milestone, I’ve completed implementation of factories so that they actually use the data that is stored in them when creating entities and spaces.  (Before, this was only the case with the people factories.)  I also created a mall factory.  We didn’t do a major overhaul of the interfaces as we’d considered, but instead decided to stick with what was working for now.

    In the next milestone, we’re going to try setting up the system so that factories are run separately from the main GUI.  Running a factory would load or create a store and start it running on the machine.  Once a store is running, it will show up as an option in the NetHub system tray menu.  Selecting that option would load a GUI connected to the store.  This will help us in keeping our view and model completely separate and should be helpful in connecting the PocketPC GUI later.

    I’m not sure how the new implementation will work from a user interaction standpoint, but the task of separating the model completely from the view is necessary in any case.
  • Adapters: There was lots of work involving reorganizing adapters and creating the mall adapter interfaces.  Since this was technically Bryan’s milestone, see his journal for the details.

    I will note that IMallClientAdatper wasn’t implemented in a concrete class.  This wasn’t practical with the networking code in flux, since the adapter is the mechanism the store GUI uses to communicate with the mall server.
  • Code Clean-Up: We removed/merged in all of the “Milestone3” and etc. references from class names, so there’s only one version of the classes we’re using.  Bryan and I also cleaned up the Mall / Space hierarchy in the model so that we actually have an IMall interface, as opposed to just a concrete Mall implementation.  And we made unique ID’s actually unique – take a look at the System.Guid class.
  • Networking Code: NetHub works!  We spent a lot of time merging the networking code that Jim wrote in with the modified adapters and mall model code that Bryan and I wrote.  Jim had to keep his copy out of source control because he was making such substantial changes, and in that time Bryan and I had to change some of the classes he was working on.  In the end it all got done, though.

 

Note that the project in source safe has moved to the Production directory.  For more information, check out my post to the newsgroup from Friday morning.

 

Process Analysis

Work continues to go well, and I continue to be impressed with improving inter-group communications.  I worked more closely with the UI group in determining exactly what they needed for the adapters and factories, and Jim had to work closely with the AR group to get the networking code working.

 

My biggest complaint for the week is with SourceSafe.  When Bryan, Jim and I were merging our code, SourceSafe failed to properly put things together and wouldn’t allow us to roll back some of our changes.  We ended up having to go through and merge the code by hand and check a new version into SourceSafe.  It’s probably too late in the semester to go through and set up another system (like cvs), but I’d suggest using something else next year.
See my suggestion above for creating a new VSS DB.

 

I do question the feasibility of getting a Pocket PC version of the code working before the end of the semester, along with the regular version.  I think that if we pursue that route, we have to be aware that we won’t get as far in implementing the actual product.  We should make sure that’s a choice we want to make.

Reality check:   We have satisfy a real funding agency that gave us real dollars and who is keenly interested in what we do with the PPCs.  

 

Nice journal.

 

 

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

Milestone Status

 

Gains made:

·        Ali and I decided upon various preference behaviors such as when to enter stores and the mall (instead of dying) and what to do with items (specifically the timing of decisions and the possible choices for different items).  I don’t think (yes or no?  Be sure about these things!)  that they been integrated into the current execution model, however.  Let’s get them in!

·        Some general behaviors have been written, but there will probably need to be more specific ones made for specific items to differentiate between them (since you can’t try on pizzas or taste shirts).

 

Obstacles:

·        Realizing that there are only about 3 weeks of school left.

·        Putting everything together (not really, but it takes time).  Weekends are more free to being productive, and to meet.

 

Solutions:

·        Have the people in comp411 finish the project…

·        Don’t sleep.  You were considering actually sleeping?  J

 

Development Process

 

What’s working:

·        The half hour of the Stephen Fulcher talk that I got to hear was nice.

·        It’s good that we all have realistic expectations of how much of this project is going to get done so that we won’t have to put in 80 hours of work in the last week of classes or get mad at each other (I mean any more than we already areJ) because of unrealistic expectations.

 

What’s not:

·        I know it’s late, but I never understood why we just had talks start at lunch and provide food then instead of having people with other classes miss the bulk of people’s talks.  Oh well, maybe next year…

·        I guess we won’t really get around to the pocket PCs.  Are you giving up already?   See my note in Ryan’s journal.

 

Suggestions:

·        Keep on making class time work time or demo time.

·        I don’t think too much change right now is going to do a lot of good.  Except that everything must be done faster.

 

Nice journal.

 

 

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

·        Milestone Status:

 

Gains: This week was extremely productive.  I was able to ( along with the help of Jim ) get the code to a level that I had my personal copy of the code at over Spring Break.  The networking hub was implemented finally and things were finally worked out.  As of right now: People and items are rendered in the store and the mall.  The mall has a full mall view ( i.e. the central space and the connecting stores are rendered. )  The double buffering problem is solved as far as the actual rendering of the simulation is concerned.  There is no noticeable flickering.  The user can also select what space he/she wishes on the client-end.  And the animation is smooth now.

 

o       Obstacles: There were all types of coding obstacles.  These obstacles were subtle at times, dealing with Serializable objects.  And at other times they were pretty obvious.  <