Monthly Archives: February 2017

The Clean Coder: Chapters 5 & 6

Ahhhh Uncle Bob, You always enlighten my week in some way!

This week in the clean coders I delved into chapters 5 & 6. These chapters talked about Test Driven Development (TDD) and Practicing respectively. These chapters really didn’t introduce these topics to me as these are things I’ve known about for a while but, they shed some light on a few areas that I haven’t heard of before.

In the topic of TDD Uncle Bob made a statement about TDD I hadn’t truly thought of before – Courage. He basically stated that when you follow proper TDD practices you gain courage to go back and fix code. The reason for that is because, we will know whether or not we actually broke the code or not when trying to “fix” it. I’ve worked on a few projects now that I went the wayside of TDD for two reasons, I didn’t really understand it and it seemed like a waste of time. However, even though these were small projects mainly going to be used by myself, when I come across a bug (That wouldn’t have been there in the first place if I’d TDDed) I am always nervous to touch the function or method again. I find myself between this state of “Well did the bug really hard the ability of the software to work? Should be fine.” or “During normal use this shouldn’t happen, I can leave it be.”. Where as if I had written tests I wouldn’t be fearful at all to rewrite and “fix” old code!

Chapter 6 delved into the topic of practice. Uncle Bob seemed to mostly talk about practice in the terms of physical speed of writing code. Like, writing the same method over and over to gain speed of being able to write methods. I’m not going to lie, this is something I’ve done. I’ve worked hard creating code snippets and practicing using key-binds to be able to get the most out of my workflow. The less time I spend writing “boiler-plate” the more time I actually get to be solving the hard problems (aka the “Fun stuff”).

Practicing your workflow and making sure you can code really quickly and you are good with the tools you are using is an important thing. However, one thing I feel Uncle Bob missed is practicing our language specific knowledge. I know for myself and the projects I’ve worked on, every time I don’t have to refer back to documentation is major time saved. One thing I’m not saying is that we should spend major amounts of time learning the deep dark corners of each language. What I am saying is that you should know how to do semi basic things in the language you are working in, without referring to documentation. I remember working on a PHP project where I was doing a massive amount of string manipulation and find/replace type stuff. The first few pieces of code I wrote, I would google my problem and typically find a similar solution to what I needed on Stack Overflow. I would then go to the PHP documentation and see what it had to say to try and figure out the rest of my problem. I found that I kept coming back to the same 4 or 5 functions so I decided to commit these to memory and really try and understand the full capabilities and “hackish” things you could do with each. The 3 or so hours I took reading the documentation about string manipulation probably saved me a week or two worth of work over the projects duration. I’d say that’s worth it!

All in all another great week from The Clean Coder. I am really enjoying this book and cannot wait to see what Chapters 7 & 8 have in store! Thank you Uncle Bob for this awesome book.

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 4 & 5

In the 5th chapter “Test Driven Development” author Martin discussions about the use and benefits of TDD. He puts the three laws of TDD up on front, and relates them back and forth in the entire chapter, as:

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

Begin by writing a small portion of a unit test is a first step to implement. The next step is to make the unit test fail to compile by releasing there’s more code to be written. And then write the production code that make the test compile. Be that as it may, you can’t compose any more than that, so you begin composing more unit test code.

I find the whole TDD concept a little but complicated and time consuming, since I have only written test cases for small size code. I do agree, after reading the chapter, adopting TDD as a professional discipline enhances certainty, courage, defect reduction, documentation, and design. I will be looking forward to use TDD as our project progresses.

The next chapter “Practicing”, is about the ways in which programmers can practice their coding art. Martin lists several kinds of activities which helps developers practice coding that take place in a dojo such as Kata, Wasa, and Randori. They helps to broaden our approach and improve our coding skill. Most of the times we programmers are too busy writing code to think about practicing skills. We spent much of our time waiting for compiles or debugging long codes. But we should always be willing to practice in order to keep our skills sharp. I completely agree with the author. I find myself practicing and improving coding skills just by playing coding related games. From now I will also be engaging my leisure time to participate in testing and also code reviewing open source software that helps me to learn how to apply TDD, and single-responsibility to track an overwhelmingly large project.

 

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.

Week 3 Reflection

This week we finished our sprint with only one task that has to be carried over to the next sprint and that is the angular tour of heroes. We also took the time to review each other based on communication, participation, reliability, and attendance. Ultimately our group was rated well with some room for improvement. For the rest of the week we just had to continue working on angular and openMRS. I did not learn anything new this week however, my team and I are ready for the next sprint.

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

Week 3 – Learning Reflection

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.

Week 3: Reflections on Learning & Work Products

Last week I finished the tour of heroes tutorial.  I learned a lot from just working through it and understanding the implementation of Angular 2.  I liked how the tutorial brought you through something and then had you change it to make it better.  For example, we started off declaring the type “hero” in on of the main folders.  As the tutorial went on, it had me move thedecloared type, “hero”, into its own class.  I learned a lot more then I thought I would from doing that.  This week I already forked the am-path project on git and got it up and running.  That was definitely an accomplishment in itself.  My goal for this current sprint is to work through the AMPATH code and to get a feel of how everything works together.  As of right now I haven’t actually looked at any of the actual code so I am planning to start that tomorrow or Thursday.  I think everything went pretty smoothly this week and I can’t really think of anything I would do differently.  I’m happy we are getting closer to finding out what we will be doing to contribute to the AMPATH project.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

Clean Code Chapter 5-6

On chapter 6 of Clean Code, the book talk about law of Demeter and it showed an example of a code that was typed with a function that calls multiple other functions leading to an extremely confusing line of code. The fix is to separate them out into different lines with each line calling a function.  This is easier to read and have the proper formatting that is expected.

I have read and also written codes that did not have proper formatting and was a long line of calls. It was just a mess to read and I’m sure anybody afterwards trying to pick up my code will have a hard time understand my though process. It is imperative to have proper formatting to not only help yourself if you run into issue with your code, but to other people in the future that might be reading your code.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

The Clean Coder ch 5 & 6.

In this week’s chapters of The Clean Coder, Robert C. Martin talks about the importance of test driven development and ways that programmers can practice their art. Robert talks about the first time he became acquainted with TDD. Although he was skeptical at first, he soon realize that TDD had a lot more to offer than just shortening cycle time. There are three crucial laws one must follow when practicing TDD. One, You are not allowed to write any production code until you have first written a failing unit test. Two, You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing. Lastly, You are not allowed to write more production code that is sufficient to pass the currently failing unit test. even though these laws does not guarantee perfection in any program,  It is a discipline that enhances certainty, courage, defect reduction, documentation, and design. As professional coder, it would be foolish not to follow these laws because of those benefits.

Moreover Robert explain the importance of practicing. Practicing allows us to keep our mind and skills sharpened and stay up to date. As coders, we should be excited about coding therefore, practicing should be done for the enjoyment. After all, as the author, mentions “Professional programmers practice on their own time. It is not your employer’s job to help you keep your skills sharp for you. It is not your employer’s job to help you keep your resume tuned”. We are responsible for mastering our craft and the best way to do that is practicing.  Additionally, Robert correlates Coding and martial arts with a series of activities he calls the coding dojo. In a dojo there are several activities such as Kata, Wasa, and Randori. The purpose of these activities are to synchronize the mind and the body to practice the movements and decision involve in solving a problem.

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

Week 3: The Clean Coder

This week I read chapter 5 & 6 of The Clean Coder.  Chapter 5 discusses that it’s a good habit to write the J-Unit tests before you start to code at all.  I personally am not a fan of doing this, but this chapter taught me how much it can really help.  A quote that stuck out to me was, “I know this sounds strident and unilateral, but given the record I don’t think surgeons should have to defend hand-washing, and I don’t think programmers should have to defend TDD.”  I never have really thought of TDD as a key to programming, so this was a little weird to me.  Obviously as a surgeon it’s a known thing that you NEED to wash your hands.  However, as a programmer I don’t think it’s that known that you should write your tests before coding.  It is extremely important to make sure every single program you write has high coverage tests to go along with it.  The chapter also explained things like documentation of the unit tests.  Someone who is reading through your code should be able to look at the unit tests and see exactly what it should do.

Chapter 6 of the book discussed how important it is to PRACTICE.  I agreed with this chapter a lot more then I did chapter 5.  Practice 100% does make perfect and you need to be willing to put in your own time to be the best you can possibly be.  No one is born being great at something, you need to practice and perfect your skills to make yourself great.  As a professional, you NEED to practice and this chapter doesn’t stress that enough. “Practicing is what you do when you aren’t getting paid.”  That quote really showed me that if you ever want to be the best at something you have to willingly put in your own time.  Overall I liked reading chapter 6.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

Reflection Week 3

We haven’t been doing too much, we just finished our first sprint and got together to talk about our reflections and how everything went and whether anyone had any problems or not. We also performed a review for each individual group member in our group and how how they performed doing the tasks we were assigned or even if they hadn’t been posting their daily scrums and quickly talked about everything we needed to cover. This helped us get a feel of how each sprint would go and helped us strengthen our scrum framework and communicate thoroughly with each other.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

Reflections Week 3

In Week 3 of my Software Development Capstone, we finished up our Sprint and focused on doing the Sprint review and retrospective. First we rated each team member on a scale of 1 to 3 – 1 being “Needs Improvement” and 3 being “Excellent” – on how well they preformed certain things during the Sprint; like communication, completion of tasks, etc. Overall our team went easy on one another for the first round since everyone was still getting the hang of doing the daily scrums and what we defined as “commitment.”

After that we did the overall retrospective of what our team could do better on in the future and also put items on the product backlog to address in the next Sprint. Again we didn’t go too far into the retrospective since we didn’t do much work besides go over the Angular 2 tutorial and read some of the Advanced pages about Angular. We did go over small things that we wanted to put on the Sprint Backlog such as making a proper definition of “done” for the team, and also setting up a priority list so we know how long certain tasks will take.

Overall it seemed to make sense to go easy on this first Sprint review/retrospective so that all team members have a baseline for how this will go. Once we have code and actual projects to work on, our team plans to go more in depth about giving reviews for people  and also take a bit longer with our retrospective about what our team could improve on in the future.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.