DDD East Anglia 2014 In Review
Well, it’s that time of year again when a few DDD events come around. This past Saturday saw the 2nd ever DDD East Anglia, bigger and better than last year’s inaugural event.
I’d set off on the previous night and stayed over on the Friday night in Kettering. I availed myself of Kettering town centre’s seemingly only remaining open pub, The Old Market Inn (the Cherry Tree two doors down was closed for refurbishment) and enjoyed a few pints before heading back to my B&B. The following morning, after a hearty breakfast, I set off on the approximately 1 hour journey into Cambridge and to the West Road Concert Hall, the venue for this year’s DDD East Anglia.
After arriving at the venue and registering, I quickly grabbed a cup of water before heading off across the campus to the lecture rooms and the first session of the day.
The first session is David Simner’s “OWIN, Katana and ASP.NET vNext – Eliminating the pain of IIS”. David starts by summing up the existing problems with Microsoft’s IIS Server such as its cryptic error messages when simply trying to create or add a new website through to differing versions with differing support for features on differing OS versions. e.g. Only IIS 8+ supports WebSockets, and IIS8 requires Windows 8 - it can’t be installed on lower versions of Windows.
David continues by calling out “http.sys” - the core of servicing web requests on Windows. It’s a kernel-space driver that handles the request, looks at the host headers, url etc. and then finds the user space process that will then service the request. It’s also responsible for dealing with the cryptography layer for SSL packets. Although http.sys is the “core” of IIS, Microsoft has opened up http.sys to allow other people to use it directly without going through IIS.
David mentions how some existing technologies already support “self-hosting” meaning they can service http requests without requiring IIS. These technologies include WebAPI, SignalR etc., however, the problem with this self-hosting is that these technologies can’t interoperate this way. Eg. SignalR doesn’t work within WebAPI’s self-hosting.
David continues by introducing OWIN and Katana. OWIN is the Open Web Interface for .NET and Katana is a Microsoft implementation of OWIN. Since OWIN is open and anyone can write their own implementation of it, this opens up the entire “web processing” service on Windows and allow us to both remove the dependence on IIS as well as have many differing technologies easily interoperate within the OWIN framework. New versions of IIS will effectively be OWIN “hosts” as well as Katana being an OWIN host. Many other implementation written by independent parties could potentially exist, too.
David asks why we should care about all of this, and states that OWIN just “gets out your way” - the framework doesn’t hinder you when you’re trying to do things. He says it simply “does what you want” and that it does this due to it’s rich eco-system and community providing many custom developments for hosts, middleware, servers and adapters (middleware is the layer that provides a web development framework, i.e. ASP.NET MVC, NancyFX etc. and an adapter is things like System.Web etc. which serves to pass the raw data from the request coming through http.sys to the middleware layer.)
The 2nd half of David’s talk is a demo of writing a simple web application (using VS 2013) that runs on top of OWIN/Katana. David creates a standard “Web Application” in VS2013, but immediately pulls in the Nuget package OwinHost (This is actually Katana!). To use Katana, we need a class with the “magic” name of “Startup” which Katana looks for at startup and runs it. The Startup class has a single void method called Configuration that takes an IAppBuilder argument, this method runs once per application run and exists to configure the OWIN middleware layer. This can include such calls as:
app.UseWecomePage(“/”);
app.UseWebApi(new HttpConfiguration(blah blah configure WebAPI etc.);
app.Use<[my own custom class that inherits from OwinMiddleware]>();
David starts with writing a test that checks for access to a non-existent page and ensure it returns a 404 error. In order to perform this test, we can use a WebApp.Start method which is part of the Microsoft.Owin.Hosting – This is the Katana implementation of an OWIN Host) and allows the test method to effectively start the web processing “process” in code. The test can then perform things like:
var httpClient= new Httpclient();
var result = httpclient.GetAsync(“http://localhost:5555”);
Assert.Equal(result.StatusCode, 404);
Using OWIN in this way, though, can lead to flaky tests due to how TCP ports work within Windows and the fact that even when the code has finished executing, it can be a while before windows will “tear down” the TCP port allowing other code to re-use it. To get around this, we can use another Nuget package, Microsoft.OWIN.Testing, which allows us to effectively bypass sending the http request to an actual TCP port and process it directly in memory. This means our tests don’t even need to use an actual URL!
David shows how easy it is to write your own middleware layer, which consists of his own custom class (inheriting from OwinMiddleware) which contains a single method that invokes the next “task” in the middleware processing chain, but then returns to the same method to check that we didn’t take too long to process that next method. (This is easily done as each piece of middleware processing is an async Task allowing us to do things like:
context.Invoke(next middleware processing method).ContinueWith(_ => LogIfWeTookTooLong(context));
Ultimately, the aim with OWIN and Katana, is to make EVERTHING X-copy-able. Literally no more installing or separately configuring things like IIS. It can all be done within code to configure your application, which can then be simply x-copy’d from one place to another.
The next session up is Pete Smith’s “Beyond Responsive Design – UI for the Modern Web Application”. Pete starts by reminding us how we first built web applications for the desktop, then the mobile phone market exploded and we had to make our web apps work well on mobile phones, each of which had their own screen sizes/resolutions etc. Pete talks about how normal desktop designed web apps don’t really look well on constrained mobile phone screens. We first tried to solve it with responsive design, but that often leads to having to support multiple code bases, one for desktop and one for mobile. Pete says that there’s many problems with web apps. What do we do with all the screen space on a big desktop screen? There’s no real design guidelines or principles.
Pete starts to look at design paradigms on mobile apps and shows how menus work on Android using the Hamburger button that allows a menu to slide out from the side of the screen. This is doable due to Android devices often having fairly large screens for a mobile device. However, the concept of menus on iPhones (for example), where the screen is much narrower, don’t slide out (from the side of the screen) but rather slide up from the bottom of the screen. Pete continues through other UI design patterns like dialogs, header bars and property sheets and how they exist for the same reasons, but are implemented entirely differently on desktops and each different mobile device. Pete states that some of these design patterns work well, such as hamburger menus, and flyout property sheets (notifications), however, some don’t work so well, such as dialogs that purposely don’t fill the entire mobile device screen, but keep a small border around the dialog. Pete says that screen real estate is at a premium on a mobile device, so why intentionally reserve a section of the screen that’s not used?
The homogenous approach to modern web app development is to use design patterns that work well on both desktop devices as well as mobile devices. Pete uses the new Azure portal with its concept of “blades” of information that flyout and stack horizontally, but scroll vertically independently from each other. This is a design paradigm that works well on both the desktop as well as translating well to mobile device “pages” (think of how android “pages” have header bars that have back and forward buttons).
Pete that shows us a demo of a fairly simple mock-up of the DDD East Anglia website and shows how the exact same design patterns of a hamburger menu (that flies in from the left) and “property sheets” that fly in from the right (used for speaker bio’s etc.) work exactly the same (with responsive design for the widths etc.) on both a desktop web app and on mobile devices such as an iPad.
Pete shows us the code for his sample application, showing some LESS stylesheets, which he says are invaluable for laying
out an application like this as the actual page layout is best achieved by absolutely positioning many of the page elements (the hamburger menu, the header bar, the left-hand menu etc.) using LESS mixins. The main page uses HTML5 semantic markup and simply includes the headerbar and the menu icons on it, the left-hand menu (that by default is visible on
devices with an appropriate width) and an empty <main> section that will contain the individual pages that will be loaded dynamically with JavaScript.
Pete finalises by showing a “full-blown” application that he’s currently writing for his client company to show that this set of design paradigms does indeed scale to a complete large application! Pete is very passionate about bringing a comprehensive set of working design guidelines and paradigms to the wider masses that he’s started his own open working group to do this, called OWAG – The Open Web Apps Group. They can be found at: http://www.github.com/owag
The next session is Matt Warren’s “Performance is a feature!” which tells us that performance of our applications is a first-class feature which should be treated the same as usability and all other basic functionality of our application. Performance can be applied at every layer of our application from the UI right down to the database or even the “raw metal” of our servers, however, Matt’s talk will focus on extracting the best performance of the .NET CLR (Common Language Runtime) – Matt does briefly touch upon the raw metal, which he calls the “Mechanical Sympathy” layer and mentions to look into the Disruptor pattern which allows certain systems (for example, high frequency trading applications) to scale to processing many millions of messages per second!
Matt uses Stack Overflow as a good example of a company taking performance very seriously, and cites Jeff Atwood’s blog post, “Performance is a feature”, as well as some humorous quotations (See images) as something that can provide inspiration to for improvement.
Matt starts by asking Why does performance matter?, What do we need to know? and When do we need to optimize performance?
The Why starts by stating that it can save us money. If we’re hosting in the cloud where we pay per hour, we can save money by extracting more performance from fewer resources. Matt continues to say that we can also save power by increasing performance (and money too as a result) and furthermore, bad performance can lead to broken applications or lost customers if our applications are slow.
Matt does suggest that we need to be careful and land somewhere in the middle of the spectrum between “optimizing everything all the time” (which can back us into a corner) versus “don’t optimize anything” (the extreme end of the “performance optimization is the root of all evil” approach). Matt mentions various quotes by famous software architects, such as Rico Mariani from Microsoft who states “Never give up your performance accidentally”.
Matt continues with the “What”. He starts by saying that “averages are bad” (such as “average response time”), we need to look at the edge cases and the outlier values. We also need useful and meaningful metrics and numbers around how we can measure our performance. For web site response times, we can say that most users should see pages load in 0.5 to 1.5 seconds, and that almost no-one should wait longer than 3 seconds, however, how do we define “almost no-one”. We need absolute numbers to ensure we can accurately measure and profile our performance. Matt also states that there’s a known fact that if only 1% of pages take (for example) more than 3 seconds to load, much more than 1% of users will be affected by this!
Matt continues with the When? He says that we absolutely need to measure our performance within our production environment. This is totally necessary to ensure that we’re measuring based upon “real-world” usage of our applications and everything that entails.
Matt talks about the How? of performance. It’s all about measuring. Measure, measure, measure! Matt mentions the Stack Overflow developed “MiniProfiler” for measuring where the time is spent when rendering a complete webpage as well as OpServer, which will profile and measure the actual servers that serve up and process our application. Matt talks about micro-benchmarking which is profiling small individual parts of our code, often just a single method. He warns to be careful of the GC (Garbage collector) as this can and will interfere with our measurements and shows some code involving forcing a GC.Collect() before timing the code (usually using a Stopwatch instance) which can help. He states that allocations (of memory) is cheap but cleaning up after memory is released, isn’t. Another tool that can help with this is Microsoft’s “PerfView” tool which can be run on the server and will show (amongst lots of other useful information) how and where the Garbage Collector is being called to clean up after you.
Matt finishes up by saying that static classes, although often frowned upon for other reasons, can really help with performance improvements. He says to not be afraid to write your own tools, citing Stack Overflow’s “Dapper” and “Jil” tools to perform their own database access and JSON processing, which has been, performance-wise, far better for them than other similar tools that are available. He says the main thing, though, is to “know your platform”. For us .NET developers, this is the CLR, and understanding its internals on a fundamental and deep level is essential for really maximizing the performance of our own code that runs on top of it. Matt talks, finally, about how the team at Microsoft learned a lot of performance lessons when building the Roslyn compiler and how some seemingly unnecessary code can greatly help performance. One example was a method writing to a log file and that adding .ToString() to int values before passing to the logger can prevent boxing of the values, thus having a beneficial knock-on effect on the Garbage Collector.
After Matt’s talk it was time for lunch. As is the custom at these events, lunch was the usual brown-bag affair with a sandwich, a packet of crisps, some fruit and a bottle of water. There were some grok talks happening over lunch in the main concert hall, and I managed to catch one given by Iris Classon on Windows Universal application development which is developing XAML based applications for both Windows desktop and Windows Phone.
After lunch is Mark Rendle’s “The vNext Big Thing – ASP.NET shrinks down and grows up”. Mark’s talk is all about the next version of ASP.NET that is currently in development at Microsoft. The entire redevelopment is based around slimming down ASP.NET and making the entire framework as modular and composable as possible. This is largely as a response to other web frameworks that already offer this kind of platform, such as NodeJs. Mark even calls it NodeCS! Mark states that they’re making a minimalist framework and runtime and that it’s all being developed as fully open source. It’s built so that everything is shippable as a Nuget package, and it’s all being written to use runtime compilation using the new Roslyn compiler. One of the many benefits that this will bring is the ability to “hot-swop” components and assemblies that make up a web application without ever having to stop and re-start the application! Mark gives the answer to “Why are Microsoft doing this?” by stating that it’s all about helping versioning of .NET frameworks, making the ASP.NET framework modular, so you only need to install the bits you need, and improving the overall performance of the framework.
The redevelopment of ASP.NET starts with a new CLR. This is the “CoreCLR”. This is a cut-down version of the existing .NET CLR and strips out everything that isn’t entirely necessary for the most “core” functions. There’s no “System.Web” in the ASP.NET vNext version. This means that there’s no longer any integrated pipeline and it also means that there’s no longer any ASP.NET WebForms!
As part of this complete re-development effort, we’ll get a brand new version of ASP.NET MVC. This will be ASP.NET MVC 6. The major new element to MVC 6 will be the “merging” of MVC and WebAPI. They’ll now be both one and the same thing. They’ll also be built to be very modular and MVC will finally become fully asynchronous just as WebAPI has been for some time already. Due to this, one interesting thing to note is that the ubiquitous “Controller” base class that all of our MVC controllers have always inherited from is now entirely optional!
Mark continues by taking a look at another part of the complete ASP.NET re-boot. Along with new MVC’s and WebAPI’s, we’ll also get a brand new version of the Entity Framework ORM. This is Entity Framework 7 and most notable about this is that the entire notion of database first (or designer-driven) database mapping is going away entirely! It’s code-first only! There’ll also be no ADO.NET and Entity Framework will now finally feature first-class support for non-SQL databases (i.e. NoSQL/Document databases, Azure Tables).
The new version of ASP.NET will bring with it lots of command line tooling, and there’s also going to be first class support for both Mac and Linux. The goal, ala NodeJS, is to be able to write your entire application in something as simple as a text editor, with all of the application and configuration code in simple text-based code files. Of course, the next version of Visual Studio (codenamed, Visual Studio 14) will have full support for the new ASP.NET platform. Mark also details how the configuration of ASP.NET vNext developed applications will no longer use XML (or even a web.config). They’ll use the currently popular JSON format instead inside of a new “config.json” file.
Mark proceeds by showing us a quick demo of the various new command line tools which are all named starting with the letter K. There’s KVM, which is the K Version Manager and is used for managing different versions of the .NET runtime and framework. Then there is KPM which is the K Package Manager, and operates similar to many other package managers, such as NodeJS’s “npm”, and allows you to install packages and individual components of the ASP.NET stack. The final command line tool is K itself. This is the K Runtime, and its command line executable is simply called “K”. It is a small, lightweight process that is the runtime core of ASP.NET vNext itself.
Mark then shows us a very quick sample website that consists of nothing more than 2-3 lines of JSON configuration, only 1 line of real actual code (a call to app.UseStaticFiles() within the Startup class’s “Configure” method) and a single file of static html and the thing is up and running, writing the word “Hurrah” to the page. The Startup.cs class is effectively a single class replacement for the entire web.config and the entire contents of the App_Start folder! The Configure method of the Startup class is effectively a series of calls to various .UseXXX methods on the app object:
app.UseStaticFiles();
app.UseEntityFramework().AddSqlServer();
app.UseBrowserLink();
etc.
Mark shows us where all the source code is. It’s all right there on public GitHub repositories and the current compiled binaries and packages can be found on myget.org. Mark closes the talk by showing the same simple web app from before, but now demonstrating that this web app, written using the “alpha” bits from ASP.NET vNext can be run on an Azure website instance quite easily. He commits his sample code to a GitHub repository that is linked to auto-deploy to a newly created Azure website and lets us watch as Azure pulls down all the required NuGet packages and eventually compiles his simple web application is real-time and spins up the website in his browser!
The final talk of the day is Barbara Fusinska’s “Architecture – Why so serious?” talk. This talk is about Barbara’s belief that all software developers should be architects too. She starts by asking “What is architecture?”. There are a number of answers to this question, depending upon who you ask. Network distribution, Software Components, Services, API’s, Infrastructure, Domain Design. All of these and more can be a part of architecture.
Barbara says her talk will be given by showing a simple demo application called “Let’s go out” which is a simple scheduler application. She will show how architecture has permeated all the different parts of the application. Barbara starts with the “basics”. She broaches the subject of application configuration and says how it’s best to start as you mean to go on by using an Ioc Container to manage the relationships and dependencies between objects within the application.
She continues by saying that one of the biggest and most fundamental problems of virtually all applications is how to pass data between the code of our application and the database, and vice-versa. She mentions ORM’s and suggests that the traditional large ORM’s are often far too complicated and can frequently bog us down with complexity. She suggests that the more modern Micro-ORM’s (of which there are Dapper, PetaPOCO & Massive amongst others) offer a better approach and are a much more lightweight layer between the code and the data. Micro-ORM’s “bring SQL to the front” which is, after all, what we use to talk to our database. Barbara suggests that it’s often better to not attempt to entirely abstract the SQL away or attempt to hide it too much, as can often happen with a larger, more fully-featured ORM tool. On the flip-side, Barbara says that full-blown ORMs will provide us with an implicit unit of work pattern implementation and are better suited to Domain driven design within the database layer. For Barbara’s demo application, she uses Mark Rendle’s Simple.Data micro-ORM.
Barbara says that the Repository pattern is really an anti-pattern and that it doesn’t really do much for your application. She talks about how repositories often will end up with many, many methods that are effectively doing very similar things, and are used in only one place within our application. For example, we often end up with “FindCustomersByID”, “FindCustomersByName”, “FindCustomerByCategory” etc. that all effectively select data from the customers database table and only differ by how we filter the customers.
Barbara shows how her own “read model” is a single class that deals with only reading data from the database and actually lives very close to the code that will use it, often an MVC controller action. This is similar to a CQRS pattern and the read model is very separate and distinct from the domain model. Barbara shows how she uses a “command pattern” to provide the unit of work and the identity pattern for the ORM. Barbara talks about the Services within her application and how these are very much all based upon the domain model. She talks about only exposing a method to perform some functionality, rather than exposing properties for example. This not just to the user, but to other programmers who might have access to our classes. She makes the property accessors private to the class and only allows access to them via a public method. She shows how her application allows moving a schedule entry, but the business rules should only allow it to be moved forward in time. Exposing DateTime properties would allow setting any dates and times, including those in the past and thus violating the domain rules. By only allowing these properties to be set via a public method, which performs this domain validation, the setting of the dates and times can be better controlled.
Barbara says that the Command pattern is actually a better approach than using Services as they can greatly reduce dependencies within things like MVC Controllers. Rather than having dependencies on multiple services like this:
public void MyCustomerOrderController(ICustomerService customerService, IOrderService orderservice, IActivityService activityService)
{
...
}
Where this controller’s purpose is to provide a mechanism to work with Customers, the orders placed by those customers and the activity on those orders. We can, instead, “wrap” these services up into commands. These commands will, internally, use multiple services to implement a single domain “command” like so:
public void MyCustomerOrderController(IAddActivityToCustomerOrderCommand addActivityCommand)
{
...
}
Providing a single domain command to perform the specific domain action. This means that the MVC Controller that’s used for the UI that allows customers to be added to activities only has one dependency, the Command class itself.
With the final session over, it was time to head back to the main concert hall to wrap up the days proceedings, thank all those who were involved in the event and to distribute the prizes, generously donated by the various event sponsors. No prizes for me this time around, although some very lucky attendees won quite a few prizes each!
After the wrap up there was a drinks reception in the same concert hall building, however, I wasn’t able to attend this as I had to set off on the long journey back home. It was another very successful DDD event, and I can’t wait until they do it all over again next year!
