Changes between Version 6 and Version 7 of NDGRoom101Meeting


Ignore:
Timestamp:
28/08/08 16:47:25 (11 years ago)
Author:
mpritcha
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NDGRoom101Meeting

    v6 v7  
    11= NDG "Room 101" Meeting = 
     2 
     3(DRAFT NOTES IN PROGRESS) 
    24 
    35Meeting to remind ourselves of what we have, why, & what we have learned along the way. 
     
    108110 Maybe there was some attempt to be predictive in some parts of the project (bits of project were agile, bits predictive). But there was not enough attention to the relative '''pace''' of the different development streams. 
    109111 
    110  RM-ODP model 
     112=== RM-ODP model === 
     113Reference Model of Open Distributed Processing 
     114 
     115Start off with what needs to be achieved (Enterprise Viewpoint), and develop other viewpoints to develop a specification of the whole system (others are information, computation, engineering, technology, [http://www.rm-odp.net/]) 
     116 
     117(Calum) Comment : Lots of code in the NDG stack seems to be non-OO. 
     118(Phil) RM-ODP gave structure at the start, and hence a structured approach. But it felt like we fell off the end of something. This had benefits (adaptive style) but at the expense of some loss of structure. 
     119 
     120Plus some things were never deployed.  
     121 
     122[''RM-ODP doesn't provide any help beyond the initial design phase'']. '''Is there another [''complementary?''] model that is more applicable further down the development path?''' [''Flag this, and RM-ODP in general, as something to discuss in more detail at some point.''] 
     123 
     124=== Development across institutions === 
     125 
     126EDP / NERC Portals experience : suggests benefits of ensuring that at least 1 person is actually using a particular component, in order to provide feedback on it. 
     127 
     128MOLES : There seemed to be someone in each institution trying to use it. But many people were trying to understand DIFs, let alone MOLES (some "fear" of it), even worse with CSML. Perhaps should have implemented (& made deployable) early on to get people on board [''...by showing what benefits were obtained rather than what overhead it entailed?''] 
     129 
     130== Review of components == 
     131=== COWS === 
     132==== Overview ==== 
     133Low-level toolkit aimed at building data services including visualisation. 
     134 
     135With fairly small amount of "glue" code, can produce services. 
     136 
     137COWS was an example of change of tack. Realised that it was not going to be possible to integrate DataExtractor (Dx) code (for various reasons, Ag's availability, difference of approach etc). 
     138 
     139==== Strengths ==== 
     140 * Standards compliant (built on OGC etc) 
     141 * Can quickly implement any dimension we like 
     142 * Presenting spatial data via JavaScript map interfaces is now very prevalent on the web [''e.g. Google Maps'']. This is a "big win", in that we now have lots of expertise in this. 
     143 * ...whereas Dx was a component all to itself (& the code of 1 person who didn't have enough time) 
     144 
     145==== Weaknesses ==== 
     146 * Never got visualisation tools quite there actually joined up to data. 
     147 * Not completely integrated with CSML 
     148 
     149==== Lessons ==== 
     150 * Code development 
     151   * Got to stop situation where only 1 person writes code [''Another item for further discussion''] 
     152   * Very useful to review '''code''' at the end of a project. 
     153   * People have different levels of skill : code review is good way of demonstrating good code to team members 
     154   * Need to take step back occasionally and ask questions 
     155   * Unit testing : very useful but not often done 
     156     * Requires certain mind set at start and end of project 
     157     * Time constraints can be an obstacle to proper testing. Unit tests are fairly easy to do; system tests more tricky and require more discipline. 
     158     * Misdirected thinking to say that unit tests "take up" time (often happens early on when developers want to "get in the thick of things" straight away & see/demonstrate some result). 
    111159 
    112160 
    113161 
    114162 
    115  
    116