Changes between Version 6 and Version 7 of NDGRoom101Meeting

28/08/08 16:47:25 (11 years ago)



  • NDGRoom101Meeting

    v6 v7  
    11= NDG "Room 101" Meeting = 
    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. 
    110  RM-ODP model 
     112=== RM-ODP model === 
     113Reference Model of Open Distributed Processing 
     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, []) 
     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. 
     120Plus some things were never deployed.  
     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.''] 
     124=== Development across institutions === 
     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. 
     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 ['' showing what benefits were obtained rather than what overhead it entailed?''] 
     130== Review of components == 
     131=== COWS === 
     132==== Overview ==== 
     133Low-level toolkit aimed at building data services including visualisation. 
     135With fairly small amount of "glue" code, can produce services. 
     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). 
     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) 
     145==== Weaknesses ==== 
     146 * Never got visualisation tools quite there actually joined up to data. 
     147 * Not completely integrated with CSML 
     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).