Ok I am yet again frustrated by having to grapple with WCF configuration. I would love to see someone write us all a really nice fluent interface for WCF configuration so we can all be put out of our misery. As Juval (WCF Uber Meister) has said from time to time, the configuration options in WCF are somewhat akin to the controls on a Jumbo Jet. I suspect that Juval has a photographic memory or perhaps flew Jumbo’s in a previous career; whatever the case, he seems to have all the configuration options and combination scenarios printed on his brain, but Juval is the exception and not the rule.
I would gladly have a go at putting one together myself but I have other projects that sit in front of it in the queue and would be glad to see someone knock one up before I get to it. If anyone knows of one out there that just hasn’t come to my attention, then please point it out and I would be most grateful. Perhaps I can drag a colleague or two into the fray?
I am thinking. Stop that you say? Seriously, I have been wondering about combining a fluent interface with a some VS.Net VSX visual DSL tooling. I am currently working a small internal domain specific language and it occurred to me that rather than leaving the only method of access to the DSL as raw code, that perhaps by building out some visual entities around the entities expressed through the DSL, I might just be able to build a platform and not just the DSL on it’s own. So if we have code like:
3.Month.Old.Documents(“Contract”)
created by a designer like experience along of the lines of this:
Just having preliminary thoughts about this at the moment and I can already see that the vocabulary of DSL runs the risk of being influenced by the UI design in way that obscures and corrupts its meaning. For example should it read:
//makes sense
3.Day.Old.etc
//seems awkward and clunky
3.Day.InFuture
A quick revision to the Fluent Interfaces and Designer and we might get this:
Ok so we can start to think about all sorts of things when it comes to the readability of the language underneath the designer but my next question is what about constraints? Should we have any? Does it feel right to leave the user the ability to define a design that would produce this:
But I don’t want to start building constraints around what would amount to business logic concerns now, or do I? A lot more thought is required on this whole topic I think.
I just cant seem to shake Ruby off. Often something comes up in my day to day job that pushes me get serious about Ruby and for as long I have the idea of the Polyglot programmer in the back of my mind, I feel compelled to find out more, even if it’s in microscopic increments. A while back I installed Ruby on my development laptop and played with the interactive console for a while and then predictably got distracted and didn’t follow up for months, until today when I downloaded NetBeans (Ruby version only) and made a decision, that to understand Domain Languages better I wanted to learn more about a language that would help in that understanding. Ruby is well thought of with respect to being a useful language to 
develop internal DSL’s and given the other sentiment in this post, I thought it was as good a choice as any. I have been a C# developer since beta of the 1.0 Framework and now that IronRuby and DLR are close at hand, I feel compelled to let my interest in DSL’s, the DLR and learning a dynamic language begin to engulf me to the point that I have been stung into action. So with this in mind I am setting down the path to learn Ruby and hope that this provides a great springboard into taking up IronRuby. Of course the benefit of going deep into another development language and platform I believe will lead to a far richer appreciation of the platform I am currently so deeply invested in.
Last Minute Update:
After re-listening to the HanselMinutes podcast with Robert Pickering on F#, it would appear that F# is a potentially useful language for creating internal DSL’s. I have been thrown a little as I must confess this threw things into debate for a short moment. The argument that kept me down the Ruby path was the relationship that IronRuby has with the DLR and the upside that brings to the learning experience. 
Last minute problem solved. Wait hold the press. VbX or Visual Basic 10 is on its way and it too will be a dynamic language. Dilemma. Given that I am almost equally conversant in VB as C# (I prefer C# by choice), perhaps I should concentrate on F# and let my strong understanding of VB languages to carry me through the transition to VB10 which gives me the DLR leverage? Again I decide to take the Ruby path also because its not a Microsoft Language per se and I think the exposure to Ruby in general will do me good from a platform perspective. I would also like to use Ruby in exploring RESTful Web Services. So I have downloaded NetBeans and installed Ruby 1.8.6 and here I go.
Ok I am yet again frustrated by having to grapple with WCF configuration. I would love to see someone write us all a really nice fluent interface for WCF configuration so we can all be put out of our misery. As Juval (WCF Uber Meister) has said from time to time, the configuration options in WCF are somewhat akin to the controls on a Jumbo Jet. I suspect that Juval has a photographic memory or perhaps flew Jumbo’s in a previous career; whatever the case, he seems to have all the configuration options and combination scenarios printed on his brain, but Juval is the exception and not the rule. 
