Sergey Shishkin

on agile software development

Archive for December 2009

Mono as a lightweight .NET runtime

How big is .NET 3.5 runtime? The full redistributable package for x86, x64 and ia64 platforms including 2.0 and 3.0 is about 200 MB. Not a single user needs to download and install it all: somebody already has 2.0 or maybe even 3.0, and nobody is going to install all the supported architectures (x86 etc.) on a single machine. So this huge download is only intended to be distributed on a CD or DVD with applications requiring .NET, when you don’t know in advance what platform you are targeting. If you do know the user’s platform in advance, you can downstrip the package down to some 20-60 MB. Which is pretty good.

Anyways .NET Framework has to be installed using Windows Installer, and it’s a quite invasive way of deploying an application. Can somebody XCOPY-install .NET Framework? I suppose it to be very tricky if possible at all. And we have those copyrights and license agreements saying that Windows Installer is the only legal way to deploy .NET runtime to users.

All this problems might seem illusive, since Microsoft is pushing .NET Framework through Windows Update and starting from Windows XP SP3 and Vista RTM users get at least .NET 2.0 installed. But the e-health market, my company works in, is very conservative (at least in Germany) and users are still running Windows 2000 with windows apps emulating DOS-like GUI. It is horrible! We can not rely on any Windows Updates or even a live and fast internet connection to run the .NET Framework setup bootstrapper. Moreover, our software, a web service, should be deployed as an integrated component into some third party application (almost definitely not a .NET one). And the more complex our deployment story is, the less partners would want to embed our software into their products.

Are there any alternatives out there?

One can turn to virtualization solutions. But instead of hardware virtualization, one can virtualize the .NET runtime. Using Xenocode Postbuild it is possible to compile a managed application into an unmanaged one with embedded fully functioning .NET runtime. The size of an app starts from 11 MB for a simple Hello World App and is from 40 MB in a real world scenario (without deleting unused .NET code, so that reflection can work properly). And this is pretty good, although not cheap.

Here comes Mono

There is also the Mono Project out there, which contains an open source runtime compatible with .NET CLR on binary level. It means that you can run apps compiled for .NET CLR on Mono CLR without recompilation. Mono’s cross-platform nature makes it much simpler in what it means to deploy the runtime. You just have to fulfill the requirements of the LGPL or obtain a commercial license from Novell.

How it works?

So I downloaded and installed the full Mono for Windows package and started to play with it. My aim was to get a minimal subset of Mono to be able to run the Mono’s XSP development web server and its test web site (\lib\xsp\test\).

The result is the following structure of 45 files only 21 MB in size total:

\bin\libglib-2.0-0.dll
\bin\libgthread-2.0-0.dll
\bin\mono.dll
\bin\mono.exe
\bin\run.cmd
\etc\mono\2.0\Browsers
\etc\mono\2.0\DefaultWsdlHelpGenerator.aspx
\etc\mono\2.0\machine.config
\etc\mono\2.0\settings.map
\etc\mono\2.0\web.config
\etc\mono\2.0\Browsers\Compat.browser
\lib\mono\2.0\Accessibility.dll
\lib\mono\2.0\gmcs.exe
\lib\mono\2.0\gmcs.exe.config
\lib\mono\2.0\Mono.Data.Tds.dll
\lib\mono\2.0\Mono.Messaging.dll
\lib\mono\2.0\Mono.Posix.dll
\lib\mono\2.0\Mono.Security.dll
\lib\mono\2.0\Mono.Web.dll
\lib\mono\2.0\Mono.WebBrowser.dll
\lib\mono\2.0\Mono.WebServer2.dll
\lib\mono\2.0\mscorlib.dll
\lib\mono\2.0\System.Configuration.dll
\lib\mono\2.0\System.Configuration.Install.dll
\lib\mono\2.0\System.Core.dll
\lib\mono\2.0\System.Data.dll
\lib\mono\2.0\System.Data.Linq.dll
\lib\mono\2.0\System.dll
\lib\mono\2.0\System.Drawing.dll
\lib\mono\2.0\System.EnterpriseServices.dll
\lib\mono\2.0\System.IdentityModel.dll
\lib\mono\2.0\System.IdentityModel.Selectors.dll
\lib\mono\2.0\System.Messaging.dll
\lib\mono\2.0\System.Runtime.Serialization.dll
\lib\mono\2.0\System.Security.dll
\lib\mono\2.0\System.ServiceModel.dll
\lib\mono\2.0\System.ServiceModel.Web.dll
\lib\mono\2.0\System.Transactions.dll
\lib\mono\2.0\System.Web.dll
\lib\mono\2.0\System.Web.Extensions.dll
\lib\mono\2.0\System.Web.Services.dll
\lib\mono\2.0\System.Windows.Forms.dll
\lib\mono\2.0\System.Xml.dll
\lib\mono\2.0\System.Xml.Linq.dll
\lib\mono\2.0\xsp2.exe

It is still far from perfection (why ASP.NET applications need System.Windows.Forms, for example), but it is a good proof of concept. I’m only a newbie to the whole world of Mono. But now I can start a web site on a windows machine without any .NET Framework installed from a website folder just like this:

..\mono-mini-2.6.1\bin\run.cmd ..\mono-mini-2.6.1\lib\mono\2.0\xsp2.exe –root . –port 8080 –applications /:.

In order to make it repeatable, I made a batch script that creates this Mono-mini package out of a real Mono installation. It can be used like this:

mono-mini.cmd c:\work\ExternalBin\Mono-2.6.1 c:\temp\mono-mini-2.6.1

Summary

I’ve got an XCOPY-deployable .NET runtime for my ASP.NET web services with 3.5 support in under 21 MB (7.5 MB zipped) which works on my machine 🙂 What now?

  • I need to test it thoroughly with the apps I will run on it. It is still possible that some components are missing.
  • Also I might remove the Windows Forms dependency but it would require me to patch the machine.config and the global web.config though.
  • All this bin\, lib\, etc\ coming from the linux-background of Mono could easily be simplified for the Mono-mini package.
  • Some licensing questions are yet to be clarified. When licensed under LGPL, Mono is not allowed to be embedded into a non-LGPL executable, AFAIK. So, making deployment even more simple with Xenocode (only as an assembly repackaging solution) or .NETZ (for the same purpose) is not possible without purchasing the commercial license from Novell.
Technorati Tags:

Written by Sergey Shishkin

24.12.2009 at 20:41

Posted in Development

Story Of Change

Friday was a huge day for me! My team officially announced that we a going to implement Scrum. This was by no means an easy change. It took us 9 month and I just want to save this story in my blog for the records.

Why Change?

In April 2009 I was architect in a company using “waterfall” process with 3 month release cycles in a team of 40 people separated in 3 full blown departments of “product management”, “development” and “quality assurance” with its own organizational structures and typical “us against them” mindset. In addition to that there are also technical writers, who have to write all the user manuals on weekends after the code is implemented, and support engineers, who keep distracting developers with all those “urgent customer issues”.

PM was aimed to complete the software specifications before the “spec-freeze” milestone and throw it at DEV over the fence. Specs were long boring documents with faked GUI screenshots and lots of ambiguity. While PMs were writing specs, DEV made housekeeping, fixing bugs or writing code that DEV thought will be useful in future. With a spec at hands DEV coded like crazy to hit the deadline. Then QA started thoroughly comparing the spec with the software and filing found bugs or what QA thought was a bug. Nobody had time to make his or her job right.

After each release we heard the same annoying phrase from our management: “It was the toughest release ever, but we did it!” It supposed to be motivating 😉

After an unfortunate try to present Scrum with all its “pigs” and “chickens” to QA and PM, the word “Scrum” by itself became a taboo…

At that point in spring 2009 I was about to leave, especially seeing some of my colleagues leaving too. But after some management rearrangements in DEV department, I decided to give it a try to facilitate the change to Agile before I leave.

What Changed?

Today we have:

  • Sprints, which are 2 weeks long and relative consistent in terms of work committed and work delivered.
  • Teams consisting of DEV and QA sitting together in one room (pro team), communicating with each other and helping each other.
  • Teams estimate requirements and pull them from the Product Backlog into their Sprint Backlogs during Sprint Planning meetings.
  • Teams decide how requirements are going to be implemented.
  • Specification is emerging during the Sprint as a joint effort of PM, DEV and QA in form of FitNesse tests.
  • Technical writers use Sprint deliverables immediately and have an opportunity to schedule their work accordingly.
  • All “urgent customer issues” go first through the Product Owner, who is responsible for prioritizing them and putting into the Product Backlog. If it is really urgent, it goes directly to the Fast Lane on the Task Board to be pulled by a team member.
  • A few Certified ScrumMasters and Product Owners.

How?

These are all things that we practice for some time already. Although not everything from the list works frictionless. Nonetheless the “change” on Friday was more like a Scrum training for all teams and an announcement “Oh, by the way, we are actually doing Scrum already” 😉

It was an incredibly hard change, I must say. And it did not come by my will only. It could not happen without support from several people in our company who were willing to listen. Together we did it. But there are still a lot of things to do on the way to Agile. The only thing I know for sure is that there is no way back to the stone age of waterfall process anymore.

I write all this because since then Agile has become my topic of interest and I hope to be writing more on it in future. I stumbled upon many obstacles while bringing agile ideas to different people and it was always fascinating and invaluable experience. Stay tuned 😉

Technorati Tags: ,

Written by Sergey Shishkin

16.12.2009 at 18:15

Posted in Agile

Reactive Extensions @DNUGK

Update: last time I forgot to put the usage example of the ExpectedSequence extension method. Fixed now. See the end of the post.

Previously introduced in Siverlight Toolkit, Microsoft Reactive Extensions (aka Rx) is making its way to be shipped within .NET Framework 4 now. Albert Weinert gave me an opportunity to demonstrate some of my geeky experiments with Rx on the DNUGK meeting yesterday.

The following API comparison between the well-known .NET iterator pattern and the new Rx observer summarizes the intent of Rx: provide API to work with events similar to that of collections, while preserving reactive nature (push-model) of events.

That means that we can do the same set-based operations with events as we already do with collections, e.g. Select, Concat, Join, Where, Merge etc. I must admit at this point that by events I don’t mean .NET events but rather more general occurrences of asynchronous nature, speaking Rx – anything that implements IObservable can be treated as an event and even participate in Linq queries.

To following example will make things more concrete:

public class KeySequencer

{

    private readonly Subject<char> keys = new Subject<char>();

    private bool shouldStop;

 

    public IObservable<char> Keys

    {

        get { return keys; }

    }

 

    public void Start()

    {

        while (!shouldStop)

        {

            var key = Console.ReadKey(false).KeyChar;

            keys.OnNext(key);

        }

 

        Console.WriteLine("exit");

    }

 

    public void Stop()

    {

        shouldStop = true;

    }

}

The KeySequencer class publishes all the keys that user presses as a sequence of IObservable events via its Keys property. Creating an IObservable is in fact very simple – I use the Subject class from Rx that is an “observable observer”. As an observer it has an OnNext method where I can push keys into, and as an observable it forwards them further to everyone who has subscribed down the line. Note that key events are of type Char. As I said, everything can be an event!

Well, the more interesting part is what we can do with those events published by the KeySequencer. First of all we can subscribe to them:

var keySequencer = new KeySequencer();

 

keySequencer.Keys.Subscribe(Console.WriteLine);

 

keySequencer.Start();

Now every character will be put out to the console twice – first when it’s pressed and after that when the subscribed Console.WriteLine method has been called. Still not impressive? What about that?:

Func<char, IObservable<char>> pressed =

    x => keySequencer.Keys.Where(key => key == x);

Func<char, IObservable<char>> notPressed =

    x => keySequencer.Keys.Where(key => key != x);

Func<char, IObservable<char>> followedBy = x

    => pressed(x).Take(1).Until(notPressed(x));

 

var exit =

    from e in pressed(‘e’)

    from x in followedBy(‘x’)

    from i in followedBy(‘i’)

    from t in followedBy(‘t’)

    select new Unit();

 

exit.Subscribe(x => keySequencer.Stop());

Here we define four further event sequences (pressed(‘e’), followedBy(‘x), followedBy(‘i’) and followedBy(‘t’)) and combine them into another event sequence (exit) which happens when the user types “exit”, so we can stop listening to keys being pressed and quit the program.

 

A further logical step could be to generalize the “expected sequence” pattern, of course with Linq in a nicely functional style:

public static class SequenceExtensions

{

    public static IObservable<T> SelectEqualTo<T>(
        this IObservable<T> source,
        T expected)

    {

        return source.Where(x => Equals(expected, x));

    }

 

    public static IObservable<T> SelectNotEqualTo<T>(
        this IObservable<T> source,
        T expected)

    {

        return source.Where(x => !Equals(expected, x));

    }

 

    public static IObservable<T> FollowedBy<T>(
        this IObservable<T> source,
        T expected)

    {

        return SelectEqualTo(source, expected)
            .Take(1).Until(SelectNotEqualTo(source, expected));

    }

 

    public static IObservable<IEnumerable<T>> ExpectedSequence<T>(

        this IObservable<T> source,

        IEnumerable<T> expectedSequence)

    {

        return expectedSequence

            .Select((item, index) => index == 0 ?

                SelectEqualTo(source, item) :

                FollowedBy(source, item))

            .Aggregate(

                Observable.Return(default(T)),

                (accumulator, item) => accumulator.SelectMany(_ => item))

            .Select(_ => expectedSequence);

    }

}

Now I can turn the “exit” sequence into this:

var exit = keySequencer.Keys.ExpectedSequence("exit");

exit.Subscribe(x => keySequencer.Stop());

And of course it works same way for any sequences. Just put a string as a parameter for character a sequence (since String implements IEnumerable<char>) or any other IEnumerable<T> for an IObservable<T> event source of your choice.

So, that were just my first steps in a new world of reactive programming with Rx. And I really liked it!

Written by Sergey Shishkin

11.12.2009 at 15:48

Posted in Presentations