Category Archives: cs-wsu

Setting Up OpenMRS Core

This task seemed fairly simple at a glance, detailed instructions, clear screenshots, and a group of classmates doing it together; what could be so difficult? To start off I had cloned the openmrs-core repository from github into my eclipse workspace. After doing so I had imported it as a git project from a local repository. After doing so I needed to convert the project into a maven project. After doing so I was able to run the project as maven clean then maven install with build success! Doing this was just the beginning. Next was to get it to work on command line and be able to run the UI for the EMR that we will soon be creating modules for. After getting into the top level of my openmrs-core directory I ran mvn clean install with another build success. Next I needed to download MySQL in order to have access to storing patient information and to also import the demo data that was given to test the EMR. After installing MySQL and then moving one level down into the webapp folder I ran mvn jetty:run. This connected me to the jetty server where I could see the UI. After going to the EMR setup I had found out that the UI was not  installed with the latest version of OpenMRS. I had to clone another git hub repository with the UI and run mvn clean install from command line to create an .omod file. This was then moved to my appdata directory inside the modules directory of OpenMRS. Finally! The last step was to go back into webapp and connect to the jetty server. I was now able to sign into the EMR and get OpenMRS core working. All that is left is to find out what tickets need to be worked on in the Radiology module.This was very time consuming as the project instructions were out of date or missing some information that would have helped along the way. The OpenMRS project is a great tool to help people around the globe and I hope to contribute meaningful work to this project!

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

The Clean Coder

I enjoyed reading the beginning of The Clean Coder very much. The Foreword in which the way that developers  are treated by management is highlighted rang true with my own personal experience. The Foreword also laid out the main theme of the book and gave a great purpose for continuing reading. The Preface was also very powerful, and displayed how management ignores the technical experts with dire consequences. The Pre-Requisite Introduction gave a good introduction to the author and his background. The most powerful part of the reading in my mind was in Chapter 1 where the author said that QA should find nothing, and that bugs making it to QA should be just as embarrassing as bugs making it to production. The emphasis on extensive testing and automated tests had an impact on how I do my software development. I enjoyed reading the beginning of The Clean Coder and look forward to continuing reading.

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 ch2

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.

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

Clean Coder ch1

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.

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

Clean Coder ch2

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.

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

Clean Coder Chapter 1

Robert C. Martin’s book  Clean Coder: A Code of Conduct for Professional Programmers reviews the basics of being a professional programmer in chapter 1. Some of the important key points are being responsible for all your work, making sure your code is the highest quality you can manage, always test your own code, and being aware of more than just the code. Martin gives a great introduction to being a professional for anyone that is not quite sure what it truly means to be a professional programmer. I personally did not think this was that useful of a chapter though because most people know what being a professional is, it is just the matter of applying yourself to succeed at it. We will see what advice Martin gives in the next few chapters in my next Clean Coder post.

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

Clean Coder ch1

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.

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

Clean Code Chapter 1

After reading chapter one of clean code I have learned that as a programmer the clarity of your code matters and how you go about working in a team matters as well. I would pretty much agree with everything that was said in the book. A lot of the people in the chapter know exactly what they are talking about since they have a lot of experience in the field of computer science. If there is one thing for sure that the work environment is much different at school than it is when you start working in the industry.

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

The Clean Coder

After reading the first chapter of “The Clean Coder” by Robert Martin it has made me aware of many key points in the beginning of building elegant software. The most important ideas that I got from this reading was to make your code readable, versatile, and reusable. I would have to agree with everything that was spoken about during this chapter. Many of the people he had asked about it have been programming for their entire lives. They know what works and does not work, when a large majority can say that code should be “clean” then there is a high probability that it should be done this way. As I am transitioning from the school environment to the industry after this semester one thing that I could do better is making sure that code is reusable, elegant, and efficient. Working with projects in the school environment is a lot different than the industry. The project size is a lot smaller and often times the cleanliness of the code is often forgotten in order to get the assignment done on time and done right, after the point of turning it in we would not have to do anything more with it. This causes a lot of messy code that is only created to get the assignment done. I hope to work on creating cleaner code as I wrap up my time at Worcester State and start my career.

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

Recently, I started reading The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin. From what I am reading, there are many things described that I find very relatable and very helpful to me. I hope to use these tips in my last class as well as going forward with my professional career wherever I end up.

The first section I read is the Foreword. One of the many business practices discussed was the Batman-Robin routine, though the way Matt, the writer of this section, describes it makes it seem like at first, Matt was arguing with his team member, Joe. Then he says it’s also possible that Joe was trying to play a joke on the rest of the technical team. I find this practice very confusing. Why would a co-worker joke about a legal team having an issue that prevents a web application or a web site from launching on schedule? It doesn’t make sense to me.

Next, I move on to the Preface, which describes how in 1986, Space Shuttle Challenger exploded over 8 nmi above the ground due to a failed SRB. Anyone who has lived to see the event would know that the reaction and aftermath was enough to put family members of the deceased devastated. It also describes what would have been done to prevent this issue from happening again. Reading this, I had a sense of remorse not just for reading about the disaster, but also the aftermath: the mother of high school teacher Christa McAuliffe devastated and possibly in tears after hearing her daughter had died in flight. Immediately after reading the chapter, I immediately decided to watch a YouTube video of the disaster to get a better understanding of it. I do not remember my emotions after watching the CNN coverage of the disaster, but it was more remorse for the dead than anything else.

After reading the Acknowledgements, About the Author, and On the Cover, to which I did not find interest in the subjects in any of those sections, I finally start reading Chapter 1: Professionalism. In the chapter, it discusses many different rules of conduct for a professional. The “stuff happens “comment in the “Be Careful What You Ask For” section really gave me a good laugh. Reading about Martin’s irresponsibility in the “Taking Responsibility” section proved an interesting read, making me learn that proper testing of software will prevent complaints. This is especially true in the field of video games: as the game itself is considered software, proper testing of the game is very important to avoid many bugs, graphical glitches included. I have beta tested at least one game and still remember back in November when I tested the RollerCoaster Builder feature in a game called RollerCoaster Tycoon World (yes, I grew up with the series and continue to enjoy its progress).

The day was Sunday, November 1, 2015. It was the last day of the first Beta weekend for the game, and the team at Atari and Nvizzio was letting fans that pre-ordered the game, including myself, to test the Coaster Builder feature in the game. It was advertised to be very different from the previous three games, all of which let us build coasters piece by piece, a tedious process. In this game, the development team programmed a system that allowed for a safety rating on coaster designs. This rating was supposed to assist in improving the coasters’ design moreso than the other three ratings, which included Intensity, a rating I was more focused on when playing the game. However, there was a bug that showed its face frequently when I built certain coasters: the tighter a curve on the coaster was, the more likely the coaster was supposed to crash. On that day, on almost every coaster I built, I felt like I was doing something wrong; each coaster kept crashing at random curves, be it turns, slopes, etc., where normally I thought the coasters wouldn’t crash. I knew I wasn’t the only tester that noticed this, because the day after, I saw reports to the developers that other players were experiencing similar issues. To my knowledge, the bugs are being repaired to this day. I hope that all known bugs are caught and fixed before the game’s official release, which is supposed to be sometime this Spring.

Continuing on with the chapter.

My previous discussion about the coaster builder in World goes well with the “QA Should Find Nothing” section. The bugs I caught while playing the game is an example of a violation of the “Do No Harm” rule described earlier in the chapter. Once the developers were aware of the issues, they immediately pushed back their promised release date for the game and apologized for the mess they sent to supporters.

Finishing the chapter, I felt confident with the knowledge I was given. The moment I read the first section of the chapter, I thought to myself, “Now I know I want to take the direction of a professional in my career.” I still have this belief after reading.

I hope to read more of this book and learn more practices as I go.

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