NFJS - Day 2

Stu Halloway's Refactoring Javascript was a topic I did not expect to see at NFJS this year, but I walked away truly impressed. Stu presented a totally different mindset on developing, testing and refactoring javascript code. The gist of it is to use a mock browser that will allow you to run tests against your javascript code in an automated environment. Here is the mock browser but it is still in a beta state so expect to have to bend it to your will. Stu made extensive use of JSSpec for writing BDD specs against an existing javascript framework (livepipe). It was truly telling in the presentation that the first hour was spent trying to get a solid safety net of tests up and passing before we even began thinking about refactoring. Stuart accurately identified this as the norm when refactoring legacy code and it lines up directly with my experience as well. Refactoring can't be done w/o that safety net. When we finally did get around to refactoring, Stuart boiled it down to four areas:

Extract and Shorten
- If your method does more than one thing it does too much
- Keep method size to around 5 - 7 lines

Reduce Clutter
- Nix out of scope variables
- Keep the effort to duplicate a method greater than the effort to understand it

Choose Good Names
- Probably the most difficult of the refactorings
- Definitely the refactoring most in need of pair programming

Use Existing Libraries
- If you are typing document.getElementById then punch yourself first and download prototype.js second.

The talk was extremely hands on and valuable and made me wish I had a bucket of crappy javascript to go back to on Monday. Other things mentioned included another mock browser env: Crosscheck. Stu also mentioned a lack of code coverage tools for Javascript, but I found one during his talk. One last thing, he mentioned a very important refactoring anti pattern. Mirror methods (get and set on cookie) used in each others tests. If you are testing the get method on a cookie object don't explicitly use the mirror method (set). Instead, roll it by hand as a bug in code shared by these methods could offset each other in the test execution.

The second talk I went to was Stu's GIT talk. I've been looking into GIT for a little while and Stu gave a good gentle intro into it by basically walking through scenarios at a command prompt for 90 minutes. That format doesn't necessarily translate to a blog so here are some highlights:

- When using GIT, think less in terms of verbs
- GIT is not SVN++
- It's crazy fast. Branching and tagging for instance are instantaneous
- The entire source history is in every copy of the repo
- It doesn't store deltas, it stores the begin and end and calculates the deltas.
- You are forced to tell git what you are committing. It's not tracking it like SVN
- GIT encourages agility. You may not know what makes a package/release/hunk of functionality until sometime in the future. Additionally, you can stash your current task deliverables, go do something else, and come back to them later.
- Bisecting allows you to do a binary search through releases of code to identify the release that caused a bug. Kick ass.


Metaprogramming in Groovy by Brian Sam-Bodden was the third session I attended. BSB did a good job of going over the major metaprogramming techniques in Groovy. Additionally he had enough examples of Groovy code with TextMate that forced my hand to download it and see if it will cure what ails me with IntelliJ in dealing with Rails and Grails. Stream of conscience notes on metaprogramming with Groovy:
- Much simpler than using dynamic proxies in Java
- Similar to ruby it allows on the fly evaluation of code via evaluate
- Duck typing like ruby with respondsTo
- See yesterday's bits on methodMissing and invokeMethod
- obj."$methodToCall"() is valid Groovy code that will try to call the contents of methodToCall as a method on obj. In my opinion that code is utterly disgusting.

Also, the inevitable Ruby v Groovy topic came up as it did at lunch with me and a few others. There still seem to be zealots on both sides and I wish for the life of me they would just shut up.

My 2 cents are this. Use whatever makes most sense for your environment and team. At my consulting company, that is Ruby b/c I have a lot of .NET fellas that I would like to roll into and out of projects whether it is deployed on MRI, JVM, or DLR. The differences at my admittedly noob perspective are few and far between with the two languages. If it was a room full of Java developers, Groovy might make more sense because it is an easier transition for Java heads. I don't care what you choose for your environment, just quit bitching about the other side.

EJB3 Testing by Joseph Nusairat was my final session of the day. Joseph covered a wealth of testing frameworks in a very code centric presentation. The session was very interactive and covered some cool mocking techniques outside of the realm of EJB3, like dealing with mocking static methods. My attention span was slipping this late in the day, but here is a set of highlights:
- Easymock provides the typical set expectations, record and playback functionality. It is still probably the most proven, well documented, and easy to learn of the mock frameworks.
- JMockIt is a relatively new player with some cool support for AOP and Hibernate. Please notice the IT at the end of the name. JMock is a different framework. Unlike EasyMock and JMock, JMockIt is a very small and straightforward API that can be used to test methods w/o dynamic proxies or cglib.
- EJB3Unit has some very cool facilities. It provides an in memory database out of the box (HSQLDB), uses CSV files for populating the data and provides mocks of almost everything that you would need in an EJB 3 bean. If you have to use EJB3, this framework seems like a valid contender.
- Embedded JBoss is the last one covered and it seems like a good fit for mocking out an entire container when necessary and using JBoss.
- Mocking for unit testing, other tools still necessary for integration and functional tests.

I'm tired. See you tomorrow.