This is long overdue, but Nick Parker asked me a long time ago (sorry Nick) where I got the skin I use for my blog and I told him I'd make it available.  I actually ported it myself from the existing Scribbish theme that was already available for Mephisto, Wordpress and others.  I really liked the simplicity of it so I just grabbed the CSS and hacked away at it myself until I got it looking close enough as a Subtext skin.

I submitted it to the Subtext skins showcase, but it may take a bit for it to get approved.  So for now, you can just download it from here.

I kind of put this together in a hurry, so please let me know if you find any problems with it.

Enjoy!  :)

Figured I'd try and get this nailed down as early as possible.  So after some recent feedback, I decided to change the namespacing so that it focused more on "behavior/concern" rather than "types".  What this means is...

Instead of:

• using ActiveSupport.Core.Extensions.String;  // containing string extensions for access, conversions, etc.
• using ActiveSupport.Core.Extensions.Integer;  // containing integer extensions for access, inflections, etc.
• ...

It's now just this:

• using ActiveSupport;  // just basic extensions
• using ActiveSupport.Access // all accessor-based extensions for ALL types
• using ActiveSupport.Conversions // all conversion-based extensions for ALL types
• ...

I'm pretty much thinking the accessor based stuff will probably get used the most.  But either way, by grouping this way, I'm hoping they'll be a bit easier use.  And of course when our R# 4.0 EAP shows up next (right Ilya? :) all of this namespace'ry will must magically work for us.  :)

What do you think?  Is this a better approach to keeping things clean and organized?

So it seems there is some interest in getting something like this up and running.  I went ahead and did some of the basic "project setup" type tasks.  Here are some links of interest...

• ActiveSupport.NET Google Code Project
• ActiveSupport.NET.Discuss (general)
• ActiveSupport.NET.Developers (for future use once we have some a group of committers)

I look forward to some more discussions about the best way to structure things to make it easy to use.  On the google code project site you'll find a brief description of the project as well as a wiki page I've started to give some basic info on how the code base is structured (tools, build targets, etc...).  I'm sure all of this will change/evolve as things progress.

And thanks Joe (for already submitting the first patch) and others that have said they want to get involved.  Should be fun...  :)

To my surprise, none of my googling seemed to come up with anyone doing this.  So I figured I'd start it off (please let me know if you know of any other efforts already underway).  As some would say, taking extension method abuse to a whole new level.  :D  But, I see these little utility methods to be a good fit as extensions methods to make the syntactic sugar that much sweeter.

One of the many great things about working in Rails is the core extensions in the ActiveSupport library.  It just *becomes* part of the Ruby language as you work with Rails.  And I wanted to get that same feeling when working in C#.  So this is my attempt to start porting over the core extensions from Ruby's ActiveSupport Library.

So far I've just ported over a few string access and conversion extensions, but check 'em out and let me know if you'd find something like this to be useful.  Here are some examples of what's currently supported...

 1: // some accessors

 2: "blah".At(2) // 'a'

 3: "blah".First() // 'b'

 4: "blah".First(2) // "bl"

 5: "blah".From(1) // "lah"

 6: "blah".Last() // 'h'

 7: "blah".Last(2) // "ah"

 8: "blah".To(2) // "bla"

 9:  

 10: // couple simple conversions (still needs lots of work)

 11: "1/4/2008".ToDate() // DateTime

 12: "01:15:35".ToTime() // DateTime

You can grab the source at its google code repository.  You can just do a "build test" from a command line in the trunk to run the unit test suite.

Enjoy.  :-)