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

Post from week 4/11-4/15

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.

Posted in CS@Worcester | Comments Off on Post from week 4/11-4/15

Chapter 2

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.

Posted in CS@Worcester | Comments Off on Chapter 2

Chapter 3

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.

Posted in CS@Worcester | Comments Off on Chapter 3

Chapter 4

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.

Posted in CS@Worcester | Comments Off on Chapter 4