2015-05-07 Developers Forum
Owned by Former user (Deleted)
How to Join
Click here to expand...
Agenda
- Quickly review previous meeting minutes (5 min)
- Google-MSF Ebola project w/ Nick Fortescue (Google)
- Review next meeting agenda
Minutes
OpenMRS Developers Forum 2015-05-07
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 Get MariaDB support on the roadmap <http://om.rs/roadmap>
- TODO: Someone to enumerate which of our distributed modules (those in the 2.2 refapp <https://openmrs.atlassian.net/wiki/x/rg1IAQ>) are not hibernate and/or liquibase
- 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
- Source and design will be at http://projectbuendia.org/
- 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)