Monthly Archives: February 2017

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.

Java Build Automation with Maven

NOTES FROM Java Build Automation with Maven with Peggy Fisher 1. Get Started with Maven What is Apache Maven? Apache Maven, is a software project management, and comprehension tool, based on the concept of a project object model, or POM. Maven … Continue reading

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

Reflection, Week 3

I spent this week completing the Angular2 Tour of Heroes tutorial. I also spent some time learning HTML on Lynda.com. The new thing that I did this week was that I got started with katas mentioned in the Clean Coder book. I am currently working on the prime factors kata on my spare time. I plan to learn a few katas and repeat them for the rest of this year.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Reflection (Week 3)

Week 3 is officially over, and I’m ecstatic to say that my team finished our first sprint. This week I finished the Angular Tour of Heroes Tutorial and we did a team member evaluation for our group. Through this exercise, we noticed things we were doing well, but more importantly things that we didn’t do well. We then discussed about how we can all improve as team, before we tackle our next sprint.

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

The Clean Coder (Week 3)

This blog post will revolve around chapters 5 and 6 of The Clean Coder book.

Test Driven Development (Chapter 5)

The author provides us of some rules for test driven development.

  1.  You are not allowed to write more production code than is sufficient to pass the test.
  2. You are not allowed to write more of a unit test than is sufficient to fail.
  3. You are not allowed to write any production code until you have written a failing test.

By applying these rules, it aims to minimilazie larger problems later on in production. When I first started doing TDD, it was quite tricky, because I was confused on how to write a test case when there were no code for the methods that we were testing. By doing this, you know that your method will pass any type of test case, and you won’t have to worry about it anymore as opposed to trying to find a needle in a hay stack bug at the end.

Practicing (Chapter 6)

This chapter was pretty self explanatory, because we all know of the saying that “Practice makes perfect”.  The author mentions a programming exercise called Code Kata, which allows programmers to improve their skills with repetition and practice. As simple as this chapter is, it’s very important and you can’t stress the importance of practice enough. As a computer science student, I realize how the programming world is quickly evolving as there always seems to be a new language, or framework to learn. It’s impossible to stay relevant in this field without practicing or studying.

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

Waiting for the Sprint

Week 3

Finished our first sprint! It has been a low week here waiting for the next sprint to happen where the interesting tasks will ramp up. Over the past week I completed my Angular Tour of Heroes, and we did a team evaluation at the end of the sprint which turned out to be a slightly awkward experience because no one wants to throw anyone under the bus. We have to progress as a team and complete our tasks though. We will see how smoothly the next sprint goes then re-evaluate.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.