Right, so first off I am no great fan of having 10,000,000 flags.. But sometimes you run into a situation where you need to pass around a datastructure with ump-teen million flags so you end up turning it into an enum of type flag and doing bitwise OR and AND to  to operate on your flags something like

enum Flags
{
    FLAG1 = 1,
    FLAG2 = 2,
    FLAG3 = 4
}

And somewhere in your code you would have

Flags myCurrentVal = Flags.FLAG2;
bool Method HasFlag(Flags enum)
{
   return ((enum & myCurrentVal) != 0)
}

Ok sure, that works and it doesn't suck to bad.. but it has limitations.. First off, you can only have 32 or 64 flags (depending on int or long) in your enum.. Not a big deal unless you are doing something like field level security on a very complex form that includes workflow. And frankly while simple to use these things always make some on the team roll there eyes and "Dear god, no more bitwise logic"..

So in an effort to help my flag loving client have flags and my bitwise hating teammates not have to deal with & and | more than they have to I threw togeather an flag class that will support up to Int32.MaxValue flags (not wise, but it would handle it).

So here is the flags base class, its a generic base class that takes an enum in its inherited implementation

public abstract class  FlagsBase where T : struct
    {
        private bool[] _SetFlags;
        private int _flagLength;
        public int FlagLength
        {
            get { return _flagLength; }
        }
        public FlagsBase()
        {
            Type enumType = typeof(T);
            if (enumType.IsEnum)
            {
                int length = getFlagsLength(enumType);
                _SetFlags = new bool[length];
                for (int i = 0; i < _SetFlags.Length; i++)
                {
                    _SetFlags[i] = false;
                }
                _flagLength = length;
            }
            else
            {
                throw new ArgumentException("The Generic type of " + typeof(T).ToString() + " is not an enum. This base class only supports enums.");
            }
        }

        protected int GetFlagInt(T flag)
        {
            return (int)Enum.Parse(typeof(T), flag.ToString());
        }

        public bool GetFlagValue(T flag)
        {
            int flagval = GetFlagInt(flag);
            if (flagval <= _SetFlags.Length)
            {
                return _SetFlags[flagval];
            }
            return false;
        }

        public void SetFlagValue(T flag, bool newValue)
        {
            int flagval = GetFlagInt(flag);
            if (flagval <= _SetFlags.Length)
            {
                _SetFlags[flagval] = state;
            }
        }

        public T Flag(int position)
        {
            return (T)Enum.ToObject(typeof(T), position);

        }

        private int getFlagsLength(Type enumType)
        {
            return Enum.GetValues(enumType).Length;
        }
    }

So what we have here is a generic class that takes an enum as its type. So you make an enum and the length of that enum is used to create a private bool[].. Now each value in the enum becomes a point in the array and has a bool to back it. Easy sleasy as I like to say.

If I want to add new values to my flags set, I just add them to the enum and everything just keeps on working. Here is an example implementation and "use"

enum WebUI_FIELDS
{
   field1,
   field2,
   field3,
   field4,
   field5,
   field6,
   field7,
   field8,
   field9,
   field10,
   field11,
   field12,
   field13,
   field14,
   field15,
   field16,
   field17,
   field18,
   field19,
   field20,
   field21,
   field22,
   field23,
   field24,
   field25,
   field26,
   field27,
   field28,
   field29,
   field30,
   field31,
   field32,
   field33,
   field34
}
public class WebUIFieldSecurity : FlagsBase
    {
        public WebUIFieldSecurity ():base()
        {
        }
    }

And using it may look something like this

void SetupSecurity(IPrincipal user)
{
   WebUIFieldSecurity mysec = new WebUIFieldSecurity();
   if(user.IsInRole("UseField1"))
   {
       mysec.SetFlagValue(WebUI_FIELDS.field1,true);
   }
   SetupPageSecurity(mysec);
}
void SetupPageSecurity(WebUIFieldSecurity sec)
{
     field1.ReadOnly = sec.GetFlagValue(WebUI_FIELDS.field1);
     field2.ReadOnly = sec.GetFlagValue(WebUI_FIELDS.field2);
     field3.ReadOnly = sec.GetFlagValue(WebUI_FIELDS.field3);
     field4.ReadOnly = sec.GetFlagValue(WebUI_FIELDS.field4);
}

See how nice and easy that is.. And readable.. Personally I like readable.. and If I need to add more flags, I just grow my enum.. no worring about bit masks, using Hex numbering to set my flags to the right values or being limited to less than 100 flags.. Granted if you need more than 64 flags then things may be a little crazy already. But one never knows, and at least with this you won't care :-).

So more often then not I want to share something in a "singleton" fashion across a call stack. But a true singleton wouldn't work because the objects I want to share are usually not thread safe or its not a best practice to persist them across threads. NHibernate has a Session manager pattern that is very similar to what I want and so I extended on that principal making what I call a "Context" Singleton.  Its simply just a little base class that will store itself in right context and as such will also "die out" once that context has ended.

Here is the helper class

public abstract class ContextSingletonBase: IDisposable
    {
        private static string CONTEXT_PREFIX = "ContextSingleton:";

        protected static object _getObject(string key)
        {
            if (isWCF)
            {
                return WcfInstanceContext.Current.Items[ContextSingletonBase.CONTEXT_PREFIX + key];
            }
            else if (isHttp)
            {
                return System.Web.HttpContext.Current.Items[ContextSingletonBase.CONTEXT_PREFIX + key];
            }
            else
            {
                return CallContext.GetData(ContextSingletonBase.CONTEXT_PREFIX + key);
            }
        }
        protected static void _setObject(string key, object obj)
        {
            if (_getObject(key) != null)
            {
                if (isWCF)
                {
                    WcfInstanceContext.Current.Items.Remove(ContextSingletonBase.CONTEXT_PREFIX + key);
                }
                else if (isHttp)
                {
                    System.Web.HttpContext.Current.Items.Remove(ContextSingletonBase.CONTEXT_PREFIX + key);
                }
                else
                {
                    CallContext.SetData(ContextSingletonBase.CONTEXT_PREFIX + key, null);
                }
            }

            if (isWCF)
            {
                WcfInstanceContext.Current.Items.Add(ContextSingletonBase.CONTEXT_PREFIX + key, obj);
            }
            else if (isHttp)
            {
                System.Web.HttpContext.Current.Items.Add(ContextSingletonBase.CONTEXT_PREFIX + key, obj);
            }
            else
            {
                CallContext.SetData(ContextSingletonBase.CONTEXT_PREFIX + key, obj);
            }
        }
        private static bool isWCF
        {
            get
            {
                return (WcfInstanceContext.Current != null);
            }
        }
        private static bool isHttp
        {
            get
            {
                if (isWCF)
                {
                    return false;
                }
                if (System.Web.HttpContext.Current != null)
                {
                    return true;
                }
                return false;
            }
        }
        internal class WcfInstanceContext : IExtension
        {
            private readonly IDictionary items;

            private WcfInstanceContext()
            {
                items = new Hashtable();
            }

            public IDictionary Items
            {
                get { return items; }
            }

           public static WcfInstanceContext Current
            {
                get
                {
                    if (OperationContext.Current != null)
                    {
                        WcfInstanceContext context =
                            OperationContext.Current.InstanceContext.Extensions.Find();
                        if (context == null)
                        {
                            context = new WcfInstanceContext();
                            OperationContext.Current.InstanceContext.Extensions.Add(context);
                        }
                        return context;
                    }
                    return null;
                }
            }

           public void Attach(InstanceContext owner) { }

           public void Detach(InstanceContext owner) { }
        }

        #region IDisposable Members

        public void Dispose()
        {
            _dispose();
        }

        protected abstract void _dispose();

        #endregion
    }

 So you will notice I test for several contexts.. This is because going down to CallContext is not always safe.. First off for Http Applications the executing thread can actually change.. If it changed and you weren't using HttpContext you would end up loosing your ContextSingleton. (Granted HttpContext is infact using CallContext at its core, using HttpContext will handled that potential thread switch out for you).  I also check for a WCF context.. This is because (and I'm not 100% sure about this) WCF services are handled diffrently depending on the connection point. Using the WCF Context instead of CallContext removes any "wierdness" that may occure.

So this was just a base class and on its own missing the "Singleton" part of the whole design.. Its mostly intrested in the storage of said singleton and not the actual access or storeage of it. So what does an Implemented Context Singleton look like?

Well here is an overly simple one that stores a Linq2Sql Data Context... you can see the pattern is pretty much pure "singleton" but instead of the Instance being a static field its a property and it calls back to the above static classes that then look in the approproate context for the actual instance of the helper.. In this way your interact with the class as if it were a traditional singleton but it only persists inside its appropriate context (Http, WCF or Call)..

  public class Helper:ContextSingletonBase
    {
        private static string KEY = "SingletonKey";
        public static Helper Instance
        {
            get
            {
                Helper h = GetHelper();
                if (h == null)
                {
                    h = MakeHelper();
                }
                return h;
            }
        }

        private static Helper MakeHelper()
        {
            Helper h = new Helper();
            Helper._setObject(Helper.KEY, h);
            return h;
        }

        private static Helper GetHelper()
        {
            object helper = Helper._getObject(Helper.KEY);
            if (helper != null)
            {
                return (Helper)helper;
            }
            return null;
        }

        private DataContext _dc;
        public DataContext DC
        {
            get
            {
                if (_dc == null)
                {
                    _dc = new DataContext();
                }
                return _dc;
            }
       }

        protected override void _dispose()
        {
            _dc.Dispose();
        }

}

One thing I would love to do is actually replace the Contexts code I have with some kind of provider model.. Use a bit of code (or settings) to detect the approriate context and return that.. That way the ContextSingletonBase wouldn't have to be depended on .NET 3.0 (like it is now) and its code wouldn't grow in complexity as other contexts become known (I only did this for Call, Http and WCF because those are the only contexts I've run into and Call is kind of the catch all.. But who knows, Silverlight might have its own... .NET compact framework might have one, etc... you can see how seporateing the context storage from the ContextSingleton helper could become a good thing..

Over the summer I finally dug into this whole "MVC" thing for web development. Naturally I began with the Mecca of them all Ruby on Rails.  This was a twofold learning experience for me..  First off it was Ruby a meta-language that bends like read in the wind.  And second was Rails, the darling framework that seems to have been sent by the demi-gods of software to help all suffering web developers.

But all of this joy was not without its flaws. Ruby is (as I mentioned before) all but un-deployable on a windows platform. After all Ruby is a single threaded/multi-process language (great for Unix where you don't actually have threads). But this limitation makes it an un-workable option on a windows box. Since then I have dug into Monorail, and now am neck deep in ASP.NET MVC. Heck I'm even a committer on the MVCContrib project. And while these projects are great they are still missing some magic. 

In short I still have stars in my eyes when I think of RoR.. This brings up the question, Why? (ya simple question).  I've been thinking about this a bit and I think (for me) the issue boils down to just a few issues.

First off is the RoR mantra "Convention over Configuration".  This mantra is actually quite deep; and while it can be a touch annoying at times (class naming can get silly) it's actually insanely smart. I have probably downloaded 15 different rails projects and had a working knowledge of the app and how to tweak each one in less than an hour. This is because the sites structure is described 1 way and 1 way only. More over I have been able to hand over projects in no time flat. In short, getting up to speed on a rails project is a no brainer.  ASP.NET MVC missed the mark on this in a big way in my book. MS, wisely from an OO perspective, laid everything out in a strong override-able and design. If you don't like routing, just implement a new router, don't like the view engine, just replace it. MVCContrib continued this with implantations of DI containers like Winsor, Structure Map, etc.. To muddy the situation further, MVCContrib implements multiple View Engines allowing developers to choose between ASPX, NHTML, NVolocity etc.. With all of that we diverge from Convention, and in doing so remove elegance for the privilege of flexibility (* Flexibility I am sure I will be thankful for when I migrate some of my Monorail apps to ASP.NET MVC over the summer).  Monorail is also bad about this (although not as much) with multiple view engines and a solid OO framework; but monorail has a community that has become kind of set in their ways. And so, while not set in stone, some conventions have settled in.  But going back to the rails mantra "Convention over Configuration"; nether ASP.NET MVC or Monorail prescribe to this philosophy more over they are the opposite "Here's a convention, but here are 108 tools to ignore it with " (I jest). 

    The second great feature of rails is the data model versioning and deployment methodology. You want a new data model, you add a new class to your data model describing the changes. Deploy the new version to your dev db, then code. Once your are done you run your deployment in test, evaluate your unit tests and push to prod; all very elegantly and with little effort. Linq for SQL has a great model but you design the app to the data (pulling your object structure from your tables) not the other way around.. So the same model change in Linq starts at the DB (with change scripts so you can manually run them in test and prod later) then re build your mode, code, test, run scripts in test, run unit tests, and deploy using your ant script that took 2 days to write. That's a lot of work and unfortunately Castle active record isn't much better.

    No don't get me wrong I really enjoy using Monorail and ASP.NET MVC has real promise. But when you take these three MVC frameworks and you look at developer efficiency and experience RoR is closest to my heart!

Here it is, My first screencast. Like I pomised this screencast is about abstracting Linq Providers so that you can use what ever provide you want and keep your Business layer igorant.

(By the way, this i my first screencast, so no promises about quality. Oh and sorry for the annoying watermark. I know how to turn it off for the next screencast).

Last night I sat down and played with how I could abstract my linq so I could use any provider I wanted. This has been a common request on some of the forums I've been reading and so I figured I would give it a shot. Now this post is just a teaser, I am going to use this topic as my first screencast so expect that to show up here sometime this weekend.

Goals for my experiment (or what I'll be doing in my screencast):

1. Allow multiple diffrent providers (save Linq to XML due to casting constraints in Linq to XML) to expose the same objects up to a single business class
2. Make a factory where by settings could be uses to pass the correct provider to its caller such that the caller is provider ignorant about the Linq it is using.
3. Validate that there are no obvious performance hits caused by this (Most importantly tha linq to SQL doesn't do something "wacky" that caues it to speu crazy SQL rather than sain SQL).

I am happy to say I achived all of these goals, and now you'll just have to wait to see how :-)..

Nothing to major here, just made a move to use the BlogEngine.NET from using SUBTEXT. This will include a few minor visual changes, but most everything was under the hood ;-).

The biggest pain was mapping all the old posts to the new permalink format. This entailed a bit of hackery to the 404 page so that I could map all of the old posts to there new URLS.

The main cause for the change was so that I could use a blogging client to write my posts. As I am (in theory) going to start doing weekly screen-casts; I figure a little better posting experience was a good thing

     Looks to me like Microsoft isn't taking the whole Rails movement lying down. First off they have IronRuby. But why stop there? I just read thru and watched the screencasts from the MVC demo at Alt.Net (click here to watch them, and yes you do want to read and watch them!) and I have to say I am quite impressed.

      It really does look like the boys at MS realized that RoR and Monorail and other MVC platforms brought a real value add for some (in my book many) web development scenarios and as such are moving to Microsoft the Web MVC development experience. Now add in the DLR (I do love what it can offer because I have become a big fan of Dynamic languages) and top it off with LINQ (or DLINQ) and you have a very compelling argument to develop your next RoR or Monorails app using all microsoft goodness.

   So the good and bad of it for me..

The good: Microsoft level of dependability, scaleability, performance, etc..

The bad: I want all my projects on one platform. I really don't want to mix and match my apps between MonoRail and System.Web.MVC and RoR! One MVC to rule them all Damnit!!!!! Its an in-determinit amount of time away (the Screencasts are of an internal experimental build).

In an effort to become more of a company and less of a "shop", we have developed and deployed a new site for Ktomics.. The new site also has our new logo and tag line :-).. Its pretty nice (if I do say so myself), so check it out :-).. www.ktomics.net.

(oh a techical note on the products. Gift Scanner is about 90% complete with eval/alpha versions in field testing. Gift Scanner is written with a .NET client and .NET/MonoRail on the server side. Given my problems with RoR for Windows I have made the transition to MonoRail for projects moving forward. Passvault is running on a cluster of Mongrals and is still a Ruby on Rails application).

Ok so I have fallen in love with RoR as a development enviroment, its easy, elegent, and for compatent developers it can increase productivity astronomicly.. BUT it has a huge problem for Windows enviroments; it has no solid deployment stratagy for windows ( and no mongrel clusters behind apache don't count). Below are the methods I have tried any my opinion of their results.

1) Fast CGI on IIS using the old Fast CGI ISAPI filter: Slow (10, 12 connections per second) and I couldn't find an elegent way for it to run multiple sites.

2) Fast CGI on IIS using the new Microsoft Fast CGI tech preview 2: Faster BUT it couldn't handle default routes (routes to the root of a site) and it crashed when I had more than 1 app (first app would run fine, second one would keep crashing). Oh and did I mention it was a Tech Preview :-P

3) Fast CGI on Apache: I tried, 2.0, 2.2, FastCGI, fcgid, and about 2 million other combinations. I never got it work work! (I followed 3 diffrent tutorials about 10 times each, even mixing and matching steps where I thought one may have had a typo.) This may be because I am on Windows Server 2003 x64. But thats about the only reason I could find that thse just  "wouldn't work"

4) X Mongral Services running with apache as the balancer: This works great until you consider scale. It takes about 40megs per mongral instance (instance + ruby). and you need one Mongral per connection you want to handle (simaltanious, not per/second). So if I want to handle 200 connections/second and my Mongrals can each handle 10 per second, then I need 20 mongrals running. Now multiply that by 40 megs, and you are burning 800 megs of ram just on my app. This is not so go.

5) Linux VM running inside my windows box: One major downside. I can only connect to my SQL server via ODBC. Enough said.

So what are my options.

1) Ditch windows: Ya sorry, not going to happen.

2) Ditch Sql Server: See above answer.

3) Live with it and wait for iron ruby to support rails: I would if I thought iron ruby on rails was just around the corner, but its my bet its atleast 18 months out before its solid and production ready (remember iron ruby is only pre-alpha).

4) Do [X] (where X is the suggestion you place in the comments below): I am all ears.

5) Bite the bullet now (before there is TO much development to turn back) and port to Monorail or another MVC style framework that places nice with IIS and Windows: This is high on my list.

5) Give up on the clean goodness of a forced MVC framework and go back to traditional ASP.NET: This may also happen; but I am not a fan of this.

Suggestions are (of course) very welcome.

So to centralize Wiki support I am urging users of Ktomics WWWiki to migrate to DotNetNuke Wiki.  For this to work (or be necessary) you need to have a running instance of Ktomics WWWiki running on your DNN instance. The script will then CONVERT your running WWWiki into a DotNetNuke Wiki.. You don't have to do anything to the pages, modules running on your site; they will be converted in place.

Now to do that first you need to go download the new DNN Wiki Module (see the link above) and install the new module (version 4.00.01) into DNN via the HOST>Module Definisions. (*Note you don't need to add an instance of DNN Wiki to your site anywhere, you just have to have the module installed).  Next run the below script from the SQL Page under the HOST tab.  Once you have run the below script, test the pages (they should be working perfectly :-).. If you are comfortable that the system is work you can uninstall the WWWiki module. (or keep it for archival purposes).

WARNING (before you get to see the script): This is unsupported. If you have issues, I'll try to help, but I can't predict every dnn setup. So for your protection remember! Backup, backup and backup more before attempting this transition.

WARNING (before you get to see the script): This is unsupported. If you have issues, I'll try to help, but I can't predict every dnn setup. So for your protection remember! Backup, backup and backup more before attempting this transition.

WARNING (before you get to see the script): This is unsupported. If you have issues, I'll try to help, but I can't predict every dnn setup. So for your protection remember! Backup, backup and backup more before attempting this transition.

Ok now that you have read the warning 3 times (and if you haven't go read it its right above this line of text!) below is the migration script.

declare @wikiDefID as int
declare @KtomicswwwikiDefID as int 

select @WikiDefID = ModuleDefID from {databaseOwner}{objectQualifier}ModuleDefinitions where FriendlyName = 'Wiki'
select @KtomicswwwikiDefID = ModuleDefID from {databaseOwner}{objectQualifier}ModuleDefinitions where FriendlyName = 'Ktomics WWWiki' 

set identity_insert {databaseOwner}{objectQualifier}Wiki_Topic on 

insert into {databaseOwner}{objectQualifier}Wiki_Topic (TopicID, ModuleID, Content, Cache, Name, UpdateDate, UpdatedBy, UpdatedByUserID, AllowDiscussions, AllowRatings, RatingOneCount, RatingTwoCount, RatingThreeCount, RatingFourCount, RatingFiveCount, RatingSixCount, RatingSevenCount, RatingEightCount, RatingNineCount, RatingTenCount) 
Select TopicID, ModuleID, Content, Cache, Name, UpdateDate, UpdatedBy, UpdatedByUserID, AllowDiscussions, AllowRatings, RatingOneCount, RatingTwoCount, RatingThreeCount, RatingFourCount, RatingFiveCount, RatingSixCount, RatingSevenCount, RatingEightCount, RatingNineCount, RatingTenCount from {databaseOwner}{objectQualifier}Ktomics_WWWiki_Topic 

set identity_insert {databaseOwner}{objectQualifier}Wiki_Topic off 

set identity_insert {databaseOwner}{objectQualifier}Wiki_TopicHistory on
insert into {databaseOwner}{objectQualifier}Wiki_TopicHistory (TopicHistoryID, TopicID, Content, Cache, Name, UpdateDate, UpdatedBy, UpdatedByUserID)
select TopicHistoryID, TopicID, Content, Cache, Name, UpdateDate, UpdatedBy, UpdatedByUserID from {databaseOwner}{objectQualifier}Ktomics_WWWiki_TopicHistory
set identity_insert {databaseOwner}{objectQualifier}Wiki_TopicHistory off 

set identity_insert {databaseOwner}{objectQualifier}Wiki_Comments on
insert into {databaseOwner}{objectQualifier}Wiki_Comments (CommentId, Name, Email, Comment, Datetime, Ip, ParentId)
select CommentId, Name, Email, Comment, Datetime, Ip, ParentId from {databaseOwner}{objectQualifier}Ktomics_WWWIki_Comments
set identity_insert {databaseOwner}{objectQualifier}Wiki_Comments off 

set identity_insert {databaseOwner}{objectQualifier}Wiki_CommentParents on
insert into {databaseOwner}{objectQualifier}Wiki_CommentParents (CommentParentId, Name, ParentId)
select CommentParentId, Name, ParentId from {databaseOwner}{objectQualifier}Ktomics_WWWIki_CommentParents
set identity_insert {databaseOwner}{objectQualifier}Wiki_CommentParents off 

set identity_insert {databaseOwner}{objectQualifier}Wiki_Settings on
insert into {databaseOwner}{objectQualifier}Wiki_Settings (SettingID, ModuleID, ContentEditorRoles, AllowDiscussions, AllowRatings)
select SettingID, ModuleID, ContentEditorRoles, AllowDiscussions, AllowRatings from {databaseOwner}{objectQualifier}Ktomics_WWWiki_Settings
set identity_insert {databaseOwner}{objectQualifier}Wiki_Settings off 

update {databaseOwner}{objectQualifier}Modules set ModuleDefID = @wikiDefID where ModuleDefID = @KtomicswwwikiDefID