Connectivity woes

Well this blog, the wiki and all the other associated services disappeared for most of today... thanks to the magic of NoAuth ... for no reason that anyone could explain to me beyond "it sometimes happens" - Orcon lost Authority over my business DSL connection, and it reverted back to Telecom/Xtra (New Zealands "legacy" telco)... and it took must of today for them to get the authority changed back, I don't think this was any fault of Orcons, but it still pissed me off no end.

So apologies to anyone wondering where my blog went, or any of the related services - I do have plans to migrate the blog to US servers in the not to distant future.  And big apologies to all the Architecture chat participants, sorry I couldn't get a reminder email out sooner.

On a different note - It did identify a need for me to maintain a secondary connection, with a static IP, that I can fall back to if required... thankfully the three concurrent projects that have been in UAT over the last couple of weeks have all wound down now - so it didn't have as much impact as it could of.

Though at least they wouldn't have been able to log bugs about servers being unavailable, Trac would've been unavailable too ;o)

... so any suggestions as to what would make an adequate fall back technology (something other then DSL, I've used wired country two-way-radio to the sky tower in the past which has worked well, but it doesn't give much "bang" for buck and has a high up-front cost last time I checked) ... I'm not too worried about 1 day downtime, but if this had been 3 or 4 days it would've been quite damaging for me, customers and those intangibles like reputation.

At any rate - thanks for the patience, and I'll see some of you at the Architecture Chat tomorrow.

Cheers,

- Alex

Read More

2007-12-04 - Architecture Chat Tomorrow

That's right, it's time for another Architecture chat
Tomorrow

So as I mentioned last week - The Architecture
chat
is being held this thursday, 11:30am at Sylvia Park in
Auckland (at
Garrisons
), all are welcome and encouraged to come along and
share your views.

Some topics / announcements that have taken my eye over the last
3 weeks which might make good discussion fodder:

And some conversational topics related to what I've been working
on lately...

  • Agile model driven development and
    just how can you combine model driven architecture (MDA) with
    test driven development and code-level refactoring.
  • Writing parsers using F#,
    leveraging pattern matching & Active Patterns - and integrating with other languages like
    C#.
  • Visual DSL's - the good and the bad, and at what point does it become
    justifiable to roll your own for specific business needs?

If anyone has any topic suggestions either leave a comment or
email/IM me (IM details are on the left, in the "Who am I?"
section).



See you all tomorrow!



Edit: and as a late edition, I've also had a play/look into the
very recently released Volta if anyone is interested -
if you've got the time before xmas, I'd definitely suggest doing
their quick start
tutorial - interesting.


Read More

Pluggable IoC in WPF Composite & Enterprise Library v.Next

So a quick observation on the alt.net conference list:



"You'll be
happy to know then that in the new WPF Composite work we are doing,
the DI/IOC mechanism will be decoupled and pluggable. Actually the
next version of Entlib will be the same. There's a new Dependency
Injection block that will allow you to plug-in the container of
your choice."


Which was posted
on the alt.net conference
yahoo list
by by Glen
Block
from Microsoft.



I think this is very good news, at least for the WPF composite work
they're doing - it might make it a great deal more appealing to me
then the CAB was (I was never a big fan of the CAB because it
didn't integrate well with the other stacks of technologies that
made me productive).



I'm fairly ambivalent about the Enterprise Libraries upcoming
pluggable IoC support however - surely the overlap between it and
the facilities and services already provided by the IoC container
you'd be plugging into would be great ... and IoC is only part of
that story... for a number of common services (i.e. logging,
transactions etc.) you're going to have create appropriate wrappers
and sandwich things into the containers "abstracted" view of the
world, or face tightly coupling your application to the Enterprise
Library, I'm not sure there is much of a value proposition there...
though I'm open to being educated if any P&P Microsoft people
happen to read this.



Interestingly enough has picked up on this slip from Glen and
noted that it also implies Microsoft are writing yet another IoC
container that will probably ship with EntLib & the WPF
composite work (in whatever shape it eventually takes) and they ask
the question "why oh
why!
" .



Personally I think it makes good sense to provide an out of the box
IoC container, with it the product is far more accessible to new
developers and people reviewing the technology - especially when
you consider that:

  • If support was added into say the Castle Windsor container,
    it wouldn't see an official release until RC4 was made public -
    and until then would be in a state of flux as part of the castle
    trunk.
  • People would expect Microsoft to "suggest" an OSS container
    that works best with their offering - and playing favorites with
    the .Net OSS community could only do harm to the ecology I feel.
  • Microsoft retain consistency with their existing approach of
    providing an entire stack of technologies for you to get the job
    done, if that's what your like/want or are told you
    want. 

  • They can provide a set of consistent tutorials and training
    materials for developers to "get up to speed" with for the
    product, without having to provide umpteen alternative examples
    for different containers, or explain why the container
    terminology is slightly different to the product
    terminology.


So in short, I think it's a positive sign, not a negative one,
even if another container is introduced into the mix - I'll be
interested in seeing just how they do it (both the container, and
the extension points to allow for plugging in a different
container)... Though it could just be a hack using
IServiceProvider
, I wonder if perhaps they may need to go a bit
further, so they can register services into the plugged in
container with the appropriate lifestyle and configuration
etc.



Edit: I just noticed
Ayende
posted about this as well...  he seems pretty well
aligned with the "why oh why" viewpoint, perhaps I'm missing
something - but I just don't see it being all that practical in
some scenarios to provide a product that wont work without the
developer going through a separate selection process to pick an IoC
container, if they don't already use one from the OSS
community.
Read More

And time stood still... at 11:24pm


alt="clock_stopped.png" border="1" height="277" hspace="5" vspacesrc="5" width="153" />



My vista64 clock has stopped in the system tray... the funny thing
is Renee (My Fiancee for those who don't know) has been asking me
for the last half hour what the time is... and I've kept responding
almost 11:30...



I hope they fix that in Vista SP1 - Damned if I'm getting a wall
clock for my office!




Read More

F# for fun...

So I'm learning F# in my spare time... I don't have much of that however.. so I kinda squeeze it in where I can, so I'm not progressing as fast I would like... None the less it's quite an easy language to get up to speed with, even as I stab at it blindly for half an hour a week... but some fundamentals can really trip you up when you're starting to learn and experiment without having developed a good mental model of whats going on... being a wannabe "expert" in the .Net framework and BCL doesn't necessarily give you much of edge when your moving from an imperative to functional programming language.

To that end this post is going to cover some really trivial observations, so for anyone that actually knows F# it's probably going to be pretty boring... and you might as well read something else ;o)

Anyway.. so, first off lets take evaluation order.

In C# I might write some code like so...

char[] characters = new char[] { 'A','B','C','D','E'} foreach (char c in characters) Console.WriteLine("character: " + c);

Now in F# I could write something similar...
let characters = [| 'A'..'E' |] for c in characters do print_endline "character: " + c.ToString()

But it wont compile... because it's evaluated/applied from left to right, so it equates to (print_endline "character:") + c.ToString() ... which can't compile because print_endline returns a result of type 'unit' (think void... though it is actually a return value)... thankfully it's a compiled language so these things are picked up immediately - but it can make for silly/confusing compilation errors when starting out.

Now, moving on from there.. past experience has also helped screw up my mental model... for example iteration related functions - if I was going to write an iteration function in C# the approach would generally be to do something like this:

public void ForEach(IEnumerable items, Action action) { foreach (T item in items) action(item); } string[] words = new string[] { "somewhere", "on", "earth", "little", "kids", "teach", "themselves", "a", "whistling", "sound", "to", "imitate", "bombs", "dropping" }; ForEach(words, delegate(string s) { Console.Write(s + " "); });

I had the expectation of finding replicas in the F# built-in functions like List.iter etc. - in fact I even wrote code like this to start with, assuming it would work in the same manor.
List.iter words (fun word -> print_string (word + " "))

After that didn't compile I just swapped the parameters... it worked... but I saw some unusual behavior when stepping through it with the debugger... and it required further inspection... looking at the signature for List.iter revealed that it was actually a function that returned a function ...  ('a->unit) -> (list 'a -> unit)... hmmm..

So it turns out most of the built-in functions take a single function and return a function... so unlike the C# equivalent, the F# foreach would look something like the code below (though I suspect an F# guru might be able to write it in a more terse manor).

let words = [ "somewhere"; "on"; "earth"; "little"; "kids"; "teach"; "themselves"; "a"; "whistling"; "sound"; "to"; "imitate"; "bombs"; "dropping" ] let foreach f = let rec foreachInList l = match l with | head :: tail -> f head foreachInList tail | _ -> () foreachInList let n = foreach (fun word -> print_string (word + " ")) n words // or words |> foreach (fun word -> print_string (word + " ")) // or foreach (fun word -> print_string (word + " ")) words

It took me a minute or so of going hmmmm to absorb the beauty of that approach... obviously this is bread and butter of a functional programmer, but for a non-functional programmer like myself you tend to just see twice as much "work" going on (two function calls for starters).

Take a look at the second way of calling foreach... in this case |> applies the RHS as a filter on the LHS... because the function takes a single parameter we can do this easily.. but we can also chain them together... so we could alter our foreach function a smidgen:

let foreach f = let rec foreachOnList l = match l with | head :: tail -> f head head :: (foreachOnList tail) | _ -> [] foreachOnList

So it's signature is no longer ('a->unit) -> (list 'a -> unit) but is instead ('a->unit) -> ('a list -> 'a list) ... now I can chain calls to my foreach together...
words |> foreach (fun word -> print_string (word + " ")) |> foreach (fun wor -> print_string (word.ToUpper() + "_"))

I really enjoy the elegance and simplicity of the filter syntax... if you replace the anonymous functions with functions you've already declared it suddenly becomes pretty, I think it reads nicer then chained extension method calls / fluent interfaces in C#.
let capitalize (c: string) = c.ToUpper() let pad c = c + " " words |> List.iter (fun word -> word |> capitalize |> pad |> print_string)

At any rate, my half hour of F# exploration is up for the week.
Read More