Bowling Game Kata

Today, I have completed the Bowling Game Kata. Below are my notes:

• It took me three three hours to complete.
• I wanted to do this kata because I was interested in learning how scoring of bowling games worked.
• The kata ended up very frustrating, because I had to refactor code extremely often.
• The problem seemed like a great exercise for TDD.
• I was able to see where I was not following DRY principles. It was easy for me to convert non-DRY code to DRY code. I am feeling more confortable with constantly thinking about DRY as I am coding.

P.S. I would have to say that my level of self-awareness of copying code was IV during this kata. Please see what the levels mean in my learning plan.

Simplifying Time Conversion

Recently I refactored some old code with a friend. The functions we were writing allowed us to practice both TDD and DRY. We demonstrated the code to our class yesterday and immediately, many constructive comments were offered. It immediately made me feel that I was back to Level I. However, I would like to share what I learned about the Java String.format() function.

Here is the code my pair programming partner and I came up with for this self-explanatory function:

public static String monthDayYearToString(int month, int day, int year) {

  String monthString = Integer.toString(month);

  String dayString = Integer.toString(day);

  String yearString = Integer.toString(year);

  

  if (month < 10) {

    monthString = "0" + monthString;

  }

    

  if (day < 10) {

    dayString = "0" + dayString;

  }

    

  String formattedDate = monthString + "-" + dayString + "-" + yearString;

  return formattedDate;

}

Here's the refactored code:

public static String monthDayYearToString(int month, int day, int year) {

  return String.format("%02d-%02d-%d", month, day, year);

}

Neat! I wonder, what other tricks could save developers like me from writing unnecessary and potentially copied code?

Weighing with Stones Kata

Today, I have completed the Weighing with Stones Kata. Below are my notes:

• It took me three two and a half hours to complete.
• I first worked out the problem in notepad to find a combination of weights that would satisfy the criteria outlined in the kata.
• I took a brute-force approach to development. However, I saved some execution time by forcing one of the weights to have a value of 1. I believe that my execution time was O(n^3), where n is the weight of the initial stone.

P.S. I would have to say that my level of self-awareness of copying code was III during this kata. Please see what the levels mean in my learning plan.

String Calculator Kata

Today, I have completed the String Calculator Kata. Below are my notes:

• It took me three hours to complete.
• The most time consuming activities involved performing TDD, which the kata description suggested to use, and figuring out how to handle certain regular expressions in Java.
• Java requires escaping the ']' character, but does not allow the use of the '\' character to do so. Instead, one must use the java.util.regex.Pattern class. This was a necessity for handling both long and multiple delimiters.
• I was able to DRY up some use cases, while keeping them DAMP.
• I had trouble employing DRY principles when writing the add() function. It was very unnatural to have to use multiple methods of dealing with regular expressions.

P.S. I would have to say that my level of self-awareness of copying code was III during this kata. Please see what the levels mean in my learning plan.

Coin Change Kata

Today, I have completed the Coin Change Kata. Below are my notes:

• It took me three and a half hours to complete.
• I realized that using a greedy algorithm was not best, as choosing the largest possible coin denomination would only work for US coin denominations, but not necessarily others.
• It was fun, yet frustrating, to revisit dynamic programming. The last time I wrote a program using dynamic programming was in an algorithms course in my undergraduate university.
• The way I wrote the code was not modular enough to use TDD to solve the problem. Thus, I had to perform a lot of debugging by manually going through the code line by line. The double for loop did not help. Manual testing was very frustrating and took much longer than I expected.  If I were to redo the kata, I would perhaps write helper functions that could be tested individually.

P.S. I would have to say that my level of self-awareness of copying code was III during this kata. Please see what the levels mean in my learning plan.

"Crappy Code is Other People's Code"

An ex-CMU-SV student posted a video presentation by Google's Alberto Savoia in CMU-SV's Facebook group. In the presentation, Mr. Savoia speaks about writing "less crappy code". I found watching the short 49-minute video very informative and entertaining.

Mars Rover Kata

Today, I have completed the Mars Rover Kata. Below are my notes:

• It took me about two hours to complete. The kata was not overly difficult by itself. However, it may be difficult depending on one's learning focus.
• I took a very object-oriented approach to the problem. I wrote separate classes for the rover, grid, and location points.
• I am not sure whether I followed DRY principles correctly. I would like to find someone to review my code. If you are interested in helping me out, please send me an e-mail. Alternatively, you could practice writing test cases to see whether my code will pass them. I have only written one test case, because my learning focus is not TDD.
• I would like to find a program that could detect duplicate code and point it out to me. If anyone is aware of such a program, feel free to shoot me an e-mail. :)

P.S. I would have to say that my level of self-awareness of copying code was stuck somewhere between II and III during this kata. Please see what the levels mean in my learning plan.

Tracking Copy History in Windows

One of my DRY learning activities involves monitoring when I copy/paste code. Unfortunately, I cannot track this manually, because I may subconsciously copy/paste code without realizing that I should record when I have done so. Thus, I have decided to look for a piece of software that can do it for me. CyberMatrix Clipboard Magic seems to be good enough. It allows tracking when copying has occurred, and even provides an option to play a sound. The sound can remind me to reflect upon the reasons that I am copy/pasting code.

Completing the Potter Kata

Today, I have completed my first attempt at the Potter Kata. Please see a previous post for more details. Below are my notes:

• It was nice to not have to concentrate on TDD. I was able to focus on keeping my code DRY.
• I have found the com.google.common.collect.Lists package, which has several useful list operations.
• I was not able to check whether the last test case passes, because my algorithm is very brute force. It would need to generate 23! permutations of the book list for the last test case, which would take a very long time.

P.S. I would have to say that my level of self-awareness of copying code is III. Please see what the levels mean in my learning plan.

Potter Kata

Today, I have been working on the Potter Kata. Below are my notes:

• I was not able to complete the kata because I did not allocate enough time to it today.
• I have created a nice regular expression for currency using this regular expression tester. The regular expression encompasses strings such as $0.00, $0.37, $1.42, and $12313.99. However, it  does not cover $00.00, $00.0, and a few others, just as I intended. I have used this source to come up with the exact regex I was looking for:

\$(([1-9]{1}[0-9]*)|([0-9]))\.[0-9]{2}

• The following two lines of Java code can print a double in the above format. It requires an import of the java.text.DecimalFormat package.

DecimalFormat df = new DecimalFormat("#.##");

System.out.printf("$%.2f\n", Double.valueOf(df.format(13.37)));
// Output: $13.37

• I will complete the kata in the next few days.

Reinventing Time

Today, I pair programmed with a classmate of mine. His goal was improving his TDD skills. I found some old code dealing with conversion between string and date objects that was in dire need of refactoring. We first cleared out all of the code from the existing functions. My partner then wrote test cases one by one and I wrote code to make them pass. Here are a few of the things I learned:

• Converting 24-hour time to 12-hour time is fairly easy with the help of a mod (%) operation
• assertArrayEquals, not assertEquals, should be used for comparing arrays in JUnit (duh?)
• SimpleDateFormat is a pretty useful class for simply formatting dates
• Properly utilized regular expressions to split a string with multiple delimiters ("|", OR, is a useful regex character)

P.S. I would have to say that my level of self-awareness of copying code is II. Please see what the levels mean in my learning plan.

A Brand New Approach to the Gilded Rose Kata

Today, I have completed the Gilded Rose Kata for the third and final time. Below are my notes:

• Instead of focusing on TDD, I decided to use a test suite from my previous attempt at the kata.
• I refactored the updateQuality() method to simply iterate through the item list apply rules to the items, if there are any.
• The rules have been changed to be stored in a HashMap. Whenever I wanted to apply rules to an item, I could simply access the item's list of rules by using the item's name as a key.
• Each rule consists of a sellIn point, a qualityChange amount, and a sellInChange amount.
• I decided that no rule would cancel out another rule, unless it is explicitly told to do so.
• Refactoring the updateQuality() method while having the test cases in place was fun!

To revisit my notes for my previous attempts at the Gilded Rose Kate, please visit these previous blog entries: 1, 2.

P.S. I would have to say that my level of self-awareness of copying code is II. Please see what the levels mean in my learning plan.

A Revisit of the Gilded Rose Kata

Today, I have completed the Gilded Rose Kata for the second time. Below are my notes:

• I attempted to find the perfect balance between DAMP and DRY principles when writing the test cases. This balance allowed me to avoid writing repetitive code, while keeping the test cases easy to read. I went ahead with descriptive test case function headers, but kept the bodies of the test functions simple.
• This time, I assumed that the code that has been written should be left alone and unaltered. If the case was otherwise, the customer would have asked for bug fixes in addition to the implementation of the update.
• When I revisit the kata in the future, I plan to refactor the updateQuality() method in order to gain benefits outside of learning TDD principles.

To revisit my notes for my first attempt at the Gilded Rose Kate, please visit a previous blog entry.

P.S. I would have to say that my level of self-awareness of copying code is II. Please see what the levels mean in my learning plan.

Literature on DRY

I have spent a part of today looking for resources that speak about DRY principles. Of course, the first thing I stumbled upon was the Wikipedia article on DRY. It mentioned that Andy Hunt and Dave Thomas spoke of DRY in their book, The Pragmatic Programmer. The book has wonderful reviews on Amazon, and thus, I may have to find a copy of it to read. I have also found my copy of Steve McConnell's Code Complete 2. I am hoping that the book will have some information about copying code and code reuse. The index suggests that it has a section dedicated to the DRY principle:

DRY Learning Plan

I would like to submit my learning plan for the Craft of Software Development course. This is something that I have been working on over the last two weeks.

Main Goal:

Ø  I would like to become accustomed to the “Do not Repeat Yourself” (DRY) principle of software development.

Sub-Goals and Their Learning Activities:

A.      Learn about the benefits of not repeating oneself with respect to software development.

                         1.      Research and read articles that speak positively and negatively about DRY principles.

                         2.      Determine whether not following DRY principles would be beneficial in some cases.

B.      Gain experience in distinguishing code that follows DRY principles from code that does not.

                         1.      Submit my previously written code to (a) Java programmer(s) for peer review.

                         2.      Discuss which areas of the code follow DRY principles and which do not.

                         3.      Discuss whether or not it was just to not follow DRY principles in each particular case.

                         4.      Use code-checking tools to determine whether I have been repeating myself.

                         5.      Compare code where I have not been repeating myself to code where I have.

                         6.      Compare the mindset that I was in when writing code in both of these cases.

C.      Learn how to convert code that does not follow DRY principles into code that does.

                         1.      Check my old projects for instances of failing to follow DRY principles.

                         2.      Convert the code to follow DRY principles.

                         3.      Find code that was meant to self a similar problem and see how it followed DRY.

                         4.      Find code that does not follow DRY principles and fix it to follow them.

                         5.      Use sources such as GitHub, Stack Overflow, and others in order to find such code.

                         6.      Use code-checking tools may be helpful in to find repeating code.

                         7.      Convert the repeating code to follow DRY principles.

                         8.      Ask Java experts or make a detailed post on Stack Overflow if I run into problems.

D.      Understand and get into the mindset of writing code that follows DRY principles from scratch.

                         1.      Engage in pair programming with a programmer who is familiar with Java.

                         2.      Discuss with my partner why employing DRY principles would be beneficial.

                         3.      Keep DRY principles in mind whenever writing code in the future.

                         4.      Record whenever I hit copy paste and what the purpose of it is.

                         5.      Record other applicable metrics and monitor my progress over time.

                         6.      Keep “DAMP not DRY” in mind when writing test cases.

Metrics for Tracking Progress:

1.       Number of instances of copy-pasted code per one hundred lines of code (hloc).

2.       Number of instances of repeated code found using code-checking tools per hloc.

3.       Number of instances of repeated code found by a peer per hloc compared to the tools.

4.       Level of self-awareness of copying code.

                           i.      Level I – I am unaware that I am copying code.

                          ii.      Level II – I am aware that I am copying code.

                         iii.      Level III – I am able to understand why copying code is problematic in a given case.

                         iv.      Level IV – I am to convert duplicate code to follow DRY principles.

                          v.      Level V – I am able to teach others how to refactor their code to follow DRY principles.

Applicable Apprenticeship Patterns:

1.       Finding a coach – I must find a mentor who is familiar with DRY principles who can guide me.

2.       Practice – I must consciously practice using DRY principles while coding.

3.       Exposing ignorance – I must realize my weaknesses with respect to not following DRY principles.

4.       Sharing while learning – I should keep track of my progress and discuss it with others.

5.       Kindred spirits – I should discuss potential solutions with individuals who have similar problems.

6.       Breakable toys – I should first practice outside of my real work prior to applying what I learned.