February 23, 2011

This story starts somewhere between 7 and 10 mnths ago, when I was talking to my friend @cbilson during a break in a pairing session. We had previously talked about give camps and coding for causes events. This led us to the fact that we both liked the idea but felt it could be more targeted. We had also talked about renting some space from the facility my wife works at for the South Sound .Net Users Group to hold a workshop.

The idea stuck with me, my wife works for a non-profit after all and I had worked for one recently. I talked to my wife about an idea I had brewing. The place she works for just so happens to be one of the premiere Cancer Retreat facilities in the Northwest (if not the world[but don’t tell them]). Where is it that she works you ask, Harmony Hill …. just about the most centering place on earth (ok yeah I know I’m REALLY biased). Anyway back to the story. I bounced the idea of my cohorts including @NotMyself . Every person I brought the idea to thought it would be amazing. So I decided to move forward with what would become Harmony Hackathon.

Harmony Hill agreed to support the group by providing hospitality services and lodging for the entire group while they were on the hill. I can not even begin to tell you how amazing this staff is, for 48 hrs 12 of the finest developers in the northwest didn’t want for anything!

The setup on my part was pretty easy, invite some of the best programmers in the northwest and ask them to do the one thing they love, code!, for charity…. plus I promised them beer! It worked… attendance was limited by the number of beds we had available for people to sleep in. It was only seconds after sending out the first request did I have people signed up to the eventbrite site.

Finally the day arrived to begin the Hackathon and you could say the excitement in the room was palpable. We started with introductions to the projects (we had initially intended to run to two projects) and to the facilities. We then headed down to the first of several amazing meals on The Hill. After dinner is when the real excitement began. We had decided on building the needed registration/waitlist management tool which is centered around available beds at the retreat center. @darkxanthos took the reigns as PM/customer liaison person and began gathering requirements for the developers to start working with. There was a lot of desire to start coding but also a deep understanding amongst the group that we must first understand the problem before we can solve it. A lot of effort went into making sure we focused on breadth and not rabbit holing ourselves on a single problem. Once again Justin did a great job and with the help of Rodica and Aeden a group of requirements was beginning to emerge as a set of mockups.

We began building out the plumbing and infrastructure of the project and decided on a couple of technology choices… MVC 3 and the default Razor view engine that comes with it.

The next 40 some hours of the weekend were a frenzy of coding…. pulling changes and merging changes…. I swear if nothing else our git skills improved. There were times that a person might have to pull again after merging changes from the last commit only to find out that they were still behind master. It was crazy, as a matter of fact you can see for yourself, thanks to a video from @NotMyself showing the gource animation of what happened.

We didn’t exactly finish, but we did cover some really awesome ground and learn a lot about how to manage such a gathering. A couple of the things we learned are kind of obvious but extremely powerful.

1. While it is exciting to see what can be started from nothing, it is a really good idea to be aware of the problem space to get the best results out of the group. Have a small group meet with the product owner at least once before the event date to flush out stories to keep the team working and not waiting. You can do more the day of the event but you need a foundation to work against.

2. Smaller teams truly do work best. Even a team of 12 is too large optimal is about 5-6. We learned that with all the commits and furious amounts of work we couldn’t help but all get in each others way no matter how much we tried not to.

3. You need a dictator. Sometimes the group can not come to a decision about technology (who’da thought a bunch of Alpha geeks couldn’t agree ) so someone has to be able to make a decision and cast that extra vote. I wouldn’t personally say you need to use this power often, only when the group seems to be wasting time arguing over some tech that doesn’t directly solve the problem. I say this because it is extremely important that the group be open to exploring lots of new spaces so that the benefit is not only to the PO but also to the developers.

4. Infrastructure is important. You really need to have the core infrastructure laid out and decided on before you get started. We chose to use ASP.Net MVC because we are mostly all web developers and are familiar with the technology. We also chose NHibernate and StructureMap as we were all familiar with them as well (well maybe not StructureMap but its concepts are universal … see we learned stuff). This meant there was some setup that was needed to get all the plumbing in place. Had this been ready at a cursory level earlier we would have spent less time shaving that particular Yak.

So the ultimate question remains. Will we do it again? The answer is quite simple, OF COURSE !!! The group learned a lot from the experience and the project continues to move forward. As a matter of fact last night while talking with my wife she informed me that they had already started to talk about how the product could help with other programs at Harmony Hill. We have already started to think about how to plan for the next one and how to get the most out of the event.

The ultimate goal…. start something amazing to help out not only this one organization but potentially help out many others. Start a tradition of greatness and see the program grow. Which is good because we might just need that waitlist manager to help out with the future waitlist for Harmony Hackathon 2012.

So anyone following my friends and co-workers Jeff Schumacher (@codereflection), Adron Hall (@adronbh) and Bobby Johnson (@NotMyself) is aware that today we [ok really just them, I was busy on a diff less awesome project] started giving nuget a serious trial run to manage our extensive list of dependencies. A lot of which are not available on nuget at the moment.

We kinda came up with the idea that we really needed something along the lines of bundler for ruby gems. So I started with the most simple version possible and Chewie was born. (All credit for the name goes to @NotMyself). At the moment its a basic file and a single line of powershell goodness.

This sample was spawned by a comment made by my friend and co-worker Bobby Johnson (@NotMyself) . I can’t remember exactly what he said but it had something to do with dynamic and views. (maybe he will tell us in the comments :-) )

Let me first say that many of the projects at work on built on MonoRail which is often considered to be the predecessor to ASP.Net MVC and as such we don’t get a huge amount of exposure to the new toys in ASP.Net MVC immediately.

With that out of the way I was getting prepared to write this post and I just happened to notice that ASP.Net MVC views in .Net 4.0 projects seem to all be of type System.Data.ViewPage<dynamic> , which got me super excited! This makes things even easier! (more…)

In this series I would like to examine the process my team and I have been undertaking on our current project. One of the aspects of working on legacy applications is that when you dive in you often see patterns that are not easily testable. The current application my team is working on was built many years ago and implements MVP (model view presenter) ,which at the time was a useful pattern for developing testable ASP.Net webforms applications. In the years since then many new patterns and frameworks have emerged and it is our desire to move the application from MVP to MVC (model view controller).

This series assumes that you are familiar with a few patterns and concepts namely the following:

How do you organize your tests. Do you separate your unit tests, integration tests and UI tests into separate projects? Do you do anything specific to keep track of your tests? What naming conventions do you use? Do you run them before a check in or is that what the build server is for?
If you are not testing, then how would you like to test your apps if given the opportunity?

This post is my response to the above question.

I tend to have a Specs assembly for each major component of a project, these usually include some form of integration tests using in memory SQLite databases. The first thing most people will think is that I am probably mixing integration tests with my specs/unit tests and getting everything all mishmashed together. That is probably a good observation. As I find myself almost exclusively using MSpec for testing I see no real reason to separate the tests into any other grouping other than by their system components.

An example set of Test assemblies would be :

Monkeys.Core.Specs
Monkeys.Web.Specs

I did learn a few tricks from my friend @cbilson that I really liked and continue to use. That is naming the actual files in the test assemblies about the feature or part of the system we are testing. So for a group of specs that test the calculation of a bunch of distribution dates for a retirement fund based on some frequency (monthly, quarterly, annually etc) the name of the file would be “creating_distribution_dates_for_funds.cs”. This name is also used for the namespace that all the tests live in since MSpec tests are each a separate class. Groups of related tests can be found quickly and helps others that may come on to the project find the tests that describe how something works.

Okay so about those in-memory database integration tests. Well this is another thing that @cbilson and I worked on together (ok mostly him but I helped). Its certainly not a new idea , I got it from some blog post of ayende’s that I read, but it was a major breakthrough in helping us move quickly with testing and be extremely accurate. We were able to not only have nice _FAST_ tests for mappings in nHibernate but also were able to test queries quickly and accurately. Having this ability helps a lot when you want to be able to test with not only the database for your application but also for test versions of other databases you may need to access (most of our apps use at least 3-4 databases). This can make repository testing a no brainer and helps eliminate the kludgy methods people have had to use in the past. @NotMyself, @codereflection and I have even gone so far as to integrate NBuilder into the process for some scenarios making tests clean, expressive and to the point. I’m getting sidetracked I think…. testing is exciting stuff damnit!

Of course all our tests are run on the CI server and we “always” run them all before committing…. right? ;)

I would like to one day soon find a really elegant way to add some more integration testing, maybe even at the UI level, into the process. As this is very painful and hard to maintain today we do our best to test as much as we can. There is no substitution for great comprehensive QA we just hope we make their jobs a lot easier by building well designed rock solid software… that works.

Hope this covers the question and hope someone finds some value in it.

So while upgrading a project from VS2008 to VS2010 at work I was under the impression that pretty much everything went pretty easy. That was of course until I tried running the psake build and hit the publish task.

My publish task looks as such:

1: task publish -depends set_prod_configs {

2: & $msbuild $web_proj_file /p:WebProjectOutputDir="$publish_dir\" `

3: /p:OutputPath="$publish_dir\bin" `

4: /p:Configuration=$configuration `

5: /p:Debug=false `

6: /t:"ResolveReferences;Compile;_CopyWebApplication"

7: }

pretty tame… but after converting this was failing with:

error MSB4064: The “Retries” parameter is not supported by the “Copy” task. Verify the parameter exists on the task, and it is a settable public instance property.error MSB4063: The “Copy” task could not be initialized with its input parameters.

The solution while obvious took a little while to emerge. This problem seems to occur when continuing to use the .Net 3.5 version of MsBuild. However the proj files are updated to use the .Net 4.0 WebApplication targets.

So the simple solution to the whole obvious problem… was… use the .Net 4.0 version of MSBuild (Duh!). I had found lots of posts saying to remove some sections of the targets files and other such suggestions. This however seemed fishy to me (plus not feasible on my CI server) which is why I continued looking for a better answer. Once I realized that the targets file had been updated then it became obvious that I was trying to use .net 4.0 build targets with .net 3.5 MsBuild.

By day I am lucky enough to work with the likes of @NotMyself@codingreflection and other great developers as an Enterprise Developer. Our customers are internal and the corporate preference is for .Net solutions. Our organization and management sees the value in letting developers be productive by allowing them to use the tools that best fit the job. I am proud to work with a team of developers that pushes me to improve myself each and every day.

In my day to day life I am just me, a geek with a passion for learning and all things… well… geeky.

quoting Liam I also favor tools that are :

are open source. Open source libraries are often designed to facilitate quality practices, not to sell tools. Also, access to the source and the price are bonuses.

support the software craftsmanship ideology. Small, sharp tools that stay out of the way and don’t force any design decisions.

April 17, 2010

Thats right…. Visual Studio has finally been given the option to allow tabs to open to the right of existing documents. I can’t but hope that my post on the topic might have helped the VS Team get on board with fixing this issue. Now that I am more addicted to R# it hasn’t been such an issue but I really feel like this is part of the new MSFT… listening to the community at large and taking note. That this is optional is actually better as far as I am concerned vs. it being the default.

With the release of Fluent nHibernate 1.0 RC (download here) there are some great changes to the mapping structure of Subclass and JoinedSubclass. This excerpt from the 1.0 RC release notes gives a highlight of what those changes are and what is expected of us:

Separated subclass mapping – Subclasses can (and should be) defined separately from their parent mapping. Use SubclassMap<T> the same way as you would ClassMap<T>; if the top-most mapping (ClassMap) contains a DiscriminateSubclassesOnColumn call, the subclasses will be mapped as table-per-class-hierarchy, otherwise (by default) they’ll be mapped as table-per-subclass.