New Blog Location

Hi,

My new blog location is at http://smilingfinney.blogspot.com/ 

All the posts have been imported. So, come on over !  :)

People Who Care And Share

Thankful*
Originally uploaded by zenera
It's wonderful that people care enough to share. People care about the gifts they have and share the fruits of their gift with the world.

From the software world, this can lead to books such as Clean Code by Uncle Bob Martin. From Flickr, it can be zenera who posts wonderful photos and shares them freely.

Thank you all. I am grateful.

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.

Next Language Making Language?

The question is not “What’s the next language?” The question is “What is the next language making language?”

The answer: It will be a language that comes downloaded with out of the box sensible examples so you can use what is given to you right away. Yet, the language itself will easily support the creation of domain specific languages (DSL).

A search for "domain specific languages" in google results in definitions of DSL and languages that can be used for making DSLs. The results are interesting!

Clearly, the demand for new languages is always there. Trying to model something new using an old programming language is sometimes like eating yesterday's breakfast.

Wanting to write in a way which is powerful yet expressive and clear is the foundation for new languages. Demanding a language which supports your domain and how you want to express yourself will always exist!

So, keep your eyes open. Explore. Share the results!

Social Web And Window Shopping

Social web. What do you think that means?

Imagine walking down the sidewalk. You stop at the big display window for a store. You're looking at this really cool item being displayed. Near you, there are a few people there looking too. You strike up a quick conversation with the person next to you. You and she share insights and then walk on; both a little wiser and happier. The shopping experience is much more enjoyable and memorable.

This same social experience can be had on the web. See the video:

System Metaphor Gold

A good System Metaphor is a golden thing to have. It's the theme that ties everything and everyone together. In an existing system with a great System Metaphor, one can find anticipated concepts reflected in the code easier. A System Metaphor is also a fantastic communication bridge between the Customer and Developers.

The System Metaphor article by William Wake explains what a System Metaphor is. I suggest going beyond the article and checking out his book titled Extreme Programming Explored to see the "More Examples" section provided in chapter 6.

Examples of System Metaphor and discussions about System Metaphors have been going on for at least 8 years. At http://c2.com/cgi/wiki?SystemMetaphor, people such as AlistairCockburn and MichaelFeathers have debated on how to make System Metaphor work best. Interestingly, Martin Fowler stated in his XP 2002 Conference article "...I don't worry too much about metaphor when working with XP...." Has he changed his mind since then?

A thought currently in my head is what to do about System Metaphor Disharmony. If an existing system lacks a System Metaphor that we can recognize, a System Metaphor conceptual rehashing is necessary. Adding communicative new code and cleaning up old code is just easier with a System Metaphor.

So, go forward! Find those System Metaphors! Go for the Gold! :)

Testing an Annotation

I found neat ways to test annotations.

Here is some annotation test code using JUnit

public class LongParameterListRefactoringTest {

 @Test
 public void isAnnotationWhenAsked() throws Exception {
  assertTrue(LongParameterListRefactoring.class.isAnnotation());
 }

 @Test
 public void annotationIsAnnotated() throws Exception {
  assertTrue(LongParameterListRefactoring.class.getAnnotations().length > 0);
 }

 @Test
 public void isAnnotatedWithRetentionAnnotation() throws Exception {
  Annotation annotation = LongParameterListRefactoring.class.getAnnotations()[0];
  assertTrue(annotation instanceof Retention);
 }

 @Test
 public void isAnnotatedAsSourceCodeAnnotation() throws Exception {
  Annotation annotation = LongParameterListRefactoring.class.getAnnotations()[0];
  Retention retention = (Retention)annotation;
  assertEquals(RetentionPolicy.SOURCE, retention.value());
 }

}

This code lived at the SeePeople project.

Note: annotationIsAnnotated has since been changed. Can you guess why?

Yes, Smile and Repeat Yourself

If you care enough about something, you will repeat yourself. That's a good thing.

"I love you!", I said to my wife this morning. I said it yesterday. I've said it for over a decade. I never grow tired of it. I care about my wife and that miracle we call love.

Writing great code is important! Creating things of value is important! Being someone of value is important! Communication, Simplicity, Feedback, Courage, and Respect are all important values.

If I am asked the same question repeatedly, I am happy to answer someone who sincerely seeks knowledge and wisdom.

Human communication often requires things to be repeated. It may take 10 times! I saw this in a training class I just took. The same question was asked 2 minutes after the answer was already given. The trainer, Brian Button, calmly responded with a smile and gave the same answer.

That's the way to go! Smile, support communication, and move on.

XP Principles Support You - Kent Beck Again

I read and heard something extremely powerful which led me to share with you this link to the Implementation Patterns book interview with Kent Beck: http://www.infoq.com/interviews/beck-implementation-patterns. I wish to share with you one small sliver of insight said in this very inspirational and insightful interview.

In response to "XP is ...practice oriented.........patterns and XP and how they work together?", Kent Beck goes way beyond the question and shares beautiful Agile insights. Here is one insight:

He reminds us there are 3 things to consider with Agile Development; values, principles, and practices. He talks about being Agile and not just doing Agile practices.

In answer to a statement such as "XP was made for the people and not the other way around", I hope you and I remember that that is why Extreme Programming (XP) Principles are published too. They are in the XP white book and are listed in Martin Fowler's Bliki.

When a practice is not working for us in a particular context, Extreme Programming Principles are what we can retreat to. Sitting on our XP principles, we can figure out how to tweak a practice, replace a practice, drop a practice, or add a practice as we need to.

In that Implementation Patterns book interview mentioned above, Kent does a great job of telling us how we should step back and examine a practice in light of a principle. It's said in that interview, it's said in Martin Fowler's Bliki post ( http://martinfowler.com/bliki/PrinciplesOfXP.html ), and it is repeated here.

Hopefully, you and I will remember.

Fluent Interfaces, Domain Specific Languages, OO Roots

I see industry backing for Fluent Interfaces. It is in more places than you may know. In my opinion, all people in the software industry will want to know what Fluent Interfaces are, where they are used, and how they fit into the canvas of what they care about.

What are Fluent Interfaces? Fluent Interfaces is an API style that empowers the user of the API to programatically express something in a natural and easy to read way. Martin Fowler describes Fluent Interfaces well. See http://martinfowler.com/bliki/FluentInterface.html

Steve Asher explores Fluent Interfaces in-depth from the user and designer point of view at his Build Without Boundaries blog at http://buildwithoutboundaries.blogspot.com. Search for Fluent API.

Having Martin Fowler support Fluent Interfaces is huge. I also see Fluent Interfaces as the bridge towards Domain Specific Languages (DSL). Are DSLs a possibility in mainstream software development?

Kent wrote in a JavaRanch post that there is a transition from OO languages to DSLs (Domain Specific Languages). What a powerful statement! Is it true? What's the sticking power to Fluid Interfaces and DSLs?

The Object Oriented (OO) approach to programming caught on because it feels natural. We play with objects in life. We speak about them within the context of a domain. The customers speak from within their domain perspective. The easier the trip between the problem domain concepts and reflecting those concepts in code the better.

Who's presenting their API / functionality via a Fluent Interface? Thanks to Steve Asher, I now know JUnit has begun that journey. See http://junit.sourceforge.net/doc/ReleaseNotes4.4.html where the assertThat(...) example is given. JMock uses a fluid interface too. See http://jmock.org/expectations.html If you search for "new Expectations" twice you will see examples of a Fluid Interface in action. It is used also where I work at CARFAX. Again, I refer you to the Build Without Boundaries blog.

Similar to the time when people implemented Object Oriented concepts via languages like C and Ada, we will see people using Fluid Interfaces and other approaches with existing languages. The benefits are likely to outweigh most difficulties and challenges.

The next step for DSLs and Fluid Interfaces will be stronger support and perhaps new languages entirely. Will the fashion of Fluid Interfaces and DSLs hold? Time will tell.

xUnit Patterns and the Mid-Missouri XP Meeting

The Mid-Missouri XP (Extreme Programming) group meeting last night was quite enjoyable. James Carr led the meeting. James Carr's great experience with test frameworks and Software Development in general really showed through in a positive light.

We dove right into Gerard Meszaros' XUnit Test Patterns site at http://xunitpatterns.com/ and specifically http://xunitpatterns.com/Test%20Double.html. We covered Test Stub, Test Spy, Mock Object, Fake Object, and much more.

I put forth the questions: What are the essential Test Patterns? Where is the UML Distilled version of Test Patterns? The answer was Fake Object and Test Stub will get you to where you want to be 95% of the time.

There was much discussion too. The people who attended had dived into various things and were just great people too. We swapped stories of experience and various technologies that we have explored. Since many people there used Java, one great example of a test framework that was mentioned is JMock.

(You can hook up with what the Mid-Missouri XP group is doing at http://tech.groups.yahoo.com/group/mid_mo_xp/ : In the group, there is a post about the meeting from James Carr )

Check My Pulse Via The Plaxo Pulse Lifestream Widget

To add the Plaxo Pulse Lifestream Widget to your blog that is located on blogger.com:

• Go to http://www.blogger.com
• Sign in (log into) your account
• Click the "Layout" link of the blog you want to add the Plaxo Pulse Widget to
• If not already active/selected, click on the "Template" tab
  
• If not already active/selected, click on "Page Elements" sub-tab
• You should be at the "Add and Arrange Page Elements" screen
  
• Copy the HTML you got from activating your Plaxo Pulse Widget (Need the HTML? go to http://pulse.plaxo.com/pulse , (sign in) and click on 'Create a "lifestream" widget' Follow the directions.)
• Again on the "Add and Arrange Page Elements" screen, click "Add a Page Element" link - located on the right hand of the screen
• A window pops up with "Choose a New Page Element" at the top
  
• Click the "ADD TO BLOG" button on the page in the "HTML/JavaScript" section
  
• You'll see a screen which says "Title" and "Content".
  
• Paste the HTML into the "Content" section
• Go back up to where it says "Title" and give this widget a title. Mine is "My Plaxo Pulse"
• Hit the "SAVE CHANGES" button.
  
• See the "Page element added" text now at the top of your blogger.com web page screen.
• Click on "View Blog" or navigate to your blog via http://www.blogger.com and click "View Blog"
• See your Plaxo Pulse Lifestream Widget on your blog!
  
• To see mine (Michael Finney blog) look at http://finneycanhelp.blogspot.com
  
• My Plaxo Pulse Lifestream widget is titled "My Plaxo Pulse" although the text "Check My Pulse" is more prominent with its white text on a blue background.
  

Enjoy. Feel free to ask questions and do not forget to ask Blogger.com and Plaxo Pulse ( Plaxo.com ) for help as well if you need it.

Gateway Jug in St. Louis

I visited the Gateway JUG in St. Louis. I enjoyed the pizza, people, and topics. The topic of the evening was Web 2.0.

There's so much that a person gets from going to such events. Undoubtedly, a person is exposed to tips and other technologies as a result. I plan on going to the Gateway JUG again.

Plaxo, Flickr, LinkedIn Are All Coming Together

I see how LinkedIn, Plaxo, and things like Flickr can finally come together, via Plaxo's Pulse.