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.
There are a few basic types of input/output sources that are usually used.
Buffered File In:
- String file = “file.txt”;
- FileReader fReader = new FileReader(file);
- BufferedReader bReader= new BufferedReader(fReader);
- String s = bReader.readLine();
Buffered File Out:
- String fileOut = “fileOut.txt”);
- FileWriter fWrite = new FileWriter(fileOut);
- BufferedWriter bWrite = new BufferedWriter(fWrite);
- bWrite.write(“Anything”, offset, length);
Standard In (Usually a Keyboard):
- InputStreamReader cin = new InputStreamReader(Sytem.in);
- char c = (char) cin.read();
Standard Out (Console):
- System.out.print(“System.out is already setup”);
- Scanner in = new Scanner(System.in);
- int i = in.nextInt();
The author is very much in favor of Test Driven Development, but while I am not opposed to it, I do not feel that it is always necessary. TDD is excellent for more difficult program projects, especially those with a lot of closely working parts, but when you have a program that is made up of many simple pieces, TDD seems to slow me down. I end up writing tests eventually, but when I do write the tests later on, I have a full view of what my program is doing, making it easier to write needed test cases. Starting by creating tests is a great idea, and I do use it from time to time, but it is just one style, and each style has its strong moments and its weak points. As a final note I will say that I should use this more than I do, and that sometimes I do need to slow down.
This chapter was full of excellent tips and many hard truths. I would love to believe I work better by listening to music, but it is not the case. Recently, I have stopped listening to music while doing work and I get things done much faster. The writer of Clean Coder knows that it is usually distracting as well, and advises others not to multi task as it either leads to distraction or what he calls “entering the zone”. He makes the point that entering the zone is not a good thing because while you may get more done when you are extremely concentrated, you may make bad decisions that will later cause you to go over that code again to make changes. This is a valid point, but for me personally, I seem to always be in either one of two states: concentrated or distracted. If I am focusing on something, every thing else is a blur. If you talk to me in this state, I probably will not hear you. And if I stop and go do something else, it takes a bit for me to concentrate again.
Some of the other points he made was the distractions of worrying, interruptions, and writers block. These are all real life situations that get in the way of our thinking, and we need to find our own ways of combating these inhibitors. Worrying causes us to always be thinking of our situation than what we need to work on right now. Interruptions can cause us to snap at others for breaking our concentration. And writers block is the inevitable situation we find our selves in from time to time that stunts our productivity. His solution was pair programming, and while this is a good thing to keep in mind, we can’t always work with someone else. Sometimes we do not have access to another person for insights.
Lastly, he also goes through the debugging process in detail, explaining why debugging is so important. Debugging is not a waste of time or something that just has to be done, it is a part of programming and is just as costly as the program itself. Debugging is what tells you the quality of your code. Without it, you are basically taking a test without finding out how you did on it. Lastly, he mentions how time allotment and scheduling is important as well, and how bad pacing can cause late submissions. Being late is what we strive not to do, but when it does happen, we need to alert others as soon as we realize our blunder.
For the openMRS radiology module, so far I have installed Vagrant and a virtual machine and am currently in the process of fixing errors that have arisen, as well as dealing with authorization issues. Here are the steps I have done so far:
- Download Vagrant – Vagrant Download Here
- Download the software for your computer version, run the .msi file, and follow the default options unless you want to change something.
- What is it? – A quote from the developers of Vagrant, here is their mission statement so to speak: “If you are a developer, Vagrant will isolate dependencies and their configuration within a single disposable, consistent environment, without sacrificing any of the tools you are used to working with (editors, browsers, debuggers, etc.).”
- Do I need it? Yes, the radiology module is currently setup to utilize Vagrant, and even though it takes a few minutes to install, it will automate the VM setup and meld it with openmrs for you.
- Download Virtual Box – Download Here
- Download the version you need, preferably the most recent Stable version.
- Run through the setup, and choose what settings you feel comfortable with. However, keep in mind that it can only use what memory you let it use, so if you will not be using any other heavy hitting programs simultaneously, give Virtual Box a good chunk of your RAM (preferably 6gb or more) so that it can run efficiently.
- You do not have to create any vm machine instances, just install the program right now. Vagrant will create a vm for you automatically.
- Clone the directory: https://github.com/teleivo/puppet-openmrs-radiologydcm4chee.git
- You will need a git account if you do not have one, but if you are a programmer you should consider using a git account as it not only works as a version control software, but also as a portfolio of sorts.
- Make sure you remember where you cloned this folder. You will need to refer back to this source folder so keep it somewhere easily accessible.
- What is this? – This will help you by running a server which will contain both openMRS and dcm4chee (An open source medical application/utility).
- Let Vagrant do your work! – Just use any console to navigate inside the git folder you just cloned, and type “vagrant up” and hit enter.
- Now you wait, a while. Walk away and get some coffee while vagrant sets up your vm and server fuctions. It takes about 30 minutes on a standard internet connection, and it will bring up a new line in the command prompt when it is finished.
- Taken from the programmer’s page who setup this project here: “This will download a virtualbox VM with Ubuntu 14.04 64bit, install all necessary puppet modules via r10k and run the manifest/site.pp which:”
- Installs mysql server
- Installs dcm4chee and deploys DICOM viewer weasis
- Installs tomcat 7 and deploys OpenMRS version 1.11.4
- Access openMRS – you can now open a localhost window in your internet browser (firefox not confirmed to work yet).
- To do this, just type “localhost:8080/openmrs/” into the url.
- This is an exact word for word step guide on what settings to choose which is also obtained from teleivo’s gitHUb page:
- In the wizard select/enter the following:
- Which type of installation do you want? => Advanced
- Step 1 of 5, Do you currently have an OpenMRS database installed that you would like to connect to? => No
- If no, what would you like to name this database? Database name => openmrs
- A user that has “CREATE DATABASE” privileges must be specified here…
- Username => openmrs
- Password => openmrs
- Step 2 of 5, Do you currently have a database user other than root that has read/write access to the openmrs database? => Yes
- If yes, specify the login user name and password for that database user
- Username => openmrs
- Password => openmrs
- Complete the remaining steps of the wizard
- At this point, you should have a working environment, but I ran into a few issues.
- First, even though I created a user account, I am unable to login when booting up the server instance. I have tried every account I have setup as well as default accounts or leaving the fields empty. I know someone else had this issue, so once I figure out what it is I will edit this post with the solution.
- For a while, when I was running the program, every other program running in the background of my pc was terminated abruptly. I did not lose anything, but I could not have any other windows open. This might be my specific pc, but be careful to save any work you have before running this.
- When running the ‘vagrant up’ command, it failed twice on me before running properly. Could be a connection issue, but try running it a few more times before searching for fixes.
And hopefully that is all you should need. There is a Slack group for people working on this project, so if you need help you can ask there or directly on the openmrs talk page. Feel free to fiddle around with the features as you are on a local host you will not ruin any data.
What I learned:
- That an installation and setup process can be made to be automated
- What dcm4chee is and how it is relevant to this module
- How openmrs functions/runs
- When something says it is needed, it is NEEDED (should be obvious).
How would I proceed differently:
- I would make sure I had all requirements before starting
- I would make sure I had the correct version of Virtual Box
- I would be more attentive to other people’s errors in case I encountered them as well
- This whole process will come in handy when creating programs in the future. This process makes installing things much easier, especially if I had to install this on multiple computers throughout a hospital.
- I will be able to apply some of this knowledge on any local server project I work on.
- teleivo on gitHub
- Vagrant software by HashiCorp
- Virtual Machine
Chapter 3 in this book contrasted the last chapter, because the subject this time was saying Yes. We cant always push things off till later and tell our boss, “I need time”. Sometimes it just needs to get done, or at least made progress on. If you can’t commit to doing the whole thing, make a commitment to doing parts of it. Also on that topic, if you can’t do something, do not say you will try, or that you will see what you can do, just tell it like it is. Say only what you intend to fulfill.
OpenMRS was not too difficult to setup, but there were a few bumps that I encountered. Cloning the code from GitHub was easy enough, but getting it into IntelliJ was a challenge. IntelliJ was not recognizing any packages or other imports, but a friend was able to help me find a way to add the packages to the scope of the program. After that, all code compiled, and all tests passed that were able to be run. However, I ended up moving over to the Eclipse environment as it works better for the purposes of the project. Importing into eclipse was easier, but did not have all the settings needed, so I had to install a few eclipse add ons such as Maven Integration, a better version control interface, and server options in case debugging in eclipse is needed. Next I set up the legacy ui by adding a module to the openmrs project webapp, and after it built and ran, I was able to view the ui in a local instance in a web browser. The sample data that can be viewed is rather odd however. I could find only 2 people in the sample data set and they were at positions 100 and 101. No other index has a person created. Not sure if this was purposeful or an accident, but I can atleast see what the database looks like and how it works.
This chapter was very hard to read because I am not a confrontational person. I would rather become a sleep deprived, caffeine addicted, overworked person for a few weeks than tell my boss no. I may argue here and there with people on the same field as me, but anyone put in authority over me is to be heeded to. I would absolutely be one of the people saying, “I will try”. I am not sure how much I could change in this aspect, being friendly with others is my personality, and I am not sure I would want to risk changing that. In the instances provided in the text, I can see why and how it is useful to say no, but it would take a lot to get me to that point. This chapter was filled with useful points and examples, and probably contains the most important information that I needed to hear.
Overall, the first chapter of the book “The Clean Coder” had a lot of useful insights and lists of useful information, as well as good ideas for self-improvement. There were a few minor things I disagreed with such as always writing tests first, and testing every single line. While parts of these things are useful, actually writing the tests first is not always the best thing, and testing every line is ideal but often unnecessary unless coding in a basic environment. His point about spending time outside of work on practice is a good idea, though hard to follow. I think it is great that he talks about owning your work and the responsibility that comes with it. I do not know if I would pay a company $10,000 for a mistake I made, but the reasoning was not lost on me. Professionalism is definitely something I must work on.