Continuing to make my way through Roy Osherove’s TDD course. There’s an interesting exercise that he introduces to help practice and gain the muscle memory required to do TDD well – the Code Kata. Wikipedia attributes the code kata to Dave Thomas:
Code Kata is a term coined by Dave Thomas, co-author of the book The Pragmatic Programmer, in a bow to the Japanese concept of kata in the martial arts. A code kata is an exercise in programming which helps a programmer hone their skills through practice and repetition.
I’m a TDD wannabe. I’ve done small tasks using TDD, and I’ve written plenty of tests, but most just get shuffled around, never included in my CI builds, and basically the entire thing is a mess… Perhaps it’s because I’ve been writing code for startups, but most likely it’s because I’ve just not taken the time to learn the right way. I’ve never truly seen the benefits that it can bring. So I saw this class as a great chance to learn from the master.
I’m going to blog about my experiences going through this course. I’ve been through the first two hours, and so far I really like the pace and Roy’s teaching style. Roy is snarky-funny, and so the content is entertaining to boot.
So here are some of the more interesting things that I’ve learned from the course so far…
Difference between Integration Tests and Unit Tests
Although the generally accepted definition of the difference may be up to some debate, Roy’s definition is simple, I like it, and it’s useful for me. Roy says that a unit test is all in memory. It should pass on any new developer’s machine, and is not tied to disk, databases or anything outside of the memory scope of the test. This is important because confidence in your unit tests is paramount. If you cannot trust that a failing test is due to a bug, i.e. if it’s due to some setup on disk, etc. it diminishes the usefulness of your test suite and developers cannot quickly setup to work on a codebase.
Arrange, Act, Assert
The three A’s of unit testing was new to me, and is a pattern for writing tests that Roy introduces:
Each method should group these functional sections, separated by blank lines:
Arrange all necessary preconditions and inputs.
Act on the object or method under test.
Assert that the expected results have occurred.
This approach, by eliminating assert code intermixed with code that sets up or acts upon your objects, reduces smelly tests by separating what is being tested from all the other stuff. See, I need stuff like this to help me fall into a pit of success of testing.
There’s a lot of good stuff in there about creating readable and maintainable tests. Roy also delves into best practices for naming tests, offers some good hints on how to setup Resharper live templates, a good deal of information on why he prefers TestDriven.Net as a test runner (and how to use it to debug methods directly!) including an interesting history lesson on MSFT vs TestDriven.Net’s Jamie Cansdale.
With over nine hours of course total, I’m expecting to learn a lot. Oh, and apparently serial killers practice TDD.
Last time, I wrote about how neat I thought the Ducksboard app was. I found a nice little project over on github that wrapped up the update components of the api pretty well. So I could easily create a dashboard, and configure my application to push data to Ducksboard using a .NET component with nuget support and coding techniques I’m used to.
I started playing and noticed that the Dashboard API (used to create Ducksboard dashboards, not update them) wasn’t implemented, and I kind of needed it. We have a product that could use a dashboard, and I wanted the dashboard functionality to go something like this:
App starts up, checks to see if there’s a Ducksboard dashboard for client x. If not, create it, populate it with widgets, and then go on doing work stuff, occasionally updating the Ducksboard dashboard with metrics, etc.
The Dashboard API can be used to manipulate all objects found in Ducksboard: dashboards, widgets, external accounts, public access tokens and so on.
I contacted the author of the Ducksboard API for .NET to see if he was working on this api, and he wasn’t, so I coded up what I needed trying to stick with the original authors api design as much as possible, submitted a pull request, and now it’s part of the project. What the heck did we do before OSS?
Anyhow, there’s some awkwardness in the code there (mostly due to my limited knowledge of json serialization, but also due to some constraints of their api), but it is working pretty nicely if you know what you want to do with their api. For example, the following few lines of code creates a dashboard with a leader board component :
One thing I’m grappling with is the long term viability of using Ducksboard for corporate dashboards. I’m exploring the idea, but am waiting to see if our clients will go for a super nice, accessible-from-anywhere dashboard, with reduced complexity on in house servers, and all of the benefit that that brings, or if they think it’s too risky to send out data to a third party… For now, I’m happy to have it there as an option for those that want to use it.
Ducksboard, is absolutely the most fun I’ve had on a web api in a long time.. “Monitor your metrics with Ducksboard, a real time visualization of your key performance indicators..” Basically, you make dashboards with it. It’s got built in pugins for tons of other apps (basecamp, github, twitter, pingdom etc. etc.) and a really nicely done restful api where you can manage your dashboards.
I’m just playing at this point, but I’m thinking that I’d like to use it to create some customer dashboards to show real-time metrics that are applicable to our apps. One thing I was thinking was an uptime dashboard that could show the health of our services and devices, sort of like this.
One way I can easily post to this board whenever there is an error in any of our apps is to create a Ducksboard Appender for log4net. I used a nice little .net wrapper for Ducksboard and made the following appender :
Configure it like this :
I’m hoping to contribute to the Ducksboard api for .NET and add the dashboard API, which allows you to create dashboards in code. A new installation of one of our services could create a new monitoring dashboard, add all of the relevant graph and informational displays, then start updating it.
Disclaimer : I recently asked Ducksboard to become “Friends” of CodeBetter.Com so you’ll see them linked at the bottom of the site, but this post is unrelated.
Nancy is a lightweight, low-ceremony, framework for building HTTP based services on .Net and Mono. The goal of the framework is to stay out of the way as much as possible and provide a super-duper-happy-path to all interactions.
One of the things I like best about Nancy, other than it’s super fun and easy to stand up and build HTTP services, is the Self-Host.
At work, one thing we make are some networked edge-devices for things like kiosks that are normally deployed into the field at our client sites. One of the things I find super helpful for configuration, debugging and troubleshooting, is a simple HTTP endpoint.
Imagine a problem with an edge device out in the field – like a kiosk, camera, DIO controller, etc. One of the first things a sysop may do is browse to the device’s HTTP endpoint, pull up a web page, check configuration and logging. There are certainly more sophisticated ways of going about management and troubleshooting, but for simple cases an administration web page works well. It often can save a sysop a trip out into a hazardous environment if a quick fix can be done remotely, even better using a secure browser session.
So what are your options for doing this? If you already have an existing .NET application running on your device, with state, etc. spinning up IIS and a web site isn’t a great option.. You will have to tackle issues of sharing data, installation of the web site every time you setup a new device, the overhead of running IIS, IIS security, just to name a few. What if there was a simple way of generating an HTTP endpoint? – Enter Nancy Self Hosting.
With the Nancy Self-Host, you can easily make your HTTP endpoint part of your existing application, which means you can share state, installation process, security, authentication etc. And you can do it all on the “Super Duper Happy Path.” Here’s how easy it is to host Nancy in a console app:
How about from a Service? Here’s how easy it is to host Nancy from within your own TopShelf service.
In short, I personally see a huge sweet spot for Nancy in these cases where you need a simple management endpoint. Next time, I’ll blog about how to do this from NServiceBus when using the NSB host – even sharing the NSB IOC container.