Category Archives: cs-wsu

OpenMRS Radiology Progress

I finally got the OpenMRS Radiology Module working with vagrant. On my first attempt with vagrant up, it seemed that I must have gotten some errors that prevented the OpenMRS module from correctly building, because although I could access tomcat, the OpenMRS module was not and could not be started. However, I simply deleted the directory, cloned again from git, and ran vagrant up again. I then ran vagrant ssh and changed the mysql password by entering mysql, then running

SET PASSWORD FOR ‘root’@’localhost’ = PASSWORD(‘MyPassword’);

Upon doing this, OpenMRS then worked. I am now working on getting dcm4chee working, as the default user/password of admin/admin specified in the readme does not appear to be working.

From the blog cs-wsu – Spencer Leal by spencerleal and used with permission of the author. All other rights reserved by the author.

Radiology Module Setup

Setting up the radiology module for OpenMRS seemed very easy at first. Cloning one repo from github and installing vagrant that does the hard work for us? Should be easy! Nothing is ever as easy as it seems. After running the vagrant up command to setup the vm and download all needed software to run openmrs I thought I was all set to start working on the first issue. Wrong! There was an error in which port was being used but after asking the question on the slack channel I found that my local install of MySQL there was an issue with the ports that it used conflicting with the ports for the vm. I did not need MySQL installed locally as my focus went from local install of openmrs to the vm so I did not need it anymore. Thinking that this fixed the issue There was a timeout error not allowing the dcm4chee to not be a recognized command in the vm. So as of now I have got a solution through the slack channel on what to do to try to fix this error. I have learned that vagrant is a very useful tool in setting up vms and can have many good applications such as what we are doing; setting up the a test environment on many machines.

From the blog CS@worcester – Greg Tzikas by Greg Tzikas and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapter 5: TDD

Test Driven Development is something that Martin thinks that all programmers should be using in the design of their code. Since this method is only something mentioned to me and done for a course and not implemented in my way of writing code it is something that I am skeptical of adapting and trying to use. After hearing what it does, how it works, and practicing it in a previous course it looks like the best way to approach coding. The main struggle I have with it is actually going about implementing it in my coding routine. I have learned to write code create an input and see if you get what you want. If that fails put some print statements in the portions of the code you think it is failing and trace back through it and try to fix it. After some mess it finally gets fixed but for the assignment to work and be run correctly. That is the problem when it is code that we are having to only do for an assignment we are not concerned with how it gets done, as long as it gets done. I think working for the last month of the semester with actual code in the Radiology module of OpenMRS will allow us to implement TDD as we need to create test cases for the code we create. This could allow for TDD to be used and possibly make writing of the code a lot easier.

From the blog CS@worcester – Greg Tzikas by Greg Tzikas and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapter 5: TDD

Test Driven Development is something that Martin thinks that all programmers should be using in the design of their code. Since this method is only something mentioned to me and done for a course and not implemented in my way of writing code it is something that I am skeptical of adapting and trying to use. After hearing what it does, how it works, and practicing it in a previous course it looks like the best way to approach coding. The main struggle I have with it is actually going about implementing it in my coding routine. I have learned to write code create an input and see if you get what you want. If that fails put some print statements in the portions of the code you think it is failing and trace back through it and try to fix it. After some mess it finally gets fixed but for the assignment to work and be run correctly. That is the problem when it is code that we are having to only do for an assignment we are not concerned with how it gets done, as long as it gets done. I think working for the last month of the semester with actual code in the Radiology module of OpenMRS will allow us to implement TDD as we need to create test cases for the code we create. This could allow for TDD to be used and possibly make writing of the code a lot easier.

From the blog CS@worcester – Greg Tzikas by Greg Tzikas and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapter 4:Coding

In chapter 4 Martin brought up many great ideas about the environment and attitude you have while coding. Early on in college I would often have music playing and have my phone next to me. I thought that it never distracted me until reading this chapter. I slowly have pulled away from listening to music or having distractions but after reading this chapter I realize that maybe it is not the best idea to have distractions on in the background that put you into a “zone” that allows you to just blow through code and problems. This leads to poor and sloppy work. While it is nice to breeze through something, more likely than not finishing a chunk of code or a problem is not as easy as taking one look and making a change. It takes time to create it and ensure that it is functioning and done in an efficient manner rather than spaghetti code. Often when things are running in the background or you are distracted because of an event that happened or is going to happen the bad code comes into play. This is because your mind isn’t giving full attention to what you are trying to get done. Doing so results in more problems down the road. The books explanation of 3am code and when to walk away reminds me of the casino. When you are there and winning(focused state) you are good you are having a good time and excited. Good code should do the same but once you start losing money and are down(unfocused/distracted) you start to play risky to try to win your money back. This is when you need to learn to step away, go outside and take a walk or just step away from everything and clear your mind. I think this is a huge thing that I myself should learn as I find the best work I do is after a few hours after I wake up. Myself working or thinking too much about something can stress me out and make me frustrated only hunting and thinking about the correct answer. Luckily being in college still with other classmates it is easy to practice and work together with others. Many times something I am just missing that is not obvious to me is obvious to someone else and we can help each other and vice versa. I think that programming with someone else and getting and receiving help is the best way to learn more. There is just so much to know about programming and given where we are in our careers it is very hard to know every little detail so some students know more about certain things and can help. I have heard that this is also true in the industry and I hope to continue having people around to program with to help and be helped by. I think in the end it comes down to practice. The more you practice the better you will become allowing times where you are stuck to recognize similar situations which when you were stuck before. It may not always be the same scenario but knowing similar problems can solve endless hours of stress and problem solving just by practicing.

From the blog CS@worcester – Greg Tzikas by Greg Tzikas and used with permission of the author. All other rights reserved by the author.

OpenMRS-Radiology Module Setup

I am using an old Windows Vista laptop, with very little memory, so I did not expect the Vagrant and Virtual Box to run properly. I tried to set it up regardless but got errors, I tried to fix them but I think it is just not going to work. I will still be able to work on this projects coding, but I will have to rely on someone else or another device in order to test my code on the module. I wish there were system requirements in this modules tutorial, so I could know if my system is the issue or something else I am doing wrong. This taught me how important it is to have good instructions for users in tutorials, and to include every piece of information they will need in order to run it. Moving forward, I might attempt to get it working, but I want to work on the module as well, and actually get work done, so we will see how far I get.

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

Clean Coder Chapters 2 and 3

I have recently read more of The Clean Coder, and what I find interesting is that the two chapters I read talk about polar opposites when it comes to clean coding in the software world. There are other tips in the chapters that I find interesting, and I’d like to share some of these tips and how they relate to my beta testing experience, if applicable.

Chapter 2 was all about Saying No and how to say it properly. However, what i found interesting and important was that not only does one have to defend their No answer, but there’s a way to find the best possible outcome. The example described in the book shows how an issue over a dysfunctional login page turned into the best possible outcome: a mock-up that doesn’t actually check the username-password combination, but one can still log in. This I find is a more appropriate approach to defending a No answer for the reason that the program that was expected wasn’t ready at the time.

Chapter 3, however, talked about how saying Yes produces the right result. One scenario I found interesting is the scenario in a conversation between a manager and her employee who is responsible for modifications to a rating engine. As the scenario progresses, the book talks about how to improve the situation, by not saying “try” and committing to the task. The situation also carries some “what-ifs” in-between. For example, “What if this happened” and “what if that happened”. The conversation between developer and manager gets really interesting as the read continues.

This book is already interesting as it is. I hope to read more of The Clean Coder soon.

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

The Clean Coder – Chapter 4 and 5

I continue to enjoy this book a lot and glean valuable information pertinent to developing myself as a professional and continue to enhance myself and my career. Chapter 4 focuses on Coding and the goals of a programmer. A software developer’s code must first and foremost solve the problem at hand. Code should solve the correct problem, and a professional developer must often determine what the correct problem actually is by interacting with the customer and business analysts. Any new code developed must integrate seamlessly with the existing system, and must be readable by any other developers.

In Chapter 4, Martin also cautions the reader about 3 AM Code and Worry Code and advises them to take a step back instead. Writing software at 3 AM after staying up all night trying to solve a particularly perplexing problem is not going to produce quality code, nor is coding while personal issues are at the forefront of your brain. I often find it hard to pull myself away from a difficult task and basically just sit at my machine making no progress, only to think of am easy and elegant solution on my drive home as Martin mentions later in the chapter. Martin asserts that taking a step back and clearing your mind will often result in seeing the problem in a new way, and a solution will come to you, and I would have to agree.

Martin also voices his opinions on The Zone and listening to music. I do believe that sometimes certain types of music like video game soundtracks help enhance my concentration and also somewhat block out outside distraction. I know distractions happen and are a regular part of work, but it can be incredibly detrimental to progress with distractions often occupying more time than dedicated development. I don’t mind interruptions as being part of a team and working towards a common goal is important, but if it hinders my own tasks and goals then it is actually quite harmful.

I’ve never really had Writer’s Block when it comes to writing code, as I usually can just move on to a different task or go through, but I see how pairing can help alleviate the inability to progress. Martin also mentions the dangers of working overtime and how it is generally only helpful in some cases. I would have to agree that helping others is also important even if it can sometimes be frustrating if you need to focus on a particular task, one should know that they also  require help sometimes, and asking for help when you need it is okay.

When I first began developing software professionally, I had the view of debugging Martin initially described in which it was something that had to be done and was not really a part of coding. But in part due to reading this book and my growing desire to be more professional, I have changed my views and always spend the necessary time debugging. However, I find it difficult to subscribe to Test Driven Development in some cases even though I believe it would be extremely beneficial.

Chapter 5 is entirely about the benefits of Test Driven Development, and Martin’s initial suspicion but eventual embracing of the practice. I’m not sure if I’m jaded or believe that it is very difficult to introduce TDD practices into an existing project with multiple systems involved. With JavaScript talking to a SaaS platform that then speaks to a Java backend, the amount of unit and integration tests is enormous, and verifying correct testing behavior for all aspects of the system is very time consuming, but generally worth it. Regression and automated testing are invaluable when it comes to developer productivity and assurance of correct behavior. TDD enables a developer to freely refactor code while ensuring that existing functionality is not disrupted. TDD also significantly reduces defect rate by verifying that new code is working the way the developer intends.

Overall I am enjoying this book and finding it incredibly useful as a tool to make myself more of a professional.

From the blog cs-wsu – Spencer Leal by spencerleal and used with permission of the author. All other rights reserved by the author.

Clean Coder ch.5: TDD

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.

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

Clean Coder ch.5: TDD

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.

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