Where’s Lou

I really need to dust off the blog. Awful how it’s sat here unused.

In my defense - I’ve been busy. There was a recent flight to GenCon 2010 of course, and a 27-hour drive to Wisconsin from Washington and back. Did it each way in a single shot, too. Much better than spending four days with a 14-hour drive around your break. Before that was a trip to Oslo to do a pair of presentations about Spark at NDC2010.

But that’s not what I’m talking about at the moment. It’s - - - Orchard!

0.5 is out, which means the infrastructure is baked enough to say it won’t entirely switch out from under you before a v1 release.

Some of the sub-systems of the platform (looking at the under-side that is) cover a feature-space including:

Integrated fundamentals - IoC, ORM, and MVC libraries out-of-the-box - because if the system didn’t do so, no module could make an assumption those services would be available.

Modularity - IoC capabilities are leaned on heavily to enable a seamless and automatically stitched together module/component development story. There was some considerable and interesting work put into producing an effect similar to dynamic compilation of modules when they’re dropped into place or altered outside of visual studio.

Content - a set of components in the Orchard.ContentManagement namespace builds a layer on top of the ORM repository pattern. Kind of like a domain model built in front of the relational model.

Commands - one of the concepts exposed from the core framework is a command handler component. There’s also an orchard.exe present in the web app bin directory which acts as a CLI bridge into a embedded instance of the orchard web environment it can host. In a nutshell you can script orchard, and modules can introduce additional commands.

Indexing - capabilities are present as a core module - with Lucene as an out-of-the-box implementation - all of this helps to ensure that a form of searchability is available, and module authors have an indexing and searching api’s in the base system they can use.

But, this is a quick post, and that’s just a small handful of things you’ll find under the hood. I’m quite happy about how many different aspects of the project have taken shape, and continue to be impressed sprint by sprint with the ingenuity and passion the folks on the team put into the effort.

Speeding up StackExchange is a good example of the motive and benefits to running multiple sites out of one instance of an ASP.NET app domain.

Update: Another good description is at Multi-tenancy in ASP.NET MVC - Why do we want it?

Not a new concept of course - the app domain itself is a framework-level implementation of multi-tenancy in a process. You could also say the process itself is an example of multi-tenancy in the operating system, and virtualized guest OS is multi-tenancy in the entire computer. You can see the pattern that forms, though, where each level you drop down has better isolation, and allows greater degree of variance between tenants, but comes at a higher cost in terms of resources or efficiency.

So it goes that multi-tenancy all the way up at the web application level should be the most efficient if you’re able to work with some limitations in freedom.

The most obvious limitation - everybody is running the same palette of code - isn’t even really the biggest issue. Being able to assume all of your tenants are on the same code, and that you can stage, test, and update all of them at a shot, could actually be a really nice benefit more than a problem. The real problems are singletons - anything static and stateful is a badness. This can be singleton extensibility points, or collections in libraries, or of course anything that’s in web config.

Your most powerful tool in avoiding places where your web application scrapes against (or introduces) a static and stateful point would be any of the modern inversion of control containers. An example of their use in that way is in the most recent development iteration of Orchard which gained the ability to host multiple sites in the same app domain.

The mechanics of spinning up per-tenant container: There’s a single IOrchardHost component created during startup from a root IoC container. That component’s job boils down to creating any number child IoC containers from the root, one for each active IOrchardShell instance, and rebuilding them when needed. The root container has the fewest number of components needed - just the ones required to create and build the shell containers.

The mechanics of hitting the right tenant: When a shell is built and activated it registers routes that have an association to its IoC container. And if there is a host header defined for the shell the route will only match those requests. At the point when a request comes in and hits a Route registered by one of the shells there is an established affinity to the IoC container for the rest of the request.

The mechanics of lightweight isolation: The rest is of the concerns all fall into place naturally. The controller factory draws the controller instance from the shell’s container - so only the components and dependencies which are enabled for that tenant are resolved. All of the configuration (right down to the settings on the database connection provider and the table name prefix) are specific to the shell. Many of the components rely on a singleton pattern to hold various aspects of long-lived state. Those components do always resolve as the same instance - to the best of their knowledge at least. In reality for multi-tenant purposes the singleton component pattern means the same instance will be returned for the lifetime scope of any given shell instance.

There are a few places you need to shim, like tenant-specific controller factory, or view engine concerns, or aspnet membership providers become lightweight classes that reach up into the request context to resolve and invoke the tenant-specific implementation of the capability in question. But other than that - the net effect - it all kind of works.

One of the things I’ve been doing a lot recently is trying to get some pretty dynamic behaviors out of a fairly strongly typed compile time language. That’s .NET 3.5 of course, and the Castle.DynamicProxy has been an invaluable ingredient.

The other day I saw some neat things like these and more David Ebbo was doing with dynamic in VS2010. Reading up on the new C# dynamic keyword and some interesting bits about IDynamicMetaObjectProvider, DynamicObject, and ExpandoObject to get up to speed - I started to wonder something about ways Castle DynamicProxy and C# dynamic could work together.
Read the rest of this entry »

Title kind of says it all. Spark v1.1 RC1 for MVC 2 RC2.

Thanks to folks who helped getting issues like this sorted out and Ben Scheirman, @subdigital, who sent a pull request on this issue. A while ago Erik Polerecky, @detroitpro, also provided a blog post with some bits you could download that contained those changes.

I asked him afterward if he would be interested in helping update the releases on Codeplex and he kindly agreed, in fact the new bits on codeplex and release notes were put together by Erik, so be sure to thank him for that. Hopefully this is just the first step in getting that larger support base I’ve been angling for. :)

As always - this is a lead up to sticking a fork in some 1.1 bits. If you find anything flaky please email the group or report an issue.

So… Main changes for MVC 2:

• Updated the MVC binaries
• Changed use of view context and updated output-capturing
• Fixed implicit support for areas to be MVC 2 compatible (”area” is in data tokens, not route values)
• Avoids autoencoding html helper and macro values

The last bit is interesting. In theory you should be able to turn on autoencoding and use ${expr} for all of your output instead of switching to !{expr} for things you know return html. It should “just work” in terms of html encoding data but not markup from things like ${Html.ActionLink(”hello”)}.

Earlier today I started this thread in the Spark google group:

There was a session at altnetseattle I kicked off “How to organize an OSS project for participation and longevity”

It was a thinly veiled attempt to solicit assistance, like the earlier thread, and recent tweet about “Re: Spark Project growth & futures. Know talented community developers you believe should be interested?”

The take-away from the session was very productive but didn’t provide simple answers. It provided obvious answers that require non-trivial effort, which passes the sanity check of the engineer in me.

Grow the base of read-only adoption, encourage promotion to the second tier of casual contributor, and it’s from that tier the active managing participants emerge. So it appears if I don’t want to be singly responsible for the code base it will take a lot more work to make it a top-shelf project in terms of participation.

The message underlying all of this is that this software belongs to everyone. Whether you’ve downloaded an eval zip, are using the tools in your project, have blogged or screencast about spark, or have submitted several patches you can see in the scc history today. You are all stakeholders in the cultural value of the project, and I believe it’s this sense of ownership that makes the vibrant, explosive open source cultures on other platforms.

That said, I think some artifacts and activities are missing, and for that I apologize. At the moment there’s not a good roadmap and the issue/task tracking seems suboptimal. There are also some bits on the ci server that could be posted as ctp on codeplex which have the mvc 2 fix and the recent pull requests integrated. I’ll reply here if there’s any news on those counts.

The current focus at the moment, of course, is all about mvc 2 readiness and with a look at vs2010 secondarily.

Read the rest of this entry »

It’s been said that ninety percent of the time you think there is a one-to-one relationship in NHibernate it’s really a many-to-one. I’ll agree with that. But this post is about one of the ten-percent cases when a single entity spans several table schemas.

So the scenario is one where you have a thing that can be extended with additional data. And capabilities, of course, but this post is just about the data. In a traditional app it’s very straightforward to add additional fields when a new feature is added.
Read the rest of this entry »

This post is really far overdue - I’ve been pretty busy. This site has been live for quite a while, over a month now at least? The first I heard of this site was when Howard van Rooijen sent a message to the Spark dev group.

In the thread Howard says, among other things:

For those who are interested - here’s a little more info:

- We ran the project using Scrum and delivered in 20 weeks: 10 x 2 week iterations
- It’s based on the S#arp Architecture framework, which we extended to support Spark and ViewModels
- Integrated other OSS projects into the solution the one most relevant to Spark being N2CMS
- Solution performs very well: 1000 concurrent users per web server, generating around 180 pages per second across 2x single quad core 64bit servers.
- The site has a YSlow B Grading.

Very nice. His associate James Broome also has a post talking about their project as it relates to Asp.Net MVC – Separation of concerns amongst team members. You’ve gotta love hearing real-world examples of where UI-centric concerns and coding-centric concerns can work together in the same space at top speed without stumbling over each other’s focus.

I’ve always liked the Castle.Core ILogger and ILoggerFactory abstraction. I don’t know why but I’ve never been a fan of log4net so I like to keep direct dependencies to it at arm’s length.

Looking into Autofac recently, I was trying to find a way of getting a logger property assigned as a component is created from the container in the same way as Windsor’s logging facility. The Autofac container has a Module/IModule extensibility which works well for the tasks a facility would have done.

Here’s the type of code I’m used to seeing from logging.

using Castle.Core.Logging;

namespace LoggingStudy {
    public interface IFoo {
        void Bar();
    }

    public class Foo : IFoo {
        public Foo() {
            Logger = NullLogger.Instance;
        }

        public ILogger Logger { get; set; }

        public void Bar() {
            Logger.Info("Bar called");
        }
    }
}

Read the rest of this entry »

The Herding Code 60: Spark View Engine with Louis DeJardin podcast just went up. Really fun group of guys. Interesting process they use to record also and seemed to work really well. I can just never get used to the sound of my own voice.

This is an open question really for people that make, use, or host ASP.NET apps… When you’re choosing a technology stack how important are memory pressure concerns?

So if you’re looking at adding automapper, or nhiberbate, or ioc xyz, you’re obviously going to be thinking about impact to CPU and memory.

And there are two type of memory impacts: load-and-hold and burn-rate (or memory pressure). The first is relatively easy to say you’re using ten megs of one-time cost memory in each appdomain once it’s initialized and warmed up. The other’s a bit more subtle - if a tool goes through a two megs of object, string, collection, buffer memory in a request - and say you’re tooling along with bursts of 25 req/sec - then 50meg/sec means you’ve given the garbage collector a gig of ram to recycle every 20 seconds. Numbers and needs vary but you get the idea that high burn rates end up causing a CPU tax to be paid affecting the net power availabe.

But on the other hand dotnet is a high level language, and a lot of there types of things are developer productivity tools - not performance tool - so they will *always* have measurable increase in cost. But in the most extreme cases, like from he point of view of a hosting company, you could almost assume that memory efficiency is directly proportional to hardware, space, and power costs per client…

Not that it’s a black and white situation, of course, but at what point are the conveniences and strengths of a library outweighed by the cost of using it? Of course it’s always difficult to weigh something subjective against something quantifiable.

But what’s your take on that?