Monthly Archives: February 2017

Week 4: Reflections on Learning & Work Products

This past week I have managed to get the openMRS code up and stably running.  I began trying to run this by doing exactly what I did for the tutorial I completed last week.  When I realized that wasn’t work I decided to ask my teammates what they did.  Turns out there was a file called, “Read Me” on the git hub repository.  This file gave in-depth instructions on how exactly to run the code.  This was very helpful and taught me to look for that type of file first when encountering a problem with running unfamiliar code.  I have began to create a new login page at this point in time.  As I started to try to do so I was very confused with how I would do this.  I decided to take a step back and read up on some more Angular 2 stuff, focusing mostly on the structure of how you are supposed to code in this language.  This sprint I plan to successfully create the login page and then go on from there.  I still don’t have too good of an understanding of Angular 2 so I am going to try and understand everything I am doing when making the login page, rather then just doing it so it works but not really understanding what I’m doing.  Last week when I was doing the tour of heroes tutorial I didn’t always pay attention and understand what I was doing.  I was kind of just following the tutorial so it worked, which wasn’t the right way to go about it.  I should have been paying more attention to the things I was typing and not just copying down what it said to.  This week I will take that lesson and focus on learning the language as well as consciously getting the program to work.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 7 & 8

Chapter 7 covers the topic of acceptance testing. This kind of testing is usually a collaborative effort between the stakeholders and the developers to define the definition of a requirement being done. By using acceptance tests, you can help avoid what the author refers to as the “premature precision trap.” Basically either the stakeholder or developer or even both is too specific which causes irrelevant requirements. By properly conducting acceptance tests a project becomes clear, precise, and it promotes communication. As a professional developer there are several key responsibilities in the acceptance test process. First, it’s the developer’s job to remove any ambiguity from what the stakeholder is asking for. Second the developer should always express an error bar when determining time tables with a stakeholder to prevent estimation anxiety.  Lastly, the developer’s role is to connect the acceptance tests to the system to make it pass. Not to create the acceptance tests. The author clearly separates acceptance tests from unit tests. An acceptance test doesn’t care about underlying code but more that a system is behaving like it should from the businesses point of view. Furthermore acceptance tests should run several times a day in a continuous integration system and they should always pass. These tests should also always be automated as manual testing is much too costly. In summary, acceptance tests are mandatory for a professional and increase efficiency between stakeholder and developer.

After reading chapter 7 there’s some important points to remember. However, seeing as I’m not working with stakeholders in a working environment yet there’s not too much from this chapter I can directly apply to my programming right now. I thought one important point was to always estimate with a margin of error. By giving an exact completion date you don’t leave room for setbacks that are bound to happen. Also I will have to remember that it is not the developer’s role to write these acceptance tests. If I come across a test that doesn’t make sense instead of trying to re-write or discard the test, it’s best practice to negotiate with the author for a better test. Moving forward I will keep acceptance tests in mind however it will be some time before I can directly apply the lessons from this chapter.

Chapter 8 covers the topic of testing strategies. The goal of any testing strategy should be that QA finds nothing when they examine a program. In order to come as close to this as possible the developers and QA members need to work closely and follow a hierarchy of tests. By following the Test Automation Pyramid the author lays out, development teams can achieve this goal. The bottom layer consists of unit tests. These test the low level specifications and underlying code. Next are the component tests. These are “happy path” tests written by QA and business with help from the developers. Businesses should be able to interpret and understand these tests. Next are the integration tests. These test the communication of component groups and make sure they communicate properly. Next are the systems tests. These execute against the entire integrated system and make sure the full assembly of components is connected. Lastly the top of the pyramid consists of manual exploratory tests. This involves human testing to seek out odd behavior and ensure normal behavior of the system. This kind of testing is unscripted. By following a hierarchy of tests like this, professional development teams are following best practice of Test Driven Development.

After reading chapter 8 I understand the concept of the testing hierarchy but some specific examples at each level would have been nice. The concepts in this chapter will be better applied when I am on an actual development team. It will be interesting to see if my team uses a similar testing strategy. I think the author places a lot of faith in development teams that they will have the communication and discipline to follow this pyramid forcefully. In a smaller company it may not be so easy to break down these testing levels into such clear guidelines. I do think it’s important to remember the manual exploratory testing. While the computer can tell you everything is working properly you never know for sure until you’ve actually tested and observed the system as a user. In summary, I will keep testing strategies in mind as a professional developer and am eager to see what strategies are truly being implemented in the field.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

The Clean Coder, Chapter 7 & 8 (Week 4)

Chapter 7 of the book is about the importance of communication and how to avoid communication errors between stakeholders and developers. According to the author the only way to effectively eliminate communication errors is to write automated acceptance tests.

Chapter 8 of the clean coder book is about testing strategies. According to the author, the goal of the development team is that the QA team finds no bugs. The development team should react with horror(it should not be something they expect) every time QA finds a bug and must take steps to prevent them in the future.

I think the whole point of this strategy is to force the development team to write clean code rather than write bad code and push them to QA, which will ultimately cost time and money since the development team will have to fix the bugs once QA finds them.

The rest of the chapter is unit tests, component tests, integration tests, system tests, manual tests and exploratory tests. Things we learnt in CS443.

Both of these chapters discuss scenarios which I have not yet faced; so I can’t give any opinions or past experiences.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

The Clean Coder 5 & 6 Week 3

The first part of the reading was about a topic I am well aware of by now. Test Driven Development is discussed and why we should all be using it. I have used TDD many times when coding and the benefits are clear, it may seem like you are doing more work than you should be, but at the end of the day you know your code is clean and almost bug free. It goes on to say that TDD should no longer be argued about using, it should be used without argument. There are no downsides that are large enough to prevent a programmer from using a TDD approach.

The second half of the reading was pretty straight forward, you should always be practicing. It doesn’t matter how long you’ve been programming you can always improve, you can practice to write code faster, learn a new language, write certain algorithms with ease. When it comes to TDD, just knowing exactly where the keys are to write your test can help reduce programming time dramatically. Most if not all practice should be done on your own time, so you become a more valuable employee over time.

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

Week 3: Reflection

This blog will be a little different this week, as a class we have switch to writing a reflection blog at the end of each Scrum sprint instead of every week. Our first sprint ended last Thursday and we held the sprint review. The overall sprint went well and there was good participation. It was a little different as each task on the backlog was to be completed by each member for themselves. We have though found a way using Trello to handle the tasks that must be completed be all members. We start off with the task in the sprint backlog with all members added to it. When the first person starts the task the copy the task to doing, add their name to the new task, and remove their name from the to sprint backlog card. Each additional member updates what cards they are members of as they work. Once the last person has removed their name from a card it is removed. This process is the same for going from doing to done.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Week 3: The Clean Coder, Ch. 5 &

Chapter five of The Clean Coder overs the method of programming know as test driven development or TDD. As the name implies the the process of writing code is driven by test cases. The idea is as you determine what needs to be coded you write a unit test that will verify a specification is meet, once you have the test written you write the bit of program. As soon as you have written the piece of program you can run the test and almost immediately know if the code works. This test driven process could be taken to an extreme where all the test are written before any production code is even started, this obviously doesn’t make sense. To balance the test code and production code the following three rules should be followed.

“1. You are not allowed to write any production code until you have first written
a failing unit test.

2. You are not allowed to write more of a unit test than is sufficient to fail—and
not compiling is failing.

3. You are not allowed to write more production code that is sufficient to pass
the currently failing unit test.”

TDD has several benefits. One of the biggest is the fact that having a test suite that is up to date allows you to ensure that your latest changes have not broken something in another location. This is especially true if you stick to the three rules from above. The TDD process also means you will end up with very high code coverage which is a great way to ensure you program works as expected.

I have tried using the TDD process several times and find it a little hard to get used to although I know it is something that would be worth using. Many times I start a program and want to sit down and just start writing production code. The biggest pain in this is once I have written a fair amount of code and compile and run it there are often errors that I must go back and find then fix. If I were to follow the TDD strategy issues would be caught right away.

The sixth chapter is all about practice. In the beginning of the chapter the author focus on the history of computing and how far technology has come. It used to take a great deal of time to compile and test code, but now computers are both faster and cheaper. Most developers can afford to practice. This is something I really wish I had more time to do. I would especially like to practice with other languages. Today, most of the code I write is in Java as that is the language the school has chosen to teach object orientated programming with. I have, in the past, written programs in Python, C/C++, Lisp, Prolog, as well as a few others. The problem is without practice I forget the syntax. I can write a simple program in Python and C/C++ but would need to use a lot of references for more advanced programs and in the case of Lisp, Prolog, and Ruby I can’t remember where to even start.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Week 3 (1/31 – 2/6) The Clean Coder Ch.5 & 6

YES!!! Chapter 5 and 6 of the Clean Coder book is probably the best chapters of this book so far. You do not understand how frustrated I have been in the past when I try to practice and brush up on my coding skills. I would occasionally Google programming problems to solve to keep my programming skills sharp but it gets annoying sometimes because most of the problems require simple one file solutions and I just feel as though I am getting nothing out of the practice. I have never heard of a “kata” before so when I looked up the links that was provided in Chapter 6, I was amazed! I feel as though I have been looking for something like this forever but never found it. What’s great about katas is that it is more like a walk-through instead of a straight programming problem where it is up to you to figure out the solution. I love the concept of a walk-through much better because in a sense, that’s like having a programming tutor help you solve problems. And this way, there’s a clean cut way of knowing if what you are doing is even correct or not!

I do admit, when it comes to practicing, I am among the vast amount of programmers out there who do not take it as seriously as we should. BUT, now that I know what a kata is and how effective they are, I am totally going to invest more time in practicing!!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapter 5 & 6

Chapter 5:

This chapter talks about how at first you might be skeptical about test driven development, but using it will undoubtedly show you how much better developing through the method of tests first is over writing a lot of code and then some tests for it (that don’t even end up working). It talks about how if anyone still wondering if test driven development is the right way to approach code, they are blind to not see that it is the best way to do so and that its proven that it works. At first you can’t even write any production code before writing your first failing test. You can’t write more of the test code either and can’t write any more production code that is passing the currently failing test. This way of writing code has proven to reduce defects by even up to ten times. This effeminately helps me see that writing tests to fit your code rather than to write code and then tests to run in it is the (maybe not best way to code with the least amount of errors.

Chapter 6:

This chapter talks about how every coder, like every athlete needs to practice his skills and continue to do so to master and perfect them. Only then will he get better and make his coding stronger. It was not common for programmers to be practicing their coding languages as a way to help them up until around 2000. It wasn’t until recent years when we even started using screen editors, so we used to take a long time to compile codes and find errors to debug. We would have to wait for code to be returned to work on it again. Now, with the evidence showing us how much we can catch such problems before they even appear, we need to realize that this is the superior way of coding and should be used by all professionals. It does not matter if you are just new to coding or are even a master coder, practice will make you better and you might even uncover skills you might have never found or tricks you pick up while practicing, no matter what the situation, practice makes perfect. I have realized that doing the same thing over can help you see it in different ways, that is why practicing is important no matter what you are doing.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Week 3 (1/31 – 2/6) Learning Reflection Blog

There wasn’t much activity going on this week since our first sprint was over and now we are just waiting for the second sprint to start. I was not in class during the last sprint review and retrospective due to my absence to a religious holiday but from what I have experienced with my group thus far, everything is going fairly smooth. I can’t really say much about the actual lack of work during this first sprint because we are still getting started with everything but I know that future sprints will be far more work-heavy once we start to dive into our portion of the OpenMRS project. For the actual individuals within our group, I think we have a pretty diverse group of students in the sense that there are a lot of different personalities and programming styles so that will definitely come in handy in thinking of creative ways to solve problems.

This next sprint is when we start working on some real programming so I’m really excited for that and I can’t wait for the next sprint review and retrospective because since I wasn’t able to attend the last one, I’m interested to see what its actually like.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Reflection: Week 3

This week we finished our first sprint. We did our first sprint review and sprint retrospective as well. We used various factors such as Attendance, Communication and Cooperation to rate each other’s performance within our group members. 1 point was given for needs improvement, 2 for acceptable, and 3 for excellent. We all received pretty good average on this one, considering there was nothing much heavy to do on our first sprint.

Looking forward for the next sprint.

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.