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 – spencerleal by spencerleal and used with permission of the author. All other rights reserved by the author.

Posted in cs-wsu, CS@Worcester | Comments Off on My Very First Pull Request

Post from week 4/25-4/27

This week we finished RAD-58 and found out it had already been completed so we started RAD-235. This issue has to do with the modality of the radiology machine. Ivo wants them called a different way. On Wednesday we believed we completed the issue. On Monday we will discuss as a group if we think our issue has been solved. If we agree that it has been we will send a pull request and submit our solution. Hopefully it will be accepted. I am assuming that if it is accepted or while we are waiting for it to be accepted we may start on a new issue if we determine we have enough time.

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

Posted in CS@Worcester | Comments Off on Post from week 4/25-4/27

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.

Posted in cs-wsu, openMRS, radiology, software | Comments Off on Issue Complete?

Post from week 4/18-4/22

This week our group fixed the RAD-58 issue. We still need to follow the steps to get the change approved and committed. This will be done next week once we ask Ivo some questions about JUnit tests. I also made progress with Dana getting the environment set up on his desktop so that he doesn’t have to work on my computer.

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

Posted in CS@Worcester | Comments Off on Post from week 4/18-4/22

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.

Posted in cs-wsu, openMRS, Oracle VM, radiology, software, vagrant | Comments Off on OpenMRS: We’ve got a working build!

Chapter 5

I agree with what the author is saying. I think test driven development is the way to go in modern programming in order to keep pace with production. I agree that before making any sort of production code you should first make a test for it so that when the code is ready it can immediately be tested for bugs. If a bug is found it can immediately be debugged, fixed, and tested again to see if there are any other issues with that part of the program. Test driven development however, does not guarantee that the code would run perfectly when you follow the rules. You program will not run correctly if if you write bad code or bad test cases. It is important to have a good understanding of what is going on and how the program is supposed to operate before writing any sort of code whether it is production or test code.

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

Posted in CS@Worcester | Comments Off on Chapter 5

Chapter 5

Chapter 5 in the book mainly talks about TDD otherwise known as test driven development.  This is when you first have to write the tests for your code before you write the code itself.  By doing this is allows for a more organized way of coding that gets your mind set around the fact that you know what you need to test for.  I personally have not had to do this much in the past because I am not actually a developer but instead am working in a quality assurance environment, which means that I have to write test plans and automation code to test the code that has already been written by the developers.  How ever it would be interesting to look at these tests that the developer have written because it would give me a little bit more insight into how there mind was when they were coding and might give me a better idea of how to write my test plans and maybe even expose some bugs in the code.

From the blog CS@Worcester – dperry2blog by dperry777 and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester | Comments Off on Chapter 5