Category Archives: cswsu

Week : The Clean Coder, Ch. 7 & 8

Chapters 7 and 8 of The Clean Coder are about testing. Chapter 7 is about acceptance testing and chapter 8 is about testing strategies. Acceptance tests are tests that are written by the developers and end users together. The aim of these tests is to agree upon what it means to be done. The author speaks about defining done. The author “Professional developers have a single definition of done: Done means done.Done means all code written, all tests pass, QA and the stakeholders have accepted. Done.” I personally like this attitude. If a development team is not upfront about what it means to be done it can lead to confusion, an incomplete product, or a missed deadline. When a team member says that the task they were working on is done the other members should be able trust that it is done and does not need to looked over by others. This is a common problem in group assignment in school. A project may be broken up in to individual tasks and on person is responsible for putting the final pieces together and submitting. To often the person responsible for the final submission assembles all the pieces only to find out some of those pieces are really not complete, they then frantically work to finish and submit the project.

In chapter the author makes the statement ” QA should find nothing”. I know, as the author also pointed out, this is an asymptote, there is a reason the company has a QA team. That being said, I like the attitude the statement conveys, developers should take pride in their work and aim to produce good, clean code that is as close to error free as possible. A developer should never say “Don’t worry, QA will catch it.”

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

The Clean Coder Chapters 7 & 8

Definition of “Done”, Acceptance Testing are both built off of communication. This is key when trying to convey your programming needs to a developer or vice versa. The definition of Done in my opinion and in what the author presented us is a moral of “Done” means many things to many people and it is important to establish your system/meaning of “Done”.

The next big topic was Agreement Testing. From personal experience I know how in a corporate environment the managers may not know exactly what they want until you build what they ask for. Then as the author tries to emphasis that they will always have changes. This is said to be because now they how more information on how it looks and what they can perceive to be most efficient. Also Agreement Tests are NOT Unit Tests…..its explained pretty clear that the access points for execution are expected to be different for a Agreement test. This also is where he went into a useful tangent to point out that the underlying framework for your GUI should be consistent but the GUI layout itself can change fluidly.

Chapter 8 discussed more about testing.Of course I think this author has unrealistic benchmarks yet they are great to strive for. He seems very stern in the words used to state Quality Assurance should find nothing. This is a topic we discussed in depth in our last semester course on integration testing, unit testing, what defines a unit etc.Yet the important point he stresses is that unit tests are for the programmers. The component tests are for the Agreement Test, and the integration testing is for large systems when piecing many components together, and the System test is where the entire program is tested from an outside perspective that is all works as one system.

From the blog CSWSU – Triforce Code| Exploring and Learning by CSWSU – Triforce Code| Exploring and Learning 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 2: Reflections

This past week most of my time was spent on setting up the environment for Angular 2 and starting to use it in small applications. I ran in to a small snag while setting up the environment, after installing nodejs and npm I was getting an issue running the server. This was resolved by installing the package nodejs-legacy. I also spent some time on various tutorials. As a group we did set up a number of tools that we will be using through the semester to organize the scrum team. We are using Slack for most of our communications including daily Scrum meetings as it is not possible to meet. We are using Trello to organize our sprints with a board for the project backlog, the sprint backlog, and the completed tasks. I was also looking in to some Trello power ups that would help with the burn down chart.

My first impressions of Angular 2 were pretty positive. I like the system that is use to run the development web server. It reminds me a lot of Python’s Django. The sever is also nice as it processes the files as you save them. This means you have more freedom when it comes to text editors and IDE’s.

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

Week 2: The Clean Coder, Ch. 3 & 4

In chapter three of the The Clean Coder, authored by Robert Martin, the focus was on saying yes and meaning it. This chapter is some what of a continuation of the last. It is very easy, when asked to preform a task, to almost reactively say yes. The author stress the fact to consider what is being asked and to only say yes if you will accomplish the task by the deadline. This is important as meeting keeping to you promises will mean others can trust and depend on you. If a person is always saying yes without delivering one will not be able take them at there word. This is where the author start using the phrase “the language of commitment”. With this he means use strong words that will convey your true intention. Use words like will or by in place of words like try, hope, or plan to. By using strong words you will minimize the worry in others, But again, this is only true if you keep to your promises. This chapter continues on the thought in chapter two in the idea that it is okay to say no or something is not possible. It is far better to say no than to say yes only to not complete the task at hand.

Referring to the same situation in my blog last week, I was working at a cabinet making company where one of the employees would always say yes. This habit of saying yes to all the tasks and deadlines meant nobody know what to expect to actually be accomplished. The word yes meant nothing. I also recall many times I was given a task and my response was “I will try to complete it” most of the time I had every intention on completing it but the words I used didn’t show it.

The fourth chapter is where the books starts to focus on coding. The author goes into some areas that are good programing techniques, like per programing, but also covers bad practices such as rushing, programing when tired or warn out, calling code done before it is actually ready to ship. He also talks about “the zone”, this is a state of being highly focused, a type of tunnel vision. In his opinion he thinks this is bad place to be and suggest taking a break or finding a partner to program with if you find your self slip in to the zone. People are different though, some like listening to music or having the television on in the background, personally I like to work without the outside noise. One of the last items covered in the chapter was knowing when to take a break. Sometimes it is good to walk away from the computer and in many cases you will think of a solution while preforming some mundane task.

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

Professionalism is not just for work but also life

I really liked the Reading in “The Clean Coder” by Robert C. Martin. In chapter one I enjoyed reading about how developing your career is not anyone elses job but your own. As a professional and of course computer science. We are expected to grow and learn daily, we may not know it all but many things we can have go wrong are within our control to prevent if we are properly thinking and are prepared. Much like as Seniors we have learned a important fact,…we are all clue less, even if we have ventured out and learned new tools and techniques we certainly have far to go to become true experts. Yet I think that was the most intriguing thing about Software development, is that you must constantly be evaluating your work and your knowledge. The second chapter brings up a very important topic that I got to see first hand and learn the needed skill of knowing when to say no. This is a respected and reserved response in my company but it should be used when you know it is appropriate. I have had the pleasure of working with understanding individuals who are willing to work with you, yet sometimes you need to push back to achieve the common goal.

From the blog CSWSU – Triforce Code| Exploring and Learning by CSWSU – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 1: The Clean Coder, Ch. 1&2

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

Week 1 Reflection

This is the beginning of the software development capstone. We started the semester by forming the scrum teams we will be working in for the remainder of the semester. the class has been divided into 4 Scrum teams each with about 6 members.

 

In these teams we will be working on the open source software OpenMRS. OpenMRS is an open source medical record system that aims to provide developing countries around the world with a reliable tool for use in medical facilities with out the high cost associated with commercial options. We will be concentrating on the AMPATH project.

 

This week most of my time has been spent looking in to Angular 2. Angular 2 is a JavaScript framework maintained by Google. We will be using this throughout the semester as we work on the AMPATH project.

 

I believe this will be a valuable experience. Throughout the past three and a half years, all of the programs we have worked on in school have been very small in size. In contrast, OpenMRS is a much larger and will offer a good opportunity to experience having to jump into a large project, become familiar, and start developing.

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

Spring 2017 Introduction

This semester I will be continuing to blog. The focus this semester will be my experience working in a SCRUM team. Our team will be working on OpenMRS specifically the AMPATH project. I will also be blogging about the reading I do as a part of the class as well as any topics I find interesting.

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