Monthly Archives: February 2017

Week 3: The Clean Coder, Ch. 5 &

Chapter five of The Clean Coder overs the method of programming know as test driven development or TDD. As the name implies the the process of writing code is driven by test cases. The idea is as you determine what needs to be coded you write a unit test that will verify a specification is meet, once you have the test written you write the bit of program. As soon as you have written the piece of program you can run the test and almost immediately know if the code works. This test driven process could be taken to an extreme where all the test are written before any production code is even started, this obviously doesn’t make sense. To balance the test code and production code the following three rules should be followed.

“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.”

TDD has several benefits. One of the biggest is the fact that having a test suite that is up to date allows you to ensure that your latest changes have not broken something in another location. This is especially true if you stick to the three rules from above. The TDD process also means you will end up with very high code coverage which is a great way to ensure you program works as expected.

I have tried using the TDD process several times and find it a little hard to get used to although I know it is something that would be worth using. Many times I start a program and want to sit down and just start writing production code. The biggest pain in this is once I have written a fair amount of code and compile and run it there are often errors that I must go back and find then fix. If I were to follow the TDD strategy issues would be caught right away.

The sixth chapter is all about practice. In the beginning of the chapter the author focus on the history of computing and how far technology has come. It used to take a great deal of time to compile and test code, but now computers are both faster and cheaper. Most developers can afford to practice. This is something I really wish I had more time to do. I would especially like to practice with other languages. Today, most of the code I write is in Java as that is the language the school has chosen to teach object orientated programming with. I have, in the past, written programs in Python, C/C++, Lisp, Prolog, as well as a few others. The problem is without practice I forget the syntax. I can write a simple program in Python and C/C++ but would need to use a lot of references for more advanced programs and in the case of Lisp, Prolog, and Ruby I can’t remember where to even start.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Week 3 (1/31 – 2/6) The Clean Coder Ch.5 & 6

YES!!! Chapter 5 and 6 of the Clean Coder book is probably the best chapters of this book so far. You do not understand how frustrated I have been in the past when I try to practice and brush up on my coding skills. I would occasionally Google programming problems to solve to keep my programming skills sharp but it gets annoying sometimes because most of the problems require simple one file solutions and I just feel as though I am getting nothing out of the practice. I have never heard of a “kata” before so when I looked up the links that was provided in Chapter 6, I was amazed! I feel as though I have been looking for something like this forever but never found it. What’s great about katas is that it is more like a walk-through instead of a straight programming problem where it is up to you to figure out the solution. I love the concept of a walk-through much better because in a sense, that’s like having a programming tutor help you solve problems. And this way, there’s a clean cut way of knowing if what you are doing is even correct or not!

I do admit, when it comes to practicing, I am among the vast amount of programmers out there who do not take it as seriously as we should. BUT, now that I know what a kata is and how effective they are, I am totally going to invest more time in practicing!!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapter 5 & 6

Chapter 5:

This chapter talks about how at first you might be skeptical about test driven development, but using it will undoubtedly show you how much better developing through the method of tests first is over writing a lot of code and then some tests for it (that don’t even end up working). It talks about how if anyone still wondering if test driven development is the right way to approach code, they are blind to not see that it is the best way to do so and that its proven that it works. At first you can’t even write any production code before writing your first failing test. You can’t write more of the test code either and can’t write any more production code that is passing the currently failing test. This way of writing code has proven to reduce defects by even up to ten times. This effeminately helps me see that writing tests to fit your code rather than to write code and then tests to run in it is the (maybe not best way to code with the least amount of errors.

Chapter 6:

This chapter talks about how every coder, like every athlete needs to practice his skills and continue to do so to master and perfect them. Only then will he get better and make his coding stronger. It was not common for programmers to be practicing their coding languages as a way to help them up until around 2000. It wasn’t until recent years when we even started using screen editors, so we used to take a long time to compile codes and find errors to debug. We would have to wait for code to be returned to work on it again. Now, with the evidence showing us how much we can catch such problems before they even appear, we need to realize that this is the superior way of coding and should be used by all professionals. It does not matter if you are just new to coding or are even a master coder, practice will make you better and you might even uncover skills you might have never found or tricks you pick up while practicing, no matter what the situation, practice makes perfect. I have realized that doing the same thing over can help you see it in different ways, that is why practicing is important no matter what you are doing.

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.

Week 3 (1/31 – 2/6) Learning Reflection Blog

There wasn’t much activity going on this week since our first sprint was over and now we are just waiting for the second sprint to start. I was not in class during the last sprint review and retrospective due to my absence to a religious holiday but from what I have experienced with my group thus far, everything is going fairly smooth. I can’t really say much about the actual lack of work during this first sprint because we are still getting started with everything but I know that future sprints will be far more work-heavy once we start to dive into our portion of the OpenMRS project. For the actual individuals within our group, I think we have a pretty diverse group of students in the sense that there are a lot of different personalities and programming styles so that will definitely come in handy in thinking of creative ways to solve problems.

This next sprint is when we start working on some real programming so I’m really excited for that and I can’t wait for the next sprint review and retrospective because since I wasn’t able to attend the last one, I’m interested to see what its actually like.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Reflection: Week 3

This week we finished our first sprint. We did our first sprint review and sprint retrospective as well. We used various factors such as Attendance, Communication and Cooperation to rate each other’s performance within our group members. 1 point was given for needs improvement, 2 for acceptable, and 3 for excellent. We all received pretty good average on this one, considering there was nothing much heavy to do on our first sprint.

Looking forward for the next sprint.

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

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.