This week I read the final two chapters of Robert C. Martin’s The Clean Coder.  These chapters were not very long and only covered a couple topics.  In fact I only took away two points from chapter 13 on “Teams and Projects.”  These two topics were on the “Gelled Team” and “Velocity.”  A quick overview on Martin’s “Gelled Team” is a group of about twelve programmers, testers, analysts, and one project manager, who have worked long enough together to develop a symbiotic relationship.  I have worked closely with a few students during my time at WSU and we have certainly developed something close to what Martin described.  I know how these students think and work, and it aligns well with my process.  Martin describes “velocity” which my group and I have been experimenting with and adjusting as we figure out how much work we can accomplish over our sprints.

Chapter 14 was entitled “Apprenticeship, and Craftsmanship” which focused on the idea that school does not prepare programmers for the field.  To be honest I am concerned that I have not accrued enough knowledge to be an effective programmer in the field.  Martin suggests a system in which there are Masters, Journeymen, and Apprentices, where the more experienced teach the less experienced.  I like this idea, where for the first year, the Journeymen teach the Apprentices, and over time the Journeymen become Masters who orchestrate the entire process.  Martin also discusses the idea of Craftsmanship, which he calls “a mindset of values, disciplines, techniques, attitudes, and answers,” which are handed down from the experienced to the inexperienced.

Well that wraps up, The Clean Coder.  Stay tuned for more posts starting next week on a whole new text!

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

Another week, another two chapters from Robert C. Martin’s The Clean Coder.  This weeks installment were chapter’s 11 and 12 which were entitled “Pressure” and “Collaboration” respectively.  They combined for eighteen pages of fluff.  Each contained the signature Bobby Marty anecdote which ate up a large portion of both chapters.  In my last post about The Clean Coder I said that I was starting to enjoy his chapters.  I guess I spoke too soon.

So chapter 11 was about pressure.  Martin writes about avoiding pressure and handling pressure.  I found it interesting that Martin thinks maintaining discipline is both a way to avoid pressure and to handle pressure.  He uses TDD as an example.  The problem with TDD is that it is time consuming.  Not only do you have to think of the code you need to write, but you need to write tests that the code will eventually need to pass.  This means that you will be writing twice as much.  His idealistic position on deadlines is unrealistic.  Sometimes you need to make adjustments in order to make deadlines, and in those cases, disciplines must adapt.  TDD may be the best way to do something, but sometimes sacrifices must be made.

Chapter 12 was about collaboration.  It is asinine to resist collaboration for the greatest accomplishments have not been achieved by a single person, but a group of people.  The overall message of this chapter is that working with other people is important, and I don’t think that many people would disagree with that.  I found his section on cerebellums to be superfluous and poorly labeled.  Cerebellum has very little to do out of the context of that billboard he read, and thusly carries little weight outside of that chapter.  I also found that his take on collective ownership interesting.  I feel as though it needs a qualifier.  Collective ownership is certainly the best way to go, IF and only IF you can trust the people you are working with AND you are using a version control system.

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

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.

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.