YOOT

It seems that Oslo is generating some buzz lately, especially since one of the Oslo PMs tried clarifying the situation … still nobody seem to know what it actually is. So, is it another vaporware from Microsoft or is it a revolutionary way of developing software ? does it do coffee as well ?

Well, I obviously don’t pretend having the final answer but I wanted to give my 2 cents on the subject:

• I don’t think it’s just about database development … I have NHibernate, thank you.
• I don’t think either that it’s just about developing textual DSLs … there is Gold, ANTLRWorks, Boo, F# …
• I don’t think that’s it’s just a MDD modeling tool (Middle-Out approach with model transformations and full traceability between models !) … we have tons of them already, and very good ones.
• It might be viewed as a Language / Domain Workbench … (here, here, here & there).
• It might also be at some point a host for executable semantic models.

My hope is that it’s all of that, unified in a single consistent vision and bundled in an integrated suite of tools & technologies. This might well change the way we think about and develop, or should I say model, software.

Maybe I am completely wrong. But if there’s a good mix of those technologies in it, I am very excited about Oslo, even though it is still in its (very) early stages and the future is still somewhat unclear.

And you, what is your opinion about what Oslo is / should be ?

An interesting presentation that I also encourage you to watch (after those ones) is about Creating DSLs in Microsoft Oslo, by Amanda Laucher, if you have any interest in Domain Modeling, Domain-Specific Languages & Semantic Models.

Very interesting presentation by Anders Hejlsberg.

I’ve been pretty busy for the past months … I didn’t have or take the time to write interesting posts and I mostly just linked other articles written by much smarter people than I am.

Nevertheless I wanted to post here a few ramblings …

• Java developers are smarter than .Net developers. They know what SOLID is. They know the theory, not just the tools.
• Scrum looks good … has anybody seen it applied correctly ? (cfr. day to day xp, Flaccid Scrum & Technical Debt)
• It’s very very very difficult to measure a developer’s productivity … don’t believe me ? well, you may be smart but smarter people wrote about it : CannotMeasureProductivity. And it’s unfortunately not just an excuse … ok, we can try to evaluate it through code reviews, but it’s not going to be the panacea.
• Bored of being a simple developer ? well, that’s an easy one : start a company !!! now, how to make it successful ? well … hum … well … there’s no success formula, you have to cleanup & refactor until it’s green … and then start all over again. I think I heard that somewhere already … (How hard could it be ?)
• Why the hell is it so damn hard to write a good business-writeable DSL ? Most of the time because the ‘Less is good’ boy will be pushed away in favor of its evil brother ‘Less it not enough’ (BusinessReadableDSL, DSLQandA) and will lead to an horrible ‘DSLitis’. But don’t get scared too quickly, if you proceed carefully, at least give it a shot, it might be worth it. (ParserFear)
• Are senior / experienced developers that cost at least 2 times more than junior developers really that more productive or bringing that much benefits ? You’re telling me, ‘Bob the rich business guy’, that hiring 2 junior / average developers costing the same as or less than ‘John’ the super duper star developer, they will produce less, or even, considering the improvement over time, the work quality will remain, for a given (short to medium) period of time, under the one of an experienced guy. Well … yeah, and I don’t have numbers to backup that assertion. You just have to believe (PreferDesignSkills, CheaperTalentHypothesis, XFiles).
• F# is damn interesting … but why do I sometimes have to read that line 5 times before I get it ??? Is my brain so ‘wow dude, take it easy’ already ?
• Silverlight is … Cool ;o)

That’s it … maybe one day I’ll write a real article instead of linking to other’s posts. lol

Just ordered a few new books to keep me busy during the long & cold winter nights …

• Concurrent Programming on Windows Vista – Architecture, Principles and Patterns: At the time of multi-core CPUs, having a good understanding of concurrent programming is crucial.
• Agile Project Management with Scrum: want to improve my management skills … they still suck although I’m making big efforts.
• Expert F#: deep dive into the functional way of thinking & programming. Looks damn interesting.
• The definitive ANTLR Reference – Building Domain-Specific Languages: Deadly interesting too … while waiting for Ayende’s book on the subject.
• Learning XNA 3.0: Just for fun.

Next on the list will be VS 2010, M & Repository stuff when there will be some good references on the subject … yeah I know, I’m an old-fashioned type of guy, I like to turn pages made of paper.

Any other good book to recommend?

While waiting for Microsoft's “Oslo” platform, here is a very very interesting (and complex) article on Model-Driven Development & Domain-Specific Languages. Apply with caution … (a.k.a. “Don't try this at home kids”)

Just stumbled on the new soap opera of summer 2008: the so-called Ado.Net Entity Framework Vote of No Confidence (that I will nicely abbreviate ANEFVONC). Come on, we have Euro 2008 Cup, the Olympic Games in China … isn't that enough ?

The open letter describes the main problems that, following the Alt.Net community, currently prevent the Entity Framework from being a great DDD Tool:

• INORDINATE FOCUS THE DATA ASPECT OF ENTITIES LEADS TO DEGRADED ENTITY ARCHITECTURES: Yes, EF is currently mainly about data access … let's hope it will evolve and introduce more & more 'Entity services'. Concerning Business Rules, is there a standard way of expressing Business Rules that EF could include ? Not sure about that but anyway I don't believe that EF currently prevents you to define your BR … because in a system with numerous & complex BR, your BR logic wouldn't be coded right inside your Entities.
• EXCESS CODE NEEDED TO DEAL WITH LACK OF LAZY LOADING: I remember EntitySet<T> has Lazy Loading built-in … but yeah, then you're not 100% PI compliant anymore. And no, I don't need Lazy Loading to keep my business logic free of Data Access concerns. I can use specific Repositories that will contain custom Linq queries if my base Linq-generic Repository is not enough. Lazy Loading is very appeling at first, but frankly, is only applicable to simple cases. 'Transparent data access' is a myth … you need to express a query in some form. Defining relations in order to benefit from Lazy Loading is a very simplistic view of the task of Querying on a Domain Model.
• SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES: Haven't tested EF on that point … but indeed, support for Partial Models (see here, and here) is needed for complex Domain Models (especially when split in many Modules).
• LACK OF PERSISTENCE IGNORANCE CAUSES BUSINESS LOGIC TO BE HARDER TO
  READ, WRITE, AND MODIFY, CAUSING DEVELOPMENT AND MAINTENANCE COSTS TO
  INCREASE AT AN EXAGGERATED RATE: Last time I checked, the EF Team had written a post on its blog to express its commitment to making EF as close to PI as possible … did they changed their mind ? Or is the Alt.Net community not patient enough? lol
• EXCESSIVE MERGE CONFLICTS WITH SOURCE CONTROL IN TEAM ENVIRONMENTS: Well, let's hope it can be fixed.

Although, I think I understand most of the concerns expressed in the letter, I still feel that it focus too much on the data access part of Domain Driven Design … and DDD is so much more than that, right? IMHO, here are some key problems that must be adressed for DDD to hit mainstream:

• Bridge the gap between DDD & MDD: I want to do DDD, but I don't want to know 100 patterns and tricks and tips in order to work efficiently … Gotta focus on defining the Ubiquitous Language right ? What we need is a Meta-Model for DDD that allow us to create our Domain Models more easily than with Code, Unit Tests, Refactoring … I want to work at a higher level of abstraction, please. Give me DDD domain-specific languages !!! (a textual one for purists and a graphical one for realists, both being SCM-compliants).
• DDD Best Practices Validation Rules: Create Generic DDD-specific rules that can be verified on the Domain Model created using the DDD DSL. Allow to define Domain Model-specific rules (= Business Rules) directly at the Model level, using a Business Rules DSL.
• ORM-free DDD Code Generation: Well, if my first wish is realized (DDD DSL), then generate the code for me based on what I have described using the DSL. One way code generation would be fine (if they are enough extension points otherwise, we are back to square one with open letters and blah blah). Bi-Directional DSL would be great, but much much harder. Also, make the code generator pluggable … so that, any ORM-specific artefacts can be generated (keep the core DDD DSL free of any ORM-specifics). Also, generate Business Rules code.
• Relationship as first-class elements of the language: let's get rid of those horrible Add / Remove methods hiding the fact that we are still not able to manage bi-directional relationships correctly & consistently. Make the concept of relationship an integral part of the language (Linq 2.0 ?). A great article on the subject (in french, sorry).

Other interesting (old !) posts that also shed light on the fact that DDD still has a long way to go: here and there.

Personnally, I think that EF is the first building block for more DDD goodness to come … so, give feedback, but be patient. I believe an annoucement like this one can only bring good things. Like NHibernate, Rome wasn't built in just one day.

Or did I miss something ?

Reminder: Never a sign a paper just because a lot of other people did it before you.

While working on a DSL project (a database designer supporting pluggable RDMS & pluggable validation rules) at my current customer, I had growing needs for extensibility in my Domain Model and its graphical representation. Unfortunately, I didn't have much time for experimenting & fiddling with all the power living under the hood of the DSL Tools SDK. That's why I was very happy to discover the JaDAL library on Codeplex, which is a collection of helpful classes & methods that add support for advanced scenarii such as:

• Compartment Mapping: Allows you to create connectors from entries of one compartment shape to another (or to a regular shape).
• Adding properties to Domain Classes at runtime: You can add properties dynamically to your domain classes (different elements of the same domain class can have different properties).
• Restrict dynamically the usage of Domain Properties in DSL Models: Now you can dynamically (for example having a basic and advance mode for your DSL editor) lock or hide properties in the properties window.

More DSL goodies on the blog of the creator(s) of JaDAL …

My house will look like a bookstore soon I've been reading & ordering too many books lately … lol

(Guess it's gonna slow down soon, our most awaited friend 'Sun' is finally coming back to Belgium, my lovely rainy home-country. No wonder why beers are so popular here.)

In case you missed them, here is a quick list of some highly recommended books:

• Domain-Specific Development with Visual Studio DSL Tools: Good read to discover Domain-Specific Development with Visual Studio.
• Programming WCF Services: another masterpiece from Juval Lowy. Cautious: This is a tough read, not an introductory book. But it will surely help you appreciate the design of WCF in all its glory (am I exaggerating ?). Also, if you have the opportunity to attend Juval's stellar presentation 'Beyond the endpoints', don't hesitate 1 second: it was an enlightening experience.
• Patterns of enterprise application architecture: Not new, but you'll find yourself often coming back to it as it provides so much insight about the design of so-called 'enterprise applications'. Don't call yourself senior .net developer or architect if you haven't read it yet
• Java persistence with Hibernate: Yeah, I said 'Java' & 'Hibernate' … why ? because if you wanna know (mostly) everything about persistence with an ORM tool, that's the book. You can then learn any other ORM in 5 minutes.

Other books as recommendable as the previous, that I have at home but haven't read yet (and will read asap lol):

• Release It!: Just received it today, and by looking at the back cover and table of contents, I wish I had read it several years ago. One advice: Read It! That's what I'm going to do …
• Visual Studio Extensibility: The perfect companion for Domain-Specific Development with Visual Studio if you want to create DSL that are highly integrated into VS. I'd like to know more about that Visual Studio 2008 Shell also … looks promising.
• Essential Windows Workflow Foundation: Wanna gain more insight about the design of WF? Everything's in here.
• Framework Design Guidelines – Conventions, Idioms, and Patterns for Reusable .NET Libraries: Do I have to say that it's a must-read for any framework-developer ? Shamefully, I haven't read it yet. Gonna fix that.

Well … gotta go, I have 4 books to read

I’ve recently started a pet project to build a Domain-Specific Language, using Visual Studio DSL Tools, for Domain-Driven Design. Indeed, DDD usually involves writing a lot of code using Patterns, OO constructs, Unit tests … it would nice to work at a higher level of abstraction (hence the graphical designer) and have most of the code generated. IMHO DDD & DSL form a very nice combination, but unfortunately there aren’t many tools yet (or there are some but immature) that are addressing the growing needs of Domain-Driven Design development.

Here is a quick peek at how such a designer could look, dealing with concepts such as Aggregates, Aggregate Roots, Repositories in addition to more common ones such as Entities & Relations:

Yoot DDD DSL Sample

Still a lot of work to be done and a lot of aspects to be taken care of, but if I manage to find enough time and make good progress on it, I might release it as a small open source project.

Additionally, I will try to make it as open as possible, with a plugin system, so that code and other artefacts generated from the diagram are completely customizable.