It turns out both Scott Cowan and Barry Dorrans have tagged me with the latest meme.  I guess I should respond :)

How old were you when you first started in programming?

I guess I was a late starter compared to others. I got my first PC when I was 12 and I think I started with web development when I was 15.  I started desktop development when I was 18, but I had played around a bit with VB6 before then.

What was your first programming language?

While everyone else is saying assembly or some low level language, my first programming experience was with ASP 3.0 where I developed a commercial website but I guess that doesn’t count as a real language. After that I guess Eiffel was my first real language I knew to a good level while at University.

What was the first real program you wrote?

As I mentioned, I started with web development.  My webpage took user input and emailed it via CGI FormMail.  My next larger project was the ASP 3.0 website which took user input and stored it in an access database.  It also had a few admin sections, some interactions with CDO etc.

I then left development alone for a while while I worked as Tech Support \ SysAdmin.

My first real program was a web server using Eiffel in my first 3 months at University – told you I was a late starter for software development.

What languages have you used since you started programming?

From memory, the languages I have used in a commercial \ real project sense are:

VBScript, Java, VB6, C#, Ruby

I’ve then played around with:

Python, VB.net, Eiffel, C++, Scheme, Prolog

What was your first professional programming gig?

The ASP website was semi-professional (I got paid), and I did this when I was 15 at school.  First full-time position was at a transaction handling company during my year in industry at University. This was a mix of VB6 and C# 1.1 with a SQL Server 2000 backend where I worked on a lot of bug fixes and maintenance work.  During this time I attempt to introduce some improved ways of working, more automation and its where I found my interests in TDD (but we wasn’t doing it there).

If you knew then what you know now, would you have started programming?

Definitively! I just would have started earlier. I think I would also have started to release software sooner – just small applications which solve real problems.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Don’t do it for the money, do it because you love it. Community matters! Talk to people, it is the best way to learn. 

What's the most fun you've ever had programming?

weLearn was good fun, if not a little stressful. This is the application we produced for the Imagine Cup while I was at University.  Two friends and myself created the application, promoted it internally at University and finally presenting it at MS UK Imagine Cup final.

Some of the work I did at my first company was very good fun as it was great to create something which solved real problems. The work I did was mainly around automating various day-to-day tasks, it was all done at home and nothing got implemented (management…) – but I know it would have worked :)

MbUnit was also fun when I first started, it was good to have some technical discussions with people. Sadly, I haven’t done much work on this for a while.

Who am I calling out?

John Lam

Ian Cooper

Richard Fennel

Colin Jack

Mike Hadlow

Labels: Personal

Previously, I have spoke about how you can update your AssemblyInfo file using MSBuild. However, I haven’t spoken about the very basics – how to build a Visual Studio solution and execute your unit tests.

MSBuild is a very interesting build scripting language, out of the box it includes a set of standard tasks which you can use based on your requirements, such as creating a directory or copying a file in order to correctly build your project. I also take advantage of the MSBuild community task project, while it hasn’t been updated in a while, the tasks work perfectly.

Below is the basic MSBuild script.

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Test" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/> 
    <Target Name="Build">
        <Message Text="Starting to Build"/>
        <MSBuild Projects="TeamCityBlogExample.sln" Properties="Configuration=Release" />
    </Target>
    <Target Name="Test" DependsOnTargets="Build">
        <Message Text="Starting to Test"/>
        <NUnit Assemblies="TeamCityBlogExample.Tests\bin\Release\TeamCityBlogExample.Tests.dll"
               ContinueOnError="false"
               ToolPath="C:\Program Files\TestDriven.NET 2.0\NUnit\2.4\" 
               OutputXmlFile="NUnitResults.xml" />
    </Target>
</Project>

Within the project section at the top, I set the default target to Test. This is the target which will be executed first, the Test target then has a DependsOnTarget attribute which enforces that the build must be done before we test.

On line 3, I import a reference to the MSBuild community tasks so I can access all of the custom tasks included – such as NUnit.  Next I define my build target, within this I define the solution I want to build and the configuration. To execute my unit tests, I use the NUnit task from the community task project, this takes a list of all the assemblies which we need to run, define if a test fails wether it should fail the build and finally tell it where NUnit lives on the local machine.

Now, the script can be executed by a build system, such as CCNet or TeamCity, or from the command line using the msbuild.exe <scriptname> command and build your solution and execute your unit tests.

Download script: http://blog.benhall.me.uk/Code/Build/BaseMSBuildScript.txt

Labels: MSBuild, TeamCity

On Tuesday I gave a 10 minute nugget at NxtGenUG Cambridge on how to setup a project using JetBrain’s TeamCity. TeamCity is a continuous integration server, similar to CruiseControl.NET, however I find it much more useful, easy to use and more importantly easy to manage. In this post, I thought I would explain how easy it is to setup a new TeamCity project.

Installing TeamCity is an easy process, you simply download the installer from the site and click next a few times.  This will install both the server and a build agent, TeamCity allows for multiple build agents on different machines to allow you to share the load of building and running tests.

Once it has been installed, visit the webpage (for me this was localhost:8080). You will need to accept the license agreement and create an admin account.  You will then be shown with the homepage for the server. Click the nice big Create project link.

You will then need to enter a friendly name for your project.

Your project has now been created. The next stage is to add a build configuration, this will be how the project monitors source control and what is executes to build the project.

After clicking Create build configuration, you will be shown the first build configuration page.  Give this a friendly name, you can then enter a build number which can be used in your build scripts and on TeamCity’s UI as I described in a previous post.

Next, you can enter some artifacts, these are the files which are saved and stored on the build server.  These files could be your binaries or an installer. For example, to copy everything to a build\release directory the syntax would be:

“**/*.* => builds/Release/”

Next stage is setup the source control which TeamCity should monitor.

Click Create and Attach new VCS root. Given this a friendly name, and select the type for example Subversion. Enter the url of the SVN server, this is the directory which will be monitored. For example, it could be https://Newbie:8443/svn/TeamCityDemo/trunk

You VCS is now setup.

The next stage is to configure the build runner. This defines how to build the project. Below, I’m using MSBuild, which when it needs to build it will execute msbuild with the script src\build.msbuild.

That is now your project created. The final stage is to use build triggering by ticking the enable box. This is what will cause the project to be built when you commit an item.

Your now ready to go – everything is setup.  The project and builds now appear on the main homepage.

Let the automated builds begin!

Labels: TeamCity

During the development lifecycle, there are many different automated tests which should be wrote, each style of test has different priorities and different levels of maintenance required. For example, TDD helps with designing the code your just about to write, they are small and focused. As such, when your code changes, your tests change too. Where as acceptance tests have a much longer life-time, there role is to ensure the application works and nothing is regressed as developers continue to make changes. These tests need to be maintainable enough to cope with application changes, readable enough to identity the story \ feature they are testing with reusable\flexible sections to help readability and maintainability.

In an attempt for my tests to meet these goals, recently I've been using delegates in certain scenarios to improve my test code. Delegates are great for reusing sections of code, it allows you to have static sections of code but be flexible to cope with minor changes and different scenarios the tests might cover.

For example, below is an acceptance test which must connect to a server based on a project file which has been saved to disk.  Remember, acceptance tests should cover the system in an end-to-end fashion.

In order to test the application, the code needs to do a lot.  It needs to create and configure a project, save it to disk, create the service and finally it gets to the point of what it is testing - connecting to the service. This code, while it is flexible it is not very maintainable. If we need to change something related to the project or how we connect to the service we would have to change a lot of code to take this into account.

public class Project_Execute_Tests_Standard
{
    [Fact]
    public void Project_Can_Login_And_Can_Connect()
    {
        string path = System.IO.Path.GetRandomFileName();

        Service service = null;
        try
        {
            Project project = new Project();
            project.Server = "Test";
            project.Username = "Admin";
            project.Password = "Password";
            project.Save(path);

            service = new Service();
            service.Start();

            service.LoadProject(path);

            bool connect = service.Connect();
            Assert.True(connect);
        }
        finally
        {
            if(service != null && service.Started)
                service.Stop();
            File.Delete(path);
        }
    }
}

The first logical step would be to use helper methods.  We can extract the creation of the project and gaining access to the service into separate methods which we can reuse throughout our test code. However, these methods aren't very flexible, if we need to add some more configuration to the project we would have to create a different method and as such losing some of our maintainability.

[Fact]
public void Project_Can_Login_And_Can_Connect()
{
    string path = string.Empty;
    Service service = null;
    try
    {
        path = CreateProject();

        service = GetService(path);
        bool connect = service.Connect();
        Assert.True(connect);
    }
    finally
    {
        if (service != null && service.Started)
            service.Stop();
        File.Delete(path);
    }
}

This is why I like delegates. You have the advantage of helper methods, but the flexibility of having the code inline. Below I've created a helper class, this abstracts away from my actual implementation and manages the state, such as the file path for the project. Within the delegate for the project, I'm setting all the details based on the requirements of the test and different configurations, however the rest is abstracted away.

public class Project_Execute_Tests_Delegate
{
    [Fact]
    public void Project_Can_Login_And_Can_Connect()
    {
        ServiceTester tester = new ServiceTester();
        tester.CreateProject(delegate(Project project)
                                        {
                                            project.Server = "Test";
                                            project.Username = "Admin";
                                            project.Password = "Password";
                                        });

        bool connect = tester.ConnectToService();
        Assert.True(connect);
    }
}

While I was writing this example, DevExpress popped up and told me it can shorten my delegate to a lambda expression. As a result, the delegate could be this.

tester.CreateProject(p =>
                            {
                                p.Server = "Test";
                                p.Username = "Admin";
                                p.Password = "Password";
                            });

Within my ServiceTester helper class, my CreateProject method looks like this:

public delegate void ProjectDelegate (Project project);
public void CreateProject(ProjectDelegate ProjectSettings)
{
     ProjectPath = System.IO.Path.GetRandomFileName();
     Project project = new Project();

     ProjectSettings(project);
     project.Save(ProjectPath);
}

Given the right scenario, I think this could really improve your test code.

Download complete code sample: http://blog.benhall.me.uk/Code/Test/TestCodeDelegates.txt

Labels: TDD, Testing

Codeplex have recently added a new feature – mailing lists for the project.  This means you can use the discussion forum\board in the style of a mailing list. To join a ‘mailing list’ for a project, login to CodePlex and visit the Discussion tab for a project

Click get email notifications, you can then select how you would like the messages to be delivered. However, its a shame you can’t have a different project address and discussion address, I like to use Googlemail for all discussions as it has a much better interface but my private webmail for personal emails.

You have now signed up to the ‘mailing list’. To post a message, you send an email to <ProjectName>@discussions.codeplex.com, where ProjectName is the name in the URL. For example IronEditor@discussions.codeplex.com

Your email message will then be placed on the discussion board. This actually took a while to appear, I don’t know if it was because I had only just created the project.

Very useful feature, means all discussions can happen in a central place without having to go to a separate service provider (Google Groups).

Documentation:
http://www.codeplex.com/CodePlex/Wiki/View.aspx?title=Mailing%20Lists&referringTitle=CodePlex%20Documentation

Labels: CodePlex

For a while now I have been working on an application called IronEditor, this is a simple application designed to make it easier to pick up and start coding against the DLR based languages. By taking advantage of the DLR's Hosting API, the application can execute code for any language built on top of the DLR platform.

The project is hosted at CodePlex, along with all of the source code.

Download: http://www.codeplex.com/IronEditor

Build: 1.0.0.46

Out of the box, the application works with IronRuby and IronPython, however one of the main aims of the application is to allow other languages to be easily embedded into the application.

The reason why I decided to build this is because Visual Studio Integration for the languages is a long way off and while playing around and creating code to use the languages is painful via the provided console applications. As such, the aim of the application is to provide a very lightweight way to edit and execute code, great while learning the languages and giving demos (I used this application for my NxtGenUG Oxford DLR session).

One of the items I'm really pleased about is the fact that the application works on Mono (Tested only on Ubuntu 8.04 and Mono 1.9.1), something which will definitely not be possible with the Visual Studio integration.

To run the application, you will need to ensure you have Mono installed on your machine. Download the application and extract the zip into a directory. Then enter the command:

mono IronEditor.exe

You will then have the same application, same binaries everything working on Mono.  The only difference is that syntax highlighting for IronPython doesn't work at the moment.

I admit, at the moment the application is very basic. However, over the next few weeks and months I will build new features into the application to make it easier to start playing around with the DLR languages.

Executing IronRuby and IronPython Code

1) Start the application

2) File > New Project

3) From the drop down, select your language

4) Type some code (print 'Hello World' is always good)

5) Press the green arrow, or hit F5.  Code is executed and the output is wrote to the Output Window.

Very quick and easy I think!

There are some very big limitations and bugs within the application, but I'm going for the 'Release Early, Release Often' approach. Various items could be improved, for example Ruby doesn't have any syntax highlighting but this will come in time. There are some other much larger features I want to implement, keep an eye on the blog for more information as and when. Over the next few weeks I will also be blogging about the implementation of IronEditor and how it uses the DLR Hosting API. 

Any feedback is most welcome!

NOTE: As I mentioned this is a very early, it hasn't had a great deal of testing.  Please don't use it on your production code base just yet! I wanted to get a release out for some initial feedback, if it causes everything to go wrong - I'm very sorry!

Download: http://www.codeplex.com/IronEditor

Build: 1.0.0.46

Labels: DLR, IronEditor, IronPython, IronRuby

We have just opened registration for the Alt.Net.UK Summer Conference. To register visit http://altdotnet.org/events/5 . Once the registration is full, you will be able to join the waiting list incase of cancellations.

If you have any problems or questions, please let me know - either leave a comment or email me at Blog {at} Ben Hall . me . uk

The plan is host the event at Conway Hall in London and our thinking is to follow the same sort of schedule as we did in February:
- Evening planning session on Friday 12th September, following by a trip to a bar to socialise.
- The Open Spaces sessions all day on Saturday 13th September

For more information take a look at my previous announcement and the Alt.Net.UK website.  Details regarding hotels and bars will be made available at a later point.

What is the conference format?

The conference will be based on the open spaces format.

Whoever shows up is the right group. Whatever happens is the only thing that could have. Whenever it starts is the right time. When it's over, it's over.  An Open Space conference's agenda is decided upon by the conference participants during the opening of the event.

What is Alt.Net?

Various blog posts have defined Alt.Net.  Term originally coined by David Laribee on his blog.

Who are the organisers?

Ian Cooper, Alan Dean and Ben Hall.  Conchango and Red Gate are also providing support.  

Labels: Alt.net, alt.net.uk

We are pleased to announce that the Alt.Net UK Conference will be returning in September, and that there will be room for more attendees this time!

The plan is host the event at Conway Hall in London [1] and our thinking is to follow the same sort of schedule as we did in February:
- Evening planning session on Friday 12th September, following by a trip to a bar to socialise.
- The Open Spaces sessions all day on Saturday 13th September

This time we are thinking of starting off Saturday with a Park Bench to get the juices flowing.

We are very open to listening to feedback from the community if you think that there are ways that we can improve on the conference experience.

We would especially like to have more testers, technical authors and usability folk attend to foster cross-pollination of ideas.

User registration will start from Friday 11th July at 07:00 UK time [2] so the early birds will get the worm!

The following social hubs have also been set up: Upcoming [3], Facebook [4], FriendFeed [5] and LinkedIn. Don't forget that you can subscribe to the AltNetUk News River [6].

Finally, we are currently looking for sponsorship, so if you know of an organisation that would be interested to be associated with the conference in return for a little lucre, we would love to hear from you / them! (The conference is non-profit)

Conchango and RedGate have generously agreed to be launch sponsors - but more is needed, especially as we have to pay for Conway Hall this time.

[1] http://www.conwayhall.org.uk/

[2] http://altdotnet.org/events/5

[3] http://upcoming.yahoo.com/event/867921/

[4] http://www.facebook.com/group.php?gid=31833353320

[5] http://friendfeed.com/rooms/altnetuk-conference

[6] http://newsriver.altnetuk.com/

Regards,
Ian Cooper, Ben Hall and Alan Dean

Labels: Alt.net, alt.net.uk

Yesterday afternoon I received an email from Microsoft telling me I have been awarded the MVP award for my "extraordinary efforts in Visual C# technical communities during the past year." Excellent!!

I'm really happy with this award and I hope it allows me to contribute even more to the community.  I would also like to say a big thank you to everyone in the UK Community (you all know who you are...) who has supported me over the past couple of years.

I'm sure it will be an interesting year ahead!!

Labels: MVP

Last night I present my a new session for me, 'It's all dynamic with the DLR!', at NxtGenUG Oxford. The session was an introduction into the DLR, where I covered how languages are implemented (with the example of ToyScript) and how to embed the DLR within your own applications.

Personally, I was really happy with how the session went. I was a little worried about Barry being in the audience, but actually it was really good fun having him there and I think it helped the session with his 'insightful' questions.

A big thank you to the the Oxford group (Organised by Barry Dorrans and Chris Seary) for having me and the group for listening.

Download

Slides: http://blog.benhall.me.uk/downloads/NxtGenUG/DLR/DLR.zip

Demos: http://blog.benhall.me.uk/downloads/NxtGenUG/DLR/Demos.zip

Labels: NxtGenUG