Be Privileged And Skip JavaScript's Prototype

Reading Pro JavaScript's second chapter "Object-Oriented JavaScript" reminded me that I do not use the prototype property to add public methods to a JavaScript object. I use "Privileged Methods" (pg 36) instead.

In the book, John refers to Douglas Crockford's JavaScript site and the Privileged technique described in the web page titled Private Members in JavaScript. I quote from the web page:

"A privileged method is able to access the private variables and methods, and is itself accessible to the public methods and the outside."

If you are looking for more code examples beyond what Douglas Crockford provides, Quizzpot shows more code examples at Private and privileged methods in JavaScript

Using Privileged Methods is a great technique when coding JavaScript objects. Have fun doing it.

JavaScript, TDD, JQuery

In the area of Ajax and JavaScript, the rate of change has increased where I work. I believe this is reflective of the industry in general.

Since there is so much for one to look at, people will want to focus on those things which are essential.

Items of immediate interest are (in no particular order):

• Object Oriented JavaScript Best Practices
• TDDing JavaScript
• JQuery
• JsTestDriver and its eclipse plugin

James Carr and I had fun integrating Hudson with JsTestDriver. It's a good step towards TDDing JavaScript.

Here's to the future

:)

Corey Haines and Code Katas

Surrounded by the smell of burnt popcorn and listening to the video Road Thoughts - Practice : 'Doing it right' vs 'Getting it done' really drove home some thoughts.

Do Katas. Do the same problems over and over again. Apply different techniques and approaches. Some quotes from the video:

• "don't wait for those things to be ingrained..." over time.
• Practice. "1 hour a day; as much as you can."
• "Write small problems or solutions to a problem."

Practicing is essential. Practicing effectively is the goal. Practicing efficiently is a challenge.

For a Refactoring kata, what may work for you is setting up some code that needs to be refactored along with the needed JUnit Tests. Once at a satisfactory level of refactoring, you can blow away the refactored solution and refactor again from the start. Where to store such an exercise or Refactoring starting point?

I have given some thought to creating a Java project using Google's Project Hosting that contains things to practice on. I could apply the following labels to the project; label:Java label:kata. There are a couple projects in there now with those labels. I even see a "java-katas" project, but it is currently void of code.

Another thing to think about is practicing with a framework such as Struts2. Perhaps another project could be created which has the labels of Java, kata, struts2.

If Maven 2 is gaining enough popularity, maybe an even better solution is to create Maven archetypes which contain everything you need to practice particular things. Imagine creating a temporary project that is based off a starter template/archetype. Everything you need is downloaded automatically and you're ready to practice.

Well, good luck to you in your quest to practice. Time for me to practice and eat more carefully prepared popcorn.

Update! (March 15, 2009) -  http://code.google.com/p/funkata/ now exists.

Wrapping 3rd Party Code Is Clean Code Crafty

The Clean Code book by Robert C. Martin has great points about system boundaries. In chapter 8 titled Boundaries and in the section called Using Third-Party Code, the book shares why and how to wrap 3rd party code.

Points For Why To Wrap Third Party Code (page 115):

1. The third party code can evolve
2. Your wrapper's interface can be made to precisely suit your application's needs

Like the book says on page 115, "If you use a boundary interface like Map, keep it inside the class, or close family of classes, where it is used."

That's huge! I also like the "Sensors" class example which has a method that will give you a "Sensor" class. Sensors giving you a Sensor, implies a naming rule-of-thumb which I also like.

Pair Programming - Pair Share Feedback

I discovered that the most satisfying pair programming experience is when the following cycle happens:

1. Pair
2. Share
3. Feedback

Pair - You do the work. You Pair Program.

Share - I share or my partner shares knowledge. Beyond sharing while pairing, this can be additional followup information. Most recently, this was in the form of a follow up email from me with resources.

Feedback - Feedback on the knowledge and the pair programming experience itself is exchanged.

Pair, Share, Feedback. Yes!

Coding Dojo Outcome

Two Coding Dojos were cofacilitated by Ryan and myself.

The Dojos were:

1. Great fun and exciting too
2. An excellent opportunity for those who are shy; You're in front of an audience coding.
3. Best when the story / CodeKata was small, focused, and simple to work on
4. Better when the JUnit red bar indicated that the audience should not talk

Styles of writing code and tests were shared on the fly. New tricks were discovered.

In all, it was awesome!

Code Kata Quest for a Coding Dojo

In my quest to find Code Katas for an upcoming Coding Dojo at work, I searched quite a while for something suitable for our needs.

Dave Thomas' Back to the CheckOut at http://codekata.pragprog.com/ is good. The others there did not seem to exactly fit what we want right now. Either they were

• too academic (often single function solutions)
• the ramp up in explaining the problem was too high
  
• or there was no coding involved in solving the Kata

The other Code Katas of Dave's may be exactly what others are looking for.


Perhaps if the Klondike one at http://codekata.pragprog.com/2007/01/kata_twenty_klo.html was sectioned into several exercises, the ramp up of explaining the Kata would be manageable.

Looking elsewhere, I see http://www.codingdojo.org has a KataCatalogue. Nothing there that seemed to fit as of this writing (August 17, 2008).

In the future, looking at something like Head First books may be promising.