Moving in a new direction

This week we have still not heard back from the OpenMRS admins about our issue. As we are running out of time in the class, the decision has been made to move in a different direction and come up with documentation to add the project into Eclipse, which I understand to be the way that most people use this product. In my opinion Xcode is much better to use, but not a lot of people have Macs, and it is probably more practical to make it into Eclipse. The plan is to come up with this method soon, and then the OpenMRS people can do with it what they will, except and use it, or ignore it like our other contributions. Additionally, I plan to finish up on reading the book on Git for the 5th. 

Advertisements

Junit Testing

Our bug that we chose is related to JUnit testing, so the lab we did was especially useful in understanding the code. As far as our bug went, we looked through the code some more. It would be great if the OpenMRS community answered our questions asking for clarification: I do not really want to have all of our changes rolled back again like with out last bug that we needed to abandon. 

Trouble with issue

This week we started working on a new issue: refactoring the wiki pages to indicate a change in the name of a feature from general properties to settings. I was concerned about changing everything without asking, so I asked on the bug report to clarify, and after receiving validation that my intention for replacement was correct, began to carry out the plan. However, after making changes on some of the pages, I got a barrage of emails questioning me, to which I responded to, explaining why I did what I did, and asking for more validation. I received an email back vaguely replying that my path way correct, and that the community might not have been aware about the bug we were working on. I though everything was good. However, last night I got another garage of emails stating that all the changes that I made from my account were reverted back, and by the same person who told me I was on the right path. I think that I wasted my time, and will be more careful about working on things in the future. I would think that the questions I asked would have been sufficient, maybe in the future they should take a look at the bug reports instead of being surprised and upset when someone works on them. 

First Bug Attempt

This week got off to a bumpy start when someone else claimed the bug that my group had decided to work on the week before. However, we got together in class and decided that it would be good to work on another documentation bug, specifically one about editing the wiki to reflect a naming change. However, we had a question about what the desired edit’s should look like, so I posted a question to the bug. After a couple of days I finally got an answer back, so now we are able to start working on and hopefully finish that bug in the next week. 

Week Four

For something that should be fairly easy and straightforward, getting the OpenMRS started was much more involved that it should have been. For one thing, the installer did not work at all, so I did the manual installation instead. Getting the maven and mysql aspects up and running were easy using Homebrew, and we had already cloned the git repository so that was easy. I needed to download the java 7 SDK, and then compiled everything. However, when i compiled and started the web app, I was missing the /var/lib/OpenMRS/openmrs-runtime.properties file, and as of now have not been able to figure out where it is and why it is missing from the git repository.

Week Three – Three Issues

The introductory bugs seemed like a good way of learning and contributing to the project. I think that the ticket creation ticket is good, because it will help learn about using the bug system, and the icon bug seems like it would be an easy fix that would make the application much easier to use for computer illiterate people.

Week Three

I thought that the git activity served as a simple thing to learn how to better use a tool that will come in handy later on. On the other hand, the videos did not seem to be highly useful as they mostly just stated fairly obvious things about git and SCM as a whole. The wiki editing seemed to be fairly easy, but made me think of all the work that must go into maintaining a wiki with lots of information in it. The issue tracker activity was interesting to me because we use bug tracking at work, and a lot of the information was similar. However, this seemed to be much clunkier than Accurev, the program we use.

Week Two

I really enjoyed the IRC chat class. I thought that the silence was excellent, and that the logs were a good way to get everyone on record for what they said. As far as the readings go, I felt that the most interesting one was the “14 Ways to Contribute to Open Source” article. I felt that the author hit on many important, easy, quick ways to contribute. One way that stuck with me was creating a real world example. Personally, I always look at the usage examples when learning a new cli utility. 

Week One

I hope that this class gives me a better idea about how working on a large scale project is, especially working with others who are all remote. I agreed with the beginning of the cathedral and the bazaar, with how it would make sense that large scale programs should be more closely controlled so that they work better together. Linux operating systems seem to be the exception to that rule though. 

Git Activity

I thought that the git activity was interesting. I have been doing tons of work through the command line and liked that it could be done that way. Almost everything seems quicker and easier to do through the cli then a gui now.