Android Room Manager

During my year as a Graduate Assistant at Carnegie Mellon University, Silicon Valley, I worked on an Android tablet application, Android Room Manager, which allowed students and staff to quickly reserve meeting rooms at the university. This post contains some screenshots from the application, which can be seen running on Android 3.0 (Honeycomb). I will make future posts outlining how the app was developed completely from scratch.

WordLord - Now Available!

Project WordLord

WordLord: Guess the Word - Become a Lord!

WordLord is a party word-guessing game for 4+ players.

Download the free demo here:

Download the full version here:

Download from Amazon Appstore here.

Smartphone Development - Week 12 - Project WordLord

My plan for the future:

• The game's initial reception did not go as expected. There has been under 10 downloads of the demo version and just 1 download of the paid version. My goal was to make back the Google Play store publisher fee of $25. Hopefully, the application will help me to achieve this goal in the long run.
• I would like to implement different game modes and include additional features.
• I would like to create a website for WordLord where users can share custom word lists. The word lists can be upvoted or downvoted, with the most popular lists displayed first. The website would allow users of the full version of WordLord to easily find word lists to expand the game with.
• I would like to collect more feedback from the user base. Perhaps this would explain why the game's launch was not as successful as anticipated.
• I would like to advertise the application on more websites and perhaps on campus of my university.
• Should the paid version fail, I will release an ad-supported version.

I have made a new video to showcase WordLord. It is shorter than the old one. The video is available here: http://www.youtube.com/watch?v=AMPFWh5VJ_E

WordLord is now available on the Amazon Appstore: http://www.amazon.com/Borys-Boyko-WordLord/dp/B008QTR0IW

Smartphone Development - Week 11 - Project WordLord

This week, I have published WordLord to the Google Play Store.

Free Demo:

https://play.google.com/store/apps/details?id=edu.cmu.sv.bboyko.wordlord_demo

Full Version ($1.99):

https://play.google.com/store/apps/details?id=edu.cmu.sv.bboyko.wordlord

I have also made a couple of posts on Reddit:

http://www.reddit.com/r/gaming/comments/xgpwd/finally_released_my_first_android_application_a/

http://www.reddit.com/r/Android/comments/rdfdn/megapost_of_all_apps_created_by_randroid/c5m9jir

I have modified the user interface to scale for any screen resolution. This way, the game can be played on all types of Android devices that support landscape mode.

Screenshot of WordLord on a 10.1" tablet running Android Honeycomb 3.2.1:

Screenshot of WordLord on a 4.3" phone running Android Gingerbread 2.3.3:

Supporting various devices increases the market for the application.

Smartphone Development - Week 10 - Project WordLord

This week, I continued styling the application. The new options screen can be seen below:

Smartphone Development - Week 9 - Project WordLord

This week, I have created an icon for my application:

I have also created a new user interface:

I will now discuss several items:

1. Motivation behind the name
1. Not taken
2. Rolls off the tongue
3. Fewer than 10 characters in length
4. States that the game is about words
5. Sets up the theme for the game
6. Domain name available
2. Righteous feature set
1. Simple and attractive user interface
2. Automatic scoring
3. Plenty of options
1. Round timer
2. Score limit
3. Skip counter
4. Sound and vibration
5. Shake gesture recognition
3. Ways to get to market
1. Release on Google Play Store and Amazon Appstore
1. Advertise on www.reddit.com
2. Advertise by word of mouth
3. Create a website
4. Add support for tablets
5. Free ad-supported version
2. Sell rights to a game/toy manufacturer
1. Manufacturer handles advertising
4. Market analysis
1. Over 200 million Android devices are active
2. Amazon Appstore users more likely to pay for apps
1. Influence by Kindle Fire users
3. Games dominate top-purchased lists
4. Over 5,000 purchases of similar apps at $1.99 and over
1. True numbers are not publically available
5. Over 100,000 downloads of similar apps
5. Value of market testing
1. Tested within my own demographic
2. Could be beneficial to test within other demographics
3. Would like to learn which word categories are most desired
6. What I need to know
1. How to style PreferenceActivity
2. How to style AlertDialog
3. How to release on Google Play Store
4. How to release on Amazon Appstore
5. How to go about contacting game manufacturers to see whether they would like to purchase the rights to the application

Smartphone Development - Week 8 - Project WordLord

I have added the ability to play with custom word lists within WordLord. Users can simply deposit lists of words to the <external storage>/WordLord/ directory on their Android device and play with any words or phrases that they would like. The desired word lists can be selected when a game is started:

I have also added the ability for the developer (me) to easily add additional word lists to the game's .APK file. These word lists can be released in future updates of the game.

Next, I have done some some research on user interfaces of games similar to Hasbro Inc.'s Electronic Catch Phrase ™. Below are some screenshots:

The original game

PhoneFraze (11,000 - 55,000 downloads, including 1,000 - 5,000 paid downloads at $3.99)

Phrase Party! (51,000 - 105,000 downloads, including 1,000 - 5,000 paid downloads at $1.99)

Buzzword Frenzy (unknown amount of downloads)

Out of all the games, the latter (Buzzword Frenzy) seems to have the best user interface. However, Buzzword Frenzy is an iPhone game. I would like to mimic its sleekness in my application, perhaps in a simpler way. I believe that I can use 9-patch PNG images in order to create the sleek interface that elegantly frames its elements. Thus, I will have to perform some research in this area. I also enjoyed the game's website, http://www.buzzwordfrenzy.com. Should I make a website for WordLord, I can refer to Buzzword Frenzy's page for inspiration.

Sources for UI images:

https://play.google.com/store/apps/details?id=com.dev.games.ipartylite&hl=en

https://play.google.com/store/apps/details?id=theandroidworks.apps.PhoneFrazeLite&hl=en

http://www.buzzwordfrenzy.com/

http://www.gamenightapproved.com/game.aspx?gameid=6

Below are some notes I took regarding the UI topic for WordLord:

• What is an appropriate frame for UI?
• Metal, wood, desk-like?
• Frills?
• Simple?
• Should the game have a shadow?
• Paper that's tearing?
• Font choice for current word - is there anything better?
• Timer - put in frame?
• Application name - how to make it cool looking?
• Celebrate the current word

I have set a goal that I would like to achieve by the end of the Smartphone Development II class - place WordLord on the Google Play store. I plan to charge $1.99 for the full version of the game. I may create a demo with a word list of around 900 words. I believe that WordLord has a nice set of features and options that differentiates it from the currently available Catch-Phrase-like games. For example, no game uses the device's sensors to accept the shake gesture and no game keeps score automatically.

I should not run into any copyright-related problems. According to FL-108, "copyright does not protect the idea for a game, its name or title, or the method or methods for playing it. Nor does copyright protect any idea, system, method, device, or trademark material involved in developing, merchandising, or playing a game."

Research - not much of it exists on the topic of word guessing games. I do not believe that research of papers dealing with word guessing games will affect the outcome of my project. It would be more useful for me to have groups of people try each of the Catch-Phrase-like applications, including WordLord, and tell me what they like or dislike about them. This sort of feedback can help me differentiate my application in a positive manner and create a successful game that many want to play.

Smartphone Development - Week 7 - Project WordLord

This week I have implemented the full options list for the application. All of the options are now fully functional. I have asked seven of my friends to play-test the application. They have found a few issues. One issue is that the user interface is not as nice as it could be for a game of this caliber. Another is that the timer is sometimes buggy when the application is paused.

After fixing the bugs, I will implement custom word lists. Once this is complete, I will be able to finish the application by reworking the user interface.

Smartphone Development - Week 6 - Project WordLord

This week, I tested WordLord with my team from a different course. The feedback has been positive. We found several bugs for me to fix. I have also created a demo video for WordLord and posted it on YouTube. It is available here: http://www.youtube.com/watch?v=dnw-sPYOXEM

I am going to keep the application in its current state for the rest of the week. Remaining and additional features will be added in the second Smartphone Development course.

EDIT: I have tested the WordLord application on a tablet device running Android Honeycomb (v. 3.2). The game looked and worked just fine. I may need to work on a better layout for tablets in the future.

EDIT 2: I have enabled all of the options currently present in the game. I now have to add the ability to edit team scores, as well as add functionality for customizing word lists.

Smartphone Development - Week 5 - Project WordLord

The basic part of WordLord is now complete. My next goal is to work on the options of the application, which will differentiate it from its competitors. A screenshot of the application in its current state appears below:

Smartphone Development - Week 4 - Project WordLord

I have added a few features to WordLord, including one that pauses the game if the home button is pressed, or if a phone call is received. The game can be resumed from the same point. I have also found a review of a competitor's application, PhoneFraze. My long-run goal is to make my application have more/better features than PhoneFraze, as well as create a sleeker user interface. 

EDIT: I am now around 60% done with the user interface. I will spend the rest of the week working on it, as well as adding options and features to the game.

Smartphone Development - Week 3 - Project WordLord

I have decided to go with the word game idea and came up with a name for the application - WordLord. I have come up with a basic UI layout, as well as a state machine. These items will be used as reference while coding the application. Speaking of coding, the development of the application is in full swing. The game is now "playable" - no words are generated, but a placeholder function serves a different word every time the button "Next" is pressed, or the device is shook. My next step is to work on the dictionary and the game options.

EDIT: I have now completed the first version of the dictionary. In order to randomize the words, I made two lists. When a word is served, it is moved to the second list. When the first list runs out of words, the words from the second list get moved back to the first. The index of the chosen word is randomly generated. Every time the list is traveled through, the order of the words will change. Thus, the same word should not pop up often. The dictionary currently contains over 900 words, which should satisfy a play session of over an hour.

Smartphone Development

I have recently enrolled in an introductory smartphone development course at my university. From this point on, the blog will focus on my progress within the course. The professor required me to come up with several ideas for android applications.  Below are my ideas.

Catchphrase-like Game with a Custom Dictionary

1. Purpose: create a game similar to Catchphrase. The game will have a settings mode that would allow users to add their own words and phrases to the dictionary that will be used by the game.
2. Market analysis: PhoneFraze is an application that has a similar goal. However, there are several issues with it. For example, users complain that it repeats the same words within a round of play - something that should never happen in such a game. Should I make the application, I would allow the word list to be expanded, so that users do not have to keep playing with the same set of words.
3. Initial development plan:
1. Create a simple UI layout with all of the elements required for the game
2. Determine which data structure would be best for storing the dictionary
3. Determine how to randomly pick a word
4. Determine how to keep score
5. Implement a countdown timer
6. Implement a buzzer mode (to be used on others' phones in the case that the player states one of the words that they are having their teammates guess)
7. Improve the UI

Effort Log Editor for My University

1. Purpose: allow a user to log into the university account and edit effort logs on a smartphone within a visually appealing interface.
2. Market analysis: no such application exists - students currently must use a mobile browser in order to access the sluggish effort log interface. A mobile application would be useful to any student with an Android phone at the university.
3. Initial development plan:
1. Find out whether the application is viable (need to see whether can log into university accounts using Android account manager; need to see whether can get access to the university's website) 
2. If the application is found to be viable, work on a visually appealing UI
3. Implement functionality to add courses
4. Implement functionality to select effort types
5. Implement functionality to input effort for logging
6. Implement functionality for viewing previously logged effort from past weeks
7. Implement functionality for adding up the total effort for a particular course, effort type, semester, or school year and displaying the amount to the user

Spreadsheet Editor

1. Purpose: create a simple spreadsheet application for quick data organization and calculations. If there is time, expand the application to allow visual representation of data via graphs.
2. Market analysis: there are many spreadsheet applications available in the Google Play store. However, most of them are intended to work with Excel file formats. Many of the top rated applications cost money. There is a free spreadsheet application, Simple Spreadsheet (free/ads), but users have been reporting lack of functionality, such as the inability to compute 4 or more cells together.
3. Initial development plan:
1. Look for open source spreadsheet calculation code
2. Determine how to use data structures appropriately for storing spreadsheet data
3. Create a visual layout for a spreadsheet application
4. Combine the calculation code with the visual layout
5. Work on advanced functionality, such as adding all values in a given row or column
6. If there is time, add graphing capabilities

Friend Scheduler

1. Purpose: I have had experiences with many instances in which my friends and I agree to meet somewhere at a particular time. Unfortunately, someone always ends up being late because they underestimated how long it will take them to get to our meeting location. I would like to create an application that will tell the users when to head out from their current location to make sure that they arrive at the meeting place just on time.
2. Market analysis: I was able to find a similar application in the Google Play store - saambaa. The application allows users to create events and share them with their friends, as well as get directions to their meeting location. However, it does not provide functionality for telling the users when they should be leaving for the meeting location.
3. Initial development plan:
1. Determine how to obtain the current GPS coordinates of a user's phone
2. Determine how to query the Google Maps API on Android with a start and end address, as well as obtain the time for the quickest route to the address
3. Consider other functionalities that may be included, such as allowing the user to specify additional stops and the time for such stops (e.g., in cases where a person may be offering a ride to a friend)
4. Consider including group text messaging/communication functionality, such that a planned destination on one phone can be sent to the phone's user's chosen contacts

Multi-timer

1. Purpose: allow users to keep track of multiple timers and/or stopwatches at the same time. The timers will be displayed on one page and will turn different colors when the time runs out, so that it is easy for the user to see which of the timers has expired. The timers will be allowed to have a short description label for easy tracking by the user.
2. Market analysis: there are hundreds of applications available on the Play Store that offer the functionality of both stopwatches and timers. However, there does not seem to be an abundance of applications that allow running multiple timers or stopwatches at the same time. A multi-timer application would be very useful to many. It was requested of me by a graduate physics student who would like to use it in his physics lab.
3. Initial development plan:
1. Determine whether it is possible to run multiple timers at the same time in one application
2. Learn how to make a simple timer application
3. Learn how to make a simple stopwatch application
4. Create an application that allows the user to create multiple timers, each of which can be started and stopped independently

I will choose one of the ideas above and work on the chosen project throughout my last semester.

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.

Gilded Rose Kata

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

• I had an instance of not following do not repeat yourself (DRY) principles through copy-pasting because I wanted to see where to add functionality for degrading quality of "Conjured"items. I ended up pulling the duplicate code out into a function.
• I saw a lot of duplicate code within the kata and was wondering whether to refactor or rewrite from scratch. Because I was burned out from using test-driven development (TDD), I decided that I will simply make minor corrections and use DRY for any changes that I make.
• I performed a lot of copy-pasting during TDD, but learned that it is ok to do so: "DAMP not DRY" is the rule for test cases. DAMP stands for "Descriptive And Meaningful Phrases".

The First Leak

I am currently a student at Carnegie Mellon University, Silicon Valley, who is looking forward to obtaining his Master's degree in software engineering. My goal is to extend my knowledge within the field. One way that I am working toward this goal is by taking a seminar course on software craftsmanship in order to get rid of a particular weakness - my inability to follow the "Do not Repeat Yourself" (DRY) principle when writing code.

This blog's purpose is for me to log my progress within the software craftsmanship course, as well as to communicate other topics related to software engineering. I feel that "A Leaky Memory" is an appropriate title for the blog, as my journey will be told, or leaked, from, well, my memory.

If you are interested in learning more about CMU-SV's program, please visit this link.