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.

I spent this week learning Typescript and Angular2 (continuing from last week). I continued with what I did last week. The only thing which I did different this week was that I listened to videos on Angular2 and TypeScript on Lynda.com.

Some of the videos were good and some put me to sleep. I am also working on the Angular2 tutorial (building the tour of heroes app); I’ll complete it by the end of this sprint.

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 third chapter of this book is about when and how to say yes and commitment. I liked the section on commitment speech vs. noncommitment speech. We should avoid language that shows or may signal that we are not commited to doing something. For example, using words like I need to do this, I hope to get this done, or I should get this done by Friday signals to the other person that you might not do it at all.

There are three parts to making a commitment
1. You say you’ll do it.
2. You mean it.
3. You actually do it.

The secret to recognizing commitment when somebody says something, according to the author, is to look for the words I Will. When somebody uses the words I Will when commiting to something, it shows that they are commited to doing it. And using these words also forces you to fulfil you promise, because you might feel embarassed for not fulfilling you promise.

I personally plan to use the words I Will when I commit to something. This way it forces me to fulfil my promise and also avoids people thinking that I am not commited to doing something.

The second chapter of the book is about when to code, when not to code and what to avoid while coding. This chapter is about the author’s personal beliefs about the matter. I persoanlly don’t agree that 3AM code is bad, I am a night person and most of my best works and ideas come at night. My brain usually does not work 100% during the day, it only starts to work from 8PM to 2AM.

I do however agree with him on the HELP section. Building software is not an easy task; it is the responsibility of developers to help each other and it is a violation of professional ethics to not help others or receive help.

From the blog CS448 – The blog about software by Sudarshan 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.