CFUnited Presentation Roudup

CFunited was busy for everyone involved so I have no excuse for falling behind in making blog entries as many others just as busy as I did kept up just fine. I'll only post 2 entries for CFUnited this one with all my presentations and then a second one recapping my CFUnited experience (spoiler: It kicked ass!). On with the recap!

Red Green Refactor
PDF Keynote

I was fortunate enough to be given the opportunity to present this topic 2 times at the conference. I feel like both presentations were solid and entertaining; including a reference to old Purple Pants (if you do not know, probably best not to ask :) ). Barney B was disappointed in my lack of gratuitous vulgarity, I'll attempt to not let him down next year. I got really good feedback, even testimonial that TDD does speed up development!

Fusebox Past Present Future (Busy Developers Guide to Fusebox)
PDF Keynote

This was a bit awkward given the current situation surrounding Fusebox and Myself. The first half I did my best to sell on the framework and break down some of the old myths. At about 5:55 I entered my 5th Myth: Fusebox is Dead and instead of really getting into that I made the attendees aware of the current state (at the time) and announced I was resigning. I think spent the second half of the presentation talking about FuseNG (or Fork-a-doodle-doo). Expect more entries soon surrounding FuseNG 1.0 (code named Cuddles).

Code Review and Team Dynamics
PDF Keynote

This started my 3 hour marathon of presenting. It was also a late add to the conference, I was subbing for Jake Munson who was unable to present do to person reasons. I love this presentation, I've given it a few times previous. I felt really good about my delivery and I think everyone got something out of the presentation. I think I might create a new presentation on the same vein but with more emphasis on Team Dynamics and mentoring for next years conferences. I appreciate all the positive feedback from everyone!

Busy Developers Guide to Java Part 1
PDF Keynote

This was one of those presentations with so much content it has to go perfect or you run out of time. I screwed up 2 times and ran over. I was also called Drill Sgt. and Reverend after this presentation. Apparently I was too brash haha! I felt everyone still learn a great deal about java and I got some great positive feedback as well, definitely help enable folks in this one. This was the second session I got to repeat. The second iteration I tried not to preach as much I also pulled some content that might have been too preachy. I ended right on time and had some great interaction, just like the first time. I think this session has great replay potential for future conferences.

Busy Developers Guide to Java Part 2
PDF Keynote

This was my final presentation of the 3 hour presentation marathon. I'll admit that about halfway through the Part1 session I felt ill. This continued into part 2. About half ways through one of the most embarrassing things happened, I had to excuse myself from the presentation for a moment. Luckily this was the last session of the day and everyone was very understanding and allowed me to run over the time and finish the content. I appreciate everyone's patients with me. Aside from the total misery I was in as far as how I felt I think this presentation was awesome. I got good participation from the attendees and very positive feedback from many folks. Anytime I stick around after a session to answer additional probing questions seeking to learn more is awesome.

Overall I had a blast presenting. I hope everyone attending my presentations was entertained and learned or was motivate. As long as I was able to positively affected at least one individual that is all the more I can ask for as a presenter the rest is gravy. Our community is growing and I am glad to be part of the growth. Here's to CFUnited and any other conference that facilitates collaboration and growing! Thanks Stellr for organizing, promoting and kicking ass.

MXUnit ExpectedException

I'm glad to see the next minor release of MXUnit :) I'm even happier to see ExpectedException make it into the release. I'd been doing a lot of development in Java and using the latest JUnit and the expected exception annotation was so nice. When I went back to writing test cases for Fusebox I found myself avoiding writing tests that would throw errors (like testing bad paths for Fusebox parsed files). Well long story short I found myself one night debugging something in Fusebox only to find Fusebox should have been throwing an error. Since I never tested for it I never caught that Fusebox was not throwing an error. That motivated me enough to spend the 30 or so minutes it took me to write a couple test cases and add the functionality to MXUnit.

So the old way to test for an error was something like this:

      <cffunction name="ensure_error_on_load_extentions_with_bad_path">
           <cftry>
               <cfset extManager.loadExtensions(getDirectoryFromPath(getCurrentTemplatePath()) & '/notthere') />              
               <cfset Fail("Last line should have thrown an error") />
               <cfcatch type="mxunit.exception.AssertionFailedError">
                   <cfrethrow>
               </cfcatch>
               <cfcatch type="fusebox.BadDirectory" />
               <cfcatch type="any">
                   <cfset debug(cfcatch) />
                   <cfset fail("Bad Error")>
               </cfcatch>
           </cftry>
       </cffunction>

Now all we have to do is this:

       <cffunction name="ensure_error_on_load_extentions_with_bad_path" mxunit:expectedException="fusebox.BadDirectory">
               <cfset extManager.loadExtensions(getDirectoryFromPath(getCurrentTemplatePath()) & '/notthere') />              
       </cffunction>

I love the feature, and I hope others enjoy it too.

CFUnited session # 2!!

I know at least one man will be very happy to know I will be presenting Red Green Refactor at CFUnited! I gave a presentation at bFusion about TDD and MXUnit with the same title that got a lot of great feedback. This presentation will follow a similar tone as that one, only less MXUnit and more rants about BDD. I've previously ignored talking specifically to BDD as I felt (and still feel to an extent) that BDD is really just TDD done right. After the recent cfSpec announcement I got to talking to Sean Corfield about BDD and he made a comment of getting BDD over TDD. This leads me to think I should talk more about BDD (it seems to make more sense to more folks). I'm still of the mindset that BDD is little more than TDD done right but, I think BDD is starting to become more relevant as the concepts mature and evolve. I will probably focus more on some BDD concepts than I previously had planned. This should give me a chance to learn more about BDD in the process, I can't wait to give this presentation!

Improve Code Quality: Peer Design

As I work on my presentations I enjoy sharing some of my thoughts along the way. This will be the first of a series of entries that talk about concepts I plan to cover in my presentations. This is mostly a practice of thinking out loud but I think, or maybe hope, they will make a good series of blog entries. Of course, my opinions might change as I collect more and more empirical data, I'm very pragmatic, but I just have to share this knowledge pent up in my head!

What I am about to say may well change the way you think. You might think I am am a blooming idiot for saying it but I hope it helps folks improve their code's quality. Unit test do not improve your code's quality. Pause for a second and let that sink in, unit tests do not improve your code quality. They measure and verify code quality but they themselves do not improve the quality of your code. Think about it, running unit tests over and over again will not improve code's quality. I'm not intending to undervalue unit tests but it is important to realize unit tests improve the application's observed quality by ensuring properly functioning code. Unit tests do not improve your code's quality and more importantly maintainability.

Once you come to accept this fact the question you may be asking yourself is how does one improve the code's quality? Coding standards provide a good quality baseline and may serve to enforce some code quality, TDD can help improve the code quality (a node to unit tests), code reviews could certainly help improve quality, and design up front might help code quality as well. The truth is we all have different techniques to improve the quality of our code and I will discuss each one of the aforementioned topics in the future, and in my presentation.

Today I wanted to spend some time discussing peer application design. XP advocates may be keen to note I left off peer, or pair, programming from the list techniques to improve code quality. I did this with good reason, I do not like it. In my experience it is a waste of a developer, I'm not saying it is a bad technique for everyone but I am not an advocate. The reason for my lack of enthusiasm towards peer programming is I favor peer design. In my experience peer programming really turns into peer design only with lots of code being written and rewritten. Peer application design is when a group of developers/architects, not necessarily limited to only the developers of the system, have a design burn down of how the domain(s) should be modeled. It certainly does not need to be limited to the domain(s) but since at Kroger we have a fairly standard framework stack most of the design discusses focus in the domain modeling and not other aspects of an application. Peer design forces us to use our whole brain as we must first internalize our rationals then verbalize, and often times defend, our rationale with others. At the same time, or near same time, we are internalizing others' concepts and mapping them to our own. Peer design has the added benefit of cross training, since we are including peers that are not planned developers on the system in design. Peer designs, just like their big brother JADs, do not generally just happen; they need coordinated and a strong facilitator ensuring the flow and guiding decisions in the correct direction. This is not to say you can not do a quick peer design with one other person at the bar on a Friday night but generally they are slightly more organized than that! Generally the output of a peer design session(s) is some sort of map for development. The map could be as simple as a cave drawing on a bar napkin or as sophisticated as a set UML diagrams. The diagrams, whatever form they come in, are much easier to change and morph than large chunks of code that you will get with peer programming. In a future entry I will talk about code reviews these diagrams can be very important in code reviews.