Sunday, February 28, 2010

Slides and demo code dotNed event February 27th

As promised, you can review the slides from yesterday’s DotNed event on Software Development Practices from here, and you can download the source code from here.

Notice that you need Visual Studio 2010 Beta 2, the Silverlight 4 Beta tools and the Silverlight 4 Beta Toolkit November 2009 to run it. Since the Visual Studio 2010 RC build does not support Silverlight 4 yet, you can’t use to run the demo.

Update March 9th: I’ve uploaded a new version of the demo code that takes advantage of our new Fluent Assertions framework and shows how to extend it with your own fluent extensions.

DotNED event on software development practices was awesome

It’s Sunday morning and I’m looking back at an awesome DotNED event in Doorn. The location was very nice, the audience was a blast, and my two fellow speakers Jonne Kats and Peter Hesseling did a great job.  Thanks to everybody for being there!

DSCF1664 DSCF1663 DSCF1657 DSCF1660

Some of the statements made on Twitter for backing up my enthusiasm:

  • obelink: +1! and @ddoomen: well done!
  • roelsn: Druk dagje vandaag! Leuke #dotned meeting in Doorn thnx @ddoomen
  • LocalJoost: What I especially liked about #dotned was the concrete translation in code of pretty high level architecture concepts. Makes it alive for me
  • RolandGuijt: @ddoomen #dotned You’re welcome. You did a great job dealing with the feedback and the atmosphere was very relaxed. Thanks!
  • peSHIr: Agreed. I’d like to see (and discuss) at least half of the @ddoomen #dotned material if I could...
  • sorskoot: Had a great #dotned day today!
  • peSHIr: Same here. Was great day anyway, but I guess I really missed something today as well. #dotned
  • evappeld: Attended great #dotNed event today, @ddoomen thanx for sharing your thoughts about a good software architecture.
  • Felienne: Finally back home after an interesting #dotned day. Thanks @ddoomen and @thomashuijer for organizing and @pjvds for the great discussion.
  • rclemens: Net trg uit Doorn van een #dotNed meeting...Toch maar aan TDD en BDD beginnen..Ook de rest van de info van erg boeiend...
  • eNeRGy164: Thx @ddoomen for the great day with ATDD, TDD, DDD, BDD, PT, WCF, RIA, MVC, MVP, MVVM, .NET, R#, and some more abbrivation :) #dotned
  • nielsvanderrest: End of a great all-day #dotned event, plenty of material to discuss at work!
  • cultiv: Mooie #dotned dag hoor, er mag vaker de diepte in gegaan worden. Alle organisatoren bedankt!
  • zeilplan: @ddoomen bedankt! Was een nuttige invulling van het weekend! #dotned
  • mmjv: #DotNed dag bijna afgelopen, was leuk en interessant. Dank aan organisatie en presentatoren! http://yfrog.com/4izdnoj
  • LocalJoost: Eindelijk geen Dennis onstage #dotned ;-)
  • mmjv: TDD: When_eating_too_much_paaseitjes_it_should_throw...._up #DotNed
  • beaker73: #DotNED De mensen druppelen weer binnen, na de lunchwandeling. Tweede deel kan elk moment beginnen. Tot nu toe zeeeeer informatief

Friday, February 26, 2010

My first thoughts on WCF RIA Services

While working on my demo code for my full-day talk on Software Development Practices in Practice I was a bit ambitious and introduced both Silverlight 4 and WCF RIA Services. Apart from the fact that the preparation caused a bit too much of my social live, I ran in some things I don’t really like and hopefully will be improved in next versions of the WCF RIA Services. If not, I’ll have to remove it from my reference architecture.

  • The generated domain context class does not include an interface. If you want to TDD your view model classes, you have no choice then to introduce a thin adapter. Moreover, classes like EntityQuery and LoadOperation require all kinds of constructor arguments, so you cannot easily use a mocking framework.
  • I use a domain model to hide all the database details from my object-oriented design, so I surely do not want to see any foreign key fields in my service layer. The composition functionality in RIA requires the use of the [Association] attribute to specify how my childs are related to my parent and that involves referring to the identifying properties that relate the two together. In fact, you have to use literal text for that, so be careful if you rename your properties.
  • There is no built-in support for reloading the client data after submitting the changes to the server. And even if you explicitly chain a reload after your call to SubmitChanges, you have to be aware that it will not remove anything that was deleted by somebody else. In fact, if your entities have a server-generated identifier, you may end up with duplicates (one with and one without identifier). See this post for a workaround.

Thursday, February 11, 2010

How to split a solution into projects

Yesterday, a colleague of mine asked for some guidance on how to partition a Visual Studio solution into individual projects. Instead of simply answering his email I thought that blogging about it may be useful for others as well, so here are my rules:

  • In general, have as few projects as possible. Having many projects considerably slows down compiling, but also causes the startup time of the corresponding application to increase. Loading 10 small assemblies is much slower than loading one big assembly. Jeremy (D. Miller) mentioned this already in this post, but Patrick Smacchia, the author of NDepend, provides some good proof of if it here.
  • Web Application or Web Site projects should, for obvious reasons, always have their own project. However, make sure you move as much logic out of it if you consider automatic testing important.
  • Never use logical architectural layers as a reason for partitioning your code in multiple projects. Likewise, never use it to prevent classes from accessing their internal members. Consider using Visual Studio 2010's Layer Diagram for verifying dependencies or use NDepend's excellent analysis engine. You can still use folders within your projects to maintain a clear logical separation.
  • Only split up your code if you need to deploy parts of your system separately.
  • If you like to run your unit and integration tests from different daily builds, it may be wise to put them in separate projects. We typically run the fast and independent unit tests as part of our Continuous Integration build, and only run the database-touching integrations tests from the Nightly Build. In Team Build, the easiest way for specifying which tests to run is by specifying the name of the assembly containing the test classes.
  • Consider the guidelines written down in Team Development with Visual Studio Team Foundation Server. It provides some very good alternatives that also account for branching and release management. And don't let yourself scared off by the use of TFS. These guidelines apply to all source controlled environments.

Silverlight Reference Architecture revisited

Update October 2010: I’ve started a new in-depth series on my current Silverlight 4 Reference Architecture.

In July I posted about my considerations for a Silverlight Reference Architecture, and in December I talked about it in my chalk’n’talk session on architecture, WCF RIA Services and Silverlight at the SDN Event. Although I haven’t posted about it since then, I’m still working on it. Especially the recent release of Silverlight 4 and WCF RIA Services has provided many opportunities. In fact, during my full-day workshop on software development best practices on February the 27th, I’ll be using this reference architecture in my case study. In the mean time, the illustration below shows it in full color :-)

image

Monday, February 01, 2010

DevDays 2010 wildcard proposal: Is Entity Framework 4.0 ready for the real thing?

Introduced in the 2009 edition, this year’s Microsoft Developer Days is again offering wildcard sessions to anyone who posted a proposal on their Facebook site. Obviously I posted a proposal as well, and partly thanks to the community and partly because there were only eight proposals, my proposal is now available on the DevDays site for voting. Support me by going over here and voting for my session.

ALM Practices Part 2: Peer Reviews

What is it?

A formal review of all code and artifacts related to a requirement or task by another person than the original developer. Rework because of review comments must be revalidated afterwards.

Why would you do that?

  • Because the average developer
    • introduces 10-50 bugs per 1000 lines of code (at least, according to Moore’s Law)
    • is not always aware of the potential pitfalls of particular code constructs (hence coding guidelines)
    • is not always up to date with all available constructs in a new C# version
    • does not have full awareness of all the out-of-box solutions offered by the .NET Framework, open-source sites or commercial vendors
    • often does not realize that an ingenious and elegant solution may be too complex to understand by others.
    • sometimes loses sight of the overall solution and the initial goal when working on a some piece of code too long.
  • Because it helps improve the awareness of, and the understanding behind your company’s coding guidelines.

Notice that the amount of necessary review work can be reduced by introducing the Pair Programming practice.

What’s the bare minimum you need to do?

  • Find issues in the interpretation of the functional requirements.
  • To verify compliance against your coding guidelines or standards.
  • If you don’t have one, consider the Aviva Solutions C# 3.0 Coding Guidelines. Notice that these are an extension to Visual Studio’s Code Analysis, so the latter is still worthwhile.
  • To find any loose ends such as TODOs or incomplete code. Resharper 4.5 includes a nice tool window that quickly shows an overview of all TODOs in your current solution. Resharper 5.0 even includes solution-wide analysis that finds dead code.
  • To ensure that all code is easy to read and understand. For instance, all members and types have a comprehensive name and non-trivial code is annotated with code comments.
  • To ensure that each and every check-in improves the code base, rather than introducing software rot.

What’s the usual thing to do?

  • To ensure that all naming of code elements matches those of the functional design, preferably using Domain Driven Design’s Ubiquitous Language.
  • To check for the usual pitfalls such as God classes or methods that are way too long.
  • To find any redundant code or code that is unnecessarily complex and requires refactoring.
  • To find any code constructs that may put other developers on the wrong foot and therefore jeopardize future maintenance.
  • To find code constructs that can be replaced with a simple call to a previously developed generic class or .NET Framework construct.
  • To stimulate the use of design principles such as S.O.L.I.D. or the design patterns defined by the likes of Martin Fowler and Eric Gamma so that the overall code quality increases.

How do you do that?

  • It is important to make sure that all files related to a particular piece of functionality can be easily found. Use a Check-in Policy to associate each and every change with a corresponding work item such as a Scenario, Task or Bug. Since a major change may involve multiple check-ins, especially in a larger team where multiple developers work in the same areas of your code base, Change Sets provide insufficient traceability.
  • Use a logging form or something similar to review every piece of code related to a particular work item and store it on the project’s team site.
  • Alternatively, copy and paste the code into Microsoft Word, and use its reviewing features to annotate the code with comments and improvements.
  • Or even better, install TeamReview and its corresponding Review Response work item and add review comments directly from inside Visual Studio’s code editor, while keeping them together under the associated work item. Also check-out this poster illustrating the underlying review workflow.