ASP.NET Core, John McEnroe and the Mirror of my Office

At Wimbledon 1981, during his first round match against Tom Gullikson, John McEnroe had a chance to pronounce those (in)famous words: “You cannot be serious, man”. As a long-time tennis fan, those words remained printed in my mind. More than the wording itself, though, I remember the tone of speaking—blunt speaking.

I didn’t spend much time on ASP.NET vNext until it was really close to RC. To be honest, at this time moving away from battle-tested and mature ASP.NET MVC 5 is neither crucial nor critical for my everyday real-world development business. But, of course, any new thing is crucial and critical for a “guru” who gets exposure and gigs out of experimenting and speaking about new things. Imagine then when such a huge new thing like ASP.NET vNext comes out.

Anyway, I took it very lightheartedly until the final beta and then RC1. And when I looked at it—and the documentation—in front of the mirror, locked in the toilet of my office, me and me alone, I recalled those (in)famous that John McEnroe pronounced on the Centre Court of Wimbledon in the spring of 1981.

You cannot be serious, man.

I didn’t tell this anybody. I took it as my knee-jerk reaction to something that—no matter the announced stage (RC === release candidate) –I felt to be a great piece of work. Just in progress, though.

“It’s you, Dino—I said—YOU cannot be serious if you think so.”

But then it came the rename of tools, the rename of the entire framework, the RC2 announced and postponed. And you probably know the ongoing facts much better than me.

As I see things, ASP.NET Core was born to be a smaller thing than it is envisioned now. So it is now being repositioned, probably redesigned in some way and put in some sort of a different perspective. In the end, it will probably be the great piece of software it was supposed to be. But—as it was said at some point—it will take the time it takes.

This is a great lesson for anybody in software. Certain things must take their time to become serious things.

My wife and the MS/Xamarin deal

I’m inclined to say that the author of this article on Fortune.com speaks with my own words on the Microsoft/Xamarin deal. Yesterday, like everybody else in the software industry, I got to know that Microsoft bought Xamarin. Really? OMG, we’re still there? I thought it was a closed deal since at least two years. My sentiment? In a sense, I don’t care. In another sense I do care and I feel comfortable.

Recently, my wife asked me a similar question, one of those women’s periodical questions like “Honey, do you still love me?” Believe it or not, my reply was along the lines of “In a sense, I don’t know and I don’t care” — well, it was actually just a tiny bit softer than this :).

Kind of shocked, but not too much, she replied “And in another sense?” (Well, Silvia has really a strong sense of humour.)

Well, in another sense I just feel more than comfortable and happy with you even after so many years of living together. So naturally comfortable and in a good mood that I don’t even realize I’m happy. It’s happiness by nature. Or, in software terms, by design.

 

Question is, Xamarin products are going to be integrated in the MSDN subscription now? 🙂

 

Ubiquitous Language Is Everywhere, Even in Your Nose

When it comes to designing software, the first step is getting familiar with the domain. The second step is modeling the domain into a more and more formal set of statements up to diagrams and code. To model the domain, Eric Evans suggested the use of something he called the “ubiquitous language”. In spite of the evocative name, it’s something as simple as a glossary of terms including verbs, names, adjectives, adverbs, form the pillars of a language being used in all written and spoken communications between all parties involved in the software project. The primary goal of the ubiquitous language is avoiding misunderstandings and assumptions on both ends—stakeholders and development teams. Put another way, the ubiquitous language aims at making any use of a given word or expression within the project absolutely crystal-clear and unambiguous. When that word or expression is used, therefore, there should be all around the absolute certainty that it was understood and in the right and expected way.

And now let me share a personal note to emphasize the vital role that a ubiquitous language plays in life and subsequently in software.

My wife had nose surgery a couple of months ago. In particular she had turbinectomy, namely the surgical reduction of her quite enlarged turbinate. When we discussed pros and cons, the doctor (aka, the development team) said clearly that it was a routine surgery with the hardest part of it coming in the following weeks once the patient had been sent back home. To illustrate possible complications, the doctor used the expression “nasal crusting” to be removed in a clinic or any sort of doctor’s office, in case of trouble. He also said that sometimes patients do so well that they never show up to remove nasal crusting.

We confused the term “crust” and“scab” and that was reasonable too as both usually happen when you have nose surgery. Now, crust refers to a mix of dried mucus, blood and dead tissue that altogether form a solid block as big as a small finger. A piece of crust is stuck inside the nose with barely any chance to get rid of it without a doctor. Scab is simpler matter as it’s a superficial cover on a wound of any type. You have scabs in the nose whenever you get significantly cold for example.

To make things worse, in Italian we use the same word for both crust and scab. To cut a long story short, my wife enjoyed two weeks of trouble until we called the doctor and he promptly removed the crust and explained us that crust is not the same as scab.

How many times did that happen to you software-wise? That’s just the ubiquitous language in action.

Dear Fellow CTO, I Write to You about vNEXT

I doubt many CTOs go to technical developer’s conference where they can witness cool demos like a vNEXT web site deployed to a memory stick and installed on the clean machine of an unaware attendee. Such a demo is definitely cool and just the kind of thing done to excite developers. But I’m afraid it won’t appeal CTOs as much.

The Microsoft stack started an evolutionary, and perhaps just spontaneous, change around 2005–right after the release of .NET 2. The trigger was probably the advent (or just the rediscovery) of Ajax. Fact is, that the foundation of Web Forms–keep me off HTML and JavaScript–was shaken and challenged as people started asking for completely different features–just ability to effectively use HTML+CSS+JS in Web pages. Then it came ASP.NET MVC, Web API, SignalR.  vNEXT attempts at doing a bit of due housekeeping.

As a result, there are two options ahead for a CTO to consider.

1) Ignore vNEXT entirely and do business as usual: same frameworks, same coding experience, same deployment options, no additional features. You don’t lose anything of what you have and can do today;

2) Embrace vNEXT entirely as if it really were (and it is not) a breaking platform with no backward compatibility;

vNEXT lays the ground for Microsoft.NEXT. It inherits enough from current, adds some breaking changes, sets new goals and direction. Like it or not, you won’t be able to ignore vNEXT for too long. vNEXT is where the business of software  seems going these days. I invite you to consider vNEXT as a completely new family of products and frameworks regardless of framework versioning and actual compatibility. Code is–to a good extent–backward compatible; the approach to development is not.

Imagine the .NET vNEXT as a family of frameworks to base future development on. I’d even hope that names (ie, ASP.NET) are completely changed to smooth the transition and give the right perspective of what’s going on.

• .NET Web is the modernized HTTP pipeline that includes MVC6/WebPages for HTML, Web API for JSON, SignalR for realtime and relies on OWIN for in-out communication and EF7 for data access.
• .NET Native is the revisited baseground for Windows Store and Windows Phone apps.
• .NET Core is the latest .NET Framework that is just v4.5.3.
• .NET for Devices is the framework for micro-devices.
• Possibly more frameworks coming.

It goes without saying that this is the way I see it and would explain it to fellow CTOs and architects. I didn’t mention the cloud.  The cloud is the substrate of everything around vNEXT. You can have the cloud or not; whatever you can do in vNEXT can be done through the cloud too.

 

BYOT: Bring Your Own Tool in .NET vNEXT

I think it’s safe and sane to say that the pompously announced .NET vNext is–from a pure software perspective–just a minor update. At the same time, it is a huge change from a broader perspective that includes development strategies and the same Microsoft business model.

Frankly, I think that the “next” in the name refers more to Microsoft itself than the (ASP).NET platform. At the same time, though, just because it refers to Microsoft it is automatically of interest for all developers and shops active on the Microsoft stack. Nobody can afford ignore the vNext thing; and nobody should blindly jump on it just because at some point in 2015 it will be officially released.

One of the key changes I see in vNext–and it took me a bit of time and discussion to figure it out–is the support for development tools across a number of different platforms. In other words, you can now bring in your own set of favorite development tools (mostly editors) whether they run on a Windows, Ubuntu, or Mac system.

Does it really make sense–I wondered? Why should a developer drop Visual Studio to use a text editor on Mac or Ubuntu? That’s the point–a Microsoft developer probably won’t. At the same time, the BYOT approach opens the door to developers that just don’t use Microsoft products, are proud of their Mac, and won’t even consider running Windows though in a local or Azure VM. Thanks to excellent editors such as WebStorm and Sublime developers who wish can write for the next .NET (specifically, ASP.NET).

This is a huge thing. And the fact that I missed it entirely the first time I heard about it just … reinforces the point.

On the role of Responsive Web Design

Stuck in the Delta Lounge at JFK on the way back home, can you think of a better time to reflect on DevConnections sessions? As I get ready for reflection, I also feel the need to curse on Alitalia that doesn’t check me in online and requires me to walk through another layer of security to check in face to face on a code-share flight.

At DevConnections I held a workshop on building device-friendly websites and also gave a couple of sessions on the accidental relationships between DDD and Entity Framework and enhanced web input forms. I had a bit of discussion with attendees and other people of the role of RWD in the building of responsive sites. Here’s a summary of my workshop. By the way, the source code is here.

The workshop started with a critical review and analysis of RWD. It ended with attendees sincerely captured by WURFL.js–a free JavaScript endpoint that does transparent device detection and just puts in your DOM an object that tells about name and form-factor of the device, whether desktop browser, smartphone, tablet, smart-tv, watch, bot, or even a webview within a native app. I may seem like a guy who just hates RWD.

No, I just try to fight the blindfolded perspective that RWD is all you need and device detection is nefarious and the clear sign that you’re not doing a good job of designing and architecting your site. At the conference I also attended another talk on RWD and got illuminated when the speaker put an encyclopedic citation of an “expert” saying something along the lines of “we cannot have a single design for each application–we must upgrade to having a single design that works in all cases”.

Gotcha!

It’s that RWD stems from a designer’s–not developer’s–mind and vision. Developers, though, do a different job. Developers SHOULD be ready to focus on use-cases when they emerge out of requirements. Because devices exist and make a point of providing a unique experience, treating them as they’re all the same is against common sense. I grinned then when the speaker with a serious expression admitted that, yes, beyond aforementioned wonders, RWD does have the problem of performance. Really? OMG.

In the end, RWD is an excellent first-aid for setting up responsive sites. If experience is good, performance is good and nobody complains then all is good whether you used Bootstrap for it or your own combination of HTML5+CSS+JS. When you start getting complaints, then fixing RWD may really become expensive. Thinking that RWD can be applied tout-court and those who detect devices are a bunch of idiots who are not as smart as you is a plain distortion of the reality.

My workshop just showed the two faces of the coin. It showed facts and numbers (rather than astonishing demos) and left conclusions to developers.

When DDD Leads to CRUD

As I progress on the second edition of bestselling Microsoft .NET: Architecting Applications for the Enterprise (NAA4E). I learn more and more about Domain-driven Design (DDD) and, above all, I’m seeing it through the lens of a different perspective. Instead of just blindly applying my understanding of it built on top of tips, tricks and advice collected here and there, I’m truly learning it from the foundation. And guess what? I can now fully answer the following (simple but tricky) question I got on LinkedIn. The question apparently is completely unrelated  to DDD. At a deeper look, though, it’s DDD that is related to nearly every aspect of software architecture; even when it could lead to a CRUD software.

For ASP.NET web applications requiring only CRUD operations(like automating paper forms), do you think using Entity Framework is slower than using DAL, BAL and presentation layer using stored procedures? Is using EF with stored procedure the right solution for this?

There are two distinct parts in DDD. You always need one; and may sometimes happily ignore the other.

1. DDD has an analytical part that sets an approach to express the top level architecture of the business domain in terms of bounded contexts.
2. DDD has a strategic part that relates to the definition of a supporting architecture for the identified bounded contexts. The default supporting architecture is Domain Model. A quickly emerging alternate option–in many ways fully replacing Domain Model–is CQRS.

The real added value of DDD lies in using the analytical part to identify bounded business contexts. This is the part of DDD that relies on the ubiquitous language–the key factor.

Once this has been done, the next problem is identifying the ideal way to tackle (read, implement) each bounded context. In doing so, you can certainly consider the two recommended supporting architectures of DDD. You can even–probably should–consider event sourcing in combination with CQRS.

But, in the end, it’s all about finding the ideal way to meet requirements in a well-understood business context.  So “ideal” should be measured against actual business requirements and NOT against ideal principles of code elegance, cleanliness, future extensibility, readability and the like. If, as in the question, all you need is CRUD and you need it quickly and probably don’t need it after a short amount of time, by all means go with a quick ASP.NET CRUD and stored procedures.

Stay tuned on Facebook for the progress of #NAA4E!