Author Archives: jd22292

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.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

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.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

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

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

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.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

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.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

“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.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

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.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

OpenMRS Radiology Progress

For those that haven’t been keeping up with the blog, I joined the OpenMRS team as part of a class project. Over time, I have encountered some issues with the software.

3 weeks ago, Ivo, a member of the OpenMRS Radiology team from Austria, showed us how to run the OpenMRS software properly. I found the Skype tutorial somewhat interesting, and I figured I’d use his information to help me with the ticket we were given recently.

2 weeks ago, I started catching up to the rest of my team by installing the software necessary to install the OpenMRS Radiology code as well as the puppet software. Although I had no problems installing, part of the conflict for that Monday was mainly the wireless network and its slow download speed at the time.

Last week, I tried to run the puppet software through Vagrant and VirtualBox, the 2 programs I needed to run the software. Unfortunately, after about 2 minutes of getting the virtual machine running, the Vagrant software times out trying to boot. A discussion with a classmate and Dr. Wurst later, we thought my issue had to deal with the internet connection. I was running my PC on the school’s wireless connection at the time.

As soon as I got home that Friday, I tried running Vagrant again, only to have the software time me out again trying to boot the virtual machine. This time, I was running the software from my home’s wireless connection. I hope next week, if problems persist, I can try running the software on a wired connection. I’ll keep up to date next week.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 4 and 5

The Clean Coder Chapters 4 and 5 are all about coding and TDD (Test Driven Development), respectively. Reading these chapters gave me some insight on how to properly write clean code, and there were several parts of each chapter that intrigued me.

Chapter 4 discusses proper Coding techniques, and adds onto what I learned last year reading Clean Code by the same author. Although the chapter allowed me to evaluate my coding technique, I also found the 3 AM coding story quite hilarious. It doesn’t relate to any stories I would have, but at least it helps me understand better about the importance of a healthy, awake, and alert mind.

Chapter 5 introduces some tips for TDD. TDD has been around for ten years and is still a common practice to this day. The only thing I found interesting, though, was that TDD isn’t exactly useful in every situation. One can still write horrible code even if the tests are written first, especially if the tests are bad themselves.

These reads keep getting interesting as I continue, and I hope the next few chapters make some sense for when I step out into the real world. I hope I can also use these techniques while working on the OpenMRS code.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 2 and 3

I have recently read more of The Clean Coder, and what I find interesting is that the two chapters I read talk about polar opposites when it comes to clean coding in the software world. There are other tips in the chapters that I find interesting, and I’d like to share some of these tips and how they relate to my beta testing experience, if applicable.

Chapter 2 was all about Saying No and how to say it properly. However, what i found interesting and important was that not only does one have to defend their No answer, but there’s a way to find the best possible outcome. The example described in the book shows how an issue over a dysfunctional login page turned into the best possible outcome: a mock-up that doesn’t actually check the username-password combination, but one can still log in. This I find is a more appropriate approach to defending a No answer for the reason that the program that was expected wasn’t ready at the time.

Chapter 3, however, talked about how saying Yes produces the right result. One scenario I found interesting is the scenario in a conversation between a manager and her employee who is responsible for modifications to a rating engine. As the scenario progresses, the book talks about how to improve the situation, by not saying “try” and committing to the task. The situation also carries some “what-ifs” in-between. For example, “What if this happened” and “what if that happened”. The conversation between developer and manager gets really interesting as the read continues.

This book is already interesting as it is. I hope to read more of The Clean Coder soon.

From the blog cs-wsu – jdongamer by jd22292 and used with permission of the author. All other rights reserved by the author.