Monday, April 29, 2013

Posting code in blogger

Alex Gorbatchev created a really awesome syntax highlighter for code. To add it to your blogger:
  1. Click "Template" on your main blogger menu
  2. Click "Edit HTML"
  3. Before "</head>" add the following code
  4. 
    
     
     
     
     
     
     
     
     
     
     
     
     
     
    
    
    Remove all the brush you don't need. Here's a list of all the available brush.
  5. Before "</body>", add the following code

Adding a test post

  1. Create a new post
  2. Click "HTML" on the left hand side to switch to the html view
  3. Enter the following
  4.     /**
         * SyntaxHighlighter
         */
        function foo()
        {
            if (counter <= 10)
                return;
            // it works!
        }
    
  5. Click "Preview" to view the test post
Resource: http://stackoverflow.com/questions/679189/formatting-code-snippets-for-blogging-on-blogger

Ruby: Accessor

Instance variables in Ruby are private by default.
class Book
  def initialize
    @title = "Ender's Game"
    @author = "Orson Scott Card"
    @location = "Chicago"
  end
end

book = Book.new
book.title = "Programming Ruby"
puts (book.title)
If you run the program, you get a no method error.
accessor.rb:10:in `
': undefined method `title=' for # (NoMethodError)

In order to access to the variables, you need to specify what type of access you want to grant. There are three types of access:
  • attr_reader - for read access only
  • attr_writer - for write access only
  • attr_accessor - for read and write access
Let's say you're writing a book. It's the first draft. You are sending it your friends for review. Let's imagine it's pre-email day, so you're sending it through snail mail. You only have one copy (because you're a poor author), so you want to keep track of where it is. So you have a location that others can read or write to. You haven't decided on a title yet, therefore you don't want anyone else to see it. They can change it, but they can't see it. As for the author, because it's your book, this is something that can't be change so others can only read this field. Let's review.

You have a book with the following attributes:
  • Title - write only access
  • Author - read only access
  • Location - read and write
So your class looks something like this:
class Book
  attr_reader :author
  attr_writer :title
  attr_accessor :location
  
  def initialize
    @title = "Ender's Game"
    @author = "Orson Scott Card"
    @location = "Chicago"
  end
end
So what can you do?
book = Book.new

book.title = "Ender's Shadow"

puts(book.author)

puts(book.location) 
book.location = "Philly"
You can do all that, but if you try to read the title or change the author, you will get an error.
put(book.title)

accessor.rb:22:in `
': undefined method `title' for # (NoMethodError) book.author = "Me" accessor.rb:23:in `
': undefined method `author=' for # (NoMethodError)

The really cool thing about all this is that one day, if you decide to collect all the friends ideas for the book title, you can do it, without changing the caller.
class Book
  attr_reader :author, :suggested_titles
  attr_accessor :location
  
  def initialize
    @title = "Ender's Game"
    @author = "Orson Scott Card"
    @location = "Chicago"
    @suggested_titles = []
    @suggested_titles << @title
  end
  
  def title=(title)
    @title = title
    @suggested_titles << @title
  end
end

book = Book.new
book.title = "Ender's Shadow"
puts(book.suggested_titles)
Even though I added def title, I still set the title by typing book.title = "book name". One thing to note is that you can specify more than variables to the attribute by separating them with commas as I did with :author and :suggested_titles.

Sunday, April 28, 2013

Egit: Checking out/in

Checking out


  1. Right click on "Package Explorer" view
  2. Select "Import"
  3. Type "Git" in the search text box
  4. Select "Projects from Git"
  5. Click "Next"
  6. Select "URI"
  7. Paste your git repository in the URI text box 
  8. Verify everything is correct click "Next"
  9. Select the branch you want to check out and click "Next"
  10. Verify the local destination is correct and click "Next"
  11. Wait a minute as it download the project
  12. Select "Import existing projects"
  13. Click "Next"
  14. Click "Finish" and voila, the project is in our workspace!

Checking in


  1. Right click on the project
  2. Select "Team"
  3. Select "Synchronize with workspace"
  4. Select "Yes" if asked to open the Synchronized view
  5. In this page, you can see what has been change. Verify the changes are correct.
  6. Right click on the project
  7. Select "Commit"
  8. Enter a commit message
  9. Click "Commit"
  10. Return to the "Package Explorer" view
  11. Select "Team"
  12. Select "Push to Upstream"
  13. Click "OK" when shown what has been committed
Note1: Will update with pictures once I figure out where the picture editor the a Mac is. 
Note2: I'm currently using the command line to do all the check in check out. But I thought this might be useful for someone who's familiar with Eclipse and is uncomfortable with the command line like I was a few weeks back.

Friday, April 26, 2013

Kata

Kata is an exercise which helps students hone their skills through practice and repetition (Wiki). As an apprentice, I have to perform one kata a week for my mentor, and once a month in front of a larger audience.

It's easy to dismiss this exercise because one is always looking to do bigger and newer things. As a karate student, you're often interest in learning how to do a spin kick or other cool things you see in Kung Fu movies. You probably don't know that if you execute a normal kick perfectly, you can injure your opponent in one shot instead of having to do several poorly spin kicks (which waste energy and time). It's been awhile since I took karate, but if I remember correctly, in order to do a perfect kick, you have to:
  • assess the situation which includes your surrounding and your opponent. (You don't want your foot to land on a banana peel after your kick.)
  • figure out your opponent weak spot.
  • execute the kick from your hip and focus your energy on the kick to create the most impact.
  • prepare for your opponent defense/counter attack.
All of these must be done in less than a second. It took me five minutes to remember the steps. In five minutes, my opponent could have beaten me to a pulp. So can anyone actually do this? Yes, all karate masters do this. The masters do all of these steps naturally, without even thinking because they've spent years and years performing the same kick over and over again. Through repetition, the masters have ingrained these steps into their memory so that it comes naturally. They don't even have to think before they execute.They execute perfectly each time, all the time, with very few exceptions. And whenever they don't perform one of these steps, they'll feel a nudge from their conscience telling them something is wrong. In addition, when they learn a new kick, they can focus on learning the movements because all the other steps are ingrained in their memories.

That is what I hope to achieve in code katas. I want all the good programming practices (e.g. write test first, write good variable names) to be ingrained in me so that it becomes second nature. I should feel a nudge whenever I start writing bad code.

The second part to practicing katas is that you often find new ways of doing things. The first time I did the prime factors kata, I was really slow. I struggled to write the test and write the simplest code to make the test pass. I had to watch Robert Martin do the kata, several times, to see how he came to the solution and try to emulate that.

After practicing the kata for a week, I'm beginning to feel its effect on me. I feel a nudge when I write code without a test. I begin to see what kind of test I should create to make the algorithm better. I still haven't perfected my kata yet, not that there is a perfect solution. Programming is an art, as they said. There is no perfect solution. However, I still haven't arrived at the solution I'm satisfied with. So the goal is to practice a kata a day. And only one kata a week, which means I will be doing the same kata at least five times. And every time I do the kata, I have to think of better way to write it.  

Monday, April 22, 2013

Installing/Uninstalling EGit for Eclipse in Mac

Installing

  1. Select "Help" from the main menu
  2. Select "Install new software" at the bottom of the menu
  3. Enter "http://download.eclipse.org/egit/updates" in the text box "Work with:" next to the add button
  4. Click on the checkbox to select "Eclipse Git Team Provider"
  5. Click "Next" to review the items to install
  6. Click "Next"
  7. Click "I accept the terms of the license agreement" after you read the terms
  8. Click "Finish"
Now you should have EGit install. If the Git Repositories doesn't open, follow these steps:
  1. Select "Window" from the main menu
  2. Select "Show View"
  3. Select "Other"
  4. Type "Git"
  5. Select "Git Repositories"
  6. Now the Git Repositories view should be open

Uninstalling

  1. Select "Eclipse" on the top menu
  2. Select "About Eclipse"
  3. Click the "Installation Details"
  4. Select the plugin you want to uninstall
  5. Restart eclipse

Thursday, April 18, 2013

Constants here, constants there, constants everywhere

As I'm writing Mastermind, I notice I reference the size constant a lot. It feels like it's in every class with logic. It makes it a little hard to test because I can't use my unit test to determine if the class will work if I change the size. What else can I do? Well, I can set the size in game and let the game tell all the other classes what the size is. But that means all the classes would have a reference to game, just to know the size. What's a better way to do this? These are the type of questions I hope I can answer by the end of my apprenticeship or at the least know someone who does.

If you ask why I think something is wrong with constant being reference everywhere? I feel if it's hard to test, I'm probably doing it wrong.

Wednesday, April 17, 2013

To debug or not to debug?

After going over the logistics, Eric Meyer, my mentor, told me to write Mastermind in any language that I choose. Considering I took about a week to write Tic Tac Toe, I thought this was going to be a breeze (I was wrong) so I gave myself the challenge of not using the debugger.

I'm not sure if I read this thought from somewhere or if it's my developer instinct. It is not something that I can concretely express or defend yet, but I feel if I write the code and the unit test well, I should immediately know what's wrong with the code. Thus I should never need a debugger to tell me what my code is doing. So on the first day of writing mastermind, I didn't use the debugger at all.  I like to think I did pretty well. I wrote the majority of the code without running anything through the debugger.

My problem came when I tried to figure out how to indicate the color is correct but the position was not. I spent most of my second and third day on this problem. It shouldn't have been that hard, but it was. Whenever I added new code, my tests were failing left and right. I couldn't figure out why. And the debugger devil kept whispering how easy it would be to solved the problem with the debugger. I resisted at first, but by 3PM my mind was too exhausted to fight so I gave up and used the debugger, "just to see why this test case is failing" I said. Well one thing led to another and the next thing I know, I couldn't stop running my app in debug mode.

I admit that was a total fail. I still have that mentality of getting things done. I forgot that I came here to learn, that I should do what I think is a better solution, especially when I don't have a deadline (yet). I should be patience and not rush through anything. What I should have done on day two was look at my tests again, then think, can I really trust my code? Can I really trust my tests? Did I test it well enough that I can confidently say every part of my app work and if there is a problem, I know where it is? The answer of course is no. My code and tests were messy.

I used to write unit tests to test my method. But when I went to a TDD class, the teacher said that I should focus on testing the application's behaviors. It made sense. As outsider, you just want to know if the code works. You shouldn't care about the implementation. So when I wrote my test, I test only public methods. Unfortunately, I don't think this is is working out well. Because I'm testing the class API, I can't guarantee that a certain protected method in the class work. So when I come across a problem like the one I encountered today, I didn't know how to solve it. This could be an indication that I didn't write my code well. That is probably what Eric will say when he sees the code. In fact, he probably won't say well. He'll probably say, this is bad. Do it again.