Getting started with OpenMRS was the hardest part. This post is a compilation of some technical notes on the major issues I had getting set up.
Here are my general purpose trouble-shooting tips from the early weeks of GSoC…
- Make sure database is working and has a password
- Check that subversion is updated to HEAD
– to see what revision you have, right-click on folder in Eclipse-> Properties -> Subversion
- Give Maven extra memory
- When in doubt, restart Eclipse and/ or computer
- In the event of an, “Error: Unable to connect to the database” I had a few tricks, but I’m not sure any of these would work every time.
– find and delete the .OpenMRS folder
– go to Activity Monitor and quit mysqld
– restart computer, and rebuild OpenMRS
This summer was also the first time I used the command line besides experimenting for no reason.
- (working on list of helpful OpenMRS commands)
Tomorrow is the suggested “Pencils Down” date for writing code, so this week can focus on cleaning up code, documenting everything, and getting tests in order.
I wanted to tackle some interesting issues with my project last week, the much anticipated week 12, but my mentors suggested it might be a little ambitious for the last five days and it would be best not to leave any to-do’s unchecked. I agreed, although it reminded me of the first few weeks of this summer. I was in a hurry to do so many things, but needed to slow down to do them right.
If I had the option leave school and work on projects like this forever, and learn everything I need to know as I go along… I wouldn’t, but it would be tempting. I had to learn more for this project than any CS class I’ve taken in college. It was also more real and meaningful. I can’t imagine graduating without having an experience like GSoC with OpenMRS this summer.
I hope this is the moment when the training wheels get taken away and all of a sudden I realize that I know how to ride a bike.
OpenMRS uses hibernate (the noun – the “open-source object-relational mapping tool.”) to help objects communicate with the database.
Using the Module Maven Archetype gives you the option to add a service layer. When I was setting up my module I said yes to adding a service layer just in case, and didn’t think much about it until a few weeks ago. The reason I decided to implement a MergeConceptsService was that I wanted a query from the openmrs database that wasn’t directly available using the ObsService.
The Module Maven Archetype option to add a service layer gives a module four files that make up the service layer: DAO, HibernateDAO, Service, and ServiceImpl. DAO and Service are interfaces implemented by HibernateDAO and ServiceImpl. The HibernateDAO is home to the sessionFactory, which actually connects to the database. The ServiceImpl will instantiate a DAO, and then the module controller is free to instantiate a Service.
The hibernate mapping file is unnecessary unless you are using hql to change a table.
I have yet to mention my thing for double numbers in this space. My grandpa always said they were lucky, or something. I actually didn’t know he said that until after he died. Then double numbers sort of became a family thing. This past week, I worked and accomplished more than any other week this summer. Sitting in my quiet house trying to think about how to sum it all up, I just realized that this successful week was week number 11. Figures. 🙂
I actually started with undoing most of the code I had for converting observations from one concept to another in favor of using a service method instead. I was struggling with unit tests because concepts can have different datatypes and the ObsService rejects saving a “question concept” as an “answer concept.” Good thing I was having trouble – it lead me to a thoughtful conversation about making sure certain aspects of a concept are preserved in a merge, even when an ObsService wouldn’t cause a problem.
This being week number 11 makes next week number 12 out of 12 full weeks of GSoC! How do you express freaking out via blog post? Just kidding. I’m looking forward this last real week. I’m excited and nervous about going back to school and finding out what being involved with OpenMRS will look like when I don’t have two incredible and official mentors…
This is the story of me trying to make goose.creighton.edu:8080/openmrs run faster.
My first idea was to allocate any of the extra memory on the server to my web app. I found a settings file called “setenv.sh” and opened it up to find:
export JAVA_OPTS="-server -XX:+UseParallelGC -Xmx1024m -XX:PermSize= 256m -XX:MaxPermSize=512m -Djava.awt.headless=true"root@goose:/usr/ share/tomcat6/bin#
The 1024m basically means that OpenMRS on goose was allowed to have 1GB, or a small flash drive’s worth of memory. Dr. Wierman suggested changing the 256 to 512 and the 512 to 1024, or to keep increasing those values until I broke it. Confused, I wanted to find out how much memory goose even had. So, I did:
root@goose:~# cat /proc/meminfo MemTotal: 1015836 kB MemFree: 75104 kB Buffers: 18084 kB Cached: 54532 kB SwapCached: 144048 kB Active: 396248 kB Inactive: 494176 kB Active(anon): 373024 kB Inactive(anon): 460656 kB Active(file): 23224 kB Inactive(file): 33520 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 129416 kB HighFree: 1712 kB LowTotal: 886420 kB LowFree: 73392 kB SwapTotal: 1036284 kB SwapFree: 377404 kB Dirty: 32 kB Writeback: 0 kB AnonPages: 674820 kB Mapped: 11600 kB Shmem: 15864 kB Slab: 33732 kB SReclaimable: 21136 kB SUnreclaim: 12596 kB KernelStack: 3000 kB PageTables: 4104 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 1544200 kB Committed_AS: 1973740 kB VmallocTotal: 122880 kB VmallocUsed: 10848 kB VmallocChunk: 108876 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 4096 kB DirectMap4k: 36856 kB DirectMap4M: 872448 kB
Simple enough, right? This is how I learned that out of slightly less than 1GB of “MemTotal” about 0.07 GB was “MemFree.” My OpenMRS was already allowed to have more memory than the server had to offer.
Dr. Wierman said he had a bag of memory laying around somewhere, and he would look for some that would work with goose. That sounded funny to me so I asked, “What does memory look like?” My question must have sounded funny to him too because he repeated it smiling and pulled out that previously mentioned bag of memory. Nothing in the bag matched the “MT-M 8810-WCX” sticker on goose, so Dr. Wierman opened up penguin.creighton.edu and handed me the 1GB memory from that server… “Here, you can put this in goose.” I took it excitedly down the hall. “Don’t forget to unplug it first!”
What about pair programming? Janet and I tried pair programming to start writing unit tests. Before this week I had zero experience, and writing the code together was a quick way to bring me up to speed on the when, where, and why of unit testing. We used some combination of Skype, iChat, and join.me to pair program remotely. I shared my screen and control to observe how Janet set up the class path and used the Eclipse plug-in to generate test cases, and wrote the first few tests, explaining each step as she did. Then I wrote the next few tests.
So what about pair programming? The last time I programmed in a pair was in high school with my friend and the only other girl in my class, Cassidy, on a GridWorld project. Neither of us knew more than you would expect to learn in AP CS, but we had each other to use what we did know to solve problems creatively and check syntax. The whole process then and now did not go perfectly smoothly, which was okay. It reminded me that I’m not the only one who gets stuck. Having a partner in code makes it possible to brainstorm and troubleshoot more effectively, and stay focused.
Now What? Janet and I are going to try pair programming for a couple hours again on Wednesday, this time writing code with Hibernate. *I think* there is also talk around OpenMRS of using pair programming strategies to help, mentor, guide new community members.
 From Wikipedia: Pair programming is an agile software development technique in which two programmers work together at one workstation. One, thedriver, writes code while the other, the observer (or navigator), reviews each line of code as it is typed in. The two programmers switch roles frequently.