So our second sprint has concluded, and with that, the change from posting once every week to posting once every sprint has begun!  Additionally, we have changed our sprints so that instead of having four days of downtime in between sprints, we only have a day.  I really like the way this class is developing.

This sprint included some pretty good steps in the right direction.  Everyone in my group was able to get OpenMRS and AMPATH to  run locally on their machines, and we were able to dig our hands into some code.  Each of us took it upon ourselves to rewrite the AMPATH Authentication Module in order to learn more about REST API.  A few of us, myself included, have already had some experience with this so it has not been a huge leap.  Not everyone, myself included, has completed rewriting the Authentication Module, but I intend to finish it during the next sprint.

Our group really got a good feel for how the sprint cycle works this time around.  We conducted our own sprint planning meeting, broke down our stories into tasks in our own story time, and had a successful sprint review and retrospective.  Everyone has been participating in the daily scrums, and I’m glad to see that our dedication to the process has been fruitful.  I can only imagine that, as a group, we will become more efficient and more productive as the semester continues.

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

This week I read another couple chapters out of Robert C. Martin’s The Clean Coder.  These two chapters were entitled “Time Management” and “Estimation.”  Time management is an interesting and important topic in this writer’s opinion.  Martin discusses the importance of meetings, and comments on various methods for limiting these meetings from being time wasters.  He also mentioned a few types of meetings, such as stand-up, iteration, iteration retrospective, and demo meetings.  These are components of the agile process which we have been utilizing in our course thus far.  In my experience with these meetings, I agree with Martin.  If there is not a clear agenda, and if all the members do not maintain focus, a lot of time can be wasted.  Fortunately, we have had pretty good success keeping our meetings on track.  Another topic that Martin broached that I found to be interesting was the Pomodoro Technique.  It is a method for ensuring that time is used effectively and I aim to try using it next time I sit down to do some coding.

As I mentioned, in chapter ten, Martin discusses how to estimate how much time is required for completing tasks.  In his previous chapters he mentioned the importance on estimations, but in this chapter he discusses the process in much more detail, and to my pleasant surprise, provided concrete calculations for how to accomplish adequate estimations.  I hope to employ these techniques in the near future so I can evaluate the validity of his lesson.  As I have read through this book I found that I have been hesitant to believe what Martin has been saying because of the lack of specifics and the overall theoretical nature of the topics.  However, these past few chapters have really started to pull the previous lessons together in a way that makes the whole seem more legitimate.  With only four more chapters to go, I hope that the useful information continues to flow.

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

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.

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.