And it’s over: OpenMRS Final Thoughts

This has been an exciting 15 weeks. Already, I feel ready for the real world.

On Monday, we continued work on OpenMRS RAD-235. At this point, we had not hit any roadblocks with completing the issue. Too my other teammates, I felt it seemed like an easy task. They might say otherwise compared to myself.

On our last day of class, Friday, we discussed how our Capstone class would be improved. After a good discussion, all of us were asked to complete the survey. However, once we were done, several members of our team pushed our changes in regards to the error, and as of the time I am writing this blog, we are still waiting on a pull request.

My experience with OpenMRS has been a huge help to my experience in the field of Software Development. Understanding how an open source medical program running on Linux would work intrigued me, despite the many roadblocks we hit in the process. I feel that understanding each computer’s architecture would be beneficial in determining whether the system would be capable of running a virtual machine successfully without issue, particularly one that runs on Vagrant.

Thank you to all the Computer Science professors at Worcester State for providing me the opportunity to keep pursuing my education in this field. I hope with the tools I’ve learned, I can maintain my success in the field wherever I end up.

Advertisements

OpenMRS: A New Issue

This week couldn’t have gotten any better. We’re already working on another issue, coded RAD-235.

On Monday, we found out that our original issue, RAD-58, was already completed by Ivo, one of the lead developers of the OpenMRS radiology module, but he forgot to mark the issue as such. As a result, Ivo granted us another error that he knows he never worked on.

We made progress on this issue since Wednesday, and there’s still more to be done with one week left. Although one of our group members couldn’t understand how the enum class in Java worked. We’ll see if he can figure it out by next week.

PAX East 2016: VR in a Software Development Environment

This year, I went to PAX East in Boston. At least one exhibit I saw on the show floor contained at least one VR (virtual reality) device to try. During the event, I had the chance to try the Oculus Rift and the HTC Vive.

On Friday, the first VR project I got to see was an Oculus Rift story told by a WPI graduate. “The Piper” tells the ancient story of the Pied Piper of Hamelin in a first-person perspective. Although the sequence through the Oculus Rift headset was accurate, I found some bugs. For example, several of the virtual children kept passing through me as if I wasn’t there. This was something I could expect from an early use of VR.

I never got the chance to try any VR related projects on Saturday, as I was focused on other independent video games. Although on Sunday, another opportunity to try VR arose with another project from an independent Chicago-based developer. Titled “We Are Chicago”, the game tells the true story of a family the southside of Chicago, historically a part of the city where most gang violence has happened. In the demo, the family, the subject of the game, goes through their normal evening routine when gunshots are heard. It is then the player’s choice to take the story in their own direction. The booth displayed an HTC Vive setup, allowing the player to control the character using the headset and the two handheld motion controllers. During a brief interview with Lead Designer Cindy Miller, she told me that the game was not meant for VR and “because you’re in a Virtual Reality setting, you are expected to have unexpected things happen, like going through a table or a counter.” This had happened to me many times in my experience with the demo, though they didn’t give me any problems as I was able to fix my position easily with a combination of moving myself and the use of the motion controllers.

After the event, I looked back at a panel that was in progress while I tried We Are Chicago. The panel, “The Cutting Edge of PC Gaming with Newegg,” centered around the future of VR as well as the relationship between hardware and competitive gamers, a concept collectively known as eSports. The entire panel focused on a hardware developer’s perspective on how VR is affecting the consumer base. Several key points were made about VR, including its impact and whether it was here to stay. When asked about impact, and using education as an example, Robert Hallock, Head of Global Technical Marketing at AMD, stated that VR “redefines the way [anyone] can sense and understand learning,” supporting his case with examples such as the ride of Paul Revere and a child’s perspective of a blue whale swimming over their head.

In my perspective, I think VR has a place in the software development environment for many reasons. One of them is the many opportunities it brings, such as the point about education that Hallock described in the panel. In the same panel, when asked whether VR was here to stay, Hallock stated “versus 3DTV…everyone [he] talked to has tried or wants to try VR.” Chris Pate, Senior Product Manager at Logitech, described the evolution of VR before Hallock, stating, “as [VR] becomes more immersive [and] more compelling…that’s where it drives the interest…of the technology and…the accessibility and affordability of it is a large part of it.” These statements have helped me push my stance towards the inclusion of VR in the software development field, and, taking in a quote from Chris Geiser, Head of US SSD Sales at Samsung, I “certainly think that [VR] is a technology that is here to stay.”

You may watch a recording of the hour-long panel on VR here:
https://www.twitch.tv/pax3/v/62558539

Issue Complete?

This week was very eventful. As far as what we did, I could say we felt accomplished for actually completing an issue in the OpenMRS Radiology module.

On Wednesday, I found out that when we put the working machines on others’ computers, the machines wouldn’t work on PCs other than the original. In what I felt was a good decision, we decided to work off the working machines to help us work on the code.

We didn’t start working on error messages until Friday. All we had to do was change some error messages. The effort was to make it clear for the user that patient records would not be completely saved in OpenMRS, and that the first step for the user was to check their internet connection.

I’m really looking forward to our next issue. But lately, I heard that a specific lead developer of the radiology module forgot to mark our issue as completed. I wonder how we’ll resolve it.

OpenMRS: We’ve got a working build!

Throughout the week, I’ve been reinstalling Vagrant and the OpenMRS radiology puppet module in an effort to see whether the resulting Virtual machine worked at some point. On Monday, I uninstalled Vagrant and redownloaded the MSI file for the program. On Wednesday, I reinstalled both Vagrant and the puppet module. Shortly afterward, I tried running vagrant up on the puppet module, and 5 minutes later, the VM boot timed out. I reported this to my teammate, Nick, on Friday. What I received shortly after was what seemed like good news: we managed to get a working build of the puppet module on someone else’s laptop.

I’m hoping come Wednesday, I can receive a copy of the working build for my own laptop. I’ve spent countless weeks uninstalling and installing hoping that I can get a working build of the puppet module.

“Factory Reset your PC”?

Out of many things that could possibly solve my timeout issues with the OpenMRS Radiology virtual machine, one member of my team has been telling me for the past few weeks to “factory reset [my] computer and start from scratch.” As much as this might help me with the issues, I also did not want to give up other important files on my computer that I would need outside this class and outside my career.

This week was no different. Although on Friday, after what felt like the hundredth time trying to get the dcm4chee VM connected, and still unable to find the Vagrantfile where the config.vm.boot_timeout value was stored, I decided I would follow along with my teammates until I found a solution to my problem that doesn’t involve factory resetting my laptop. My only other solution at this point is to reinstall the files for the virtual machine, reinstall Oracle VirtualBox, and reinstall Vagrant. I’m hoping this solution works by Monday.

Wireless Connections and OpenMRS

This week, I continued work on the OpenMRS software, and continued trying to run OpenMRS from the puppet software. I’ve even tried reinstalling all the Git files for the OpenMRS Radiology system, including the puppet files for the dcm4chee servers. Even my teammates never saw the errors I’ve been getting, especially through the Windows command prompt, which is not UNIX-based.

Turns out running the software on a wireless connection makes the virtual box more likely to time out depending on how long vagrant’s timeout value is (I had it set to the default 300 seconds). I am going to try running the software on a wired connection next week. I’m hoping it all goes well.