pingles

I’ve been getting into some Ruby on Rails of late, and in the process of hunting down some information on incorporating PayPal IPN support I stumbled across a post on Tom Wilcoxen’s blog about Flock. I got sidetracked about having an integrated browser/blogger, and it’s shifted my browsing into a much nicer place to be.

was something I’ve been meaning to try, especially since Josh has pointed it out to me a few times.

To me, del.icio.us bookmarking has a good solid value proposition:

1. It ensures my bookmarks are available anywhere
2. Tags. Although they’re essentially analogous to the folders that IE uses for categorising bookmarks, they have an important semantic difference. They allow items to occupy more than one. They are also key to the powering of benefit 3 below. From a user experience point-of-view it’s important that you don’t need to create the folders first (as you would through IEs boomark support), they’re created when you bookmark. Something that now I think about it, almost every other bookmark feature gets the wrong way round.
3. Shared and social. Through tagging I can discover other related bookmarks, people that seem to be reading the same kind of things I am, and browse things they find interesting. Cross-selling for information.

In short it’s great. But, previously it just wasn’t integrated enough for my liking. Despite there being a couple of ways of making it quicker and easier to use when I’m browsing around, I wanted something more complete. So as soon as I remembered reading that Flock integrated del.icio.us for it’s bookmarking I decided to give it a go

Flock’s now my browser of choice. Although I’ve used Firefox, I never bought it as a fundamental replacement from IE, I just don’t buy a lot of the commentary about it being downright more secure than IE. I’d like to think I have enough Internet know-how to avoid killing my computer through browsing to malicious places. Flock adds value to my browsing experience, it integrates blog posting (although in a somewhat rudimentary way) such that I can blog in just 2 clicks on content I find. It includes a Shelf that I can place interesting things that I don’t necessarily want to bookmark, just come back to at some point.

So, if you want some joined-up browsing fun, get flock.

Incidentally, you should also note the addition of a my del.icio.us section on the right sidebar – this updates automatically with stuff I’ve bookmarked. If you want, you can even subscribe to an RSS feed of my bookmarks. How neat is that?

Despite having already used many of the tools I’m using to provide the build environment for EmailValidator, it still took longer than expected, so here’s the highlights of the current structure which will no doubt change as the project evolves.

The aim of the build is to provide both a) an easy way for end-users and project developers to build project consistently, and b) provide a means for a continuous integration server to regularly build the project. The continous integration server is key to ensure that when other code is contibuted, it is built and tested and that any failure is fixed as quickly as possible. The aim is to also automate the publishing of builds and testing results to this website.

Continuous integration isn’t a particularly new term, it’s origins area in the daily ‘build and smoke’ test, but is one of the key tenets of eXtreme Programming. The idea of automated tests that fully exercise the codebase is key to the overall vision of a high quality product.

The build process:

1. Clean any previous build’s output
2. Build the project
3. Run automated tests
4. Produce code-coverage reports

For this project, I’m using NAnt 0.85rc3 (built 16/04/2005) to actually perform the build – taking the source code, compiling it, running tests etc. Once the project has been built it’s then time to run the tests, these are done using NAnt’s built-in NUnit task. Finally, code-coverage is provided by Clover.NET.The continuous integration server I’m using is CruiseControl.NET which will currently be running in the background as a service on my development machine.

Clover.NET proved to be the most difficult to wire-in, but this was down to it not being entirely clear which build of CloverNAnt to use, as it happens, it was 0.85.2053. A more recent build (2100) I believe is to fix breaking changes in 0.85rc3+ builds.

Firstly, we load information from CloverNAnt’s assemblies:

This ensures we don’t need to copy the assembly over to NAnt’s directory. The current Subversion repository for the project has both NAnt and NAntContrib under source control – a practice I’ve seen recommended in a few places, including John Robbins’ excellent
so this keeps everything nice and clean and tidy.

Clover.NET works by instrumenting the code before compilation, writing in additional instructions to generate a database of results during execution. So, before compilation, we use the following tasks:

<mkdir dir=”${tests.dir}”
unless=”${directory::exists(tests.dir)}” />

Since the clover-setup task **doesn’t automatically create the CloverBuild folder (where it temporarily writes instrumented code to) it’s necessary to create the directory first. The exclusion mask ensures that we don’t instrument (and thefore check coverage) of the test fixtures themselves – just the classes under test. The other thing of note is the final line – CloverNAnt relies on the CloverRuntime assembly to work, and for our tests to run, we’ll need to have the CloverRuntime assembly in the same path. Since all test assemblies are written to the same folder, we just need the one location. Once that’s been done it’s time to execute the tests as normal, and produce the coverage report.

Since this is already long enough (and has taken longer than expected to write) I’ll save the Continuous Integration aspect of the build system for the next post!

Despite having already used many of the tools I’m using to provide the build environment for EmailValidator, it still took longer than expected, so here’s the highlights of the current structure which will no doubt change as the project evolves.

The aim of the build is to provide both a) an easy way for end-users and project developers to build project consistently, and b) provide a means for a continuous integration server to regularly build the project. The continous integration server is key to ensure that when other code is contibuted, it is built and tested and that any failure is fixed as quickly as possible. The aim is to also automate the publishing of builds and testing results to this website.

Continuous integration isn’t a particularly new term, it’s origins area in the daily ‘build and smoke’ test, but is one of the key tenets of eXtreme Programming. The idea of automated tests that fully exercise the codebase is key to the overall vision of a high quality product.

The build process:

1. Clean any previous build’s output
2. Build the project
3. Run automated tests
4. Produce code-coverage reports

For this project, I’m using NAnt 0.85rc3 (built 16/04/2005) to actually perform the build – taking the source code, compiling it, running tests etc. Once the project has been built it’s then time to run the tests, these are done using NAnt’s built-in NUnit task. Finally, code-coverage is provided by Clover.NET.The continuous integration server I’m using is CruiseControl.NET which will currently be running in the background as a service on my development machine.

Clover.NET proved to be the most difficult to wire-in, but this was down to it not being entirely clear which build of CloverNAnt to use, as it happens, it was 0.85.2053. A more recent build (2100) I believe is to fix breaking changes in 0.85rc3+ builds.

Firstly, we load information from CloverNAnt’s assemblies:

This ensures we don’t need to copy the assembly over to NAnt’s directory. The current Subversion repository for the project has both NAnt and NAntContrib under source control – a practice I’ve seen recommended in a few places, including John Robbins’ excellent
so this keeps everything nice and clean and tidy.

Clover.NET works by instrumenting the code before compilation, writing in additional instructions to generate a database of results during execution. So, before compilation, we use the following tasks:

<mkdir dir=”${tests.dir}”
unless=”${directory::exists(tests.dir)}” />

Since the clover-setup task **doesn’t automatically create the CloverBuild folder (where it temporarily writes instrumented code to) it’s necessary to create the directory first. The exclusion mask ensures that we don’t instrument (and thefore check coverage) of the test fixtures themselves – just the classes under test. The other thing of note is the final line – CloverNAnt relies on the CloverRuntime assembly to work, and for our tests to run, we’ll need to have the CloverRuntime assembly in the same path. Since all test assemblies are written to the same folder, we just need the one location. Once that’s been done it’s time to execute the tests as normal, and produce the coverage report.

Since this is already long enough (and has taken longer than expected to write) I’ll save the Continuous Integration aspect of the build system for the next post!

I have to say that when I thought I’d start doing this I’d find it difficult to stop writing, not the other way around. The recent excellent first post by a colleague of mine has spurred me into action, obviously I don’t want to be outdone! As it happens, I seem to have written a good few drafts that are in the process of being refined, so there is some (hopefully) quality technical post-age on the way soon!

In the meantime, I thought I’d take time to discuss the progress on moving EmailValidator into Open Source land.

The answer is slowly but surely.

The Subversion repository is created, a basic structure exists and the underpinnings of a build system are also in-place. I’ve also been grateful to receive an open-source license to Clover.NET that I’ve installed both with Visual Studio .NET and inside the NAnt script so that an HTML report is generated on each build.

I’ve started making the first steps on the road to a functional product, and am approaching it slightly differently to how I’ve approached controls in the past. My real aim for this project is to produce something of the highest quality possible, and to me, that means something that has 100% code-coverage from tests.

Now, whether that’s something that is achieveable by myself (and anyone else that contributes) remains to be seen. My exposure to attempting to test ASP.NET controls so far has essentially proved relatively fruitless – roadblocks were hit far too soon on the lifecycle. However, since some aspects of lifecycle are indeterminate and can be influenced by other controls in the tree, it’s something that is too important not to test. So, this project will also serve as a good purpose for trying to identify ways to successfully test ASP.NET controls.

My previous exposure to code coverage was limited to NCover, but this seemed somewhat problematic and the reports generated (in particular, the ones that were generated through various CruiseControl.NET XSLTs I’d come across) were very difficult to follow. The result was relying mainly on the overall percentage of coverage, without being able to drill-down to precisely whereabouts the problems were.

Clover.NET is different, not only is it very easy to plug-in, it works well and produces the best kind of reporting possible – directly in the IDE. This is something I believe will be incredibly beneficial once I get around to building the ASP.NET control side of the project. At present, code coverage serves as a good reminder that my ‘little baby’ TDD steps aren’t growing too big, or that I’m jumping ahead of the test when I implement. My green-bar/red-bar psychology has been instilled sofar as to make any red bar abhorrent and thus require immediate action. I like it. Time to see whether I can keep the solid green bar up! This is definitely something I’ll be charting my progress with here.

Which reminds me, I must get around to finding a way to automatically publish Clover.NET reports somewhere on here along with access to the SVN repository, time to get back to it!

I have to say that when I thought I’d start doing this I’d find it difficult to stop writing, not the other way around. The recent excellent first post by a colleague of mine has spurred me into action, obviously I don’t want to be outdone! As it happens, I seem to have written a good few drafts that are in the process of being refined, so there is some (hopefully) quality technical post-age on the way soon!

In the meantime, I thought I’d take time to discuss the progress on moving EmailValidator into Open Source land.

The answer is slowly but surely.

The Subversion repository is created, a basic structure exists and the underpinnings of a build system are also in-place. I’ve also been grateful to receive an open-source license to Clover.NET that I’ve installed both with Visual Studio .NET and inside the NAnt script so that an HTML report is generated on each build.

I’ve started making the first steps on the road to a functional product, and am approaching it slightly differently to how I’ve approached controls in the past. My real aim for this project is to produce something of the highest quality possible, and to me, that means something that has 100% code-coverage from tests.

Now, whether that’s something that is achieveable by myself (and anyone else that contributes) remains to be seen. My exposure to attempting to test ASP.NET controls so far has essentially proved relatively fruitless – roadblocks were hit far too soon on the lifecycle. However, since some aspects of lifecycle are indeterminate and can be influenced by other controls in the tree, it’s something that is too important not to test. So, this project will also serve as a good purpose for trying to identify ways to successfully test ASP.NET controls.

My previous exposure to code coverage was limited to NCover, but this seemed somewhat problematic and the reports generated (in particular, the ones that were generated through various CruiseControl.NET XSLTs I’d come across) were very difficult to follow. The result was relying mainly on the overall percentage of coverage, without being able to drill-down to precisely whereabouts the problems were.

Clover.NET is different, not only is it very easy to plug-in, it works well and produces the best kind of reporting possible – directly in the IDE. This is something I believe will be incredibly beneficial once I get around to building the ASP.NET control side of the project. At present, code coverage serves as a good reminder that my ‘little baby’ TDD steps aren’t growing too big, or that I’m jumping ahead of the test when I implement. My green-bar/red-bar psychology has been instilled sofar as to make any red bar abhorrent and thus require immediate action. I like it. Time to see whether I can keep the solid green bar up! This is definitely something I’ll be charting my progress with here.

Which reminds me, I must get around to finding a way to automatically publish Clover.NET reports somewhere on here along with access to the SVN repository, time to get back to it!

Well it’s been a long time since my last post, but a lot’s happened!

I’ve changed my outlook somewhat, and will be open-sourcing (not that the code was closed-source before) some of the work, and retaining some projects as entirely commercial.

Although the projects are currently posted at CodeProject, they are essentially quite difficult to maintain, update, and involve other people. I will be moving some over to SourceForge over the coming days, and setting up the environment for building – using CruiseControl.NET for automated builds and uploads.

So, watch this space, and if you’re interested in contributing code etc., just fire me an email and I’ll make a note to add you to the users with CVS committal rights!

Update: Should have mentioned what I’ll be open-sourcing! The first project will be the ASP.NET Email Validator.

Well it’s been a long time since my last post, but a lot’s happened!

I’ve changed my outlook somewhat, and will be open-sourcing (not that the code was closed-source before) some of the work, and retaining some projects as entirely commercial.

Although the projects are currently posted at CodeProject, they are essentially quite difficult to maintain, update, and involve other people. I will be moving some over to SourceForge over the coming days, and setting up the environment for building – using CruiseControl.NET for automated builds and uploads.

So, watch this space, and if you’re interested in contributing code etc., just fire me an email and I’ll make a note to add you to the users with CVS committal rights!

Update: Should have mentioned what I’ll be open-sourcing! The first project will be the ASP.NET Email Validator.

Ok, it’s decided.

Finally tonight I’m getting on the blog-wagon. It’s something I’ve been meaning to do, but until I figured I had a reasonable belief in providing some content of any value I held off. Talking about something during work the other day with one of my colleagues prompted me into action so here I am.

As with most first posts, I figure it’s probably better to provide some kind of context and background. So first a tiny bit of background about me, why this site and blog, and what to expect from here in future.

By day I’m a C#/.NET developer within an agile team in central London, working mainly on web-based applications, and have been doing so for a few years. About 3 years ago (around when I was graduating from University) I decided that would start taking some of the stuff I’d be working on in my spare time (and posted on the CodeProject website, improve it, and sell it for a little bit of money.

The CodeProject articles were great for me, they provided an excellent way to test my (limited) knowledge of development and design, and provided a kind of instant feedback to a mass of developers that I would otherwise not have had. Although looking back now I can see large flaws in my thinking, or wince at the relative inelegance of the solution, at the time I was happy.

A few of my articles even led to people contacting me suggesting improvements, asking me to add features, alter the way things worked. I was glad of the response and welcomed the suggestions. So, it got me thinking that perhaps I could focus on building better quality, better supported, better working controls that I could perhaps sell. I touted this idea to a few people that emailed me to get an idea about the potential response and most was positive – that provided I could show additional value from the commercial code, developers seemed to be happy to pay.

And oobaloo was born. Don’t ask me where the name came from, I think it was just sound kind of sound I had in my head at the time I was trying to think up a domain name.

So, this site (and blog) will be where you’ll shortly be finding posts and information on upcoming controls. I’ll be approaching the work with a somewhat agile approach – centred around short iterations, user stories, regular releases, and providing far greater feedback. It’s something I’ve appreciated from ISVs as a professional developer, so I’m looking to provide the same.

In my next few posts I’ll hopefully cover more about the development process, as well as marketing/selling of products etc.

Until then, pleased to meet you, and hope you stop back again.

Ok, it’s decided.

Finally tonight I’m getting on the blog-wagon. It’s something I’ve been meaning to do, but until I figured I had a reasonable belief in providing some content of any value I held off. Talking about something during work the other day with one of my colleagues prompted me into action so here I am.

As with most first posts, I figure it’s probably better to provide some kind of context and background. So first a tiny bit of background about me, why this site and blog, and what to expect from here in future.

By day I’m a C#/.NET developer within an agile team in central London, working mainly on web-based applications, and have been doing so for a few years. About 3 years ago (around when I was graduating from University) I decided that would start taking some of the stuff I’d be working on in my spare time (and posted on the CodeProject website, improve it, and sell it for a little bit of money.

The CodeProject articles were great for me, they provided an excellent way to test my (limited) knowledge of development and design, and provided a kind of instant feedback to a mass of developers that I would otherwise not have had. Although looking back now I can see large flaws in my thinking, or wince at the relative inelegance of the solution, at the time I was happy.

A few of my articles even led to people contacting me suggesting improvements, asking me to add features, alter the way things worked. I was glad of the response and welcomed the suggestions. So, it got me thinking that perhaps I could focus on building better quality, better supported, better working controls that I could perhaps sell. I touted this idea to a few people that emailed me to get an idea about the potential response and most was positive – that provided I could show additional value from the commercial code, developers seemed to be happy to pay.

And oobaloo was born. Don’t ask me where the name came from, I think it was just sound kind of sound I had in my head at the time I was trying to think up a domain name.

So, this site (and blog) will be where you’ll shortly be finding posts and information on upcoming controls. I’ll be approaching the work with a somewhat agile approach – centred around short iterations, user stories, regular releases, and providing far greater feedback. It’s something I’ve appreciated from ISVs as a professional developer, so I’m looking to provide the same.

In my next few posts I’ll hopefully cover more about the development process, as well as marketing/selling of products etc.

Until then, pleased to meet you, and hope you stop back again.