Things have got a little less confusing..

So, big congratulations to Alex J - first an MVP and now a Microsoft employee to boot... (which I suspect trumps his MVP status, probably should be MVE now, for Employee!).

I've been working with Alex (2 Alex's... very confusing) on a pretty interesting project for the last couple of months, and it's been a lot of fun getting a brain dump from a guy who's so passionate about technology (and community too) and with so many varied and original ideas... Whenever Alex J starts a sentence with "now I've been putting some thinking around this" you generally know your about to learn something cool :)

On a side note, I'm thinking of taking over the organization/blogging etc. of the Sylvia Park Architecture Chats in the other Alex's absence... It would be a real shame to let it die once Alex J has moved to the states... at any rate, something to talk about this coming Thursday at the next chat!

Read More

playing with feeds...

I decided to have a play with some of the new aggregation-esque platforms this evening... for a break from cutting code...So first off I had a play with dapper, turning the castle project's build feed (that's html) into an RSS Feed... It was painless, and required zero skill ... but it was limited in what it was capable of achieving... basically you can just just click on the content you want, give it a name, then pick which named parts will make up say an RSS feed.

dapper.png

It's pretty elegant at what it does, though I think it's got a way to go before it'll parse some of the more tricky content out there.

The next thing I did was to have a go with yahoo pipes... I decided to do something pretty simplistic, aggregating the feeds from the Fisheye change log RSS for the castle proejct with the feed I'd created with dapper.net for builds.... this was a delightful drag and drop experience, I didn't even read a tutorial ... I just seems to "work" exactly as you would expect.

The resulting published pipe is here.

yahoo_pipes.png

I didn't originally have the truncate step in the pipe, but had to add it after attempting to burn the feed with feedburner (it was over 512K in size, so feedburner politely said "no") after that it burnt just fine... as you can see:

feedburner.png

I couldn't get the two aggregate feeds to sort correctly, but I'm sure it's possible using yahoo pipe's, any new events should appear in the expected order though... you can subscribe to the feed here if your curious.

Of course the hosted platforms aren't much use if you need to handle private/local feeds or interact with other types of systems (like your private gmail account) and that's where I believe something like plagger comes into it's own... I haven't had a chance to play with it yet, but it's definitely on my list of things to do... there's still a lot of manual information management and categorization/organization that I'd rather hand over to some kind of automated agent.

[Disclaimer: I'm no expert on these kinds of things, I just figured there might be some other "head-in-the-sand" developers who haven't played with these kinds of sites, and might find it interesting like I did ;o]

Read More

Note to self...

Wasted 5 minutes figuring out what was going wrong, maybe this will save someone else the effort!

When using RhinoCommons and CastleProject both from trunk there's a version conflict with NHibernate.

RhinoCommons has NHibernate Version 2.0.0.1001 (Including support for things like Multi criteria) ... and then the Castle Project is using NHibernate Version (1.2.0.4000) - this took me a little bit by surprise when I discovered that a monorail project I had was failing when attempting to databind properly when using the ARSmartDispatcherController... because I wasn't checking the binding errors collection, this was just failing silently... so a save would just load/save the existing record, without any binding.

Quick fix is just to use a  assembly binding redirect in the web.config:








Read More

And like that it was gone...

Well I've had a highly unproductive afternoon scrambling to rebuild my development PC after the RAID 5 decided to kill itself off... at first the pc reported one disk had fallen out of the raid... I brought it back in, rebooted, the machine started rebuilding the array then rebooted itself.. at which point it declared each disk was a member of different array... stuffed around with it for about an hour and contemplated throwing a 750gig drive in and doing a software-based recovery... but considering last time I did something like that it took a number of days to complete, I decided to just heave a large sigh, break the array up into individual disks and re-install (without RAID-5 this time...).

Thankfully between svn, google apps (gmail for domains, google reader) and del.icio.us I don't think a lot has slipped through the gaps, barring the odd bit of skype history.

Guess I know what I'll be doing this weekend.  bleh!

Read More

Wading in on the language debate

So I see both Andrew, Nick and Alex
J
have some thoughts on languages, and of course Rowans post sparked it off... and
people talk about beautiful languages, mentioning expressiveness
in the same breath. 

Personally I love how expressive Ruby is - I think
potentially because I got my first exposure to ruby after reading
Why's poignant
guide
 a while back (I see there are new chapters
...oooh) which was quite surreal compared to how I say learnt C++
(from reading the Borland Turbo C++ manual when I was 11, also my
first exposure to OOP)...

When I code in ruby I feel like I'm telling stories... I dig that
:)

So Alex J mentioned that extension methods let us achieve much of
the syntactic sugar that ruby provides (though obviously in
ruby's case this isn't so much syntactic sugar as core mechanisms
in the language itself) - and of course Lambda expressions are
helping too, but does expressive == good 100% of the
time?   I don't think I'm qualified to say, but I can't
help but feel that a language which is very expressive, isn't
necessarily the easiest to manipulate and refactor, so I may not
be as productive and it may not feel as fluent to me... I quite
liked this resharper horizons post which suggests that tooling
support should probably influence future language design - could
that requirement possibly fight against an increased level of
expressiveness in a language, will compromises need to made, or
is nirvana just around the corner?

As for C# vs VB.Net - large clumsy keywords are only a
probablem until something like Resharper steps in... when I'm
developing I see a lot of unusued space on the right hand side of
the editor with C#... if VB.Net fills it up, and I'm not typing any
harder to get there, why should I care - hell it'll probably make a
VB.Net Resharper Jedi look more impressive then the C# equivalent,
he'll be producing more characters ;o)

OK, well I figured this post should at least have some code...
I'd feel uneasy otherwise... so how about:

public static class CommonExtensions{    public static Action<>> LoopTo(this int start, int end)    {        return new Action<>>(action => To(start, end).ForEach(i => action(i)));    }     public static IEnumerable To(this int start, int end)    {        if (end < start)="" for="" (int="" i="start;" i=""> end - 1; i--)                yield return i;        else            for (int i = start; i < end="" +="" 1;="" i++)="" yield="" return="" i;="" }="" public="" static="" void="">(this IEnumerable sequence, Action action)    {        foreach (T item in sequence) action(item);    }     public static void PrintLine(this object o)    {        Console.WriteLine(o);    }}



So now we could try and do this....


// ruby(10..20).each { |i| puts i }// C#10.LoopTo(20) ( i => i.PrintLine() );



Alas I don't think C# will ever match ruby in this game, no
matter how we try to nudge it there... and until the development
community figures out where the healthy place is to draw the line
in the attempt, we may be doing more harm then good by pushing
for it, sacrificing discoverability/maintainability for
expressiveness.   Maybe that's just dogma, and
expressiveness makes code inherently easier to maintain in the
first place, so we don't need to care.... time will tell.



Of course I could be wrong, I am a little sleepy ;o)

Read More