Category Archives: cs-wsu

Finally

Well, my first pull request was a bust. Obviously it would be since I didn’t adequately test it, but I finally got everything resolved and have my test environment set up correctly… Sourceforge seemed to be the common point of failure during my dozen or more vagrant up attempts. The dcm4chee dependencies are hosted on Sourceforge, and it consistently timed out, or errored out when trying to retrieve the zip files during the vagrant up process. I eventually got lucky on one attempt before I was going to try to vagrant scp the files onto the VM and see if I could get it working that way. I’m finally ready to test and will keep everyone updated:)

From the blog cs-wsu – spencerleal by spencerleal 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.

My Very First Pull Request

We worked on the issue RAD-138 and we finally made our first pull request! Initially I had tried cloning from https://github.com/openmrs/openmrs-module-radiology/, and setting up two remotes, one for our team, and one from the base repository. My goal was to be able to pull from the main repository, and have our team push and pull to the cloned version I created. This worked for those purposes, but I had some difficulty squashing commits into a single commit due to me merging the OpenMRS master into our branch between doing work on the code, and work on the related tests.

I realized after struggling with squashing commits that I needed to fork the repository to send a pull request anyways, so I forked the repository and cherry-picked my commits from my previous branch, squashed them, and pushed them to a new branch on the forked repository. I learned a lot about git rebase, git cherry-pick, and how pull requests work in the process. It would likely have been tremendously helpful if I had actually read The OpenMRS Contributing Guide before beginning, as they explain how to set up the repositories, and use git pull –rebase to more easily squash commits, but I think learning more about git hands-on was incredibly beneficial.

I hope our pull request gets accepted and will let the world know ?

From the blog cs-wsu – Spencer Leal by spencerleal 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.

OpenMRS Radiology: Difficulties

My team chose to work on a simple issue with the OpenMRS Radiology module. We had to delete unused lines from a couple of property files, this should have been an easy thing to do, but in order to know if the code was unused, we had to test it in the module itself. No one in our group had a completely working module, so we were unable to quickly finish this issue, and are still trying to get things working.

Our groups problems have made me learn a few things when it comes to outsourcing work to other teams. It is important to make sure the instructions for getting things set up are 100% accurate, and will work with any computer setup. If not, many people will be stuck on just the setup process like we have been in this OpenMRS project. Another important step is to include the system requirements for a project, if there are any. I am running on Windows Vista, which limits the versions of software I can download, and I don’t know if these older versions will be supported in the project.

When a project like OpenMRS expects college students, who have most likely little experience with similar work, to contribute to their project, they need to have directions for setup and submission that are refined to a classroom level. They do have the forum to post any issue we have, but this seems like a roundabout way to solve the problem, if someone keeps facing problem after problem, they will just be waiting for a response on the forum continuously. I hope we are able to get something done with this project before the end of the semester.

 

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

Radiology Module Update

This week I worked on an issue for the Radiology module in which I found dead and unused code that could be deleted to save space and increase efficiency. It might not be a difficult issue, but it helped me learn about the process of working on and testing an issue. There is nothing I would change about my process, fortunately everything went pretty well. I am in the middle of testing my edits, and I expect to receive working results as I searched for each line I was intending on deleting to see if it was used anywhere other than where it was initiated.

Overall, there were only 2 steps, but each step took a while to work on. Step 1 was just to search for each line in the messages.es file in the repository to see if it is needed or does absolutely nothing. If it is not used, just delete it. For safety reasons, I copied each line that was being deleted into another notepad file just in case we deleted a line that was actually needed. Second step is the testing to see if it still works. I am still in this process, but I will make another post that goes through the details of testing in the radiology module.

From the blog shatos by shatos and used with permission of the author. All other rights reserved by the author.

Radiology Module Update

This week I worked on an issue for the Radiology module in which I found dead and unused code that could be deleted to save space and increase efficiency. It might not be a difficult issue, but it helped me learn about the process of working on and testing an issue. There is nothing I would change about my process, fortunately everything went pretty well. I am in the middle of testing my edits, and I expect to receive working results as I searched for each line I was intending on deleting to see if it was used anywhere other than where it was initiated.

Overall, there were only 2 steps, but each step took a while to work on. Step 1 was just to search for each line in the messages.es file in the repository to see if it is needed or does absolutely nothing. If it is not used, just delete it. For safety reasons, I copied each line that was being deleted into another notepad file just in case we deleted a line that was actually needed. Second step is the testing to see if it still works. I am still in this process, but I will make another post that goes through the details of testing in the radiology module.

From the blog shatos by shatos 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.