My blog has been quiet for quite a while. My inspiration comes from crunching/exchanging information which I should do more often.

Gartner analysis tells us that by 2013 mobile phones will overtake PCs as the most common Web access device worldwide. A few years back I would have said non sense, but apparently most Web users are comfortable with less processing power. Just take a look at the increasing business in Netbooks.

Wouldnt it be great to have a mobile phone which can connect wirelessly to my home TV, monitor, car display, mouse, keyboard, etc? And to have the processing power of the current Netbook generation?

Where can I buy it?

Why are we making our PC devices (for instance the slate) smaller while we can make our mobile devices functionality bigger?

What about the single responsibility principle? Does it apply to physical devices as well as good object-oriented software?

Analyzing functional requirements for your application to capture what and how your application should work is not necessarily domain driven design. Yes, both techniques leverage the domain model pattern to structure responsibilities in code.

My tip is to pay close attention to who the real domain expert, business user or sponsor is.

Translating use-case documents into a domain model representation doesnt imply that youve captured domain concepts in code. Unless the use case writer is a domain driven design enthusiast.

Some of my clients have/had challenges embracing object-relational mapping data access APIs. Ive experienced this with introducing Neo, IBATIS, NHibernate, LLBLGen Pro, LINQ to SQL and Entity Framework in projects for our clients.

As with most things in our field this hasnt much to do with the technology choices we make. Better collaboration is the key here. Im glad that Patterns & Practices acknowledges that guidance in this area could help these two groups to leverage each others strengths. Im confident that enabling a better understanding of both domains will improve the adoption of Microsofts data access apis in the future.

Please give your feedback on the Data Access Guidance wiki.

I was triggered by Denniss post Why developers should not be happy with a project manager in which he states.

..in a team with different roles, theres always the product manager and the program manager. These roles can never be filled by the same person. Putting it simple, the first role is there to make sure the customer gets what he wants. The second role is to make sure the team isnt stressed out, can do their job, etc.

Dennis continues with..

People involved so far are also pretty anxious to use Scrum and some XP practices for this project, so well see where this ends.

This reminded me of my own project experiences. Agile purists better stop reading ;) Looking back I cant really say that applying more Agile methods gave perceptible better results. We did, however, spend more time thinking about the development process while applying Agile practices. During these times we strongly focussed on the sum of all the parts. I felt as if everyone in this big team had an equal share in the joint success.

Success equals the sum of all the parts.

Years ago I was very strong in advocating Agile over the Waterfall approach. Today I dont care so much anymore which process is being applied as long as we all realize that success equals the sum of all the parts. My advice is to focus on the connection between your work and the work of others. Have great projects!

The Patterns & Practices team is working on the upcoming release of its Application Architecture Guide, 2nd Edition which should arrive late summer this year.

One of the areas the team seems to be concentrating on is Domain-Driven Design (DDD). A how to guide is publicly available since January. Skimming through the comments it appears that developers/customers are challenging the original authors how to apply the ideas and experiences published in books (Evans, Fowler, Nilsson).

Implementing a domain model in a general purpose language (Java, C#, etc) is challenging. Key to success is to have as little distractions (from the development platform) as possible. The set of design principles and patterns will help to accomplish this goal. I learned that, after discussing ideas with attendees during my Applying Domain-Driven design in .NET talk at SDC 2007, theres a strong focus to overcome the technology use/constraints in applying DDD in our target platform.

My advice for the Patterns & Practices team is to focus on:

Which principles and patterns should be applied (as a coping strategy) for the distractions in the development platform?

Please realize that this is different from guidance on how to implement DDD-patterns with the .NET platform.

Language workbenches are well underway to completely change the way we do programming, so we might not this guidance anymore ;)

I love the summaries on InfoQ. Earlier this week I received a presentation by one of the customers developers. Basically they used MVC for a spreadsheet type application. The answer to the question what made you guys decide to use MVC for this applications was interesting because we wanted to learn something new, and because its cool!. Thats when my architect alarm bells start ringing. What Id like to add to the whole ASP.NET MVC discussion are these two questions:

1) Why do you need an MVC in your application?

2) Why is the, compared to other alternatives, ASP.NET MVC the best MVC solution for your application/environment?

Received my Thinkpad from Lenovo repairs earlier this week (vga output issue). A couple of minutes later the Windows 7 installer was running.

After all this time I assumed MS would have fixed my biggest gripe with Vista. Network copy performance. Rest assured... it's even slower in Windows 7.

update: Copying large (200 MB) files fails with the error "Make sure you are connected to the network and try again". It looks my Windows 7 adventure will be a short one.

update2: Updated the wireless network driver (this version) as suggested in the comments. Still not working, not even with Robocopy.

update3: Turned of autotuning with "netsh int tcp set global autotuninglevel=disabled", don't forget to reboot. Fixed! Copying files over the networks is still sloooooooow.

You dont know anything about the Entity Framework or didnt get around installing it on your box and pour the Northwind data onto a screen? This book could give you a great jumpstart into the Entity Framework. There are a lot of Entity Framework books coming your way, so why should you buy a copy of the Entity Framework Tutorial by Joydip Kanjilal? Packt was so kind to send me a copy, but you can always try to get a free copy as a blogger, reviewer or educator. Otherwise I can definitely advise you to get the ebook and use it to inspire your colleagues.

Because that is what this book is great for: convincing co-workers to start thinking and experimenting with the Entity Framework. Many development teams are still handwriting their data access code.

In the first chapter youll learn the key concepts and get an overview of the Entity Frameworks architecture. In the second chapter youll learn how to get started with the Entity Data Model and bind some data to a GridView data control. From this point on youre set to build RAD applications!

It continues with getting down to the nitty gritty details in the Entity Data Model. This is not the strongest part of the book. None the less it provides a great way to learn more detailed concepts driving your Entity Framework based solutions. Stored Procedures are up next together with the lower level APIs in the Entity Framework namely Entity Client and Entity SQL. Youll learn more about executing CRUD operations against your database with the Entity Framework.

The book successfully saves the best for last; LINQ to Entities and the Object Services Layer. I recon 90% of your projects will utilize both APIs. Creating queries, execution and concurrency conflicts are interesting subjects youll learn more about. This book only gives a glimpse of these subjects which each have enough going for them to fill a 200+ page book.

I dont see the need for a chapter on ADO.NET Data Services but its included in the book.

Dont feel like skimming through MSDN and knot together the loose ends? Dont feel like reading through Julie's excellent 800+ pages? This is a great alternative. I use this book to inspire people about the Entity Framework by letting it floating around the office. For in depth knowledge and to master the Entity Frameworks complexity youll be better of with Julies Programming Entity Framework.

Months ago Ive been discussing this with attendees over at the PDC. Now its here, and no its not Windows 7. The future operating system gOS, a browser based cloud operating system. It boots a browser which is everything I need today.

Blogging at the PDC08 crushed my good old refactoring is not free series. In other words, thanks for reading my blog. I hope you enjoyed my somewhat limited live coverage.

Big thanks goes out to Marjan for sharing these photo's. ps: I'm the guy with his arm under his chin.

While discussing the Entity Framework future with Tim Mallalieu another guru jumped on the couch. Don Box shared his definite experience, without going into much detail, wearing a Microsoft speakers shirt and the bathtub scene at Tech Ed Amsterdam (where Alex Thissen in red assisted). We talked about the future of Olso and language workbenches in specific domain's. Unfortunately I don't have a picture of Chris Anderson who also joined in for a couple of minutes. It was great fun being able to spend time on the couch with passionate Microsofties.

I fully agree with Tim Mallalieu to recommend LINQ to Entities as the data access solution for your application. Sure, for an object-oriented view of the database LINQ to SQL was somewhat useful but in essence this is a scenario that the Entity Framework supports as well. Yes, in some ways the Entity Framework does add a bit of complexity but then again creating a direct mapping with the Entity Framework isn't much more difficult then it would be with LINQ to SQL. Apart from the fact that Microsoft shouldn't have released LINQ to SQL as a product I was quit surprised about the wave of people adopting this piece of technology. A tool for direct mappings misused as an object-relational mapper felt awkward from the start. I hoped for a little while that LINQ to SQL would evolve in a fully fledged object-relational mapper, but the Entity Framework with it's EDM investment had more potential from the start.

We've spend a good amount of time talking with Tim (@PDC) on the future of the Entity Framework. The team is working hard on better POCO and TDD support and to deliver stories that support Domain-Driven Design over the next two releases. Most scenarios Alex and I explained to Tim have been thought through thoroughly and despite certain design choice which are arguable seen in isolation make perfect sense in a broader scope and the vision for the Entity Framework platform.

I'm looking forward to V2 and V3 with input from the dp advisory council... and can't wait to taste mEntity. To bad since I was looking forward to another technology deathmatch with Alex.

Chris Anderson, Giovanni Dell-Libera mention that Microsoft folks are working on transformation languages for at least five years now and how  textual DSL space became more and more prevalent.

• "MGrammer" text to data
• "MSchema" Schematizing data
• "MGraph" representing data

This talk is about MGrammer. You'll build your won DSL's on top of "M".

This is the basic workflow in through the Intellipad interface to build an MGraph.

MGrammer

• Language for creating textual DSL's
• Specification will be released under OSP

Lot's of cool demos on stage I wasn't able to capture. Download the CTP today at http://msdn.micosoft.com/oslo and build your own language.

On the way back to our hotel yesterday a college mentioned the PDC will be held again in 2009, also in November. Earlier on that day it confused me to hear the Olso folks mention they would show more cool stuff next year at PDC. Anyway, I think PDC should be somewhat exclusive and focus on the big picture and future of new Microsoft technology/products. The only question I have at the moment is, why? Why not delay another year, why not keep something for under the belt.

Any clues?

I've spend the large part of this morning threatening my persistently bleeding nose. Occasionally this pops up. Left over from years of cycling. I made it on time for the XAML talk.

XAML lets you say what you want without saying how to do it. This is also referred to as declaring your intent. XAML can be used to create declarative models a simple file format for object-based systems.

Benefits of designing for XAML:

• XML reading/writing
• Markup==OM
• Consistency with .NET
• Human readable XML
• Easier to tool
• Even-based programming model
• Ride the XAML wave

Microsoft is investing in XAML in many place. Oslo is a great example with it's importing and exporting XAML capabilities in the repository.

State of XAML in 2008

• UI
• Workflow
• Electronic paper
• Runtime: .NET 3.0 & 3.5; silverlight1 & 2
• Tools: VS 2008 (WPF + WF designer and XAML editor), expression blend
• XAML specifications published

Customers need more language evolution, make it faster, fundamentals of XAML/BAML need continued investment (compilation, debugging, obfuscation, localization, FxCop, VS integration, and more). There also the need to model more domains in XAML.

What's new in XAML 2009

In .NET 4.0 XAML will be easier to author application declaratively and feature a more rich vocabulary.

• Better name references (<Label target="firstNameBox">First Name<Label>)
• Build in types (Most of the CLR types have an XAML equivalent.)
• Support for generic types directly in XAML
• Arbitrary dictionary key types
• Beyond method names (Button Click="{DelegateCreatingME Foo}" />
• Better declarative type offering
• Use non-default constructors
• Use static factory methods

System.Xaml.dll in .NET 4.0 and will hit the street in the November 2008 CTP.