OpenMRS individual bug fix

So the semester is starting to come to an end and everyone in team handicapped is working on individual bugs to fix in order to contribute to the project as a whole. The OpenMRS project has been changing a lot in the last few weeks. OpenMRS has now moved to a SCRUM like methodology for their main development team. OpenMRS now concentrates on a specific development issue for two weeks at a time. These sprints help the development team conquer individual issues very efficiently. Last sprint's theme was the OpenMRS 2.x UI framework design and development. Here are some stats that were sent out on the dev list:

• 7 people used the 2.x UI framework to create patient dashboard fragments
• Abbas Hachem: patientPrograms
• Darius Jazayeri: personDetails, patientIdentifiers, standardPatientHeader
• Jeremy Keiper: personNames
• Mike Seaton: personAttributes
• Rafal Korytkowski: personAddresses
• Wyclif Luyima: patientProblems
• We did a pretty good job of navigating distributed locations and time zones
• We completed 18 tickets
• the dashboard fragments, and assorted framework improvements I made in response to people's requests
• We didn't get to 3 non-essential tickets
• Each participant made useful suggestions about features the framework needs, improvements to widgets, or to our patient fragment conventions.

It seems to me like these sprints have been very useful for OpenMRS.

There is one problem with the new methodology that I was concerned with. How was team handicapped going to contribute? I promptly asked Ben Wolfe, who is now my go-to-guy for OpenMRS questions, if we had to only work on sprints. Turns out we can work on whatever tickets we want. Sprints are simply the recommended process of contribution.

After my conversation with Ben our group sat down and planned out an individual bug to work on for each of us. Right now I am working on TRUNK-2148. This bug is related to the JUnit tests within OpenMRS. Right now some tests are reporting ERROR to the build log. OpenMRS dev team has requested that they be logged as INFO instead. My job is to find every place the log.error is used within OpenMRS code and change it. No Problem! Just so happens there are 723 matches within eclipse's search. I've got some time to work on the project later this week so i hope to finish parsing the project this week. This fix might take some time because direct communication with some of the lead devs is needed to find out the functionality of each error that is logged.

My plans for contribution later is to somehow contribute to the creation of OpenMRS 2.x. I think there is lots of opportunity there and I would like to dive into it.

Til' next time...Adios.

POSSCON and more...

POSSCON Results
So POSSCON was a huge success in my eyes. It was great to meet people that were very enthusiastic about open source software. I think the open source community is moving in the right direction and I think more and more software solutions are going to become open source. It was interesting to see the input from some various computer scientist veterans about how open source can be useful. I found John "mad dog" Halls speech very interesting. Hall talked about his take on open source and how much money it can really save businesses. I also like that he emphasized the fact that software is only as valuable as someone makes it. If you NEED software badly and it can help you very much, then chances are that software is extremely valuable. This idea is very interesting because when you think open source you think of "free", at least I do. This is not necessarily true. Open source software can be very valuable and can be a point of profit for someone. Overall I believe POSSCON opened my eyes just a little more to the possibilities of open source and most of all reinforced its goodness.

OpenMRS Plans, Future, Work, Etc.
We haven't had much progress as a group on OpenMRS these past few weeks. Bobby Strickland did a feasibility study on our first scheduled bug and discovered the bug is fixed in later versions of OpenMRS. I presented the idea that we could extract the solution and patch it with the requested version since there is a possibility that someone is running an older version and doesn't want or can't update to the latest stable version of OpenMRS. I believe I will try and revert my code to the requested version and offer a patch to the bug submission. Our other goals this week is to find another bug to work on in order to fulfill our requirement. Overall I have become very comfortable with the OpenMRS project and I feel like we are able to get around with the code very well. Better get to contributin' !

OpenMRS Preferred Patient Fix

Progress on the home front...
Our group has finally solved our bug. As described in my previous blogs, OpenMRS does not require that you have a preferred patient ID. Our patch now fixes that and requires that a user enters a preferred patient ID. Our fix required quite a bit of research on our parts to find how OpenMRS uses the SpringMVC framework for patient form validation. After finding out where OpenMRS had their validators placed we were able to go ahead and create a new validator and its entities in order to require that the user input a preferred patient identifier.


Plans for the future
now that we have fixed our bug we are thinking of creating a code repository, which we really didn't need before, in order to handle the changes within our group. Our next process for our bug fix is to post our patch for code review within the OpenMRS ticket system(JIRA). Right now our group has not decided on a contribution for the rest of the semester but we hope to have one chosen and a road map in place by the end of the week.

Playing Catch Up

Whoa! Almost let this blog die...
I have a few things I'd like to catch up on and discuss.


CS Alumni Symposium
First I'll talk about the computer science department's alumni symposium. Our department put on this symposium for current students and in my eyes it was a huge success. Previous graduates came to offer their advice about graduating and getting jobs. I thought all of this advice was very useful. Seeing these graduates and how successful most of them are is a very big eye opener. It reminded me that I am involved in a career field that is constantly in need of new people. It's good to know that finding a job after school will be easier than most. I also got to talk to Jason Youmans of Bibliolabs who gave some good ideas about internships. I think that the main message that i took away from the symposium was that I need to get extracurricular with my computer science and get involved in something I'm passionate about. Overall I thought it was a successful meeting.

Team Project and Bug Fix
Fixing our bug has pretty much been a flop so far. Most of us have had other school work to deal with the past week or so. It has been slow moving. I did make a minor amount of progress the past few days.

I am starting to try and learn Spring MVC which deals with the form submission in OpenMRS. If I can figure out how the form submission redirects when there is an input error I can just use that same technique when the "preferred patient" is not selected. This should be easy to do within the next week. Hope to have a solution very, very soon.

After we get done working out this bug I hope to work on a bigger issue with OpenMRS and make some major contributions with our group for the semester.

TOSS Chapter 7 Exercises
...........................................

Bug Tracking OpenMRS using JIRA

Issue tracking is probably one of the most important aspects of open source software development. Evolution of open source software depends upon a community resolving problems.

OpenMRS is most certainly an open source project, and also has an issue tracker. OpenMRS uses JIRA to track all of it's issues. Issues include a bug, defect, task, improvement, incident, etc. JIRA does a great job of reporting, filtering, and designating issues. I found it very easy to navigate issue tickets and find some information that exercises in "Teaching Open Source" requested.

The oldest bug in OpenMRS:
TRUNK-330 is the oldest ticketed bug in OpenMRS that is still open. The bug is described as the following:

• audit trails for obs - can only change one attribute at a time.
• double data entry

Since I am just getting involved with the project it is hard to tell what the bug's domain and nature is. I hope to figure this out with time. My guess is that it hasn't been solved because the bug is probably insignificant to future development.

Creating a JIRA Account for OpenMRS
I was able to create a JIRA account for OpenMRS very easily and I am now ready to report or solve tickets within OpenMRS. Since our project will most likely involve fixing a minor bug, this is very important.

Reproducing a Bug
First I went into the JIRA issue tracker and picked the revision/version of OpenMRS that i have checked out:  Version 1.9.0 SNAPSHOT Build 18013.
I then searched for a bug that i felt was relatively easy to reproduce. The bug that I tried was known as TRUNK-222. The description of the bug is, "If a patient's first name is less than 3 letters, we cannot search for him without knowing his family or middle name". I thought that this would be an easy bug to reproduce so i went ahead trying.

First i went ahead and created a patient with a 2 letter name "Di":

I then proceeded to try and search for "Di" and could not produce any results, as expected.

Although this bug ticket was not well formatted, it was still easy to reproduce. Also, after reproducing it i think that this is not actually a bug but a design problem.


Bug Triage
Since I'm very new to the OpenMRS project bug triage would be very difficult at the moment. Instead, I'm just going to go through a few bugs on my own and share my thoughts on what bugs are more important than others, a part of the triage process. All of the bugs I'm going to mention are under the category from the JIRA ticket system on OpenMRS as being a "severity" of "3 or 4" (on a scale from 1-4).

Bugs:

1.  "JUnit tests fail if run independent of maven" - This bug is extremely bad. OpenMRS fails to pass the unit test's that are designed. This means that there could be an unforeseen amount of issues with the particular build (1.9.x)
2. "OpenMRS can not be installed with MS SQL Server" - This bug is also extremely bad considering some machines trying to implement the particular build could be running MS SQL Server.
3. "Change default logging levels of service methods" - This bug is import because it affects the logging of everything that happens in an OpenMRS deployment. Logging could be very important if you wanted to track information in a particular deployment of OpenMRS
4. "support names with more than 2 components when going to create patient page" - This bug is a little less important than the first 3, but still has a profound affect on any particular implementation of OpenMRS. This bug will cause the name of  a patient to display and appear to be incomplete.
5. initialsetup: OpenMRS logo text is not correct - This is a less important bug. This bug is simply a cosmetic item in a build that is very new. I think that this could be avoided until some of the tougher bugs are fixed.

This triage was simply an exercise and I hope to learn more about OpenMRS so that my triage can evolve and become better.


Conclusion:
All of these exercises were very helpful for me. They forced me into exploring deeper in to the project that I am working on. I hope to learn more and be able to contribute to OpenMRS.

Getting, Building, & Running "OpenMRS" Part 2

Okay!

Finally managed to deploy OpenMRS locally after a whole flurry of issues. Thank God for Google!

I first had issues with installing the right packages that were needed to install and run OpenMRS. Tomcat6 is used to deploy OpenMRS on a local server. Unfortunately it's not easy to get Tomcat6 working. The Tomcat6 download in the Ubuntu repositories is not a good install and has missing files, in my experience, that are crucial to running Tomcat6. I had to go directly to the apache Tomcat6 website and get a mirror to download the tar.gz file from their repositories. Some of my best researched advice came from "how to geek".

This was easy since all i did was run:

sudo wget http://www.trieuvan.com/apache/tomcat/tomcat-6/v6.0.32/bin/apache-tomcat-6.0.32.tar.gz

sudo tar xvzf  apache-tomcat-6.0.32.tar.gz

sudo mv apache-tomcat-6.0.32.tar.gz usr/share/tomcat6

After installing Tomcat6 properly I had to change a couple .xml files associated with the software in order to get it running. This was fairly simple.

Next was the feat of trying to get OpenMRS deployed on the tomcat server. This took me multiple tries with different settings. The quick installation is known to fail since it was just commited to the OpenMRS Trunk last week. All I had to do was to try and run the advanced install and I finally have OpenMRS running.

I can now start to explore some of OpenMRS and find out how i can contribute to the bug fixes located in their ticket system, implemented with JIRA. I look forward to blogging about more of my experiences.


Here's a screenshot of OpenMRS finally deployed on my system:

OpenMRS FINALLY Deployed

A word of advice for those reading that are trying to Build-->Install-->Deploy OpenMRS on Ubuntu:
Make sure that you get a good Tomcat6 install with /conf directory and make sure you use sun-java-6-sdk. This is crucial to getting OpenMRS deployed correctly.

Getting, Building, & Running "OpenMRS"

My goal for this week was to checkout the latest version of OpenMRS and try to build and run it. Conveniently OpenMRS had a great guide for developers looking to build and run the source code here.  I found this guide to be very helpful. OpenMRS recommends that you use a couple of integrated pieces of software in eclipse such as m2eclipse and subclipse. subclipse and m2eclipse proved to be very helpful in the building process. Subclipse, which is a subversion client for eclipse, made it very easy to check out the Trunk for OpenMRS. All you have to do is type the repository's link and designate that it is indeed an SVN server. After checking out the code it was also very simple to build the code using m2eclipse, which is a client that maintains dependencies of a "mavenized" project. At first i encountered an issue with version conflicts but that was easily resolved. After resolving these issues i was able to succesfully build the project. Next my goal was to run the built code. This is the hardest part about the project since it has to be built as a web application instead of a piece of software that you use locally. OpenMRS suggests that you use TomCat to mount the OpenMRS web app. This is what i ran into trouble with. TomCat requires that you change permissions to the "users" file. I ran into trouble getting access to the .xml file. I am very close to getting OpenMRS to run and I am very excited to get it running.


I also got a response from one of the core developers and she suggested that we go ahead and resolve some of the ticket issues/bugs. As soon as i get OpenMRS built i will blog my experiences.