Skip Ribbon Commands
Skip to main content
Site ActionsUse SHIFT+ENTER to open the menu (new window).Open Menu Navigate Up
Sign In

Quick Launch

   
View: 

1. Milestone Status: Gains made
(If possible, include hyperlinks to what you mention here.)

 

1. Central Docs for Modules   SW:  It's not clear here what was accomplished this week vs. what was accomplished before this week or even if this statement simply means all you did was to write it all down in a single document.
2. Implement interface for ModuleManager subsystem. Updated API and start on implementation.

-Kevin

 

 (7%) 
 
 

 

 
Model
  • Reworked modules design to all synchronous. This change was made because it  eliminates complexity from module design, and the previous design with timing was not working.
  • Working on saving. Frank is currently working on 'serialization', so creating the objects on the model side which will be saved into the database which are module signatures (name & lambda), configurations (AKA plans, initial values & lambdas), and blueprints (AKA model, a connection matrix of module signatures).
  • Simulation Manager. John is working on the Simulation Manager which works as the state tracker for the modules, which calculates the value at a certain point in time, starts and stops the system, fetches results, etc.
 
Network
  • Working on Role Manager. Alex & Apoorv are working with the Microsoft auto-scaling frameworks to dynamically create/delete/move around roles as needed for different loads.
  • Working on Storage Manager. Damien is working on the storage manager and starting to integrate that with the model team (see Solutions for more).
  • Overall Architecture. See Network team's journals, but they have drafted a diagram of the overall architecture of the Networking subsystem and what it will do (working from the use cases)
 
GUI
  • MVC4 Design - The GUI team now understands that they need  to use a JavaScript/C# combination MVC4 design to get the functionality we want. From my understanding, this means that they will use JavaScript to move around objects on the view side, but use action points to call methods and load new web-pages whenever we need to talk with the back-end. (This could be a very bad description of what they need to do - I don't exactly understand it. See Archie's journal for a better description.)
 
Controller
  • Interfaces up on Main Project.  Each controller team member is responsible for their liaison team's subsystem's interfaces.
  • Updated Use Case diagram up on SharePoint. Randy completed the updates to the use cases, he's planning on having a version 2 ready for next Wednesday with any changes that are made during integration.
-Carrie

 MG: Great summary of everything that's going on!

 (7%) 
 
 

Use Case Diagram v1.1 - I had originally planned on only updating this after integration so I could update the diagram to reflect changes we discovered needed to be made during the integration process. This turned out to be a really bad idea for two reasons. First, there were many ideas that were discussed and agreed upon since diagram verson1 was released and because they weren't in the diagram, not everyone knew about the changes. Second, we never got integration done so if I had followed my original plan, I wouldn't have been able to update the diagram. 

Luckily, we decided it was a bad idea by wednesday so I was able update the diagram by thursday. This one includes the changes to module instantiation as well as a change in definition for Model and Configuration. In class on friday, the Module team also settled on a better definition for Blueprint, which I will add to the definitions block in the diagram. 

SW:  You were putting the cart in front of the horse--the Use Case/System Block  diagram is what is driving the integration not a result of the integration.    The whole point of the diagram is to communicate the unifying ideas across the teams.   Since the diagram wasn't updated, that communication failed and groups splintered from eachother.  

I also updated the interfaces in the DEV/Controller branch to reflect teh changes I made in the Use Case Diagram. MG: are you doing any actual development? Don't get me wrong, the use case diagram is important but losing a whole developer just to its maintenance is a tad excessive. If you aren't doing actual development (you don't list any here), you need to start again.   SW: Conversely, part of the reason you have to spend so much time on the diagram is that you aren't getting enough help and input from the rest of the class.    That is a SERIOUS PROBLEM.   Do not be passive about getting the involvement that you so desparately need.

-Randy

 (7%) 
 
 

​Implemented serialization* of Configs, Nodes, and Modules

MG: more details? I have no idea what this implies.

-Frank

 (7%) 
 
 

This week the GUI team focused very heavily on understanding ASP.NET MVC. I did get some work done on the implementation of jsPlumb over the weekend, related to this task: https://comp410.tfspreview.com/DefaultCollection/Comp410f12%20Main%20Project/_workitems/edit/120

 

However, we have all been pretty stumped by ASP.NET MVC and our major milestone goal has been to get over the learning hurdle as fast as we can.​   SW:  You need to clearly DOCUMENT exactly what you are trying to accomplish and what you're stumped about accomplishing it.   Be specific at the level of "we want to update the text in a status label" and "we want to upload a custom view of a component in jsPlumb and dynamically attach behaviors to it" -- actually that last one should be stated and then broken down into smaller tasks.

 (7%) 
 
 

​​Investigated scaling as per Task 137​, findings here:

http://www.bandgap.cs.rice.edu/classes/comp410/f12/F12%20Personal%20Updates/Scaling%20of%20worker%20role%20instances.aspx

Tomorrow (saturday) Apoorv and I will be trying Microsoft's azure scaling solution, the autoscaling application block. MG: please be explicit about how this will be useful/used for this project

SW:  Good research, good start at documentation.   Now, ask yourself, "what is the priority on the scaling capability right now?".   Then think "encapsulate, encapsulate, encapsulate!".

On Wednesday, Damien and Apoorv worked out architecture for our subsystem.  Details are here:

http://www.bandgap.cs.rice.edu/classes/comp410/f12/SitePages/Network.aspx


Tomorrow I will also start moving from hard TCP connection to WCF service for communication.

 (7%) 
 
 

  • This sprint we had started with finishing up our backlogged Task 146(https://comp410.tfspreview.com/DefaultCollection/Comp410f12%20Main%20Project/_workitems#_a=edit&id=146&triage=true SW:  Please use the correct URL for tasks as I've shown many times before and documented in the TFS wiki.   This task URL should have been:  https://comp410.tfspreview.com/DefaultCollection/Comp410f12%20Main%20Project/_workitems/edit/146 )  which was to put the demo code into the cloud, so in that perspective only we started looking into the detail architecture for the network subsystem. Damien and me was able to come up with the architecture of the network subsystem which includes consideration from various other subsystems like GUI and Modules.

     

  • Details about the architecture could be found out on the page(http://www.bandgap.cs.rice.edu/classes/comp410/f12/SitePages/Network.aspx).

     

  • With the help of the diagram only we were able to make some considerable decision like we need subsystems like web role and worker role manager along we would be needed with the allocation manager who would be responsible for the creation of modules that may or may not be collocated.

     

  • This diagram also helps us to understand the where we would be placing our subsystems inside our system.   SW:  Can you pleae formalize this diagram into your official documentation, not just as a photo in a side blog?

     

  • We now have started creating some of the task like management of the WCF communication between the roles and along with that we had continue working on our other task of storage management.


MG: sounds like a lot got done!

-Apoorv agarwal

 (7%) 
 
 

The GUI team has been working on updating our client-side focused code to using the ASP .NET MVC 4 structure.  Previously we were generating modules through jsPlumb by iterating over a C# loop that called the JS function createModule that made a module through jsPlumb.  There was no interaction with the backend.  We knew there was no communication with the backend at the time, and simply made the loop for testing the drawing of modules with jsPlumb.   SW:  I think some of your "C# code" was actually Razor code which has C# syntax.   Razor trnaslated the "C#" code into Javascript to run in the browser.

The MVC change means we are changing our code to have a separate controller for the palette and the main window/canvas.  These controllers make url call requests to the backend, which then sends back new web content to load into the page.  My understanding of the flow of the calls and MVC can be found in my page notes hereSW:  While its good that you wrote something down, the problem here is that the information is neither in a format or a location that someone else can easily find the relevant details they need.   What you wrote also doesn't givve enough details to really see what you are trying to do and what happened when you tried it.

All of this work has been corresponding to the task 107 (I made this link using the instructions from my J10 as posted by Dr. Wong -- and it works!  :-)).

-Archie​

 (7%) 
 
 

​This week has been focused on understanding/learning ASP.NET MVC.  

All of our efforts have been diverted into gaining a fundamental understanding of ASP.NET MVC, without which we cannot move forward.  

SW:  The lack of details here implies that you haven't learned anything all week...or did you just not write any of it down? 

-Nathan

 (7%) 
 
 

This week the GUI team mainly concentrated on understanding ASP.NET MVC .   SW:  But all that learning is locked away in each individual's brain as separate pieces to the puzzle, unable to be joined because non one can see the larger whole they create.   We read a lot of online tutorials and tried to create a basic MVC within the GUI. SW:  The main GUI is too complicated already to be able to tell what is working and what is not working.    There are too many variables, too much interacting stuff to be able to sort out issues.   Make a mini "test" project to isolate the issues! We created a dummy controller which made the server side calls for us. We used this to change a simple label on the web page using an action link .​   SW:  It's not clear if an ActionLink was the right thing to use here since ACtionLinks return <a>...</a> tags.

 

 (7%) 
 
 

​Martha

While the Managers still need to be implemented and some of the supporting classes need love, I feel optimistic about the state of the Model's code and our ability to finish the desired functionality before Mr. Hoffmesiter's meeting on the 9th.

Controller Team:

  • Randy released a new use case diagram
  • Controller API interfaces and Model interfaces have been merged such that they match closely enough to try implementing the SimulationManager, ModelManager, the Blueprint, etc.
    MG: what process did you follow for specifying the interface between the two?


Model Team:

  • Migration is complete. We can officially work just off the code in the main project now.
  • Of the two major issues encountered last week, timing has been solved by replacing the asynchronous module code from the warmup with shiny new synchronous modules.
  • With the exception of the Event Lambda, the new synchronous modules code may be ready to merge.
  • Lambda classes have taken back much of their functionality from modules, allowing easier storage. 
  • Google Docs Module documentation here under Module Interfaces
 (7%) 
 
 
The early part of the week I spent working on role-to-role communication via TCP channels and stub GUI code. I modified our test page so that actual processing would occur on the worker role when requested by the web role, rather than a hard-coded response. While this isn't vital to the final project, it should help us see the results of our actual code more clearly; that is, when we make changes to back-end processing, we can see them on the GUI.   SW:  This is a mission-croitical piece of technology (creating a process that calls all the way through to a worker role from a web page) that you had to get working for the final product, so it is very vital indeed.

On Wednesday I had a major development in cognitive understanding of our project. After class, I discussed the various structures of the networking subsystems (networking, storage, role managing, allocation managing). You can find what we drew up on our main page http://www.bandgap.cs.rice.edu/classes/comp410/f12/SitePages/Network.aspx    SW:  Arghh!!!  You never describe here, or in the linked page what that "major cognitive understanding" was!

With this knowledge, I began to work on the storage subsystem. Since we determined that the storage system would be separate from networking, as both web and worker roles would need to initialize and use it, I created a separate instantiable project. I also drew up some preliminary APIs based on our current needs, which you can find http://www.bandgap.cs.rice.edu/classes/comp410/f12/SitePages/Network%20Team%20APIs.aspx

-Damien
 (7%) 
 
 

I feel good about this week's progress. At least from the Modules system perspective.

The week began with me trying to tighten up timing within the synchronized module system. It became a huge pain because our core modules system is pretty much a direct port from the warmup project, where modules were inherently asynchronous. And while it would be technically possible to build a synchronous modules system out of the asynchronous modules, the problem is riddled with race conditions, patching functionality, and just generally felt like I was trying to bend our old modules system into a pretzel. It was a bad feeling. And it was impossible to write tests that passed for the system (both because it's hard to write tests for an asynchronous system, and because the system was inherently flawed).

I started drafting out a “Modules Revamp”, which basically redefines modules from the ground up with the assumption that they are synchronous. On Wednesday, Kevin approved the initial design decision and I went on to flesh it out into a fully working modules system with a full test suite that passes. That feels good. The new core modules system has a vastly simplified API, it maps very cleanly onto the way we're storing lambdas and composites in the database, and it works.

The old modules system has been a burden on my conscience ever since we starting migrating it to the main project because I knew it was a ticking time bomb. I knew it wouldn't be long before the whole thing blew up. And when I couldn't even get timing and synchronization working properly, I knew it was time to rethink the implementation. So, I'm happy.

The Modules Revamp™ also seems to help simplify our external interfaces. I met with Randy after class today to discuss the changes. We talked mainly about how instantiation of modules across VM's is going to work. With the new Blueprint structure for holding the structure of a composite module, the problem all but disappears. We found a really nice recursive approach to the problem, which is always great when dealing with composite types.

 MG: great! I like the testing

 

 (7%) 
 
 

​This week, I lifted some SIUnit members into a more general Unit class and modified our existing modules code to use the new classes. (Task 164: see SIValue, SIUnit, TypedValue, and Unit classes in the CommonData package). Still working on unit tests and the simulation manager implementation - the simulation manager interface is essentially done.


SW:  Where is documented exactly what the "Simulation Manager" is and exactly what it is supposed to do?

-John

 

 (7%) 
 

Total: 14

2. Milestone Status: Obstacles Encountered

 

Grafting synchronization  onto our asynchronous modules system was becoming too much of a kludge so we're revamping much of modules internals to make them synchronous from the start. MG: what changes to the modules does this imply? more details?

-Kevin

 

 (7%) 
 
 

​ 

Model
When I talked to Kevin, he said that the Model team did not currently have any blocking obstacles. There was a little confusion about the Simulation Manager and its border with the Networking system, but Randy and Adrien were clarifying this during class. Other than that, any unforeseen obstacles should appear this weekend when more rigorous testing and integration is done (see Solutions for more details).
 
Network
Via Apoorv, the network team does not have any major blocks currently. They said overall they have a better idea of what the scope of the network subsystem is (see diagram on their journals) and they are making good steady progress and are ready to start integrating storage.
 
GUI
The GUI team is having major difficulties with getting the interface to work. Today in class the worked a great deal on just changing a label when a button is clicked and had very limited success even when working closely with Dr. Wong & James.
 
Controller
The Controller team's major obstacle is that we haven't really started integrating yet. They're currently mostly blocked by the GUI team, since with the way the cloud system works, the Controller will be started once the web page is loaded (info via Randy). They've analyzed their interfaces and believe they are comprehensive, but need to start actually writing code and have a preliminary integration to test.
 
NOTE: I will be editing the page http://www.bandgap.cs.rice.edu/classes/comp410/f12/SitePages/Current%20Obstacles.aspx this weekend (aka by Monday class-time) with an updated run-down of the current obstacles each team is facing.
-Carrie

 

 (7%) 
 
 

Our initial goal of full integration fell apart when we discovered on monday that the GUI code was done incorrectly. The main integration was going to be modules + gui, but since gui was not ready, this pretty much did not happen. 

In addition, the obstacles that are are being encountered by gui appears to be really difficult. I spent a few hours working with them on thursday night because I had hoped they were farther along and I could at least help them integrate to the main controller level (using stub code) and then continue the integration with modules later on. Unfortuntely due to everyone's lack of understanding of Razor (cshtml) and the MVC4 pattern, even doing simple tasks became extremely difficult. This hurdle must be overcome soon or else integration (and testing) will become very difficult. MG: what is the challenge in understanding the pattern? Every journal keeps saying that GUI is having a lot of problems, but no one is presenting a series of ideas or concepts that are genuinely difficult to understand, just that lack of experience is a problem. The GUI team has been accruing experience for weeks now, so what else is it?  SW:  But the lack of documentation of that experience accrual has resulted in far less net progress than should have been expected.     The GUI team should have made a series of small "proof-of-concept" apps to test out their evolving understandings and techniques rather than trying to shoehorn untested ideas into the big GUI framework.  

-Randy

 (7%) 
 
 

​The Modules architecture is going through an overhaul this weekend. This means that:
1. Serialization* will need to be moved into its own project MG: why?
2. Serialization* will have to be updated to accommodate the new architecture, if necessary MG: any idea what this implies yet? what changes, how drastic, etc?

It's difficult to implement serialization* for objects without knowing what they'll require to be re-instantiated. While the new architecture has been documented (https://docs.google.com/document/d/18qCKeFIyuPeQTFDyfd1pNCq5640m8lpIWn9AQg57TWE/edit)
I've learned the last couple iterations that what the interface exposes and how the object implementing the interface is constructed are not always the same.  SW: EXAMPLES PLEASE!!  

SW:  This whole push for serialization still baffles me.   The only place that needs maybe any sort of serialization is going to the database.  Why is saving the instantiation information anything more than saving the constructor's Signature object and its associated parameter values?  Also, why is your group concerned with this process?   Shouldn't the database group make the decision whether to use serialization or not?   For instance, they could use .NET's Entity Framework to transparently save the entire object structure to the DB and never worry about serialization at all.   (To note: to do this still requires some very careful separation of the model from its parameters so that the proper one-to-many relationships are preserved.)

One of the biggest problems here is that the whole issue of WHY serialization is needed has NEVER BEEN WRITTEN DOWN.   No one can point to a definitive statement that says "this is why we are doing it and the purposes we expect to acheive with it and these are exactly the problems we are having".


-Frank

 (7%) 
 
 

ASP.NET MVC is proving very difficult to learn. Although there is a large amount of information and tutorials available online, we have had some trouble finding examples that do what we need the platform to do for our project. The COMP410 staff has been aware of our issues and is trying to help us along, but there clearly isn't a simple solution to our problem with finding precisely relevant information. As Dr. Wong put it this week, it can be difficult to sift through all the tutorials online and pick out the relevant pieces. MG: can you provide some specific examples of obstacles? I haven't been involved in trying to educate the class on ASP.NET so I don't understand the major challenges. Everyone is saying that ASP.NET is difficult for the GUI team to learn, but I haven't seen one specific sample of what knowledge is lacking in these journals. After weeks of study, there must at least be some understanding of where the knowledge is lacking.

More than that, ASP.NET MVC isn't exactly easy to wrap our heads around in the first place. It is a combination of its learning curve with the lack of specific help that has been our most difficult obstacle.​

 (7%) 
 
 

​Despite getting more concrete from Wednesday, network design/architecture is still not completely hashed out.  We are still unsure as to how the simulation manager works. (Are there multiple instances?  Is there one per worker role?  Is there one super one and then a bunch of smaller ones?)

SW:  I'm not convinced that the design of the simulation manager is complete in the sense that there is no clear distinction between the "management" of simulations (to/from DB, starting/stopping, saving/retrieving results) from the "execution" of a simulation (input/output data connections, inter-composite tick managenment, crash management, etc).   Note that a big difference here is that the former is singly located while the latter is spread across VMs.

 

 

 

 (7%) 
 
 

  • Though this network architecture has helped us to understand the system much better but still there are some of the gaps that need to be completed like still we do not understand the point when Dr Wong said there would be two allocation manager (one would be administrator and the other would be normal) cant we have just one residing on single machine communicating with the controller.    SW: First of all, if you didn't understand something I said, you should have come back to me to get clarification.  I'm not sure what you're talking about here because there some context that is missing from your description here.   I'm going to guess that you are referring to my comment that there are two types of allocation issues going on:  1) allocating VMs to handle scale out and to measure the current "load" on each VM and  2) allocating different composite module instantiations across the currently available VMs (and possibly asking for another VM).  In either case, in addition to a centralized allocation manager, there might need to be pieces of the allocation manager on each VM for localized management issues.   Also there are crash-recovery issues for any centralized service.   The allocation service is cross-session, that is, it must be aware of all the needs from all the current users of the system.   Careful databse usage and access control can probably handle this so multiple session-specific instances could run -- this would imply this service is running on the web role in that case. 

Has anyone thought about what services can/need to run on which roles?     Note that the web role can most easily handle session-specific operations.

 

  • The other doubt as mentioned in the Alex journal that we still do not know the complete functionality of the simulation manger.


-Apoorv agarwal

 (7%) 
 
 

There has been a huge setback with the GUI development as our entire team is struggling with development using the ASP .NEt MVC 4 structure.  I cannot assign concurrent tasks to be worked on to my team members until we ALL understand the MVC material thoroughly.

First, as a team, we created a partial view called Index.cshtml and placed it in a folder called Dummy.  The DummyView only contains a div with some text in it.  Next we added a DummyController that handled the action requests corresponding to the views in the Dummy folder.  The point of this was to try and reference a controller besides the HomeController within the Index.cshtml file of the Home folder.  Thus, we then added an ActionLink in the view of the Index.cshtml file in the Home folder that makes a call through the DummyController to load the Index.cshtml of the Dummy view folder.  This all worked fine.  When the action link was clicked, we were redirected to another page that only displayed the contents of Index.cshtml in the Dummy View folder.

The problems came up in the next few steps.  Our next goal was to add a button and a label.  When the button was clicked, the label's contents would be filled with the Dummy's partial view.  To do this, a JS function was called when the button was clicked.  The razor call denoted by the @ symbol in the JS function was being rendered despite being placed in a JS function.  This then placed the entire web page's contents into the label, breaking our page.

Another test we tried was a similar approach, where double-clicking a FactView in the palette made a JS function call that would then make a razor call denoted by an @ symbol.  The problem with this, besides also be rendered before the function is called, is that we could not figure out a way to pass the parameter sent to the JS function to the HTML.Action call.  MG: Thank you for the details! This is the first journal I've read that actually discussed the GUI challenges being faced. I now have a better understanding of the obstacles you are facing.

SW:  This is exactly the sort of documentation that should be in your development wiki.   In fact, some of these issues should be in the main Resources wiki because it is likely that these problems will arise again, if not for you, then for others.   Documentation does NOT equal "answers".   It is just as important to document the problems and questions.   Once you figure out the problem, come back and fill in the answer.   For instance, you should document in the main Using HTML 5 wiki that you did this seemingly reasonable attempt but it failed in an unexpected way. This warns everyone taht this danger exists and that one should not be surprised if it happens to them.    Simply write down that you haven't yet figured out what the correct solution is.    The info you give will jump start whomever is lookng for the solution towards the answer. 

-Archie​

 (7%) 
 
 

​Any advancements feel like shots in the dark, as our experience with ASP.NET MVC has been limited to largely unrelated tutorials.  SW:  This is because you haven't created any sort of unifying documentation to help clarify what you do and do not understand.   The answer(s) don't lie in a single tutorial, but each tutorial and article contributes a piece to the puzzle--but do you remember what pieces you've gotten so far?      Would you attempt to make a picture puzzle by taking each piece, one at a time from the box of mixed-up pieces, try to memorize the piece and then put it back in the box because you plan on taking them all out later and instantly assembling the puzzle because you now "know" all the pieces?    Here, you must do the same sort of organizational process to solve a picture puzzle -- sorting by what you initially recognize and then increasing the detail of that sorting and organization as you learn more about what each piece represents.

It becomes difficult to document anything, because what progress has been made when we break the project to the extent that we have to shelve all pending changes?  I feel like this will get "vague"-marked, so I will cite a specific example of one of the bugs we ran into that caused us to have to revert.  (Thank you!)

To verify that we could establish communication from View to Controller (we aren't even dealing with any model stuff yet; just passing parameters), we created a JS function, whereupon clicking a factory on the palette would trigger an @HTML.action which would send the param ViewBag to the Controller.  

The value returned by this HTML action would be assigned to a JS var, "mod", which we would then use to create a module named after whatever "mod" was.  

During one trial of debugging, we found that the value for ViewBag (I assume you mean the value of the variable IN the ViewBag) was always 14, for reasons I don't know.    SW:  Did the controller set the variable in the ViewBag?   The first thing I did when I read this problem was to look up and document some info on ViewBag to make sure I understood it (http://www.bandgap.cs.rice.edu/classes/comp410/resources/Using%20HTML%205/Action%20Results.aspx).   

During another trial, we found that the factories on the palette would change themselves when we tried to communicate with the controller (their display name would change to whatever value "mod" was, but we didn't change anything related to the factories).  Having no idea what was causing these results, we reverted.  MG: sounds like some weird stuff going on. Are you using any kind of debugging tools/prints to see the exact moment when these unexpected actions are occuring?

-Nathan

 (7%) 
 
 

We had trouble executing a razor command inside a javascript function. Even before the function is called the razor command is executed.  SW: But from the debugger, there was no evidence that the razor command was executed, i.e. no call back to the controller.   There's something else going on here.    We also could create function calls to the controller to return a value ,like a string. But we weren’t able to pass a client side variable as a parameter of a function using razor command to the server.We are trying the basic function like changing the label name with the help of the COMP 410 staff but there isn’t much success.

 

 (7%) 
 
 

​Martha

Integration is going slowly. We're at the 'make our interfaces match' point right now.   SW:  Careful, the interfaces don't need to "match", you just need to be able to implement an adapter between them.   Do NOT make one subsystem reference the interfaces of another subsystem!   Only the controller should have references to all the subsystems.
We had differences between the Controller team's interface and the Model team's interface which should mostly be worked out after the merge by now. MG: what caused these differences? But as we are still making design decisions even now, I fear this will change and our interfaces will fail to match again.

 (7%) 
 
 
My current problems result from a lack of actual APIs that I should implement for the storage subsystem, or an idea of what other people will need. I know that I need to store a module. The staff notes page was very helpful in identifying what that entailed, along with confirming with the Modules team. I have some concept that an energy plan needs to be stored, which is merely a list of variables. I'm not sure how those variables are identified yet though.

SW:  Define what *you* need for the interface, that is, what you expect people to hand to you.    For the parameters, it will essentially be a  Signature object plus associated values.      These are just one-to-many or many-to-many relationships in the DB or simple object storage if you are using the Entity Framework.
 
 
 
-Damien
 (7%) 
 
 

I know I know I know! Where's the documentation of the Modules Revamp™? Good question.

Well I've got initial documentation of all of the important types in this document: https://docs.google.com/document/d/18qCKeFIyuPeQTFDyfd1pNCq5640m8lpIWn9AQg57TWE/edit

But you're right. There should be more than that. The Modules Revamp™ is a SIGNIFICANT change that would be foolish not to document. It's basically the core that is running our simulation. I need to document what it does, how it does it, and how to use it.  SW:  Don't forget to use diagrams to augment your text.    Too much plain text and people's minds just turn to mush because they can't see the relationships between the pieces.

This week, while productive in 410, has been insane for me. I'm working towards a huge deadline for a different project on Monday. I was able to scrape out enough time in my schedule to get the Revamp working, tested, minimally documented, and explained to my teammates, but there will inevitably be more questions that I need more thorough documentation for. I unfortunately can't invest that time until after Monday though.

 (7%) 
 
 

​I didn't run in to it this week, but at some point I'll have to deal with the networking aspect of the simulation manager, which is still a little bit nebulous. Also, my schedule is still insane but should get better after next Wednesday.

SW:  Is it a matter of dealing with networking code or just identifying and setting up the interfaces for the cross-VM method calls?   The former is not in your bailiwick, the latter is.    

-John

 (7%) 
 

Total: 14

3. Milestone Status: Proposed Solutions

 

Make sure top level API's are agreed upon so that modules revamp doesn't block others. Thus, 
its really important that module docs are fleshed out.   SW:  Have these API's actually made it into the committed codebase and propagated to all the various branches?  If not, it won't do any good until then.

-Kevin

 

 (7%) 
 
 

​ 

GUI
I'm a little stumped on how to help the GUI team make progress. We thought about adding more volunteers to help them out, but decided against it as a 'mythical man' issue (more people != more progress). We contemplated calling up the GUI team from last year, but the GUI design this year is fundamentally different as an MVC4 which calls the back end, while last year everything existed on the client side. We just need a breakthrough in understanding concretely what the exact process and method calls are in our system, and then the implementing the rest of the GUI will just be a slight variation of that process. The solution I'm going with now is to have the GUI team work closely with the staff who have a (slightly) better understanding of the MVC4 web-page structure than any of us. However, unless a breakthrough happens relatively soon, further measures may need to be taken, like contacting a professional (perhaps in Microsoft). MG: where would you say their primary lack of knowledge is? I've never worked with "MVC4" but JS itself is relatively easy to grasp, and it sounds like C# is analogous to just about any server-side language (i.e. Ruby, PHP, Python, etc.). Both of these languages should be straightforward in working with, is the disconnect in how they interact?
SW:  The biggest problem I had on Friday during class was simply trying to understand exactly what the GUI team was trying to do and what exactly was the problem they were facing.   Clear, detailed  aticulations of exactly what they need to accomplish and the current problems being faced are critical here.   For instance, I understand that Archie was trying to change the text of a label, but I kept getting the feeling that the real problem was more than that--that, in the end, it had to do with dynamically adding/subtracting views for modules....I think--it wasn't clearly articulated.    Changing the label's text was actually accomplished long time ago, but it wasn't the "right thing" for some poorly articulated reason.   
 
Now, certainly all will agree that the HTML 5, ASP.NET MVC and Razor documentation is an absolute mess.  It's all but impossible to go to a single location and find complete documentation.   For instance, I still haven't found a complete list of the available "HTML Helpers" and what they do.   That said, I spent most of my weekend doing what should have been done in the first place:  RECORDING THE RESULTS OF MY RESEARCH in the "Using HTML 5 and ASP.NET MVC" wiki.    It's not complete yet, but it should save people a lot of time in finding the answers they need for more specific questions as they come up.   I also tried to include tidbits to help clarify the overall "ethos"  of MVC and Razor, something that has been causing problems because of confusion on how operations were supposed to be implemented.    But since so little was written down, it was very difficult to make net forward progress because the confusion could never be definitely cleared. 
 
I cannot stress enough the importance of documenting one's research and all the "how-to's" that you figure out.    Consider this fact:  almost all the Azure technology issues were figured out 2 years ago by the Comp410 F10 class then forgotten because weren't written down, re-discovered by the F11 class but still not recorded and the vicious cycle repeats this year.    But the problem is more than just across years--this anecdote does not account for all the information that was lost and the resultant time and effort lost during each year.
 
Controller
Get a preliminary integration this weekend - Regardless of what progress the GUI team makes this weekend, we NEED a preliminary integration to happen. To do so, I have asked the Controller, Model, & Network teams to work together on doing a simple integration between these subsystems. The idea is that we would like the Model to be able to save a Module's signature (name & lambda) to the Network's database, and then have the Model team load that module's signature from the database and install it into a module. This will accomplish a few goals, a) we will have the integration of this part of the system completed and b) the Controller team will be able to write some code and encounter any unforeseen issues.
-Carrie

 

SW:  If I asked you "what still needs to be done to create a successful integration?" could you list out exactly what still needs to be done?   Can you assertain whether or not what people are working on is germane to this goal?   For instance, is VM management critical at this juncture, is merely the installing the encapsulating infrastructure the key thing since you only need to run on a single web and a single worker role for now?  

 

 

 (7%) 
 
 

​I had suggested that we get some extra members to help the gui team, but they assessed their situation is because of lack of understanding and not that they don't have enough manpower to finish their task. They think that extra people might just end up being a distraction. I still plan on joining at least part of their coding sessions (I know they have one saturday 2-6PM). 

SW:  Perhaps the utility of the extra people might not be in coding but in researching and documenting specific techniques and concepts needed by those who are coding -- that's what I was trying to do all weekend. 

Modules team has made some changes to their interface and data type definitions. I have asked Adrien to make sure that the controller team definitions and Modules team definitions remain the same. This should be much easier for him because he has branch merge permissions.   SW:  Be sure that Archie is in the loop so that the different DEV branches stay in sync.   DON'T LET THE TEAMS DRIFT APART!

We HAVE to push for integration. Until we actually go through the process of doing so, we won't know if the design choices made by the controller team are actually implementable. MG: agreed, integration is generally a non-trivial task.

-Randy

 (7%) 
 
 

​I've decided that, in the updated serialization* system, I'll expose the classes that store the fields gathered from the interface. When a request for deserialization* of a string is made, I'll return the corresponding configuration class and allow whoever called the method to do the work instantiating the class. This is what I should have been doing this entire time, rather than trying to force my subsystem to accomodate all changes made to the concrete implementation/interfaces. Better late than never. MG: sounds like a great way to interface with the other teams without blocking on them. Good job! Just make sure that, if they are going to be using something from your code, it is well documented and provides the necessary interface or is extensible enough to provide the interface in the future.

SW:  It sounds like your are saying that you are effectively imbedding the deserialization target/deserialization-provider in the serialization information, which is what the .NET and most language serializers all do (the target class is in the serialization stream).   Several questions:

  1. Are you re-inventing the wheel here?   .NET provides hooks for custom serialization and deserialization of any C# class.
  2. Why is it that you don't already know what class you are deserializing?  Isn't the classname stored in the DB?  Remember, no serializations are being transmitted anywhere only to/from the DB, maybe.  If you're thinking about complex data structure transmission to the browser, you should be using JSON, not XML because the JSON will a) trivial to create and b) trivial to convert into the target JavaScript.    If this is not true, then you need to clearly articulate why.
  3. How much custom serialization is actually needed here?   What actually needs to be serialized?   The most complex thing I've been able to find so far that might warrant serialization is a dictionary of primitives, which you should use the trivial JSON encoder for.

-Frank
 (7%) 
 
 

This week the GUI team has already tried to solve our ASP.NET MVC problem by tackling the learning process in small, careful steps; we have been trying to do simple actions just as proof of concept before we attempt to implement anything complicated. This has proved to be a non-trivial effort, though. I would like to propose a better solution than "learn more", but it seems like that is our only choice.​ MG: again, learn more about what? what were the "small, careful steps"? How are you choosing these steps as to benefit the project?

 (7%) 
 
 

​Do we care about the simulation manager?  We should just implement what we have, modifying it should be easier than doing everything from the beginning. MG: this seems like a solution that should be solved with the other teams, i.e. dividing up responsibilities to see if there is a need for the simulation manager and whose responsibility it is

SW:  There is a lot to be said here for writing something, however simple just to learn what it is going to take to do it.  A lot will be learned, but at all times, what you are doing must be kept in perspective to keep "test code" from becoming "production code". 

 (7%) 
 
 

  • To remove the ambiguity and rehashing the network architecture design a task has been created Task 205 and has been allocated to Randy as he is the member of the Controller team and had the better understanding of the other subsystems.

     

  • Along with that we also had started working on the WCF communication between roles and storage management so that we can see the role of the allocation manager which might be needed in the scaling up and down of the system (Task 198).


SW:  Links please!

 

-Apoorv agarwal

 (7%) 
 
 

We spent the entire class today with James and Dr. Wong trying to resolve the listed problems.  We did not make much progress.  The FactView and JS parameter issue wasn't even presented to them because we never even resolved the label issue.  James has directed us to some potential Ajax solution listed in our tutorial section, but in reality we did not really make much progress today even with the aide of Dr. Wong and James.  This is extremely nerve-racking and intimidating, as we have a LOT of development to go through that really can't be done until the basic understanding of how to do simple operations using the MVC structure is achieved.

SW:  One thing that would help a lot would be to make a stripped down test project to focus on specific GUI issues.    For instance, is the problem above due to other syntax or sturctural errors in the View code, unrelated to what you're trying to do?    You need to test the above issues in isolation.   This is standard scientific procedure -- minimize and isolate your variables. 

 

Carrie asked me if more people on the GUI team would help, but both James and I agree that it is not a lack of numbers or man power, but simply an inability to understand the interactions we are trying to complete.

We will meet as a team extensively this weekend, minus Victor who is out of town, looking for other solutions and asking the 410 staff for as much help as possible, but I am honestly very very worried right now.

-Archie​

 (7%) 
 
 

​I see two ways out of this hole.  The first is to mess around with our code until we understand enough to move on.  So far we have been trying to implement very small steps to incorporate ASP.NET MVC into our project, but our progress is limited.  

The second is to look through more tutorials, hoping to find a question from a project someone else worked on that is somewhat related to what we're dealing with.  

Neither proposition is particularly insightful, but that's just the point we're at right now.  

SW:  Simply "messing around with your code" and pot-shotting for a solution is not a statistically viable solution.   Neither is simply looking at more tutorials.    The question here, is what exactly are you looking for?   Can you narrow the problem down any?   What do you already know that you don't have to look for anymore?   What exactly is it about the problem that you don't understand?    You need to create a directed search for the answer.

 

-Nathan

 (7%) 
 
 

Maybe we have to change our approach and use something other than razor inside javascript to access the controller. We have to read more about it and ask COMP 410 staff for help. And we will be working this whole weekend to hammer out this issue.

 (7%) 
 
 

​Martha

Typically, I would say let the Controller team handle design decisions. But we're past that stage, and the Model team has put a lot of time and effort into discussing design decisions.   SW:  It should have always been a cooperative process.    The problem has been too much of "dump it all on Randy".

We're coordinating with Randy more often, who comes to visit the Model team every so often. That will have to do.

 (7%) 
 
 
Rather than waiting for the controller team to decide on the structure of data, I should engage in direct communication with other teams, especially since this is now effectively my subsystem (inasmuch as one person can claim a subsystem). Rather, I have a vested interest in it. Talking with other teams will allow to me to completely understand their needs in terms of Azure permanent storage, and I can better structure my code through that.  MG: Taking the initiative! Love it! Just be sure to keep in mind that even though the teams tell you they need something today, they may need something else tomorrow. Always keep the need for generality and flexibility in mind when designing your system.

SW:  Be careful about excessive coupling of your subsystem to the other teams though.   Be very aware of the encapsulation boundaries of your system. 
 
-Damien
 (7%) 
 
 

I've not been very good at documenting my thoughts and ideas throughout the project in general (not just in this case). What I'm going to do from now on is just keep a running document open while I'm working at all times. That will decrease the barrier of “Ugh, but I have to make a document, figure out where to put it, etc.” and I should be able to more fluidly dump my ideas into the document. I'm going to try this moving forward.

SW:  Great idea! 

 (7%) 
 
 

​We started discussing the networking-simulation manager interface at the end of our last class, so I'm confident we'll get it ironed out soon.   SW:  Focus on what hte Sim mgr needs to do, let networking deal with its implementation. 

-John

 (7%) 
 

Total: 14

4. Development Process: What seems to be working and why?

 

Showing a graphical summary of journals make it much easier to go over everyone's journal at one go. MG: why is this helpful? what do you gain from viewing everyone's journals?
SW: Why did you ignore my repeated advice from the beginning of the semester to use the graphical summary?  

-Kevin

 

 (7%) 
 
 

​ 

Documentation has been getting a little better - agendas were up by class on Friday and the minutes have also been posted regularly this week. Overall, the development processes seem to be working well.
-Carrie

 

 (7%) 
 
 

​Teams are using TFS tasking a lot more now. Also the tasks aren't as vague/broad as the ones we started when we first used TFS tasking. 

-Randy

 (7%) 
 
 

​I've started creating tasks for what I need to do as soon as I become aware of what needs doing. This allows me to actually remember everything that needs doing and stay on top of things. Once again, it looks like writing things down is the best way to make sure I don't forget about them.

SW:  Hallelujah! 


-Frank

 (7%) 
 
 

Other teams seem to be getting along just fine. I take this to be a relatively good sign, because our stoppage in the GUI team has not forced any other team to idle. I feel like we have done a better job as a team at splitting up the work so that there are no choke points, like the Controller team experienced during the warmup project.​

 (7%) 
 
 

​Actually documented what I found out about scaling, although it could be a bit more detailed.  Now I can just link teammembers to quickly catch them up.

 

This week, rather than waiting for someone to decide what we're supposed to do, I've asked questions to figure out what needs to be done, and then created tasks.  I understand that this is vague, so here's an example:

On Wednesday, I realized that all we had was a hard TCP connection for inter-role communcation, and there was no task for moving forward beyond this point.  It was puzzling that there was no task yet for moving to our next step (WCF), so I created the task and it's now assigned to me.  Now I can move forward.

SW:  Good pro-active work! 

 

 (7%) 
 
 

  • Making up everyone writing up their name at the end of the journal helps us to follow with everyone journal.


-Apoorv agarwal


 (7%) 
 
 

The TFS tasking system, when utilized, is a great tool.  People can see exactly what everyone is working on and there is an obvious location for documentation of the tasks you are working on.

The best development sign is that none of the other teams' work has been impeded so far by the GUI team's slowed progress.

-Archie​

 (7%) 
 
 

​Thankfully it sounds like other teams are not getting stuck waiting on GUI.  

I think we will make good strides this weekend, but I worry that if we don't get this ASP.NET MVC stuff working for us, we may cause a block on other teams who can't move on without us.  

-Nathan

 (7%) 
 
 

The GUI team coding sessions seem to have help us alot ! We managed to understand the MVC concept better. And the sessions with Dr.Wong and James during class helped us solve some problems.

 (7%) 
 
 

​Martha

The new Model development policy as of today: if it isn't documented, it doesn't exist. If it isn't tested, it doesn't work. I'm excited to hear about the new documentation policy - it should make our lives much, much easier. :-)

I'm not thrilled about the Google Docs documentation location though. MG: have you suggested an alternative?   SW:  Articulate (to everyone) WHY you think the use of Google Docs is sub-optimal.  

 (7%) 
 
 
Now that I have identified an area in which I can make progress (the storage subsystem), I feel like I am better driven to work than before (it sounds terrible, I know. That's because it is). I believe this is supposed to be the effect of tasking; having a concrete goal that is within reach gives people something to work for. MG: EXACTLY! In my case, understanding that the storage subsystem would be a separate piece from everything else because it was needed by multiple systems, and having another team that needs my system to work (modules wants to save and load a simple module) is inspiring me to work better.
 
:-)

 
-Damien
 (7%) 
 
 

I feel like the Modules team is finally feeling more grounded now that we're seeing concrete implementations of the core modules system that works and has a definite API. The ModelManager and the SimulationManager interfaces and implementations seems to be better defined now that we understand how the core modules system works.

As a result of this clarity, I feel like my colleagues have a much more concrete grasp on how to move forward with their respective systems:

John on SimulationManager

Kevin on ModelManager

Frank on Serializing Modules (JUST KIDDING!!! I know you guys hate that phrase. What it really means is storing lambdas and composite definitions)

Also, we're slowly but surely getting better at tasking. I feel really cliché saying that week after week, but it's actually true. My tasks are becoming much more clearly defined and actionable.

Also, I am as well a fan of Kevin's new motto: If it isn't documented, it doesn't exist. If it isn't tested, it doesn't work.

 (7%) 
 
 

​Meetings are going smoothly and we all know more or less what we're doing thanks to solid tasking. The journals are pointing to fewer dev process issues in general.

-John

 (7%) 
 

Total: 14

5. Development Process:  What does not seem to be working and why?

 

Still no integration. We need to start putting these subsystems together. MG: what is holding this up? again, more details.

SW:  I thought that Archie had a well-defined protocol for pushing code to the branches for integration.   Has this ever happened, or are the groups simply splintering apart?
-Kevin

 

 (7%) 
 
 

​ 

The biggest obstacle right now to development is that everyone is not pulling their weight equally. I understand that unless people are given concrete, reasonable tasks, they can't be explicitly responsible for anything. However, at the same time, we're going to run into problems in this class (more and more) that require more than just explicit clear tasking. We need everyone at this point so late in the semester to be taking initiative and ownership over their subsystems.
-Carrie

 

 (7%) 
 
 
It really hurt our development timeline when we weren't able to integrate. James had predicted that we might run into problems with GUI, but they were progressing along and showing us really nice mockups and demonstrations that I thought the GUI team would not be a problem. The discovery of them not using the MVC4 pattern correctly until 2 days before our integration deadline really set us back. 
 
SW:  There's nothing like real code to mess up the best laid development plans.  :-p
 
 
 (7%) 
 
 

The development of the serialization* subsystem is very reactionary/passive. Every time a change is made to the interface that needs to be stored, I have to re-examine the interface in question and make updates as appropriate

SW:  Doesn't this simply scream "Something is VERY wrong here!" ?   Please, please post examples of this issue because it makes no sense at all at the moment.   Your terse, vague description of the problem seems to imply that you are trying to serialize something only knowing its interface, which would say that your serialization code is in the wrong place (it should be part of the concrete class's hierarchy where each level of the hierarchy performs its part of the serialization process).   This would also be consistent with needing the target class during deserialization.   But this is also consistent with the built-in serialization/deserialization process already in .NET: see for instance http://msdn.microsoft.com/en-US/library/ty01x675(v=vs.110).aspx

Another thought:   Is any of the discussion of role/lack-of-importance of serialization trickling down to your tasking?   That is, while no one has voiced any reasons for continuing the serialization effort to me, are you still working on tasks that stemmed from before any changes in attitude were made?   If so, you need to be pro-active to bring up the issue that your tasks may not be germane anymore.


​-Frank

 (7%) 
 
 

Tasking has gotten a little tough in the GUI team, mostly because we are stumped. I suppose  (?? Definitely!!) there should be tasks for learning MVC, but it becomes more and more difficult to assign those as we find that we know less and less about it.​   SW: It's all about breaking the problem down into small, concrete tasks and clearly documenting everything that is learned in the process of solving those problems.

 (7%) 
 
 

​Tasks aren't being doled out as soon as they arise, so certain things that need to be done slip by longer than they should.

 (7%) 
 
 

  • Lack of the understanding of the complete system had affected to create ("the creation of" ??) concrete tasks but in some cases it may happen that we might overlook some task/ feature .


 

-Apoorv agarwal

 (7%) 
 
 

Coupled with the good news of no teams' progress being slowed down is the fact that there has been little integration of code among the teams due to the GUI landfall.

Finally, GUI tasking has taken a huge setback because, frankly, I have no clue what to task to my team when none of us can get past this important MVC issue.  Task 192 is the priority for the entire team.  Until this is completed by the team, there cannot be concurrent development tasks assigned to individuals.

-Archie​

 (7%) 
 
 

​I wish I could say that I saw some huge flaw in our approach to dealing with ASP.NET MVC, so that I could propose some grand solution that would fix everything.  

I suppose that we aren't documenting our problems very well, mostly because we don't have specific tasks in which we could write about said problems.   But that's an artifact of all of us working on the same problem at the moment.  SW:  It says that you haven;t broken the problem down into small enough pieces.    Don't try to solve the problem in one fell swoop, identify and separate the building blocks to your solution.

-Nathan

 (7%) 
 
 

Integration seems to be on hold because we haven’t got the GUI code figured out. Which seems like a big hurdle now.There isnt much taking happening because we are just learning about MVC and implementing small examples.

 (7%) 
 
 

​Martha

I didn't initially realize when the Controller team interfaces failed to match the Model team interfaces, and I think I cost John some wasted effort. I guess I'm not as on top of things as I thought I was.

SW:  You need to be more specific by what you mean by "the interfaces don't match".    Syntax mismatch is normal and should be taken care of at the adapter level.   Functionality mismatch that prevents adapter implementation is another deal, whose solution still does not require syntax matchng. 

 (7%) 
 
 
With an understanding of our subsystems also came a realization of how much we actually had to do. I believe that we spent too much time discussing inconsequential things, or too much time waiting around for something to do rather than finding those things ourselves.

SW:  Good point.
-Damien
 (7%) 
 
 

The biggest process-related challenge I've experienced directly is my not being able to spend as much time with the controller team (Randy) as I should be as a controller liaison to the Modules team. Modules tasks have pretty much dominated my workload. There have been comments that having controller members that are also members of other teams isn't working because it's way too much work for any one person to do. I'm starting to experience that.

 (7%) 
 
 

Late last week, I discovered that I was building a "simulation manager" instead of the "module manager" I thought I was building. They turned out to basically be the same thing with different names, so everything worked out, but it occurred to me a few days later that when in doubt I should be double-checking things with Randy/Martha and the rest of the controller team rather than making something up.   SW:  If they are the same thing with different names, are you duplicating code?  Perhaps there are shared  services?

-John

 (7%) 
 

Total: 14

6. Development Process: Proposals for change
--issues addressed and why the change will help.

 

We should make it a habit of leaving comments on other people's journals. Discuss journal issues within teams. MG: this assumes that everyone looks back at the journals, something typed in a journal is easy to ignore. Is there a better way to make this work that ensures something productive comes out of it?

-Kevin

 

 (7%) 
 
 

​ 

I really don't know what to do to combat this problem. I feel like we have all the development processes in place -  teams are small to enable communication, each team has clear milestone goals on the schedule to accomplish, individuals have clear tasks on TFS tasking, etc. Yet, I still see a few people sitting around in class playing on their laptops rather than asking about what they could be doing. I don't feel like having either myself or team leads monitor everyone during class is an option, but doing nothing will just let the problem persist.  Ideas? MG: Grades? I think it's pretty clear to the staff (even me, who isn't in class often) who is accomplishing work and who is marginally contributing, and they should know that they're grades will reflect that. They should care enough that you shouldn't have to revert to this, but sometimes you have to find anything that will be a motivator. Or point out that if they don't enjoy this or want to learn to be better at team development, they should really consider a different career because otherwise they're going to be quite miserable for the rest of their lives.
 
SW:  Remember that the creation of additional "motivating measures" is an option.   All I ask for is a democratically-reached consensus on such measures before I implement them.
 
-Carrie

 

 (7%) 
 
 

​I know this is not an adequate "solution", but I really dont know how we could have detected this sooner except to have made intermediate deadlines for the integration. However we can't go back in time and fix that, so this is mostly left as a note for future comp410 classes. 

I guess if we have future deadlines, we need to set mini-milestones to hopefully catch errors where teams are making a lot of progress, but not in the right directionMG: did the GUI team themselves not realize what they were missing? if so, how did they miss it? if not, how did they not report it? This seems like a rather large oversight on someone's part.

 (7%) 
 
 

​The documentation of proposed changes linked above will help me update my system ahead of time, but I think the best solution is for me to be more vocal about the changes made to interfaces in question. I've started pointing out how proposed changes will affect the serialization* subsystem, and that seems to be making the update process smoother. I just need to continue doing so and not become complacent 

 -Frank

 (7%) 
 
 

There should be tasks for "learning MVC" (as the GUI team has had before, actually). They would probably be vague, but it's better than nothing, and will help us to document our learning a bit better.​    SW:  Why should they be vague?   You should have documentation that says things like "can't find list of all HTML Helpers", "what is the difference between MVC and Razor?",  etc. etc.   These all become specific tasks to pursue.    If you just say "learn more about MVC" then you won't get anywhere.    You know a lot already -- get it written down and identify the holes in what you understand and fill them.    Sometimes it means going first after what you know is just a part of your lack of understanding but will help you fill in the holes, for instance, first getting an understanding of models, views and the controller before tackling partial views.  A lot of time, something you run across and document is useful later on when you understand its significance better, but if you hadn't written it down, you would have lost it and had to repeat the work to find it.

 

 

 (7%) 
 
 

Teammembers need to be more active in task creation, so that everyone knows what work needs to be done immediately.

 (7%) 
 
 

  • I would suggest to create some task as the need arrives keep it in the work pool and distill it as we make some progress so that we might not miss any task or feature


-Apoorv agarwal

 (7%) 
 
 

While I feel like we are taking better advantage of the 410 staff for help, we still need to using them as our number one solution solvers.  Expect a lot of emails tomorrow from the GUI team 410 staff.

-Archie​

 (7%) 
 
 

​The most helpful thing I can suggest is that we put some tasks up so that we can at the very least have documentation of our problems for future classes, so that they have some sort of warning.   SW:  It will also bring your current problems into much sharper focus.

-Nathan 

 (7%) 
 
 

We should somehow understand and implement this mvc .This is the biggest task for the team. Tasking i think will be back to normal once we cross this hurdle this weekend.

 (7%) 
 
 

​Martha

I try to take notes of design decisions in the Model team as they happen.

This means that my notes are often much longer then they could be, messy, poorly organized, and incomplete (I don't always catch everything that is said).

While I usually get the gist of what's happening after I write it down, that means my notes are not a very good resource.

I could organize my notes afterward, but it doesn't seem like it would be worth the effort. Would it?

 (7%) 
 
 
Well, most of the solution is coming from my explanation of the problem.   SW:  Exactly.  That's why we push you for clear, detailed articulations in your journals.   Now that we have fully identified the components for which we are responsible, we can work on them. I have begun this process by fleshing out the storage manager subsystem in some small part. It will also help if I push Apoorv to assign specific systems to people for them to specialize in, at least until we get something up and running.

-Damien
 (7%) 
 
 

If there are any members of our team who do not have enough to do (I don't know if this is the case), their help could desperately be used by the controller team. I think the Controller team, in retrospect needs at least 2 full-time members. These are the people who define the high-level interfaces and use cases that interact between all of the systems. Having liaisons to the other teams still makes sense. The Controller team can't operate in a vacuum. But I think the team needs more full-time members.

That being said, now that I'm finishing up the Modules Revamp, I might have more time to dedicate to the Controller team.

I'm going to meet with Randy on Monday to discuss progress and figure out how I can best contribute to the controller team in the coming weeks.

 (7%) 
 
 

​I just need to make sure I'm on the same page as everyone else before I start coding things.   SW:  This is not a proposal for change because it doesn't offer any suggestions on HOW you would ensure that you are on the same page as everyone else.

-John

 (7%) 
 

Total: 14

7. Peer review:  Positive or negative feedback for other class members

 

Good idea on Carrie's part to attach names on journal responses. 

-Kevin

 

 (7%) 
 
 

​ 

Props to the GUI team for slogging through a very complex and tedious system this week. -Carrie

 

 (7%) 
 
 

I'm still not getting any feedback on any diagrams or interfaces that I'm publishing. I NEED you guys to tell me what I am doing wrong, or what I have that is inconsistent with what you were thinking so I can fix it. 

-Randy

 

(SW: emphasis mine) 

 (7%) 
 
 

​I'd like to thank my team for understanding when I missed class on monday due to sickness

-Frank

 (7%) 
 
 

Archie is taking the ASP.NET issues in stride and really giving it all his effort to move forward. Despite multiple confusions and stoppages, he has shown no signs of giving up and is constantly trying to better his understanding and make clear what information is muddled.​

 (7%) 
 
 

​Randy's been putting a lot of work into his global role.  Good job.

 (7%) 
 
 

​Nice work by Alex by being proactive of creating the task when everyone was busying with the other part of the system.


-Apoorv agarwal​

 (7%) 
 
 

To the GUI team...I know it is very frustrating trying to get through this barrier, but I REALLY REALLY need you to be as proactive as possible on trying to resolve this issue.  There seems to be a mentality that the answer and solution will just magically fall into our lap, either through the internet, Randy, or the 410 staff.  We cannot count on this, and it is imperative that we all push our absolute hardest, not just on this task but all future tasks, to resolve errors and bugs.  Passiveness is the death of this class and project.

-Archie​

 (7%) 
 
 

Kudos to Randy and Alex for coming to the OEDK on Thursday night to help us out.  

I can tell that Archie is frustrated with our current setback, but he's not being depressing about it like a few people (who remain nameless, but you can go find them if you want) I read about in previous year's journals.  

-Nathan

 (7%) 
 
 

OMP 410 staff and Randy seemed to help us a lot trying to understand the MVC code. The team is working hard and not giving up but  i guess we have to put in a lot of effort and cross this hurdle soon​

 (7%) 
 
 

​All of the modules team (especially Adrien) has done a heroic job or getting things implemented/migrated/etc.

 (7%) 
 
 
I do not have any feedback for other class members right now.

-Damien
 (7%) 
 
 

Kevin has really come through for me this week as a team leader. I came to him with the crazy idea and half-baked idea to do the Modules Revamp on Wednesday. He gave me the time to fully bake it and pushed me to finalize an API and write a full test suite for it. When I came back with those things, he trusted me with the changes, but also grilled me on the functionality of it to make sure I was confident about the new design.

 (7%) 
 
 

​Adrien's been putting a lot of work into a modules overhaul despite being really busy, and Martha's a great controller team rep.

-John

 (7%) 
 

Total: 14

8. Additional Comments

 

Kevin:  You MUST add more detail to your journal posts!  You have consistently been way too vague all semester and it has to stop.    You will not generate net forward progress for your team if you do not develop the skills to clearly and completely articulate exactly what you are doing and WHY.

 (13%) 
 
 

 

None at the moment.

 

SW:  This is one of the best journals of the semester. 

 (13%) 
 
 

​*There seems to be confusion caused by the wording used by myself and the modules team in general. We've been using "serialization" as short-hand for "storing whatever parameters are needed in order to re-instantiate an object appropriately at a later date". I pointed this out in a previous journal weeks ago, but I was not explicit enough. However, the comments from last journal were helpful in re-affirming that the process I had taken to serialize/deserialize an object were the correct steps (or at least in the right direction, there are problems with the way I was handling recreating the classes, as pointed out earlier)

SW:  The term "serialization" in computer science means something very specific: converting a multi-dimensional data structure into a one-dimensional byte stream.    Simply storing the values of an object in a database is NOT serialization because the target representation is not a one-dimensional byte stream.    Using the correct term will clear up a significant amount of the current confusion.   

My objections still stand, even with your redefinition of "serialization", however.   I don't see anything in the entire Modules system that can't be stored as a one-to-many relationship in the database, which is trivial to do.   There are arguably some many-to-many relationships needed to enforce data integrity.   For instance, storing Signature objects involves 3 tables:   A Signature table to store the invariant data for individual Signature objects, a SignatureValues table to hold the different input and output names and their SI units and a SIUnits lookup table.   Note that the values are not here--they are in a separate table setup that looks similar but is able to represent the fact that there could be many different parameter configurations for any given Signature structural configuration.    

I get a bad feeling that the proper variant/invariant decomposition has not been done on the data structures and that too much of the system is being treated as variant when in fact, it is actually invariant.    But since nothing is written down, I am just guessing and I can't help anyone except to take pot shots in the dark!

 

-Frank

 (13%) 
 
 

Thanks a lot Dr. Wong and James for your patience and help with all of the GUI issues that have arisen.

-Archie​

 (13%) 
 
 

​SW:  The staff needs more detailed descriptions, including code of things that were trirf and what happened.

 (13%) 
 
 

​I may actually be able to pull my weight here in a couple days! The NSF fellowship essays are coming along and we want them mostly done by the 9th.

Let's see how I'm doing by Wednesday.

 (13%) 
 
 

Customer meeting next Friday! Time to freak out.


Also, I don't know what all the fuss is about using Google Docs for things. Frankly, I can be much more productive in a Google Doc than I can be in a Sharepoint doc. That comes from trying both and disliking the Sharepoint document editing experience. I don't think this is something we need to waste time arguing about, but if Google Docs works for our purpose, is it such a bad thing if we use it?

 

 

SW:  Nice journal. 

 (13%) 
 
 

​Sorry about the late journal - I had a busy Friday.

 

0.5 day late:  -5 pts 

 (13%) 
 

Total: 8

9. Advice for future Comp410 classes

 

Break up monolithic tasks is just as important as breaking up monolithic code. 

-Kevin

 

 (10%) 
 
 

​ 
As the semester progresses, different subsystems start coming together and becoming more clear, but because of this it becomes more critical to assess exactly where you are and what still needs to be completed.
-Carrie

 

 (10%) 
 
 

Be careful about the assumptions you make. 

 (10%) 
 
 
If you are planning on storing objects at any point in your project, plan ahead so that the subsystem can be created independent of the other systems. Or, more abstractly: plan your subsystems ahead of time as much as possible to maximize decoupling
 (10%) 
 
 

Understand what you will need to learn for a project ahead of time. If we had known that ASP.NET MVC would be such an issue, the GUI team could have spent a lot more time comfortably familiarizing ourselves with the platform. Unfortunately, we failed to recognize the issue until it was upon us.​

SW note to future classes:   They were warned way in advance.  Ask yourself, "why did they miss the warning?" and "what can we do to hear the warnings?" 

 (10%) 
 
 

SW:  Alex, surely there's something from above that could have been put here.   Look beyond the specifics of your current situation for what carries on into the future.   That's what this class is really about, after all. 

 (10%) 
 
 

I've said it once but I'll say it again because it is that important.  Be the hammer, not the nail.  Passiveness hurts not just yourself, but the entire class.  You HAVE to actively engage yourself and seek our work and solutions.

-Archie​

 (10%) 
 
 

​I would say something about doing integration from the start here, but I think I said that at the end of the warmup project and we didn't do that in the main project at all.

Integrate from the start of your project?

 (10%) 
 
 

​SW:  Surely there's some great advice lurking above!

 (10%) 
 
 

​SW:  Why blank here? There are so many revelations above to pass on!

 (10%) 
 

Total: 10