2015-05-07 Developers Forum

Owned by Former user (Deleted)
Last updated: May 07, 2015 by Burke MamlinVersion comment
5 min read

How to Join

 Click here to expand...

 

By Browser

By telephone

  • US telephone number: +1 201.479.2627

 

Agenda

  • Quickly review previous meeting minutes (5 min)
  • Google-MSF Ebola project w/ Nick Fortescue (Google)
  • Review next meeting agenda

Minutes

View at notes.openmrs.org

 

OpenMRS Developers Forum 2015-05-07
Recording:  https://goo.gl/U6GN7N (Audio) https://connect.iu.edu/p1un2z2gnrt/ (Adobe® Flash®)
Attendees
  • Maurya
  • Nick Fortescue
  • Burke Mamlin
  • Michael Downey
  • Dallas Tx
  • shefali
  • Rafal Korytkowski
  • Willa Mhawila
  • Darius Jazayeri
  • Cosmin Ioan
  • Tomasz Mueller
  • Wireless Caller
  • Deluan
  • Daniel Kayiwa
  • Hamish
  • wintech
  • Jonathan Teich (silent)
Agenda & Notes
  • Review last week TODOs
  • TODO: Burke to notify presenters about their dev forum topics
  • TODO: Someone to Set up CI builds for MariaDB, PostgreSQL, and SQLServer, Oracle (We assume these will not be green lights)
  • TODO: Someone to Create tickets to address problems that occur for alternate DBs
  • TODO: Someone to Schedule sprint(s) to address DB tickets
  • TODO: Someone to push for mocks over integration tests
  • TODO: Someone to document how to test within IDE in dev pages in wiki
  • Google-MSF Ebola project w/ Nick Fortescue
  • Originally started by some open source volunteers
  • Google Tech Talk video was more helpful in quickly understanding the background compared to online documentation
  • It would help to have key points from the video on the website
  • OpenMRS Evaluation
  • Pros
  • Open
  • Domain knowledge of originators
  • Established user base in the field -- people actually using it in Africa.
  • Cons/Risks
  • Hibernate
  • magic is dangerous
  • efficiency/performance issues
  • Tomcat
  • performance
  • MySQL
  • can't run on a device (would have preferred to have had a SQLite option)
  • Bad rep
  • For large facilities only (more for hospitals than small clinics/efforts)
  • Bad UI
  • Not production grade
  • Getting Started
  • Painful.  Took several days to get started with OpenMRS
  • Outdated info about lightweight H2 database, only supported by some plugins
  • Standalone good for aquick try, hard to integrate with module development
  • Complexity almost made us ditch OpenMRS
  • Module development experience
  • Once you have things working it's fine, but hard to get there
  • Baded in assumptions (e.g., package name)
  • Maven archetype wizard hides critical details
  • Running doesn't stop if tests fail (runs old version)
  • Only one person could debug locally
  • One day to get developing
  • Resorted to print/log statements for debugging
  • Code
  • Mixed
  • No style guide enforced
  • Lots of large complicated methods
  • Javadoc thin
  • Undocumented assumptions about data
  • Above average for an open source project
  • Assumes single server with web based interface
  • Assumes time consistency
  • REST
  • Not good for transactionality, had to implement our own API on top
  • Made implementing our own API easy
  • Weird regex for package names
  • X/Forms
  • Significant thread safety issues (uses static variables)
  • Doesn't work out of the box with ODK
  • Led to forking
  • Performance
  • Worked amazingly good
  • Database schema
  • Diagram was super helpful
  • Design is excellent
  • Annotation based validation super annoying
  • e.g., hardcoded max age of 120!
  • bad failure mode (lack of transactionality means one validation could fail but transaction still go thru)
  • Too much business logic in low level code
  • "it has gone slightly too far towards too much validation"
  • Can lead to UX linked to data model (e.g., Order Model)
  • Concept db
  • CIEL amazing resource!
  • Need a few more consistency guidelines
  • Latin vs. common name
  • US vs UK spelling
  • Localization not quite orthogonal enough
  • UX tied to searching
  • Ended up using fake locale to work around limitations
  • Distinct local vs parent changes essential
  • Updates were hard and scary
  • updating CIEL was scary/fragile
  • Documentation
  • Some really excellent
  • Some might have once been good, but out of date
  • Most docs very hard to tell what version of code they were talking about (e.g., OrderService re-written around 1.9)
  • Version numbering inconstency doesn't help
  • Top priority features
  • Rock solid CIEL dictionary/local change management module
  • Revisit of UX localization for concepts in Schema
  • Rock solid backup/restore module
  • 30 minute process from 0 to debugging a module on Mac, Windows and Linux
  • Hard: refactor commonality from X/Forms and HTML
  • Questions
  • Can we get the transactional API that was made atop the REST API?
  • Eventually, all code will be open source
  • Note that work was rushed to address the Ebola epidemic
  • Was fork of X/Forms module submitted back (pull request or suggested improvement)?
  • Dates were formatted differently between ODK and XForms module
  • Daniel Kayiwa would be a good contact
  • Can you say more about UX localization for concepts issue?
  • Hard to add local modifications to the CIEL dictionary concepts
  • "You need to make local changes, and you have to find somewhere to put the string."
  • Did you look at the SDK? / Were you using the SDK? (Nick mentioned omrs-run)
  • yes
  • "a bit too magical" difficult to understand the difference between SDK and maven
  • Can you tell us about your experience with the offline/online synchronization of clinical data between the Android Apps and OpenMRS. This is a big challenge for OpenMRS in general use (i.e. separate instances synching to one master server)
  • Decide for every piece data if it's edit in place or additive
  • Observations are pretty easy, since changed can just be queued & aggregated
  • Orders are tougher
  • Fight with UX designers to keep the model clear to users.  For example, UX designers might want to be able to edit temperature, when this isn't actually editing a value, but adding a new value.
  • Do android apps work well vs a web based interface?
  • Big decision early on about tablet app vs web-based. (Web-based would require HTML5 offline storage, which would get tricky.) Went with native because we thought offline sync would be easier. Needed to do RFID reading, which wasn't feasible web-based
  • For UX reasons (wearing triple wet gloves, constantly washing hands) needed to prevent scrolling; you can do this in html, but it's tedious.
  • The RFID use case was the only deal-breaking reason that it had to be native.
  • It sounds like you didn't run using jetty in development. Was this intentional for some reason? (Or maybe this is a downside of the SDK?)
  • Documentation/SDK improvements would help a ton – any dev first encountering OpenMRS should be debugging
  • Couldn't get running from an IDE working
  • Did you write some "better" docs for "how to get your dev environment set up" that are worth sharing more broadly? (Or are they too project-specific.)
  • Nick will look back at his email
  • How did you interact with the community? Pros & cons?
  • Emailed dev list quite a lot, having devs in different timezones was fantastic!
  • Didn't use IRC much
  • Emailed Andy directly about dictionary issues
  • Emailed Darius directly about Ebola-specific issues
  • Emailed Daniel directly about XForms
  • After action review
  • What did you expect to happen?
  • What actually happened?
  • What can we do better?
  • Next week
  • 14 May: ThoughtWorks-SCI Ebola Module tech deep dive (Darius)
  • 21 May: GSoC Q&A/intro

TODOs

Transcripts

  • Audio recording of the call: Listen online or download (available after the meeting)