Monthly Archives: February 2017

Clean Coder Chapters 5 and 6

Clean Coder Chapters 5 and 6
Chapter 5:
I have to say that I enjoyed these two chapters, I think in
part because they are on stuff that I need work with and don’t have too much
experience in them, well the test driven development (TDD) anyways. I find it
interesting reading about coding experience from someone who has been coding
since punch cards and to see how much the skill has evolved. I used to have a
Commodore 64 and was familiar with the Apple 2 machines and programming in
Basic. It is awe inspiring to see how much the languages have grown and power
of systems increase since then. Well back on subject and TDD. I do not have
really any experience outside of some TDD examples I have done for class and
reading about it, but I can see how it can be great. I think it may be hard for
me to get used to as though it makes sense to me in theory, putting it to work
in practice is another story. I like the 3 laws of TDD and imagine it is going
to take some getting used to writing tests before writing any actual code, and
sticking to it. I can see the benefits for sure. The thing that I like is that
it seems to force you to write smaller parts of the whole and in the end you
end up with not only a bunch of smaller modules, but you also have the tests to
go along with them and the confidence that what you have will work. The other
plus is that when you add code or update, you are only doing it to smaller
parts of the whole so it is easier to track the bugs when something does break
I would think. It is crazy that his FitNesse program takes only 90 seconds to
run and has 90% test coverage with only 17 bugs in his list. That there seems
to me like proof in the pudding on TDD. As I said before, this is something I
will have to work on and gain confidence with and take his advice on courage. I
really like the statement, “When you have a suite of tests that you trust, then
you lose all fear of making changes.” For now, I will just work on following
the three laws of TDD.
Chapter 6:

This chapter’s subject in my opinion is so very important,
practicing. He hits the nail on the head here. You can’t better if you aren’t
practicing your art. I certainly need more of it and don’t do enough, but I am
working on it and I plan on using some of the techniques in this chapter to
help with that. I enjoyed how he puts it together with martial arts terms. I
will be working on the Katas that he linked and other items. I don’t really
think that I can write a whole lot about practicing as I think it speaks for
itself. Without practice you get stale and lose your touch. I really like some
of his ideas on picking a new language to practice with and finding an open
source project to work with. I believe that all of these ideas will help to
make me a better programmer as long as I put them to work and keep up what I
have been doing. I am passionate about this and sometimes feel like I am behind
the curve, but I just keep plugging away and learning more every day.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 5 and 6

Clean Coder Chapters 5 and 6
Chapter 5:
I have to say that I enjoyed these two chapters, I think in
part because they are on stuff that I need work with and don’t have too much
experience in them, well the test driven development (TDD) anyways. I find it
interesting reading about coding experience from someone who has been coding
since punch cards and to see how much the skill has evolved. I used to have a
Commodore 64 and was familiar with the Apple 2 machines and programming in
Basic. It is awe inspiring to see how much the languages have grown and power
of systems increase since then. Well back on subject and TDD. I do not have
really any experience outside of some TDD examples I have done for class and
reading about it, but I can see how it can be great. I think it may be hard for
me to get used to as though it makes sense to me in theory, putting it to work
in practice is another story. I like the 3 laws of TDD and imagine it is going
to take some getting used to writing tests before writing any actual code, and
sticking to it. I can see the benefits for sure. The thing that I like is that
it seems to force you to write smaller parts of the whole and in the end you
end up with not only a bunch of smaller modules, but you also have the tests to
go along with them and the confidence that what you have will work. The other
plus is that when you add code or update, you are only doing it to smaller
parts of the whole so it is easier to track the bugs when something does break
I would think. It is crazy that his FitNesse program takes only 90 seconds to
run and has 90% test coverage with only 17 bugs in his list. That there seems
to me like proof in the pudding on TDD. As I said before, this is something I
will have to work on and gain confidence with and take his advice on courage. I
really like the statement, “When you have a suite of tests that you trust, then
you lose all fear of making changes.” For now, I will just work on following
the three laws of TDD.
Chapter 6:

This chapter’s subject in my opinion is so very important,
practicing. He hits the nail on the head here. You can’t better if you aren’t
practicing your art. I certainly need more of it and don’t do enough, but I am
working on it and I plan on using some of the techniques in this chapter to
help with that. I enjoyed how he puts it together with martial arts terms. I
will be working on the Katas that he linked and other items. I don’t really
think that I can write a whole lot about practicing as I think it speaks for
itself. Without practice you get stale and lose your touch. I really like some
of his ideas on picking a new language to practice with and finding an open
source project to work with. I believe that all of these ideas will help to
make me a better programmer as long as I put them to work and keep up what I
have been doing. I am passionate about this and sometimes feel like I am behind
the curve, but I just keep plugging away and learning more every day.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 5 and 6

Clean Coder Chapters 5 and 6
Chapter 5:
I have to say that I enjoyed these two chapters, I think in
part because they are on stuff that I need work with and don’t have too much
experience in them, well the test driven development (TDD) anyways. I find it
interesting reading about coding experience from someone who has been coding
since punch cards and to see how much the skill has evolved. I used to have a
Commodore 64 and was familiar with the Apple 2 machines and programming in
Basic. It is awe inspiring to see how much the languages have grown and power
of systems increase since then. Well back on subject and TDD. I do not have
really any experience outside of some TDD examples I have done for class and
reading about it, but I can see how it can be great. I think it may be hard for
me to get used to as though it makes sense to me in theory, putting it to work
in practice is another story. I like the 3 laws of TDD and imagine it is going
to take some getting used to writing tests before writing any actual code, and
sticking to it. I can see the benefits for sure. The thing that I like is that
it seems to force you to write smaller parts of the whole and in the end you
end up with not only a bunch of smaller modules, but you also have the tests to
go along with them and the confidence that what you have will work. The other
plus is that when you add code or update, you are only doing it to smaller
parts of the whole so it is easier to track the bugs when something does break
I would think. It is crazy that his FitNesse program takes only 90 seconds to
run and has 90% test coverage with only 17 bugs in his list. That there seems
to me like proof in the pudding on TDD. As I said before, this is something I
will have to work on and gain confidence with and take his advice on courage. I
really like the statement, “When you have a suite of tests that you trust, then
you lose all fear of making changes.” For now, I will just work on following
the three laws of TDD.
Chapter 6:

This chapter’s subject in my opinion is so very important,
practicing. He hits the nail on the head here. You can’t better if you aren’t
practicing your art. I certainly need more of it and don’t do enough, but I am
working on it and I plan on using some of the techniques in this chapter to
help with that. I enjoyed how he puts it together with martial arts terms. I
will be working on the Katas that he linked and other items. I don’t really
think that I can write a whole lot about practicing as I think it speaks for
itself. Without practice you get stale and lose your touch. I really like some
of his ideas on picking a new language to practice with and finding an open
source project to work with. I believe that all of these ideas will help to
make me a better programmer as long as I put them to work and keep up what I
have been doing. I am passionate about this and sometimes feel like I am behind
the curve, but I just keep plugging away and learning more every day.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 5 and 6

Clean Coder Chapters 5 and 6
Chapter 5:
I have to say that I enjoyed these two chapters, I think in part because they are on stuff that I need work with and don’t have too much experience in them, well the test driven development (TDD) anyways. I find it interesting reading about coding experience from someone who has been coding since punch cards and to see how much the skill has evolved. I used to have a Commodore 64 and was familiar with the Apple 2 machines and programming in Basic. It is awe inspiring to see how much the languages have grown and power of systems increase since then. Well back on subject and TDD. I do not have really any experience outside of some TDD examples I have done for class and reading about it, but I can see how it can be great. I think it may be hard for me to get used to as though it makes sense to me in theory, putting it to work in practice is another story. I like the 3 laws of TDD and imagine it is going to take some getting used to writing tests before writing any actual code, and sticking to it. I can see the benefits for sure. The thing that I like is that it seems to force you to write smaller parts of the whole and in the end you end up with not only a bunch of smaller modules, but you also have the tests to go along with them and the confidence that what you have will work. The other plus is that when you add code or update, you are only doing it to smaller parts of the whole so it is easier to track the bugs when something does break I would think. It is crazy that his FitNesse program takes only 90 seconds to run and has 90% test coverage with only 17 bugs in his list. That there seems to me like proof in the pudding on TDD. As I said before, this is something I will have to work on and gain confidence with and take his advice on courage. I really like the statement, “When you have a suite of tests that you trust, then you lose all fear of making changes.” For now, I will just work on following the three laws of TDD.
Chapter 6:

This chapter’s subject in my opinion is so very important, practicing. He hits the nail on the head here. You can’t better if you aren’t practicing your art. I certainly need more of it and don’t do enough, but I am working on it and I plan on using some of the techniques in this chapter to help with that. I enjoyed how he puts it together with martial arts terms. I will be working on the Katas that he linked and other items. I don’t really think that I can write a whole lot about practicing as I think it speaks for itself. Without practice you get stale and lose your touch. I really like some of his ideas on picking a new language to practice with and finding an open source project to work with. I believe that all of these ideas will help to make me a better programmer as long as I put them to work and keep up what I have been doing. I am passionate about this and sometimes feel like I am behind the curve, but I just keep plugging away and learning more every day.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Capstone Project: Week 3 Reflections

Yet another week here and gone. This weeks reflections will be fairly brief due to it being the end of our sprint and having a weekend with nothing to work on. However, we did have a sprint retrospective this week due to our sprint completion! The retrospective went well. Our team has really great communication and that has helped us, so these retrospectives are just re-caps of things we found during the week.

One of the major issues we discussed was with our daily stand-ups. Due to us having to all do them remotely there leaves a lot open for loosely worded statements. We were using a lot of “I’ll try” or “I might get it done” and we wanted to clear up this language and be more precise. We found that two things happened when we became more precise.

  1. Others trusted what we said and knew we were going to get done what we said.
  2. We held ourselves personally accountable to truly get the things done that we said we were going to.

These two things I feel are very important for any scrum team!

We did our first real sprint planning today and I am very excited to start working with the AMPATH code and seeing what true professional software looks like!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

The Clean Coder, Chapters 5 & 6 Week 3 (2/7/17)

The 5th chapter of the Clean Coder focuses on the topic of Test Driven Development. The chapter involves the author describing his experience with Test Driven Development and how he realized how much beneficial the method of testing is and not just for reducing the cycle time in programming. When it comes to Test Driven Development, it is an opportunity to test yourself on how well you know your code. The author came up with rules indicating that a programmer should not continue programming unless they understand the testing process of their program, including writing failed test cases on purpose to know how the program will fail.

Test Driven Development is important in the creation of code as constantly testing every method you type or just mere lines of code may be kind of aggressive but it helps you debug what will go wrong and what works. Knowing what its like using Junit for testing my code makes me relate to the authors experience of TDD.

The 6th chapter of the Clean Coder focuses on a topic that I can not express enough myself regarding people who come to ask about programming and how hard it is. Anything is accomplish-able if you just practice! From talking about his first program and also getting a computer to code on, the author describes his journey from improving his coding skills and interest along the way attending conference events and practicing methods such as katas to know how to get used to a computer and practicing shortcuts like its a second nature.

People always ask me when I tell them I was a computer science major is “how is programming is it hard?” or “oh gosh programming is too complicated for me” I always try to come up with a response that involves to at least try and keep practicing. 10,000 hours of practice means you are a master at the skill, but you do not need to be a master in order to decently code.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Reflections and Learning (Week 3 2/7/17)

In regards to an update for what was during during this week for our project included doing peer evaluations where the professor gave us sheets with a set of criteria that we have to mark for each of our team member’s performance. Criteria included the attendance of the team members since we began our groups as well as how often they seek help and ask for help when they cross an obstacle. After we all decided the performances of our teammates we ended up getting our scores tallied and the results were talked about as a group with our professors revealing the results. It honestly felt like we were on survivor and we were getting judged to see who gets kicked of the island. A lot of people got perfect scores on the team and some had only attendance issues. The average was 2.8/3 which is great for a first evaluation and hope people can improve when it comes to their weakness as well as focus on maintaining their strengths.

Lately we updated our Trello tasks and adjusted our categories in a manner where we have a product backlog category and a sprint backlog which focuses on the tasks we are doing in class. If the tasks in the doing category that are grabbed in the sprint backlog (tasks we work on in class) do not end up being complete, then they get put in the product backlog and we have to finish those tasks in the next sprint.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

The Clean Coder, Chapter 5 & 6

In chapter 5 and 6 of The Clean Coder, author Robert Martin explains two very important habits of a professional and successful programmer i.e. testing code following Test Driven Development (TDD) and practicing your craft. In chapter 5, Martin goes into detail on how he was introduced to TDD and what are the key benefits of TDD. In chapter 6, Martin explains the most important ingredient that I believe is necessary for any field in order to be successful in that field, practicing. Practicing is an exercise that can keep programmer’s skills sharp and can eventually result in perfection with great confidence and accuracy.

There were few great points that the author mentioned about TDD. First point that TDD is a three step-by-step testing process which assures that the new code added did not break the preexisting working code. Second point was that TDD gives programmers courage. If a programmer believes in his tests and is confident about his tests, then this trust eliminates any fear from making changes to his/her or someone else’s code. I believe all the benefits of TDD can be summarize in this one quote, “It is a discipline that enhances certainty, courage, defect reduction, documentation, and design.” TDD does give programmers to test their code on time and helps them break down problem into small pieces which enhances their problem solving skills. A single practice that makes TDD different and interesting from other testing practices is that in TDD programmers have to write their tests before their production code. I have learned about TDD in my Software Construction and Software Quality Assurance courses, and from my personal experience as a beginner, it is a little weird. But after reading this author’s take on TDD, I understand that it will be very helpful in the long run. In other words, I did not had enough practice with TDD which made me a little uncomfortable.

About any field out there, if people do not practice and keep their skills up-to-date and sharp, their demand in the market will degrade dramatically over time. One major point that the author mentioned was that it is not the employers who should be allowing employees to practice. It is employee’s responsibility to keep their skills sharp. I strongly agree with this point because practicing should be fun and exciting. It should be done outside work and on your own time. I believe practicing is very crucial to any field, but for programmers it should be a natural thing because without practice we tend to freeze in time and previously learn knowledge tends to escape from our mind. More practice gives you an automated and instinctive ability where your body and fingers react with your mind directly, without thinking, with perfection. As the author suggests, “We choose a repertoire of problem/solution in pair and execute them over and over again until we know them cold.” For me, lesson learn is that practice a problem over and over again until I know it cold.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

Week 3 Capstone

For week 3 I focused on finishing the stories from my teams first scrum cycle. The only one I had left was to complete Angular Tour of Heroes Tutorial which I did successfully. After finishing the tutorial I didn’t feel very prepared to build an application using the Angular 2 Framework. I think the tutorial was more for a developer who had some previous experience with web development. After some google searches it seems my best bet would be to learn the fundamentals of JavaScript, HTML, and CSS. To start that process I completed the free versions of “Learn JavaScript” and “Make a Website” on codeacademy.com and I am starting to feel a little more knowledgeable. These courses covered the mentioned topics and basically use a compiler in the browser window to walk a user through lessons. I think the next logical step would be to try and make my own web app using an IDE (probably WebStorm) to apply what I’ve learned. My biggest obstacle with Angular 2 was not knowing the syntax and how different pieces of code worked together.  I have also enrolled in Angular University which is a free resource that explains a lot of the framework’s concepts more in depth. I haven’t looked too much into that yet however. Also for the week my group finished our first Scrum cycle. We definitely need to improve on our daily scrums but overall I think we had a good sprint and reflection discussion. It will be easier to assess the effectiveness of a sprint when our tasks are truly divided and we are working on our actual project. In conclusion the first cycle went well for the team and I now know I have some learning to get done so I can better understand Angular 2.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 5 & 6

Chapter 5 covers the topic of Test Driven Development (TDD). This method of coding involves writing unit tests prior to any production code. The author summarizes TDD in 3 laws which must be followed: 1) You can’t write production code until you write a failing unit test. 2) You can’t write more of a unit test than is sufficient to fail. 3) You can’t write more production code than is sufficient to pass the failing unit test. The chapter goes on to highlight many of the benefits of TDD. First, it creates certainty when any code is changed. If sufficient tests have been put in place then you can be certain any changes haven’t broken other pieces of code if those tests still pass. This will also reduce the fear among programmers making changes to older code because they have the reassurance of their tests. The author also points out that the TDD approach significantly reduces bugs and defects in the production code because every function, class, detail, etc. needs to have a passing test. He also makes a point that this provides good low-level documentation to the appropriate audience of how the code really works. Lastly, TDD forces developers to practice good software design because each function needs to be in an independent and testable state. In conclusion the author basically says TDD is necessary for any programming professional and is considered best practice.

After reading chapter 5 I believe there are some good takeaways for a beginning software developer like myself. Many times for school assignments unit testing wasn’t really required so I think it’s important to realize what will be required as a professional. TDD seems like a very smart approach for development in the sense of reducing bugs and increasing confidence to modify older code. This would most certainly save time, money, and other resources. I thought it was important that the author noted it’s still possible to write bad tests which would hinder the effectiveness of TDD. As someone who hasn’t written a lot of tests I think I would definitely need some practice before I could make worthy contributions in a TDD cycle. Having said that I think I will start going back to older programming projects and work on my test writing skills. After some practice I will hopefully be on the level of understanding I need to be able to write unit tests before the actual production code. Moving forward I’ll adjust my approach to coding to reflect the three laws of TDD as best as I can.

Chapter 6 covers the topic of practicing coding. The idea is that any professional practices so that they can keep their skills sharp. The author gives some of the best ways he has seen developers practice which he also calls coding dojos. The first coding dojo is called a kata and it basically involves a developer solving a programming problem but in a choreographed manner to strive for perfection and commit the solution subconsciously. The second dojo is called a wasa and involves two people performing a kata together. Basically one person writes a test and the other writes passing code. This method also helps enforce TDD discussed in chapter 5. The last dojo is called randori and usually involves a group of people. Basically code is projected on the wall and every group member walks up and either writes a unit test or code to that passes a unit test. All these methods help commit problem solving techniques to memory so that they ca be called upon with ease at another time. The last part of the chapter mentions that practicing is up to the individual and not the responsibility of employers. Due to this fact, developers should practice skills outside of their expertise to broaden their knowledge and keep their resume fresh. In summary, a professional practices their programming ability and seeks to diversify their skills on their own time.

After reading chapter 6, I think it gave me some helpful reminders. While in school it seems like I’m always learning a language or tool to complete one assignment. I don’t typically go back to expand on a subject or practice what I’ve learned. This would be a really good habit to adopt so that I am retaining my past learning as well as adding to it. I felt that the author’s mention of practicing reinforced the idea from another chapter that a professional dedicates 20 hours of their own time each week to growing as a developer. After reading this chapter those 20 hours should surely include practicing their development skills. While I am still learning a lot I am going to try and dedicate some time each week and practice or even just re-learn a problem, skill, etc. to become more of the professional described in this book.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.