Wednesday, July 17, 2013

Resharper add-in idea - highlight IDisposable vars

[Update 18th July 2013]
@RobGibbens and Greg Hurlman picked up on this - Rob pointed out that there is an FxCop rule that can do this and Greg suggested a Visual Studio extension. I've had a quick look at the Visual Studio options and it looks like an "Editor Extension" is a good fit....hmmm, Project New, click...doh...dammit I really don't have time for this but it looks a fun little diversion! I'll update here if I get anything working.

[Original Post]
Had an interesting idea for a Visual Studio Resharper add-in the other day but don't have the time to implement it so thought I would put it out might already exist (and hopefully someone can point me in the right direction) or someone will build it (Darren Voisey where are you?!).

The idea is very simple really - when you have a variable for an object that implements IDisposable it gets highlighted or a tell-tale is displayed to let you know it should be disposed or should be wrapped in a using statement....simples right?

The trigger for this was a piece of code that sent an email via SMTP and we were trying to delete the attachment once sent (to clean-up disk resources) but this failed as we were not disposing the MailMessage object we had created.

Thursday, August 23, 2012

Walk-Thru: Using Wolfpack to automatically deploy and smoke test your system

First, some history...

The advent of NuGet has revolutionised many many aspects of the .Net ecosystem; MyGet, Chocolatey & OctopusDeploy to name a few solutions building upon its success bring even more features to the table.

I also spotted that NuGet could solve a problem I was having with my OSS System Monitoring software Wolfpack; essentially this is a core application framework that uses plugins for extension (Wolfpack Contrib) but how to unify, standardise and streamline how these plugins are made available? NuGet to the rescue again - I wrapped the NuGet infrastructure (I deem NuGet to be so ubiquitous and stable that is has transcended into the software "infrastrucuture" hall of fame) with a new OSS project called Sidewinder. Sidewinder allows me to wrap all my little extension and plugins in NuGet packages and deploy them directly from the Wolfpack application - it even allows me to issue a new version of Wolfpack and have Wolfpack update itself, sweet huh?

About the same time as Sidewinder was born, I also started another OSS project called TripleA as result of discovering "Continuous Delivery" - this project set out to streamline the building of system level and deployment verification tests (TripleA is the helper framework that this article alludes to) that should be used to provide "system" level verification that a deployed version of your application is fit for purpose and ready for a more in-depth rigorous test cycle. finally tie all this together I want to present the intersection of these projects as a free, OSS solution for the automatic deployment and smoke/system/deployment verification test of the your software.


A very typical scenario encountered during development is something like this...
  • Make a change, locally test it
  • Commit the change, starting a build on the CI server
  • Deploy the build
  • Run some smoke tests
  • Promote the build through the environments after further testing
Wolfpack brings automation to the majority of these steps...

1. A developer makes a change and triggers the CI build process. Unit tests run and a build is produced. Two NuGet packages are also produced - one contains the application deployment (lets say this is an ASP.Net website) and the other contains the smoke tests to verify the deployment and that the application is working correctly, at least enough to commit to more in-depth testing.
2. These two NuGet packages are uploaded to a NuGet feed server as part of the build script. There are several options here...
3. Wolfpack is running and has the "Deployment" plugin installed and configured to detect new versions of the Application Deployment NuGet package.
4. The Application Deployment NuGet package is downloaded from the feed and unpacked into the configured folder on the target server. The contents of the NuGet package could include MSI, BatchFile, Powershell script, MSBuild script etc or even something like a Dropkick deployment. Wolfpack will run the command line it has been configured for once the package contents have been unpacked.
5. Once the command line has completed a Wolfpack alert is generated based on the exit code of the process it started to perform the deployment. Wolfpack offers a number of plugins to communicate its alerts including email, hipchat, growl (prowl to smartphones).

...phew...ok, we have automated the deployment side of things...the latest build of your application is installed on the target server - but does it that new feature working or that bug fixed?

6. Wolfpack can also be configured to go and check for a NuGet package update in response to ANY alert that it generates...perfect, the alert that told us the Application Deployment package had executed provides the trigger to check for a Smoke Test NuGet package update; as a new version has been created Wolfpack downloads it...
7. ...and as part of the download Wolfpack will also detect any dependencies your Smoke Test package has and download those too...what's that...your Test package has a dependency...on the NUnit.Runner package? No problem...that's been pulled down too, it saved you including it your package!
Wolfpack "Growl" alert containing test results
8. Ok, the Smoke Test package and all dependencies has been downloaded and unpacked...Wolfpack will now run the command line you have configured it with to execute the NUnit console app against the assemblies that contain your tests. This will produce an xml file containing the test results - Wolfpack will parse this and extract the pass/fail/skipped etc counts and...
9. Finally create an alert containing the test result information
10. Automated deployment and smoke test complete!

The two alerts Wolfpack generated during this process can optionally be stored in a Wolfpack database - it supports SqlServer, SQLite & MongoDb at the moment. Storage of alerts allows you to query them in the future (for instance the duration of the deployment is captured) and to also hook this data up to some sort of visualisation...oh, did I mention that Wolfpack has native support for Geckoboard, one of the leading business intelligence dashboards?!


Sidewinder is the silent partner in all of this. In order to leverage NuGet as a deployment package for my plugins I needed a wrapper around it to be able to control it from within Wolfpack. I also quickly realised that what I was trying to do was...

A) not Wolfpack specific
B) able to deploy pretty much any file your application might need post installation.

So I immediately started the Sidewinder Codeplex project and to ensure it "delivered the goods" I was to dog food it with Wolfpack. Sidewinder allows you to package files and deploy them from within your own application - these could be binaries (as in the case of a Wolfpack plugin) or content type files, anything really and it works like this...

  1. You package up the new files you want to deploy into a NuGet package and publish this to a feed.
  2. In your application solution you reference Sidewinder via its NuGet package and add a small snippet of code that instructs Sidewinder to check for an update to the NuGet package that contains your updates.
  3. Sidewinder indicates if a new version is available and your application should quit running with a suitable message as it will have file locks on the very same files you might be updating.
  4. In the meantime the Sidewinder library has downloaded the NuGet package and unpacked it to a temp folder and launched Sidewinder.exe....this is waiting for your application, the one that launched it, to close...
  5. Once your app shuts down the waiting Sidewinder.exe completes the deployment by copying the contents of the temp folder to the root of your application.
Sidewinder can also be used independently to download ANY NuGet package (optionally plus dependent packages) and deploy it to ANY folder you choose - it doesn't have to be embedded directly in your application. To do this just call Sidewinder.exe from a command prompt with the name of the package to download and a folder to install it into like this...

sidewinder.exe /p wolfpack /i d:\wolfpack

This will download the entire Wolfpack install package and place it in d:\wolfpack - you are ready to rock with Wolfpack. 

Now - if you are familiar with Chocolatey you will be saying hold on a minute, this is what Chocolatey does...and better too (Sidewinder doesn't run any powershell scripts in your packages)...and you would be right to a degree.  Sidewinder was born to provide an update mechanism that was embedded internally to your application - if just so happens that a slight tweak to the original design allowed it to be used directly from the command prompt too. It's a lightweight, stripped down NuGet package installer can simply grabs the package and puts it into a folder of your choice.


So far I've illustrated Wolfpack (and Sidewinder as this does all the NuGet package downloading) in action...what about TripleA I hear you ask?

TripleA is designed to make writing smoke or deployment verification tests a lot easier. It is not a new testing framework and it does not replace NUnit, MSpec etc - rather think of it as a set of extensible helpers that you can call from a test within your existing test framework that lets you arrange and assert things at a "system" level.

It turns complex things into simple, parameterised one-liners(ish) that can arrange or assert something about your system.

eg: your latest deployment should redirect users that belong to a specific role to a new landing web page. Think of the code involved to do that...ensure a user exists in the database for the role, call the web page and login with the user identity, assert that you are redirected to the expected is not trivial stuff. TripleA makes this easy in four simple steps.
  1. Create the TripleA session and configure it with two steps...
  2. Add the custom sql step to add a new user to the database in the correct role
  3. Call the login webpage passing the credentials and asserting the redirect url is as expected
  4. Execute the session (think of this as a pipeline of arrange or act steps) and assert that the steps all passed.
TripleA ships with fairly good support for web, database (SqlServer), windows services, file system and process manipulation so you have a great chance it will work right out of the box for helping you verify a deployment of your system. It is also built from the ground up with extensibility in mind (all the built-in components are created using the extension framework so I know it works!) - you can roll new extensions really easily so creating domain specific arrange/asserts steps that developers can then easily use in new tests.

You can do it

You will need...
1. Wolfpack, grab the zip from codeplex and unzip it (remember you might need to right click and "unblock" it before you unzip it).

  • Wolfpack is a windows service but also runs as a console app, recommended to use it like this whilst you are evaluating it.
  • In the next version (2.5) Wolfpack will be installable via Chocolatey

2. Install the "deployment" plugin. Simply open a command prompt and CD to the folder you unzipped Wolfpack to.
3. Type wolfpack.agent.exe /update:Wolfpack.Contrib.Deployment

  • This will download and install the dlls/config that contain the NuGet version check and automatic NUnit runner.
  • You will need to follow the configuration guide here to set up these plugins

4. Create two "demo" NuGet packages - one with something you would like deployed and one with some NUnit tests in you would like run.
5. Wolfpack should deploy the former and execute the latter and send you an alert after it has done each!

Hopefully I have demonstrated how Wolfpack, Sidewinder and TripleA work together to produce a free, open source automated deployment solution...and remember Wolfpack does a lot more...once installed on a server to automate your deployments it can also monitor a whole range of system parameters such as disk space, MSMQ's, cpu load, ssl certificate expiry to name a few!

Some related posts of mine you might like...

  • DDVT - why you should approach your smoke tests/deployment verification with a declarative/bdd/test first stance.
  • Deployment, the final (.Net) frontier - I guess the post that really started the journey that this one finishes! 

Finally I'd like to do more of these "Walk-Thru" guides for common scenarios where you might want to deploy Wolfpack. It's grown into a pretty extensive system and part of my frustration is getting the message out to people just what it is capable of - hopefully these "walk-thru" guides can help achieve this and if you have any requests I'd be happy to consider doing a guide for your scenario. I'll probably put these on the Wolfpack codeplex wiki eventually - better to concentrate the documentation in one place.

Some future guides I would like to write are...

  • Using Wolfpack with Geckoboard - how to set up the Wolfpack Geckoboard Activity to power your Geckoboard business dashboard.
  • How Wolfpack can monitor your CI build - the BuildAnalytics feature allows you to monitor build status and extract stats from common build artifacts like test and coverage results.
  • AppStats - how you can actively pump KPI/metrics into Wolfpack so they can be tracked (and visualised with Geckoboard).

As always if you have an issue or suggestion for any of these projects then the best place to get in contact is through their codeplex discussion page.

Wednesday, October 26, 2011

My ideal Bootstrapper...

[Update 29-Apr-12] I've revisited Bootstrapper for a new project and it does register the StartupTasks in the IoC container and resolve them from there too (if you have your IoC extension before your StartupTasks) - this means any dependencies your StartupTask should be resolved. I don't know whether BootStrapper always did this or I was just too lazy to find it out - however with this feature you can pretty much disregard the following post!

[Original Post]
I like the Bootstrapper codeplex project - it's a nice clean approach to setting up your application....however...

I have a specific requirement to satisfy as part of my bootstrap process and I'm not sure if Bootstrapper can solve it. I'll be honest I thought it easier to write this post as I wanted to talk about my ideal Bootstrapper as well as someone hopefully telling me if Bootstrapper can do this or not!.

Lets say I have an IoC container that needs configuring - easily done with Bootstrapper.
I also have some components that need running once to perform some one-time registration. These components require some configuration values from the config file (app/web.config). Bootstrapper provides the IStartupTask interface to allow components to perform this - sweet.

I can just make a call to ConfigurationManager in my IStartupTask component(s) to pick up the relevant appSettings right?

Wrong - this sucks....appSettings suck period as they are insidious dependencies that will break your code left right and centre if you don't know what they are. They have a place in the top level application but in "components" that could be used anywhere in the software stack? No, big no. The only way to understand where they are used is to search the code for ".AppSetting" - but what if they are in an assembly you don't have the code at hand to - well you keep trying to run it until you have smoked out all the settings! Bonkers!

What I want is for the IStartupTask components to take a configuration object in the contructor - this makes it explicit and breaks the horrid appSettings dependency.....but....these constructor parameters will only be injected if the IStartupTasks are resolved through my IoC container (giving it a chance to do the injection).

So my ideal Bootstrapper sequence is this....

Initialise the IoC container
     Perform automatic programmatic registration (find all container registry/setup components and execute them).
     Process Xml config files  (this is where we would register our configuration components).
Scan for all IStartupTask implementations and load them into the Container
ResolveAll components from the container and execute them - this would ensure any ctor dependencies would be injected thus providing our configuration values.

I think I can write an extension method to the Bootstrapper to do this but it would be locked to the IoC container (there is no generic reference to get hold of ANY container used?) - not terrible though.

The key would be to introduce a "common service locator" wrapper over your IoC container in order for Bootstrapper to by able to add all IStartupTasks to the container and then perform a "ResolveAll"

...hmmmm, that's a lot of work just to eradicate appSetting references! Are they so bad if they are used just in the IStartupTask components? - These startup components are unlikely to be used anywhere else in the code/stack....

Your thoughts?

Friday, October 14, 2011

Deployment - the final (.Net) frontier

[Update 19th Apr 2012] - mission complete!...v2.4.0 of Wolfpack has been released and this includes a new set of plugins that can automatically download a NuGet package then execute a deployment tool (eg: DropkicK, MSBuild.exe) - it can even run NUnit tests (via the console runner).

[Original Post]
Another day, another project and deployment raises its head...

Thinking that this problem must have been cracked by now I had a look around the .Net landscape and found two interesting solutions.
  • Octopus Deploy - a .Net convention based deployment system using NuGet packages, loosely based on AppHarbour's approach.
  • DropkicK (aka DK) - another awesome initiative from Dru Sellers et al.
I like the simplicity of Octopus but also like DK's  fluent code based deployment.

Hmmm, this has got me thinking - Wolfpack could easily be adapted to be used as a deployment agent.

Wolfpack can already monitor a NuGet feed for new package releases and currently sends an alert if a new version of a package is detected; a small modification would enable it to instead pull down and install the package. The package format would be NuGet and it would use DK to do the "install" (included in the package itself, Tools folder with some convention to find the DK deployment implementation dlls).

You would create a NuGet feed per environment you need to deploy to. Each target machine would be running Wolfpack (akin to an Octopus "Tentacle") which would be configured to monitor the associated (correct environment) NuGet feed. "Deployment" would simply consist of publishing the package to the feed, from this point on it would be automated by Wolfpack, detect, download, deploy -> after which Wolfpack would publish an alert to let you know what the outcome was (success/fail) plus some stats.

Would I ever build this Wolfpack feature? I dunno, lets's not a lot of code and it would give me an excuse to really play with DropkicK!

Anyone interested in a deployment mashup with Wolfpack + NuGet + DropkicK?

Friday, September 02, 2011

Wolfpack vNext = vExcited

I'm getting excited about the next release of Wolfpack (v2.3). It's going to be the first application  that uses Sidewinder (unless someone beats me to it with my own framework!).

I'd been discussing updates and NuGet with a few people and wondered how it could be applied to Wolfpack - its plugin architecture makes it a perfect candidate for being able to download or upgrade plugins plus I also wanted to explore a better way of upgrading the entire install - make this as painless as possible.

Taking inspiration from the NuGet.exe commandline app that self updates I had a look at the code and took the plunge and created Sidewinder. I'll let you investigate Sidewinder yourself (if it sounds interesting) but wanted to share what this will mean when it lands in the next version of Wolfpack and how I plan to use it.

Wolfpack is a pluggable, modular system - a number of contrib projects have sprung up and a few dedicated individuals have invested time and effort into adding to the HealthCheck and Publisher plugins available (Thanks guys!). Sidewinder, harnessing NuGet will bring application update to your Wolfpack installation but also provides it with the ability to pull down new plugins and deploy them into your Wolfpack installation folder (including any configuration files required).

Updating your Wolfpack install will be as simple as running...

Wolfpack.Agent.exe /update

That's it - the entire installation will be updated if a new version has been published. Your configuration files will not be updated, only new configuration files will be installed - existing ones will remain unchanged and will need manual update if changed (I'm working on a mechanism to allow the update to make changes as part of the install).

Wolfpack vNext is also taking the first steps towards a more modular system. Feedback has highlighted that the system contains lots of functionality, AppStats, BuildAnalytics, NServiceBus, WCF, Growl, Geckoboard and it would be good to split these away from a "Core" system - making these optional sub-systems that you use if required/suitable for you. I've fragmented the configuration files and started to look at turning these areas of Wolkpack into separate packages to be delivered via Sidewinder. I am also refactoring the Wolfpack.Contrib components into new NuGet packages that can be delivered with Sidewinder...they will be the first plugin test pilot packages for Wolfpack/Sidewinder!

Finally Wolfpack vNext has got some other improvements including...

  • Logging improvements to it's startup code it make it easier to debug/understand/fix configuration issues.
  • New HealthCheck - Host (ICMP) Ping
  • Ability to load HealthCheck components directly into the IoC container (this makes DI into the check possible now) 
A really cool new feature developed by Phil Bolduc is a Powershell HealthCheck - this health check can execute a powershell script to perform any tests/checks you need - this is in beta and will be delivered after vNext as an optional package like this.

Wolfpack vNext will be appearing in a NuGet gallery near your very soon!

Tuesday, June 28, 2011

Wolfpack v2.1 (Build Analytics)

Hurrah! Version 2.1 of Wolfpack (formally MonitorWang) is released!

This release is all about "Build Analytics" - a new set of plugins allow you to monitor the state of a TeamCity build configuration and then once this is complete it can extract stats from any* build tool run as part of it.

* When I say any I mean it supports NCover, SpecFlow, StoryQ reports but as usual with Wolfpack it is easy to create your own parsers to extract from any tool you might use, eg: NDepends, FxCop. It is also simple to extend it to cover other build systems like TFS, CruiseControl.

The final piece of the puzzle of to visualise this information and the Wolfpack Geckoboard Data Service does a great job of this - it allows you to display these stats directly in your Geckoboard.

Friday, May 20, 2011

Developers have Friday "playtime"?

I've observed an interesting trend from my download statistics on my main open source project, MonitorWang...that downloads often increase on a Friday.

What can we infer from this?

Developers have some down time to look at "other" stuff on Friday? Interesting to know how official this is or just people getting bored with the humdrum stuff and looking for something interesting to do at the end of the week?

MonitorWang's official birthday is 8th August when I first uploaded it to codeplex however it was in conception & development way before that so it's almost a year old. It's racked up over 1000 downloads and I've got some big plans for it to be revealed shortly. More importantly I'm starting to get feedback and success stories of it in use which is the icing on the cake - 1000 downloads means nothing if it's not of value to someone!

Thanks to everyone that has helped shape & contribute to it, in particular Rob Gibbens and David Strickland. I've hopefully got some case studies of it being put to use to illustrate further how it can form a valuable piece of your software/ops process.

Wednesday, May 11, 2011

MonitorWang v1.0.8 released

It's taken a while to get this one out - mainly due to a combination of sunny weather and a series of Bank Holidays (and the odd beer festival!).

MonitorWang v1.0.8 is released!

This is a big release - several bug fixes and rebuilds against the latest 3rd party libraries, Magnum, TopShelf and NServiceBus plus a major new feature - AppStats (all the details here including the Etsy inspiration behind it).

Comments and feedback welcome (via the codeplex discussions page)

Monday, April 18, 2011

Wednesday, March 30, 2011

Spring Roundup

Podio - currently being wowed by this web application. It's a highly customisable collaborative "space" for your team to manage there activities. Essentially you create a "space" then populate it with the apps (widgets) that have the greatest affinity with what your "space" is about. So if you were collaborating on a new website then you will use apps from the software development pack (suite of apps) but you can mix and match apps from any category to provide a completely customised environment to manage your work & team with. This concept is excellent as I've used many "management" type sites, must notably (and well known) being Basecamp and found it good but not great - its suitability & popularity varied between project/client - with Podio you can tune the environment to ensure that you only have the features you need and even better you can create your own apps if there is nothing suitable available; I've not tried this feature yet but think it's the ultimate feature! Great user support from the guys there too - very responsive and from the fairly small amount of time I've spent with it so far (I'm running a new project from it) it's been a robust and good quality application but performance can be a little slow, something I think the team there are working on though.

Summary: Highly recommend this if you aren't 100% happy with your current project management tools, well worth a testdrive! (free plan/signup)

Source Meet (via - Greg's Cool [Insert Clever Name] of the Day) - this looks great! I'm interested in this as I've started to get contributors on my OSS project MonitorWang and this tool looks just the job for some remote pair programming and idea shaping. 

"Source Meet enables software developers to directly and quickly view and edit source code together, wherever they are and in the development environment they are familiar with. Not only all of the modifications to the document, but also conditions such as highlighting or position changes are synchronized in real-time with all participants. The additional combination with Instant Messaging, virtual team grouping and context-sensitive collaboration significantly enhances the efficiency in cooperation for development teams".

NuGet - the .Net package management system. This is something I've been following but not actively used, however a contributor to MonitorWang, Rob Gibbens packaged the assemblies required to create your own custom MonitorWang plugins and I have to say it's impressive stuff, a really slick way to get people connected to your code/components. Thanks Rob for introducing this!

The packages below give you the required MonitorWang assemblies to allow you to develop custom MonitorWang plugins...just choose your flavour!

Thursday, February 17, 2011

Google Infographic Tool + Geckoboard?

So just saw this (via @hugorodgerbrown)

You can upload your data and visualise it - if you use Geckoboard for your business dashboard then how about a mashup - want to map your biggest customers? Order hotspots? you name it - it would now appear possible...just need to work out how to get the Google output into Geckoboard....anyone?

Tuesday, January 25, 2011


Another roundup post to cover a few things of interest I've discovered lately....

(via Automated Home) comes the HDMI hacker box from Kwikwai - it allows you to bridge home automation systems into AV equipment, eg: send a text string to your TV OSD! CEC is an optional command channel built into HDMI that allows commands to be sent from one device to another - eg: when you turn your TV off it sends a turn off command back down to your DVD player connected to it. This box allows you to sit in between devices and fake commands or just discover (sniff them).

(via HRB/JasonFried/Twitter) Great post on un-managing your team to unlock potential from a guy at 37signals (basecamp). Superb post - a must read! 37signals are rewritting the development team book!

Friday, January 14, 2011

NServiceBus and BizSpark

Just seen a post by Udi Dahan about NServiceBus (NSB) licensing and companies that participate in Microsofts BizSpark program (which I/mine does :-).

"So, if you're company is in  BizSpark, in addition to all the software you're getting for free from Microsoft, I'm happy to offer you a free NServiceBus Foundation license or $1500 off a Standard license. That includes support".

The new NSB licensing model is pretty well thought out but still restrictive in terms of physical layout of applications - the community license (and even other licenses) only allow it to run a single machine - if you want to use it across machines then it's big bucks (as far as I understand it).

Anyway - if you are in BizSpark, check the link out to benefit from Udi's/NSB Limited generosity.

Thursday, January 13, 2011

These are the 'droid's you're looking for!

I recently posted about Brands and API's and in it I mentioned the rise of Android and this new article on mashable confirms things....

Some great stats in the article if you are interested in the smartphone market. Ok, - it is from a single company but I think it shows the general trend - Android is big and getting bigger,, how's that app coming on? ;-)

Thursday, January 06, 2011

MonitorWang v1.0.6 released

Just a quick note to say that I've released v1.0.6 of MonitorWang - all the details are here.

The main focus of this release is to add some more HealthChecks...
  • Windows Service State and Startup type Checks - monitors that services are in the expected state (eg: running) and have the correct startup type (eg: automatic).
  • Url Ping - pings your urls checking for http failures and slow performance (response threshold configurable)

PS: I'd love to hear from anyone using MonitorWang - what sort of checks are you running, any problems or suggestions you have would be great!


Wednesday, January 05, 2011

Why a Brand needs an Open API

This is a great article by Adam Kleinberg on how a brand and enabling third parties to write exciting applications and mashups targeting new channels via your Api is so important.

The resources required to produce a website and accompanying iPhone app can be significant - what if you invested in your business/eCommerce API and a referral/developer programme instead?

The world becomes your development partner and ANYONE can start creating applications backed by YOUR business.

Take Android as an example - it's gaining market share at such a rapid pace that you will need an Android App soon to stay in the game as it's not a sector you can afford to ignore. Pouring all your money into a specific vendor channel (say iPhone) could mean you are left out in the cold when other technologies/forms/channels become viable. With an API in place it would be a simple, cheaper exercise in creating an Android application on top of the API calls - and the API gives you options in how you go about this; give the API docs to an off-shore resource, in-house team or let some bright spark come to you with their app or idea.

Sure you will always need YOUR website but an API "powers the possible" - who knows what killer mashup someone out there could dream up tomorrow - and your business could benefit from it with thousands of new sales. You have the infrastructure to process sales and transactions - let the other 6,891,463,699-ish people (world population as of today) figure out how to make money out of it for you.

2011 - year of the API! (Oh and Geckoboard, 2011 is all about the dashboard)

Happy New Year Everyone!

Wednesday, December 29, 2010

MonitorWang v1.0.5 released

Just a quick note to say that I've released v1.0.5 of MonitorWang - all the details are here.

The main feature is "Growl Notification Finalisers" - these allow you to modify the Growl notification based on the result or result count plus you can easily write your own Finaliser to adjust the Growl Notification priority or message text based on your custom logic.

There is also a major bugfix to the Castle Interceptor logic that affects the Publisher Filters.

Enjoy - please report any problems via the "discussions" tab on the codeplex site.

Saturday, December 25, 2010

Pass it down the line...

Just read this on the BBC News website and thought it a lovely heart warming story - just remember...."pass it down the line".

Merry Christmas!

Wednesday, December 08, 2010

MonitorWang v1.0.4 released

Big release this....

  • Added support for SQLite databases
  • Added a check that captures energy usage data from an Owl Energy Monitor
  • Added Publisher Filters to allow you to hook custom logic into the publication process
  • Added support for swapping between data sources for you Geckoboard Data Service Activity
  • Plus a refactor of the internal HealthCheck/Publisher mechanism (now uses the cool Magnum Pipeline components)
More details on the v1.0.4 codeplex release page.

Tuesday, November 16, 2010

FreeAgent Geckoboard widgets....its a trust thing

So I've been looking at how simple it would be to get Geckoboard widgets up and running to visualise your FreeAgent data....and the answer is, pretty easy really. The idea I had was for a text widget to display your due invoices. The FA api is pretty comprehensive and this data is available via REST as XML - authentication is http basic using your FA username and password.

I created a new FA widget user for my account and assigned it permissions up to the Invoicing Level - this protects my more sensitive data. Wrap all this up in a Google-AppEngine (GAE) app and there you have it - your FA pending invoices....

In glorious public view....oh dear

Ok, no problem - we use the Geckoboard ApiKey to secure it so that only requests with the correct ApiKey (that we set in the widget configuration) will be allowed access to the feed. Or rather I use my Apikey - it works in my GAE app as I can hard code the apikey check into it...this app instance cannot be used to provide FA data for your account as it means sharing your ApiKey with me...hhmmm - as trustworthy as I am and with a lock down FA user it's still too unsecure for my GAE widget to provide your FA data. I could generate and share a unique ApiKey for your widget but that's not what I want - I don't want to have to administer this in any form!

Furthermore - my GAE app would also need your FA widget user credentials to be able to make the FA api call to grab the data - you don't want to provide this on the url as querystring params and it can't be POSTed from your Geckoboard widget. Ideally you would tell me them - I would store them and use them when your widget called for the data - not something I want to do/offer from my what was once simple FA widget data feed!

So this problem makes something like GeckoboardApps make a hell of a lot of sense. They already have the ApiKey problem licked with a random key and feed url and I suspect storing any credentials securely is also part of the package! Nice...