A Summer of Community Involvement

My kids are headed back to school in just a couple of days and that has me thinking about that what I did over the summer. It turns out, I did a lot of presenting over the last few months.

Agile Roots

On June 22nd, Zhon Johansen and I presented a hands-on learning experience as part of the Agile Roots 2012 conference. We spent the weeks leading up to the conference preparing a self-paced kata on London (Mockist) Style TDD in JavaScript. Because this was a self-guided kata, we put a lot of time and effort into making the instructions readable and easy to follow.

As part of our preparations, I presented the kata at the Utah Software Craftsmanship group on June 6th.  This was a great group experienced with katas, TDD, and group work like the Randori. Because of their comfort with these practices, they provided a lot of valuable feedback.

A week later, on June 14th, we presented the kata with additional updates at the Utah .NET User Group. This group was more of a challenge as the tools and language weren't as familiar. There were even people in attendance who had no TDD experience and some who didn't have development laptops.

With a few more days of work, we were ready or at least out of time. The presentation went really well and we have both gotten positive feed back both at the conference and since. This was my first national conference presentation and I was happy to have Zhon with his years of experience as my co-presenter.

Utah .NET User Group

After the fun we had with the JavaScript kata, the .NET User Group invited me back the next month to present on Legacy Code Rescue. We borrowed Michael Feathers' definition for legacy code: any code without automated tests. We spend nearly 2 hours adding tests to a pretty decent codebase. The slides and code are available online if you missed it. We covered a lot of basic and intermediate testing strategies which you can see if you walk through the git commits.

Utah Software Craftsmanship Group

You may have noticed a pattern already, so you won't be surprised to hear that I was asked to give a lightning talk on TDD vs BDD and NUnit vs MSpec at the August 1st Utah Software Craftsmanship group meeting. I demonstrated the Bowling Game kata in the NUnit style and the MSpec style. We then discussed as a group the differences between these two styles of unit testing. I concluded by showing how to use FitNesse to accomplish the actual goal of BDD which is that the whole team, not just the developers, focus on automated verification of business requirements. As usual, the code can be found online with instructions.

Public Speaking is Scarier than Death?

Obviously, I don't agree. I had a tremendous amount of fun this summer. I hope that the attendees at my presentations found them to be as valuable as I did.

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc
Read more