Part 1 - Simple configuration


Welcome to part 1... today we're looking at supporting basic configuration in components without additional coding by using the windsor container.

So - with the container we can provide configuration for a component which is loaded at runtime, so every time you start your app it will be read in - you can do this using the configuration support in .Net - but using castle makes support for this very code-light in comparison... let's take a look.



So first off, we have a class we can use to calculate the tax on a gross ammount:


public class TaxCalculator
{
private decimal _rate = 0.125m;

public decimal Rate
{
set { _rate = value; }
get { return _rate; }
}

public decimal CalculateTax(decimal gross)
{
return Math.Round(_rate*gross, 2);
}
}



By default the tax rate is 12.5% - but we can change the tax rate by setting the "Rate" property.



Now, lets look at setting up the container... so we have this code in our sample:


private static void Main(string[] args)
{
WindsorContainer container = new WindsorContainer(new XmlInterpreter());

TaxCalculator calculator = container.Resolve();

decimal gross = 100;
decimal tax = calculator.CalculateTax(gross);

Console.WriteLine("Gross: {0}, Tax: {1}", gross, tax);
Console.Read();
}



The windsor container is constructed with an "XmlInterpreter" - this configuration will pull the setup for our container from a section in the App.config.



Let's have a look at that:




type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />








Running the program will display: Gross: 100, Tax: 12.50



Now, what about changing the tax rate in the configuration?




type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />



0.25





Now running the program will display: Gross: 100, Tax: 25.00



And that's part 1 done - so now you can see how can we supply configuration parameters, and provide sensible defaults for them.

Next time we'll look at configuring arrays...

Read More

2007-04-15 - Architecture Camp 2007

Well it's over - and it's been great!

First off Architecture Camp 2007 was a lot of fun to present at this weekend... the relaxed nature and opportunities for everyone to talk, rather than just listening, was great - a nice soft introduction to a newbie presenter such as myself!

And a big hat-tip to all the guys who helped put this together, including Alex James, Kurt (where's your blog boy!) and Chris + all the other presenters.

The thing I liked the most about this event was the number of people who brought their a-game... damn but there were some seriously experienced and intelligent guys in the audience, asking great questions - contrasted with the often pointless heckling and misguided questioning you can get at events like teched, this event was great ... if you couldn't make it, definitely try to get to the next architecture camp, and if you were a no-show ... shame on you!

I'm still not 100% sure if my session got recorded or not, but if it did, I'll point you to it at some point...  in the mean time - here's the presentation itself in both pdf and pptx (powerpoint 2007) formats.

Read More

Codeplex... Damned if you do... Damned if you dont...

In a follow up to this  post I made yesterday, it seems some people are annoyed that a Codeplex command line client exists at all...


I still can not help but feel some people are missing the point of Codeplex all together... as I see it (and these are only my opinions on the matter) - Codeplex:
  • Supersedes the aging gotdotnet.
  • Demonstrates TFS features
    • Scalability for high volumes of users (not necessarily usability, but they're working on that)
    • Case study for any large organizations considering deploying it across their organization.


  • Provides a place Microsoft can.
    • Host open-source projects for life.

    • Control and support the environment.
    • Keep a single message across their organization - we use TFS for source control from now on.




(At this point it's worth noting I'm a SVN/Trac/CC.Net guy myself... I can't actually justify the expenses of TFS at the moment)

For me the reasons to use codeplex over another open source provider are simply:

  • It's different / new.
  • It has a strong Microsoft / .Net focus.
  • It's easier to get going for a newbie .Net developer (integrated source control in VS.Net, simple wiki pages baked-in)
  • You can play with TFS.


They are reasons, but hardly "compelling" ones ;o)

The beta command line client is a good thing, but to counter that "6 months wasted effort" with a call to replace TFS with subversion in Codeplex ... that just seems counter-intuitive to me... suddenly you have a roll-on effect of zero integration between source control and the in-built issue tracking mechanisms... so what, lets replace that with Trac??... and now that comes with it's own wiki... so ditch the existing one... and suddenly Codeplex is nothing more then a shell for managing file releases with some forums.

What kind of message would it send to microsoft customers who have invested time and effort into team system... let's be reasonable, it's just not going to happen, so whats the next logical step... improve the tooling to work with the existing source control solution... first step to achieving that... build a decent command line client!

So... if you are looking for subversion based hosting why not use well established players who have been supporting open source from the beginning like SourceForge or tigris... don't they still deserve your love now more then ever since Codeplex is on the scene... what better way to vote than with your choice of OSS project hosting?

Codeplex is an alternative, not a replacement, for the likes of Sourceforge... perhaps what we need is a OssHostMatrix, much like WikiMatrix that compares
feature for feature so you can pick the host that's appropriate to your project on features alone, rather then bitching about what's missing in Codeplex, when it's freely available elsewhere...

I'm starting to feel sorry for some of the codeplex guys (like

Jonathan Wanagel, who I commend for being vocal about what's going on at codeplex... he seems to pop up on a lot of blogs I read) ... they certainly do seem a little damned if you, damned if you don't at the moment - especially when progress is slowly being made and demonstrated.

Read More

Some notes on creating your own license keys

If you have to make your own license keys i.e.

ABCDE-ABCDE-ABCDE-ABC1Z-A32DE

Here's some thoughts/ideas for things you can do to break up the key space a little so people can not easily brute-force your keys by fiddliing just a couple of numbers.

  • Select a range of numbers and letters that can be directly mapped to 32 values (10 digits and 22 alpha maybe?).
  • Know your maths.. creating helper classes for unpacking and packing bytes will help.
  • In this example you could carry 125bits (15 bytes and just over a nibble ;o) ... or 13 bytes + CRC16 (or Maybe an Adler16).
  • Use lookup tables to translate sequential values into pseudo-random values.
  • Break any multi-byte values up into individual bytes, stuff em around your payload of bytes in non-sequential offsets.
  • Calculate the CRC for your payload and include it as part of the key's data, verify it when you're decoding.
  • You can use structs with a sequential layout and a packing of 1 to define your structure...
  • Use Marshal.Copy etc. methods to copy between the struct and a byte array.
  • Remap individual bits in the overall payload.


The last one is something that works really well... it's hard
to avoid certain digits "sticking" when generating sequential keys
no matter what you do... but if you remap the individual bits of a
15 byte array (i.e. using a lookup table containing 120 indexes)
you end up with very unique looking keys that have no sequential behaviour to them (especially if you redistribute the bits of the CRC into all the bytes of the key, which in turn are repacked into 5 bit letters).
Read More

New codplex TFS command line client

Cast your mind back...


If you recall (maybe you don't) there was some discussion a while
back about Codplex, TFS and the fact that it's a bit of a wash for creating an collaborative environment for an open source project... why?  Well because of the chasm between developers for the project and those users who wish to collaborate by providing small patches, or working on the bleeding edge (i.e. checking out changes since the last time they build your project from source)

Just to recap the big problems were:

  • No support for patches
  • No anonymous check-outs
  • No easy way to diff/merge between your version and the latest version on source control (because you could only get the source as a tarball).


In particular I remember Ayendes posts on the subject, which sparked a bit of debate on the whole issue (and even got some feedback from the codeplex developers themselves...)

Codeplex's new command line client


Well it looks like one small step has been taken this week, check out this
entry
on the codeplex blog ... There is now a .Net 2.0 command-line client being developed, which will include support for:
  • Anonymous checkouts (hurray! dragging down a tar ball every time there were changes... what an arse that is/was)
  • Merging
  • Patching


I got all excited (well as excited as you can be about a command line client for TFS) and grabbed the beta... really all I cared about was anonymous checkouts... I like my open source medium rare (mmm... nothing like a fresh check-out of castle... release candidates
never have any of the fun stuff!)

But my hopes were dashed - it appears there's no way to skip the authorisation check as far as I can see, and when supplying my own credentials I didn't have access:

c:devtoolscodeplex_client>

cpc co reflectoraddins:/ c:devresourcesreflector

_addins

Username [sndanonymous_cp]: bittercoder

Password for bittercoder: ********

error: TF50309: You do not have sufficient permissions to perform
this operation

. ---> Attempted to perform an unauthorized operation.


I guess there's a little more waiting to go yet...

Still, not to get too disheartended I decided to try it on a project I coordinate for (ye olde Splicer...) and I can certainly confirm it works... considering that the command line tools are less than 200K, this is already a great improvement over the current situtation... (about 250mb to download Team Explorer's iso).

c:devtoolscodeplex_client>

cpc co splicer:/ c:devhomesplicer_copy

A    c:devhomesplicer_copy

A    c:devhomesplicer_copysrc

A    c:devhomesplicer_copysrcASL - Apache
Software Foundation License.txt

.... and so on ;o)

So as you can see ... it does work... but I have to say it's pretty damn slow (could just be because I'm in New Zealand of course).

At any rate... I'll be keeping my eye on it... there may be hope for codeplex yet ;o)

... and on one last note... the gui check-in looks a little like TortoiseSVN don't you think...  hopefully the work towards some feature parity there.

Read More