Updates from December, 2011 Toggle Comment Threads | Keyboard Shortcuts

  • danielsaidi 4:12 pm on December 8, 2011 Permalink | Reply
    Tags: circular namespace dependencies, , implementation, ,   

    NDepend getting my juices flowing 

    I have been using NDepend to analyse the latest version of .NExtra. The code is spotless (this is where you should detect the irony), but the analysis is highlighting some really interesting design flaws that I will probably fix in the next major version.

    First of all, almost all cases where method or type names are too long are where I have created facades or abstractions for native .NET entities, like Membership. Here, I simply add exceptions where NDepend will not raise any warnings, since the whole point with the facades are that they should mirror the native classes, to simplify switching them out with your own implementations, mocks etc.

    Second, NDepend warns for naming conventions that I do not agree with, such as that method names should start with m_. Here, I simply remove the rules, since I do not find them valid. However, when I look at it after removing the rules, I could have kept them and renamed them and make them check that my own conventions are followed. I will probably do so later on.

    Third, and the thing I learned the most from today, was that I turned out to have circular namespace dependencies, despite that I have put a lot of effort into avoiding circular namespace and assembly dependencies. The cause of the circular dependencies turned out to be between X and X/Abstractions namespaces.

    Circular dependency graph

    The base and abstraction namespaces depend on eachother

    For instance, have a look at NExtra.Geo, which contains geo location utility classes. The namespace contains entities like Position and enums like DistanceUnits, as well as implementations of the interfaces in the Abstractions sub namespace.

    Now, what happens is that the interfaces define methods that use and return types and entities in the base namespace. At the same time, the implementations in the base namespace implement the interfaces in the Abstractions namespace. And there you go, circular namespace dependencies.

    Now, in this particular case, I do not think that it is too much of a deal, but it highlights something that has annoyed me a bit while working with the .NExtra library.

    In the library’s unit tests, the test classes only knows about the interfaces, but the setup method either selects a concrete implementation or a mock for the various interfaces. For an example, look here. This force me to refer both the base namespace as well as the abstractions namespace. Once again, this is not that bad, but it raises the question…

    In the next minor version of .NExtra, I will probably get rid of the abstraction namespaces, since they add nothing but complexity. Sure, they tuck away all interfaces, but why should they?

    • Daniel Lee 6:40 pm on December 8, 2011 Permalink | Reply

      Were you inspired by Greg Young’s session at Öredev? I have to get into NDepend as well. Did you buy a license or you testing out the trial version?

    • danielsaidi 9:30 am on December 9, 2011 Permalink | Reply

      I have been using NDepend for a while, but yeah, Greg’s session opened up my eyes for other ways of looking at the metrics. And even if I remove some metrics (like methods should start with m_, static members with s_ etc.) it is really striking how some of the metrics really highlight design flaws that are easily corrected.

  • danielsaidi 11:41 pm on December 6, 2011 Permalink | Reply
    Tags: cqrs, , ddd, event sourcing, , , rickard öberg, uncertainty   

    Øredev 2011 in the rear-view mirror – Part 3 

    Øredev logo

    This is the third part of ny sum-up of Øredev 2011.

    I will label each session with day:order to satisfy all structure freaks (myself included) that read this.


    2:1 – Dan North – Embracing Uncertainty – the Hardest Pattern of All

    If there is one session I really regret not attending to, it has got to be this one. Everyone I spoke to afterwards were totally blown away by Dan’s keynote about how we humans strive to avoid uncertainty at all cost, even in situations where uncertainty would be a much better mode to be in than being certain.

    Uhm…I’ll just point you guys straight to Daniel Lee’s excellent blog, where he write more about this session.

    Dan North

    The quote “Fear leads to risk, risk leads to process, process leads to hate… and suffering and Gantt charts”, “We would rather be wrong than be uncertain!” and the way Dan reasons about how faith become religion makes this the top session that will keep me waiting for the Øredev videos.


    2:2 – Greg Young – How to not apply CQRS

    I just love Greg. After this session, I stormed out of the room and bursted out “I think it is SO cool that Greg is, like, the Henry Rollins of software engineering”, on which a complete stranger turned around, equally happy, and almost shouts “I KNOW!”. A minute or so later, I happen to overhear a conversation, where one guy says “Wow, Greg looks JUST like Phil Anselmo”.

    Greg Young

    Henry Rollins?

    Yeah, Greg is the personification of all those metal vocalists we always wanted to be (or be friends with) and lets us embed ourselves in a thick layer of ignorance that allows us ignore that we are a developer converence. Oh no, we are almost those rock stars we dreamt of to become…and almost friends with Phil and Henry. I also think I saw a little bit of Mike Patton in his eyes, and a piece Christian Bale in the way he speaks.

    Henry Rollins

    Greg Young?

    All this despite the fact that Greg wears Five Finger Shoes. Five Finger Shoes!

    That is quite an achievement.

    But hey, what did he talk about, I hear you ask. Well, I frankly do not remember. No, that was a lie. Greg talked about how one good way to fail is to apply CQRS everywhere within a monolithic system. CQRS is not a top level architecture. It requires a bounded context. So, to apply CQRS in a non-core context, and without a bounded context, is an almost fail-proof way to fail. With CQRS applied everywhere, nothing can change.

    Greg then went on to speak about CQRS and DDD, and the dangers of imaginary domain experts. Who can be considered to be a domain expert? The consultant who have worked with a system for a while, who maybe even answer to another consultant? Or is it an employee who have worked with the domain for a couple of years? How about twenty years?

    This is really important, since CQRS is business-centric, which is why CQRS and DDD without domain expertise does not work. The result will become like playing the telephone game and translating Shakespeare with Google Translate. BA:s are really good at asking the right questions, but they are not domain experts.

    As an exercise, Greg talked a bit about Programming as Analysis, which I’d like to try. The point is that you are supposed to build a system for a domain that you do not know. Now, timebox your access to the domain expert to two hours. That is it. In two hours, you  have to find out everything you need to build your system. The entire system. Sure, you will fail. Fail hard. But, in doing so, you will come up with a bunch of new questions. So you throw everything away. Everything. Then you do it all again. Two hours. Build the entire system. Then again. Then again.

    Greg finally summed up his session with pointing out the most certain way to fail – by learning CQRS by building a CQRS framework. Instead, focus on the business value of applying CQRS. He finished his great session with calling frameworks “crack for architects” and  stating that frameworks are evil.

    Great one, Greg. Thanks a million. Now, drop those five fingers and I would not hesitate to put a poster of you up on my wall.


    2:3 – Rickard Öberg – Event Sourcing explained

    Next to CQRS, which I have not had the pleasure of applying (maybe I should build my own CQRS framework…or?), Event Sourcing is something that I’d love to try out.

    Rickard Öberg

    Rickard started with describing a common architecture:

    Client <- Service facade <- Domain <- Storage

    and how with Event Sourcing, things look a bit different:

    Client <- Service facade <- Domain (Commands -> Events) <- Event storage

    We do not store state – we store events, which is a huuuuge difference. By storing the events, we can replay all the events that has affected an entity during its lifetime, and in such a way build it up from scratch to its current state. In order to avoid really heavy operations, we can store snapshots as well. With snapshots, an event stack like this one (the latest event is topmost):


    is handled by starting with the lastest event. As long as the item is not a snapshot, we keep it for later. Once we reach a snapshot, we grab that representation, then apply all the events that we have kept for later. This way, we do not have to replay the entire life of the entity, just a part of it.

    That is basically it.

    Rickard, however, then went on to talk a bit about his event sourcing framework. Obviously suffering after Greg’s recent framework burstout, Rickard had the balls to still insist that his framework was really good…and that he likes to use it. I for one believe him.

    With event sourcing, report generation becomes a breeze. Also, you never loose data. If I add 5000 to my bank account then withdraw 3000, and no events are stored, all I know is that I now have 2000 more than before I started. Sure, maybe the system writes transactional details to the log, but with event sourcing, the event storage becomes the log.

    Due to its log-like nature, event sourcing also simplifies debugging. Who did what when? With event sourcing, nothing gets thrown away. My events is what makes my entities look the way they do. If an event accidentally was not saved, that is bad, sure, but it is another problem. My entity does not know about it, since the event does not exist.

    Event sourcing continues to interest me. Maybe one day, I will actually get around to use it?

  • danielsaidi 8:50 pm on December 1, 2011 Permalink | Reply
    Tags: api, , , fredrik mörk, , , nathan totten, neil ford, , phil haack   

    Øredev 2011 in the rear-view mirror – Part 2 

    Øredev logo

    This is the second part of ny sum-up of Øredev 2011.

    I will label each session with day:order to satisfy all structure freaks (myself included) that read this.

    1:4 – Phil Haack – Building Mobile applications with ASP.NET MVC4, HTML5 and jQuery Mobile

    This session was quite interesting, since Phil discussed a lot of aspects of mobile browsing and how ASP.NET MVC4 can help you out by introducing .

    Adaptive rendering will be added to the default web application template, which will cause the page to automatically render differently depending on the size of the screen. If you want to view how adaptive rendering works, check out Zurb Foundation. In other words, ASP.NET MVC4 does not introduce adaptive rendering to the world – there are already plenty of free options that you can greb and use directly after reading this post. It’s just a convenience.

    Another new, cool feature is that it is possible to create device-specific variations of the same view, so that Index.cshtml is the default one and Index.iphone.cshtml is the variation that you’ll see when viewing the site in your iPhone. Custom modes can be registered in global.asax, which means that you are entirely free to tailor your own set of custom views.

    Phil also demonstrated using iBBDemo2 for simulating an iPhone when browsing the web. Quite handy if you want to easily be able to try out your custom views.

    All in all, a quite interesting session, although Phil did not seem too enthusiastic about it. Also, the wifi at Øredev was a disaster, and caused several speakers a lot of problems. I really hope they improve this until next year.

    1:5 – Nathan Totten – Facebook Development

    Nathan was yet another speaker who got hit hard by the wifi problems, as he demonstrated how to develop apps for Facebook. I really enjoyed this session, despite the technical problems and the fact that I already have developed Facebook apps. Since I am self-taught in doing so, though, listening to Nathan explaining several parts that I have not gotten around to work with before, was a great take-away.

    Nathan talked about various types of Facebook applications, like iFrame apps, web sites with Facebook Connect, mobile applications, desktop applikations (like Spotify) etc. and how they use OAuth 2.0, REST services, the Facebook Graph API and FQL to integrate with Facebook. He also discussed the JavaScript and C# Facebook SDK:s. His advice was to use the JavaScript SDK whenever possible, and to a server-side SDK whenever the integration should be more invisible.

    Finally, Nathan demonstrated how he works with local and live applications, e.g. if you are developing an application locally (running on localhost) and have it live as well. He then creates two separate FB apps – one that is bound to the live site and one that is bound to localhost. Quite convenient. He also told us that  FBML is dead, so do not use it ever again 🙂

    1:6 – Fredrik Mörk – API – the hidden UI

    The first Swedish speaker I got around to listen to was Fredrik Mörk, who spoke about how we have to give our API:s the same tender loving care that we give our UI:s. Users shun bad GUI:s, while developers shun bad API:s, so we should put some effort into our API designs.

    An API must be discoverable, but how? Always assume that the user knows nothing. So, adapt conventions used by other API:s, so that developers instantly recognize the API instead of having to remember it. even if they have not used it before. This involves making it possible to navigate through the API, adapting naming conventions (delete or remove, store or save etc.), put an equal amount of attention to all parts of the API and…take care of the API like you do with other parts of your systems.

    Fredrik advised us to always expose as primitive as possible, to make the API accessible to as many as possible. Always choose abstract before concrete…and choose your abstraction according to the purpose. For instance, if you expose an IList instead of an IEnumerable, you are communicating that you expect your users to insert stuff into it.

    Fredrik’s view upon an API is that once it is out there, it is no longer yours to change. A GUI can change…an API cannot. But, be careful with inserting stuff into your API just because a user wants it in there. It will ultimately bloat your API. And when you insert stuff, be intentional. Do not let chance determine where a feature ends up and what it is called.

    All in all a good session…and quite liberating with a Swenglish accent instead of the spotless American, Scottish and British ones that dominated the rest of the day.

    1:7 – KEYNOTE: Neil Ford – Abstraction Distractions

    After a long day, we decided to skip this session and go for a short nap before hitting a meat restaurant. I have not spoken with anyone who attended it either, so I am at a loss whether it was good, bad or just meh. It will be interesting to check out the video once it is released.

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc