|
||||||||
Journal Entries, Week #13
Quick jump to: alio, beowulf, jamesmcd, jkdot, jsegars, lipinski, localguy, othello, rjmorgan, ryanaip, thewang, tjice, wrprice, swong. ----- ALIO
------------------------------------------------------------------------------------------- Status of Milestone: 95%
What is
the status of these problems? Have they
been overcome? If not, do you have a
proposed solution for them? Development Process
-----
BEOWULF
-----------------------------------------------------------------------------------
Nice
journal. ----- JAMESMCD
---------------------------------------------------------------------------------
Nice
journal. ----- JKDOT
---------------------------------------------------------------------------------------- Milestone: For this milestone I worked mostly with Jeff on the connection to the server and with Brian on the toolbars and Menu. I also offered some support to the AR group for the PocketPC implementation. Continuing discussion with TJ and Will about the concept for the PocketPC interface implementation. Gains Made:
Obstacles encountered:
Solutions proposed: One less
project in another class would have helped tremendously. Just more time would have been nice. Development Process: What seems to be working:
What doesn’t seem to be working:
Proposal for change: Looking
back, it seems that we did many things in an organized fashion to get us to
this point. However, since we did have
to amputate some features because of lack of time and other problems of higher
priority coming up, if this was done again, the team should spend more time
evaluating the features and making more realistic decisions. For a couple of the features, though realistic
at design-time, we just didn’t think that they would get sidelined. What may
be helpful next time:
Nice
journal. -----
JSEGARS
------------------------------------------------------------------------------------- Gains Made This
week was continuation of most of the work from last week. Further refinements were made to the GUI so
that values within control only update when they are dirty rather than control
updating each time. I also worked on
displaying demographic attributes through the DemographicAtt property that
Gilbert and Ali created. The final part
of my milestone was working on the PocketPC UI.
I was able to build Kijana’s mockups in Obstacles My
biggest obstacle this week was difficulty in finding a place to work on the
PocketPC project. There wasn’t a
SourceSafe repository set up and a very limited number of machines had Development Process What's Working Intergroup
communication has been very strong as the project has wound down. We’ve had some last minute needs come up in
the UI (IMallClientAdapter and DemographicAtts) and the model group has done a
great job of providing the needed functionality. What's Not Working / Change I
mentioned this in the obstacles section, but the lack of any Nice journal. -----
LIPINSKI
------------------------------------------------------------------------------------- Milestone:
· Configuring the model and GUI to run in separate processes, communicating through the NetHub. (E.g., write controllers for them.) · Make the factories run as an application used to launch stores. · Figure out which new adapters are needed for the PocketPC and implement them (work the AR group on this). · Implement MallClientAdapter if there’s time, but the PocketPC functionality is the priority. Gains Made: Ryan and I did got everything done, and then some. With Jim we got a GUI application made, to hook into the current model. We also retooled the adapters to make this work, and Ryan made the IPocketPCAdapter, specifically for the pocketPC. Ryan and I also redid the Wizards, and set them to appear on startup. With this, was also having the Wizards configure the factories. I made an instantiation of IMallClientAdapter, it now just needs to be passed to the Client UI. I also made stores run by themselves and add people to them. Obstacles Encountered: · Algorithm for determining whether to add people each turn. · The Wizards don’t seem to work as they are described in their API. Solutions Proposed: Probability of appearance is
(MaxPeople – peopleCurrentlyinMall)/ MaxPeople.
This is thanks to Theo. The Mall
will always contain at least one person, since probability is 1 in that
case. Furthermore the probability of
adding people once at MaxPeople is 0, capping the population. I’m open to further suggestions if anyone has
any. In general,
this probability should be encapsulated as some sort of strategy. One could imagine a probability that was also
affected by the time of day, for instance.
Theo’s self-limiting probability is nice, theoretically, but not very
realistic. People going or not going to a mall because the current
number of people in it is only a small effect. I rigged the Wizards to disable the back button on the first panel. Previously if you pressed back, an exception was thrown. The API suggest ways to disable the back button, but they don’t work. Development ProcessWhat’s Working: Pretty much everything in the model is ready. The only thing is actually finishing setting it all up. We have the factories, we have the model working, and we have behaviors. We need to tie in the advanced behaviors and adjust the factories for them. Hitting Jim, even if it was with a blunt, foamy object. What’s not Working: We still don’t have a “final product” defined yet. We’ve
all written about that for the past 3 Journals, but nothing’s happened.
The UI still has a ton of little things that are “off.” There are menus with nothing in them. There is no help section. To Change: We need to take the next class period and actually put down what we can accomplish. I don’t know what exactly the plans are with the menu, but we need to get the UI in shipping state. Nice journal. -----
LOCALGUY
--------------------------------------------------------------------------------- Milestone:
Development Process:
Nice journal. -----
OTHELLO
----------------------------------------------------------------------------------- ·
Milestone Status: o Gains: So, the adapter layer is implemented
now. I’m in the process of making a
Pocket PC test of the adapter layer, to make sure that the information is
transporting correctly. In implementing the adapter layer, we’ve found out that many types
don’t reappear the way that we’d expect them once returned from a proxy
generated by the WSDL tool. Other types,
like System.Drawing.PointF are unavailable on the Pocket PC (and for some
reason, we couldn’t get WSDL to generate a proxy of that type, though we could
generate proxies for our own customized Serializable types). Ryan and Will implemented an adapter layer that used C#’s
rectangular array abilities, and the ability to composite arrays of
arrays. However, when returned by the
WSDL proxy, the arrays would all be one-dimensional. This leads us to question exactly what was
going on under the hood, and at what order were the array elements
returned. Some of the composited arrays
didn’t have the size of the arrays stored as data fields (since they’re
inherently a field in the object, in the C# type). If composited arrays are converted to a one
dimensional array, with their elements immediately after each other, it would
be impossible to reconstitute them with the multidimensional size data again. Thus, I rewrote the adapter layer (the PPCSpaceAdapter class,
which wraps around any SpaceAdapter, and is shared via Remoting as a Web
Service), to return one-dimensional data, and to rearrange the data so that
they can be reconstituted into multiple dimensions. Mostly, for our data we were lucky, though this isn’t as “elegant
and extensible” as I had hoped. But then
again, protocols never are. The storage
mechanism is pretty simple. The actual
data types for the multidimensional occurrences are in floats or strings. Luckily, float captures a large range of ints
and can convert back without error. If
it really becomes a problem, I know for a fact that the int-part of the float
is at least 16 bits, so we can always store the high 16 bits of the int size in
one float, and the other lower 16 bits in the next float, and thus get the full
functionality. Since we’re using SOAP
already, the efficiency issue is pretty much moot, and writing support for that
wouldn’t be hard at all. I thought about using the actual float with the same
binary equivalent as the int (since both are 32 bits), however I suspect that
SOAP might not have strict floating point requirements by default, so the
binary representation of one float value might change between processors. If that’s the case, since x86 and Pocket PC
processors aren’t the same, then we shouldn’t count on binary compatibility by
default. I know that in Java, you have
to label a block with “strictfp” to force the absolute IEEE-adherence, otherwise
it allows particular float operations to be done in fashions that might be
faster for whatever processor it’s running on. One can also convert an int to a string and
back to an int without error too. Thus taking advantage of ints being stored as floats or strings as
needed, the multidimensional arrays of strings/floats are stored in this order: (1)
the
number of arrays in this 2d array, that are being encoded back to back (2)
the
arrays encoded, back to back, with the size of the arrays encoded as the first
piece of data before the actual array data. The size of the output array is first made by making a sweep
across the outer array (of the multidimensional staggered array) and counting
the sizes of elements of the arrays inside (without traversing them). This isn’t very expensive, and is done so
that I can allocate the output array’s size first, before populating it (the
number of data elements required to store the inlined size data is also
considered). Thus, the WebSpaceAdapter (which wraps around the WSDL proxy,
WebSpaceProxy) reconstitutes the data into multidimensional arrays on the other
side, with operations that are relatively cheap (float to int conversion, and
string to int parsing). Since this is
encoded in SOAP (plaintext protocol), then we know that storing the int sizes
temporarily as strings in a data array isn’t expensive, since the data came in
already in plaintext characters, so there’s no “ToString()” being called on the
client side. Some of the data arrays are presorted before the arrive on the
Pocket PC (using the Array.Sort() method, which I think is either a good
implementation of quicksort, or a mergesort implementation). It makes sense to sort the data on the faster
machine, prior to transferring it across the wire, since it doesn’t change the
data size and make it longer to transfer across. With the sorted data, the UI then can blindly
populate the GUI in the order provided, and not have to worry about fields
appearing in different order over time.
This would be more efficient if the model’s backing collection guaranteed
a sort order, but as far as I know, most of this is backed in hashtables, not
in sorted dictionary structures. So, right now, I’ll most likely make a PPC client that asks a
SpaceAdapter for values. I don’t know if
I’ll hook it into an actual mall or store, depending on the stability of the
mall development and how much someone can quickly explain how to instantiate a
mall / store space. o Obstacles: The reconstituting of types as different than
the original types is definitely a curve ball.
Though I think we handled it pretty well. o Proposed solution: I think we’ve implemented
the best solution possible, to make sure that our types and objects are either
not transformed across the wire, or transformed in means that we understand. ·
Development Process: o
What’s working: Big coding
sessions in Symonds, as always.
Communication is nice, and it’s nice to see that there’s fundamental
understanding of how integral it is at this time. o What’s not working: Load distribution is always hard/uneven, but crunch time is
definitely a time where it can be expected to be bad. o Proposals for change: Finishing this course will
be nice…. :-P Nice journal. -----
RJMORGAN -------------------------------------------------------------------------------- ·
Status of the student's milestones o
Gains made This past week I was successful in converting the NetHub GUI into
a small tray icon, and I was able to include useful information about the
NetHub (port, services, etc). The Nethub
is now much less obtrusive (and much less likely to be closed by the user!), so
users will focus on the MallSimulation. o
Obstacles encountered Midweek I was
informed that the model group wanted to receive events that were triggered by
the user for a particular zone. This
required adding methods to the HubLink and exposing the HubLink to the NetHub
process. o
Solutions proposed Will and I were able to rush it and take the steps necessary to
get the requirement completed by Friday.
In the future earlier
notice would be helpful for ensuring that development is completed on time. ·
Analysis of development process o
What seems to be working It seems that the project has come together well, through the
tireless efforts of our group. I’m very
happy with the way we have worked together to ensure that the PocketPC
milestone was met, as I had major doubts that we would be unable to finish it. o
What seems to not be working The AR group’s tasking was never completed, which made it difficult
for me to point to specific things we accomplished or failed to accomplish.
To be fair our requirements changed frequently throughout the milestone,
especially for the web service, but we needed to be more proactive about getting an initial tasking
and revising it. o
Proposals for change I propose that we all give ourselves a pat on the back for a job
well done throughout the semester. All
of my other proposals have been addressed well, and I’ve run out of things to
complain about (except the lab time). Nice
journal. -----
RYANAIP
------------------------------------------------------------------------------------ Development StatusLots of things got done this week, but there’s still more to do…
For the most part, all of the functionality of the model has been implemented. What’s left is to bug-proof the code and help the other groups integrate the model functionality into their parts of the project. Process AnalysisThis is the time when the rapid development of the XP process makes things difficult. As we tie everything together, there are places where the system isn’t quite as extensible as we’d like it to be or where little bugs creep in. Some of these things probably wouldn’t be there if we’d taken a little more time at the beginning of the semester. I assume that’s where things like experience and unit tests help – although unit testing distributed systems is something that no one has quite figured out how to do. The question is how much additional
testing would have fixed a priori. I
believe that it may have pointed out some issues if done well, e.g. if the
tests did a good job of looking at
flexibility issues, some redesign may have been forced earlier. On the other hand, a big problem with XP is
its inability to foresee large quantum changes in the code. Up front design is needed for this. It’s all about “programming with your eyes
open”. In general, though, I think we’re in good shape. Everyone’s working hard and communicating well. We just need to keep working to get it done. (Also, Dr. Wong’s computer seems to expose more bugs than
anyone else’s…) Nice journal. -----
THEWANG
---------------------------------------------------------------------------------- Gains made: · Completed the Statistics classes. They are stored in the Model.Statistics namespace. Basically, each demographic (ethnicity, wealth, etc.) has a DemographicStats object that compiles statistics for a particular space. Therefore, one can [there is missing verb here] the number of purchases or people entering a room grouped by ethnicity or wealth or whatever else will be made up. Probably the most useful methods: o Void AddDemographicGroup(string groupName) – adds a new demographic group the particular demographic (i.e. Slovenian). o Void IncrementPerson(DemographicAttribute att) – increments the number of people that have entered the space of the particular demographic group. If the group is not found, it will be created. o Void AddPurchase(DemographicAttribute att, PriceAttribute price) – adds the purchase by the particular demographic group to the stats. Again, if group is not found, it will be created. o I smell a Flyweight Design Pattern here. · To get the statistics (for the UI group), the SpaceAdapter has a method DemographicStats GetDemographicStats(string demoName) that will return the demographic stats corresponding to the demographic (ethnicity, wealth). Come to think about it, it would be easier to return an Ienumerator over the Stats class. So there will be a method: o IEnumerator GetStatsEnumerator(string demoName) – returns an enumerator over the Stats class. o The stats class has the following properties: NumPeople, NumItems, TotalSales, DemographicGroup. Those are pretty self-explanatory. · There is also a DemographicAttribute now that extends Aattribute. New demographics should instantiate this class. See the class for details. · The stats and new attributes only need to be inserted by the factories. Obstacles encountered: · I lost some code in sourcesafe. Pretty sad. I got it back though. · It seems a little late for a lot of the abstraction that should have been done (i.e. there doesn’t seem to be any way to use the abstraction at runtime. Like adding new demographics dynamically or new attributes. Solutions: · Just write stuff that works. Don’t bother writing abstract stuff that won’t be able to be used unless some of the model’s structure is reworked. This is a standard XP mantra. · Need to test a lot. Also a standard XP mantra. · Write the factories. That will determine whether the model code works or not. Development process: What’s working: · If nothing else, at least the gui looks good. That’s what’s really important J · Actually the model is coming together pretty nicely, too. What’s not: · Not much. It’s time to just stick our faces in the computer and put everything together. Solutions: · Write code and test it. Nice journal. ----- TJICE
----------------------------------------------------------------------------------------- ·
Milestone Status: Gains: I have started on the Pocket PC
implementation. The basic GUI is
finished. We just need to plug in the
Web Service Code and things should be on their way. Code that I had last week was magically
overridden, and bugs were introduced.
But I have fixed these. I have
worked a bit on behaviors. I have
implemented a zoom in/out feature on both the client and the server applications. The rendering system has been totally
revamped. Now people are more than just
little red circles. They are circles
with expressions now. The change in a
person’s appearance is based on the behavior that is dominant at the time. This required me to change some code in the
behaviors and revamp my animation system.
Watch the level of coupling here. It’s really easy to create tight couplings
when doing this kind of stuff. o Obstacles: The only
obstacle I am facing currently is the fact that I cannot get anything from the
space proxy on the pocket pc. This
journal is a bit late because of that. I
have tried this out and things don’t work.
Your journal doesn’t have to be filled with successes. The point is to document where you are, wherever
that is. o Proposed
solution: I have posted to DevHood.
I will contact the AR Group tomorrow and try to iron out these
kinks. I don’t really know where this
problem is lying, but hopefully we can nip it in the butt. ·
Development Process: o
What’s working: Communication is good. We seem to get better at this with time. Everyone seems to know it’s crunch time and
is acting accordingly. o What’s not working: Well I’m a little disturbed that people check out more classes than they actually change. And when they check the code back in, they override changes made by o |