Archive for December, 2008

Gotta Love A Clean Development Environment

5 commentsWritten on December 24th, 2008 by
Categories: Off Topic

Just installed a new development system for personal use... currently i only have the following installed:

  • Windows XP Professional, with Service Pack 3: i don't have Windows 2008 and i still don't consider Vista to be a valid option
  • SQL Server 2005 Developer Edition: i don't have the 2008 version, plus the 2005 version more than suits my needs
  • Visual Studio 2008 with Service Pack 1: duh....
  • Resharper 4.1: duh... won't use Visual Studio without it
  • TortoiseSVN + VisualSVN: TortoiseSVN is great already, but the Visual Studio integration that VisualSVN provides is so nice that i can't go back to just using TortoiseSVN.
  • NHibernate Profiler: it's not even out of private beta and i already consider this a must-have tool... i hope Ayende is gonna go easy on the licensing cost for this ;)
  • dotTrace: you gotta have a profiler, right?

Anything else i should consider installing? I only use this system for development so i don't want any suggestions that aren't related to that.

On a side note, despite being a Parallels customer i set this system up in VMWare Fusion. According to some reviews i read, Fusion beats Parallels when it comes to IO, making the system feel more 'snappy'. I've been very impressed with the Fusion performance already so i just bought a license and am planning to use Fusion exclusively from now on instead of Parallels.

The Unrealistic Deadline Anti-Pattern

8 commentsWritten on December 23rd, 2008 by
Categories: Software Development

I just read this post from Mohammad Azam about a project that was impossible to do using Agile practices.

I quote:

A reasonable deadline for the project was approximately 3 months but it had to be completed in a month. At this time an agile book will indicate that the developer should talk to the owner and come to a reasonable deadline. Unfortunately, in this case the owner was fixed with the deadline and was not willing to move it further.

The author further concludes that following the agile principles would have killed the project. He dropped some of the agile principles and practices, and finished the project in 29 days.

Yes, the resultant code was messy but at the end I get to keep my job.

I have no problem with Mohammad dropping agile practices/principles in order to complete this on time and to help him keep his job (especially in the current economy). I do have a problem with the idea that 'Agile' can kill a project. The only thing that killed this project is the unrealistic deadline which was set by the owner. The fact that the project was delivered within the requested time frame, and even assuming that it is completely satisfactory to the owner, does not mean that it was a good idea to hold this project to a deadline which only allowed for one third of the estimated workload.

Now some of you are probably thinking "the deadline couldn't have killed the project since it was delivered within that deadline!". True, to a point. We all know what happens when developers face tight deadlines: they take technical shortcuts and they accumulate technical debt. Mohammad already stated that the resulting code was messy so i guess it's safe to assume there's quite a bit of technical debt there. Being in technical debt is like owing money to Tony Soprano... you better get out of debt fast or things are gonna get much worse, very soon even. The longer you wait with paying off the debt, the more you'll lose certain abilities and possibilities.

Getting out of technical debt can be pretty expensive, but there's not really an alternative. If you don't get out of debt, further maintenance of the code base and adding new features will only become more expensive over time. Failure to pay off the debt will sooner or later kill the project entirely because the gains that the project brings are no longer greater than the costs that come with it. At that point, the decision is often made to build a new system to replace the old one. The new one is gonna fix all of the problems of the old one. And if you're lucky, the managers will have figured out by then that unrealistic deadlines only cost more money in the long term than a reasonable deadline would have.

Favorite Operating System For Development?

7 commentsWritten on December 22nd, 2008 by
Categories: Off Topic

With the recent news that the cutoff date for Windows XP has been extended by a few more months, i was wondering which operating system you guys prefer for development. So i've added a poll to the site (it's on the right top of the page) where you can cast your vote.

I have to admit that i still prefer Windows XP, probably because it's the lightest one of them all at the moment, and since i run XP in a Parallels VM on a cheap Macbook, that kinda matters ;)

At work, i'm using Windows Vista... not really happy with it though...

The Resolvable

1 Comment »Written on December 21st, 2008 by
Categories: Castle Windsor, Memory Management

I wrote a post last week about a memory leak i had introduced in my code due to not properly releasing resolved components through the Windsor IoC container. I wanted to try to make sure that i'd never make that mistake again and this is the approach i came up with.

If you're using an IOC container it's important to not use it all over the place. You basically use it in as few places as possible to resolve a component and you let the container sort out all of the dependencies. So in the few places where you use the container directly, you need to resolve the component, and in case of transient components you also need to release them through the container. Releasing it is very easy to forget, so i wanted something that would guarantee that the component would be properly released. Enter the Resolvable class:

    public class Resolvable<T> : Disposable
    {
        private readonly T instance;
 
        public Resolvable() : this(null) {}
 
        public Resolvable(object argumentsAsAnonymousType)
        {
            if (argumentsAsAnonymousType == null)
            {
                instance = IoC.Container.Resolve<T>();
            }
            else
            {
                instance = IoC.Container.Resolve<T>(argumentsAsAnonymousType);
            }
        }
 
        public T Instance
        {
            get { return instance; }
        }
 
        protected override void DisposeManagedResources()
        {
            IoC.Container.Release(instance);
        }
    }

The Resolvable class inherits from my Disposable class, so the Disposable pattern is correctly implemented.

From now on, instead of calling the container directly, i just instantiate a new Resolvable in a using block. Let's try it out.

I'm reusing my test component with a dependency from one of the previous posts:

    public interface IDependency : IDisposable
    {
        bool Disposed { get; set; }
    }
 
    public class MyDependency : IDependency
    {
        public bool Disposed { get; set; }
 
        public void Dispose()
        {
            Disposed = true;
        }
    }
 
    public interface IController : IDisposable
    {
        bool Disposed { get; set; }
        IDependency Dependency { get; }
    }
 
    public class Controller : IController
    {
        public IDependency Dependency { get; private set; }
 
        public Controller(IDependency myDependency)
        {
            Dependency = myDependency;
        }
 
        public void Dispose()
        {
            Dependency.Dispose();
            Disposed = true;
        }
 
        public bool Disposed { get; set; }
    }

Now, instead of resolving an IController directly through the container and having to dispose of it, i just do this:

        [Test]
        public void ResolvableInstanceIsProperlyReleasedAfterDisposal()
        {
            IoC.Container.Register(Component.For<IController>().ImplementedBy<Controller>().LifeStyle.Transient);
            IoC.Container.Register(Component.For<IDependency>().ImplementedBy<MyDependency>().LifeStyle.Transient);
 
            IController controller;
            IDependency dependency;
 
            using (var resolvable = new Resolvable<IController>())
            {
                controller = resolvable.Instance;
                dependency = controller.Dependency;
            }
 
            Assert.IsTrue(controller.Disposed);
            Assert.IsTrue(dependency.Disposed);
            Assert.IsFalse(IoC.Container.Kernel.ReleasePolicy.HasTrack(controller));
            Assert.IsFalse(IoC.Container.Kernel.ReleasePolicy.HasTrack(dependency));
        }

The container doesn't hold the reference to the instance, and both the instance and its dependency is properly disposed.

Is This A Good Approach For Multi-Tenancy Or Not?

4 commentsWritten on December 17th, 2008 by
Categories: Software Development

Here's the situation: we have an application which is used by multiple customers. The application consists of various functional modules. Each customer can use one or many (or obviously all) of these modules. In the past we used to deploy this application for each customer. The configuration file contained various settings that could differ from customer to customer and obviously, each deployed version had its specific configuration file depending on the settings required for each customer. This approach worked, but it was not really ideal.

Multi-tenancy to the rescue! Not sure if this counts as the official definition of multi-tenancy, but wikipedia defines it likes this:

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a software-as-a-service (SaaS) vendor's servers, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration so that each client organization works with a customized virtual application instance.

Sounds like this is exactly what we're looking for. So i've recently been working on changing the application to support this, and i came up with the approach i will outline in the rest of this post. The approach does not strictly comply with the definition above, but it does seem to comply with Ayende's definition of it. I'd like to get some feedback from you guys as to whether you believe this approach is good or not, what could be better, what we need to keep in mind, etc...

First of all, i would like to point out that this application already exists. We already have a database with about 200 tables in it and there are about 150 pages (it's a web app obviously). So obviously, we can't just change everything to make it fully compliant with 'the definition'.

Let's start with the database. Instead of trying to use one huge database to keep all of the tenants' data, which would require modifications in a large amount of the existing tables, we've decided to go with a separate database for each tenant. Each database will have an identical structure, regardless of whether some functional modules are used or not by a particular tenant. There is also one 'master' database which contains tenant-specific data. Basically it contains all of the configuration settings for each tenant, including connection strings to each tenants' specific database. The connection strings do not contain user names and passwords as we will use Windows' Integrated Security to connect to the specific databases (more on that in a bit).

Now for the application itself. Our first idea was to have one actual instance of the application, and the application would be able to determine the current tenant for each request based on the URL of the incoming request. Tenant A would have an URL like tenanta.ourproduct.com, tenant B would have tenantb.ourproduct.com etc. The application would basically use the URL to get the correct tenant-info from the master database (note that the connection string to the master database would be the only connection string we'd have in the application's configuration file) and it would then use the tenant-specific database for each request with the tenant's application URL.

The idea was to use an NHibernate SessionFactory for each specific tenant. You obviously can't use just one because you're using multiple databases. But we also use NHibernate's 2nd Level Cache, which is problematic when you're using multiple SessionFactories. The 2nd Level Cache is great, but it doesn't differentiate between multiple SessionFactories. So if you have the result of a specific query cached, you could get that data back for a different tenant than the one the data actually belongs to if the query's parameters happen to be identical. Btw, if i'm wrong about this please let me know.

So then we figured we could still use one physical deployment (as in: one physical folder where the application is located), and then we'd use multiple virtual directories in IIS which all point to the same physical folder. We'd basically have one virtual directory (and one instance of the application) per tenant. We still have the benefit of one physical deployment, and because each tenant's 'virtual' application runs in its own AppDomain, the caching problem is no longer an issue. Each virtual directory is configured for the URL of its tenant and the running instance of the application can still retrieve the actual tenant's data from the master database based on the URL. Each virtual directory can run in its own Application Pool which can be set up to run under a Windows account which is specific to the current tenant. This allows us to use Integrated Security when connecting to the tenant-specific database. So each tenant would only have access to the master database and its own specific database.

Obviously, this approach would require a bit more effort in our 'management module' (which is yet to be written). Whenever we need to add a tenant, we not only have to create a specific database for the tenant, we'd also have to create a new windows account for the tenant, set up a new virtual directory, and an application pool if each tenant indeed runs in its own application pool under it's own Windows account.

Apart from the management module, i've modified the application to work with this approach in just a few days work. But, nothing is final just yet... so now i'd like to hear from you guys whether this is a good approach or not. What are the possible problems we need to take into account? Is this really still multi-tenancy? I guess the opinions on this will be divided, but it does largely solve the issue of multiple deployment and multiple configuration files. True, the configuration is now mostly in the master database and those settings need to be maintained as well. However, they could now be maintained without having to redeploy the application which is a plus. Some settings could even be modified by the tenant itself (at least, the users who have the proper privileges to do so).

So anyways, i'm awaiting your feedback :)

UPDATE: i've been told that i can simply use a different cache region for each tenant in NHibernate's 2nd Level Cache... so i could avoid having to use multiple instances of the application. Still not sure on whether one instance for all tenants would be better than one instance for each tenant though.

« Older EntriesNewer Entries »

Meta

Recent Posts

Categories