This week was a successful week. I got a VM running without the radiology module. I then installed the radiology module and got a new VM working with it. I have started working on issue RAD-58 while also helping my group with their installation process.
From the blog chanson2016 by chanson2016 and used with permission of the author. All other rights reserved by the author.
I agree with the author that you as a worker have to sometimes say no to certain things. You want to be able to finish a task based on a realistic goal. You do not want to say yes to your manager for a task knowing that it will probably not be finished by the right date. Here it is better to say no so that the managers will be able to work around the date. In software development you would rather spend a little extra time to get the software to work correctly rather than rush into releasing a product that barely works.
From the blog ani2017 by anirudhu and used with permission of the author. All other rights reserved by the author.
I agree with the author. A lot of the times at the work place people say they will do the work but do not seem to show commitment to doing it. When you agree to do something for the job you do it because you are getting paid for it. At the end you as the employee of the company have control over what you can and cannot do. When you have a task at had you should always do it even when you do not seem to have the will power to. One way to show this commitment is to tell you manager or whoever by when you will be able to finish the task by. It works for me because it allows you to manage your time better and be able to focus on the task(s) at hand. This works even if you are depending on someone else to finish their tasks because even if you are relying on them so that you will be able to integrate your efforts you can still do your part of the overall task without him/her. Also if you are stuck on the task you are given tell your team that you have a problem. You are not helping anyone out by not telling anyone and by doing this someone will be able to help you with the issue or pick up the issue for you.
From the blog ani2017 by anirudhu and used with permission of the author. All other rights reserved by the author.
The main point of this chapter is to make sure that you are not distracted while you are coding. This can be a variety of things such as being tired, being distracted by the people around you or music, or it could even be personal issues from your home life that could be bothering you. The key is to try and make sure that these factors are limited in your work so that you can code properly and accurately. Some people say that while they listen to music they might enter something called the zone, the thing with the zone is that you may be coding fast but not coding well. This is interesting because I sometimes listen to music at work while coding and personally I think that it helps but this helps but it might just seem like that because I am coding faster and maybe I am not coding better. I am going to have to try this out by seeing if my code is better written while listening to music or while not. Last but not least the chapter talk about partner coding. The power of this is it allows for 2 people to read over and see the code. It allows for less mistakes to be written because if it is not caught by one it will probably be caught by your partner. This is true and I see this in action while at work. For example whenever I run into an issue or an error in my code I have a partner come over and take a look at it. Sometimes just going over the code with them and talking about the code out loud allows me to realize where my mistakes are and where I am going wrong. Overall the chapter was interesting and really good material to think about in my coding life.
From the blog CS@Worcester – dperry2blog by dperry777 and used with permission of the author. All other rights reserved by the author.
It has been a few weeks since I have updated regarding my status on this project, and I apologize for that. It has been a serious challenge trying to get the proper set up in order to work on the OpenMRS Radiology Module. Our group has been plugging along at it every week trying to troubleshoot and determine what piece of the puzzle is missing to get things up and running. My computer in particular is having an issue that when the software is up and running, and all necessary services are running, the page cannot be found. The interesting thing about this issue is that it is inconsistent. For example, sometimes restarting the computer will fix it; sometimes nothing will fix it; and other times it works fine with no problems. I have not been able to get this running consistently enough to be able to use my computer for development to work on the OpenMRS module. The past few sessions I have been attempting to assist other team members in getting a successful version running on their computer.
One of the issues that our group was having is a problem where it cannot locate the Java JDK. This issue was resolved by an unknown solution. A few people were having problems with ports that were not available. The solution to this problem was properly shutting down using vagrant halt rather than using the Virtual Machine controls to shut down the machine.
My current plan is to continue to attempt to get everything running on my computer and hopefully be able to get some coding in! It has been sort of frustrating trying over and over the same methods to attain no results. I truly believe that if I were to do a factory reset to my computer I would be able to get it going, but I am not willing to completely erase all of my data at this point even with a backup.
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.
I liked the author’s analogy about how when he first started typing he was not sure what keys he was pressing and once he got enough practice he was able to figure out what keys he was pressing without looking at it. When he pressed the wrong key he was able to recognize it without having to look at the keyboard. I think that same concept is true when working in the field. Once you get a lot of practice with coding in a language or a particular technology then you will be able to notice when you are making mistakes without even thinking twice about it. I also liked how you should be prepared for every scenario put out there. When a customer you are making software for wants something entirely different than what was initially planned then you should be prepared to make changes without having to stress much. I also liked how the author talked about how it is always a good idea to walk away from a problem when you are stressing too much about it. When you walk away you are able to relax and think much more clearly which at the end will help you produce and solve the problem you had to deal with from the start. I would personally take whatever the author said in this chapter and apply it in the workplace since a lot of it is proven and I have tried it and it works when performing any type of task.
From the blog ani2017 by anirudhu and used with permission of the author. All other rights reserved by the author.
This week I installed the 12 modules. I moved the ports around so that when I did vagrant up it worked again. The next step is to install the radiology module and then I will be able to work on our issue.
From the blog chanson2016 by chanson2016 and used with permission of the author. All other rights reserved by the author.
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.
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.