If you were feeling a void in your heart for some more testing since chapter 5’s lesson on TDD, then chapters 7 and 8 are sure to get that blood pumping organ to swell.  Chapter 7 is called “Acceptance Testing” and focuses on how to determine when a programmer has completed a requirement.  Chapter 8 is called “Testing Strategies” and focuses on the “The Test Automation Pyramid” which I provided below.

In chapter 7, Robert C. Martin gives his “Definition of Done” which is accomplished when “all code is written, all tests pass, QA and the stakeholders have accepted.”  Just today our development team drafted our own Definition of Done.  Ours contains slightly different criteria as we are not engaging in TDD.  Additionally, due to our constraints, do not have the time or resources in order to produce automated acceptance tests as Martin suggests.  He focuses immensely on how integration testing through a continuous integration system is the best form of communication between programmers and stakeholders.

In chapter 8 Martin focuses on test coverage.  He believes that unit tests should cover 100% of a programmer’s code, although he admits that 100% coverage is unrealistic.  He also suggests component tests should cover about 50%, integration tests about 20%, and so forth.  Martin suggested, once again, that he believes that QA should find nothing wrong with the software that they are reviewing.  However, in this and the previous chapters, he explains that QA has the responsibility of writing the acceptance tests in conjunction with the stakeholders.  Therefore, if QA does a good enough job, and programmers ensure that their code passes these tests, then I finally agree with Martin. There exists a slim possibility that programmers can ship code to QA with some confidence that there exists no bugs in the code.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Unfortunately I have not done much since my blog post last week.  In fact, since our sprint finished on Thursday, my learning has been put on hold.  In light of that fact, the structure of these blogs will change.  Instead of weekly posts, I will be posting every two weeks, when our sprints finish.  In retrospect these past three learning reflection blogs were rather unproductive, but the future posts will contain much more useful and interesting information.

As I said, we completed our first sprint on Thursday.  So now I have experienced the entire sprint cycle, and I must say, it went pretty well.  Future sprints will certainly be more involved, but I think that our group handled the process without any major problems.  As this semester progresses I anticipate that our group will embrace the sprint cycle and scrum as a whole.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Throughout this week we had much to learn and only a couple cards in our Trello board.

• Create an OpenMRS ID
  • Easy
• Post introduction in Welcome thread
• Install WebStorm IDE and Atom
  • Easy, atom for now I like the experience better. Much more customized
• Angular Tour of Heroes Tutorial

All but the Angular tour of Heroes was easy, the angular tutorial really was weird to me and retried twice and got it to work fine. It must have been a small syntax error. Taylor has been managing well keeping us in tip top shape!

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

The importance of saying yes is something that many take for granted. This is the general theme of chapter 3. The reason Robert Martin of The Clean Coder, uses this chapter to talk about saying yes is to compliment and explain in a professional context the act of agreeing to take on work etc. I think much of this book is common sense on how to act, yet it was refreshing to have a rubric to see what your agreement means to the other person or organization you are working with. This could be even an agreement with yourself. When you agree to take on work its a test of character and really shows what your word is worth and I like this point of doing what you say.

Now Chapter 4 is another animal…it has many points brought up by many classes in the past. Everything from working too late/hard/too much, to what to when you are late on a project. These are great points to take to heart for my career and I hope I can reflect many of these perfectly throughout my career. I definitely find this chapter useful, I can tell that this author thinks TDD is the only way to clean code :D.

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

This past week I spent my time working with Angular 2.  More specifically, I worked through the Tour of Heroes.  I took my time going through the tutorial, and as a result, I feel as though I learned a lot.  Unfortunately, for everything I learned, I am sure that there is an equal or greater amount of information I did not retain.  I intend to spend the next couple days reinforcing that knowledge with some more readings.  Then the fun starts.  In the same manner that I have learned everything else, I need to apply some practical application to the material and gain some experience.  Luckily, I have a group of peers, a project to look forward to, and thirteen more weeks to practice.

I find that I am disappointed with my second week of learning reflection blogging.  I don’t think that it is for a lack of effort, but that I have not begun working on our own project.  The Tour of Heroes tutorial is pretty self-explanatory, and does not require any additional commentary.  Once we dive into our project, and hopefully that time comes soon, I will be able to write about that experience.  Until then, I will continue to learn as much about Angular 2 as I possibly can.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

In chapter five of Robert C. Martin’s The Clean Coder, his topic is Test Driven Development (TDD).  Last semester I took a course called Software Construction, Design, and Architecture, in which we practiced a bit of TDD.  I also took a class called Software Quality Assurance and Testing, and if the title did not give it away, was mostly about software testing.  With the benefit of those courses I do know a bit about TDD, and because of this, I can confidently say that Martin was spot on with this chapter.  The most important thing to take away from this chapter is Martin’s three laws of TDD.  The first is, “you are not allowed to write any production code until you have first written a failing unit test.” The second is, “you are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.” Finally, the third is, “you are not allowed to write more production code that is sufficient to pass the currently failing unit test.”  The rest of the chapter is dedicated to explaining the benefits of TDD.  My suggestion is to try a simple program, and if you follow his three laws, you should be able to determine the benefits for yourself.

Chapter six was entitled “Practicing.”  The message of this chapter was, that to be a professional programmer, you must keep your skills sharp, and in order to keep your skills sharp, you must practice.  Martin discusses his experience with the Coding Dojo, and the activities associated with it.  Kata, Wasa, and Randori are three coding activities used to hone your programming skills.  Martin also suggests working on Open Source Projects or mixing up which languages and platforms in order to expand your knowledge.  I certainly believe that practicing is an important part of being a programmer.  Once you become an experienced programmer it makes sense to repeat older problems and try to hone your skills.  I, on the other hand, still consider myself a novice, and I think my time is better served expanding my knowledge as much as possible before I begin repeating past projects.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

I continued reading The Clean Coder by Robert C. Martin this week.  This blog post centers around the content of chapters three and four.  The majority of chapter three is actually an article by Roy Osherove entitled, A Language of Commitment.  The main theme of Osherove’s article is the three parts of making a commitment, which are, “you say you’ll do it,” “you mean it,” and “you actually do it.”  Essentially he is speaking to following through with your promises.  Osherove also speaks to signs of noncommitment, such as using words like “need,” “should,” “hope,” “wish,” or “let’s.”  He says that a real commitment follows a structure like, “I will … by …”  At the end of the chapter, Martin summarizes Osherove’s points, and puts it in terms of professionals.  This chapter was pretty straight forward and I can’t say that I disagree with the message.

Martin entitles his fourth chapter “Coding” but if you were hoping to find some code, then you will only find disappointment.  This chapter centers mostly on when you should not write code, how you are probably using bad practice while coding, and how you should mitigate expectations.  Personally, I think a more proper title for this chapter would be “Negative Nancy’s Guide to Why You Suck at Coding.”  First of all, this chapter begins with a section called “Preparedness” but I do not see the relevance to the material in the section.  Martin describes the necessary elements of code, and then he talks about concentration.  He then describes a plethora of different distractions and advises the aspiring professional programmer not to get distracted.  On a side note, I found it interesting that Martin suggests that a programmer should put in eight solid hours a day instead of attempting to code for longer.  I found this interesting because in chapter one he suggests that you should commit at least 60 hours a week to your career.  If you only code for eight hours a day, seven days a week, that only equates to 56 hours.  For someone who claims to be a great professional programmer, I find his basic math skills lacking.

Well, I am now 76 pages into this textbook, only 109 more pages to go.  I’m not saying that this is the worst text I have ever read, and it has certainly given me something to write about, but I am certainly finding The Clean Coder to be far more idealistic than practical.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

This is the first installment of learning reflection posts for my capstone at WSU.  This week in class we formed groups to work on projects.  I am still figuring out what we will be doing exactly, we are very early in the process, but we started pulling resources.  This week I read up on OpenMRS and AMPATH.  I started reading through this book which I found on the OpenMRS website and gained some knowledge about the background and goals of the project.  As for AMPATH, I perused the website, and gained an understanding as to what they are trying to accomplish.  In all honesty, it seems like OpenMRS and AMPATH are noble endeavors, and I’m excited to get started on our own project.  I suppose the next step is to get together with our group and begin creating our product backlog, and start our first sprint cycle.  Unfortunately, this week was mostly spent on researching what we are getting involved with, and there was little physical progress.  Hopefully, next week will involve more direction and some real progress will be made.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

This past week I read the first two chapters of The Clean Coder by Robert C. Martin.  The first chapter’s main focus is on professionalism.  Martin defines professionalism as a “marker of responsibility and accountability,” (8).  He then proceeds to explain what he means by that statement, and he describes what he believes makes a programmer a nonprofessional.  In chapter two Martin describes in detail an aspect of being a professional.  He stresses the importance of saying “no” when a programmer is asked to complete tasks in unrealistic timeframes.  He provides numerous situations and describes why some ways of handling the situation of saying “no” are better than others.

So I am 43 pages into reading The Clean Coder, and I must say that Martin definitely has a very strong opinion concerning his topic.  To an extent I would say that I find it overboard and at times even condescending.  The thought that an employee is only a professional if he or she would pay ten thousand dollars back to the company for an error just seems unrealistic.  Additionally, I can’t imagine an employee keeping his or her job for very long if he or she kept saying no to their employer when asked to complete an assignment.  I understand that I am oversimplifying Martin’s point, but at the same time, you must make adjustments and compromises in order to fulfill demand, even if that means not testing every piece of code that you write.  Hopefully I find some more realistic information in the later chapters, because as it stands, I find Martin’s writing to be far too idealistic to be useful.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Well, it’s a brand new semester and that means a whole new slew of blog posts.  Buckle up buckaroos!

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.