DDD North 2017

TL:DR; If you are a developer, or even have a passing interest in programming or technology, you should definitely give up a Saturday and get yourself (and any tech friends!) to one of these FREE events. DDD events happen throughout the year across the UK and you should find the one nearest to you. The range and quality of talks I went to were excellent. This was the first time I’ve attended DDD North, but certainly won’t be the last.

About DDD North 2017

DDD North is a free one-day technical event for developers, which this year was held in at Bradford University.

DDD North is actually going to be hard to beat since this was a FREE event with 25 separate talks on a wide variety of technical subjects (not including the lighting talks at lunch!), FREE refreshments and lunch, not to mention the amazing prize giveaway at the end (top prizes were tickets to NDC London!).

Bradford University was a really great choice of venue. The Richmond Building Atrium is a beautiful open space and was used for registration, breaks and lunch throughout the day. The atmosphere was friendly and organisation was excellent. DDD Staff were dressed in branded purple hoodies and were around all day to answer questions.

A view into the Richmond Building Atrium

As organisers of such events it’s always going to be hard to predict the popularity of some of the sessions and as a result some rooms were a little crowded for the number of attendees that turned up (in the afternoon it got quite warm too).

9.30am to 10.30am – Thinking Functionally in C# - John Stovin

When developers familiar with Microsoft technologies talk about Functional Programming, there is a tendency to point to F#.

F# (pronounced “F-Sharp”) is a strongly-typed, functional-first programming language for writing simple code to solve complex problems.

Johns overall message was that C# developers should (and can) start applying F# functional paradigms in C# in order to begin to write cleaner code that can be easier to reason about.

Throughout the talk, John showed tips and examples on how to write cleaner, functional code in C#. He covered a variety of concepts, patterns and models that are common in functional programming (e.g. immutability, higher order functions, pattern matching etc). There were other functional programming topics that were not covered such as currying, monads and a few others.

After the session ended, I asked how I could begin to gently apply functional programming into my own C# code on an everyday basis. John suggested that I should perhaps start simply and try to make my classes immutable (making properties read only / having private setters).

As I walked out of the session at the end, I felt inspired and came to the conclusion that if a developer such as myself wants to apply functional programming concepts in C#, I will need to become more familiar with abstract concepts that I may not use regularly. I felt should learn more about writing code that introduces immutable objects, custom higher order functions, using recursion and avoiding loops, more use of predicates and pattern matching instead of “if” and “switch” statements… and many more.

10.45am to 11.45am – Meta Programming in C# 101, How Stuff Works – David Whitney

Before going to this session, I had to ask my friend Rob (who attended DDD with me) what “Meta Programming” was as I didn’t really understand (although I felt I should). Rob’s simple (and very general) answer was “Dude, it’s basically reflection”.

David divided his talk to show three examples of meta programming, MVC, Unit Testing and IoC Frameworks. He started each section of the talk by reading the obtuse definition from Wikipedia for each framework type, swearing, then breaking down the frameworks main concepts. For each topic, David showed the use of simple reflection techniques (from the C# System.Reflection namespace) to achieve similar functionality and concepts.

After every topic (and example) David caveated them by saying that the frameworks will be tried and tested, have advanced functionality (e.g. for IoC frameworks, object lifecycle management or templating engines for MVC) and are used every day in production.

David did mention that reflection libraries in the early days of .NET / C# (1.1) were used sparingly because they were generally considered to be slow. Nowadays, the reflection libraries available have advanced APIs so that developers can and should (where appropriate) be leveraging meta programming in their own code.

After the session, I asked David should we now be thinking about preferring convention over configuration, and using meta programming to help with the convention. He said yes it can help and that it was always good practise to prefer convention over configuration.

My key takeaway from this talk was that, unless you really need advanced functionality, the introduction of a potentially complex, heavy-weight, advanced framework might not be necessary and you will be introducing an unwanted dependency (and a “magic black box”) to your project when perhaps all you needed was a lightweight, simple service locator.

12.00 to 1pm – Building APIs with Azure Functions – Kevin Smith

I’d heard of Azure Functions but not really understood what they were. Azure Functions can be used to run a script or piece of code in response to a variety of events for example a http request, a timer, a web hook, an upload or submitted message to a queue.

Kevin broke down his talk by starting off with the pros (cost effective, rapid development, simplified integration, serverless and scalable) and cons (debugging, certificate verification and versioning) then moved on to mocking and developing locally and gave a full walkthrough with live code demos.

Until Kevin showed us the extension Azure Functions Tools for Visual Studio, I had no real idea of how to begin developing using Azure Functions. The suite of tools allows you to edit, build and run locally as well as publish directly to Azure.

Kevin showed that for each Azure Function you write, you can find simple JSON files in the bin folder that represents the configuration for each function. These files can be used in integration tests and source control. We were also shown that swagger.io can be easily used for documentation because it’s able to read the JSON files and create documentation from them.

Finally, Kevin told us that Azure Functions can use an API key as a query string or header parameter to secure calls (the key can be used on individual functions or the whole API). There is also the ability to use the authentication / authorisation within the Azure App Service that allows you to easily integrate a variety of authorization capabilities into your web app or API. In order to debug the Azure Functions, filters can provide logging and error handling.

Kevin’s talk was a great overview of Azure Functions. At the end of the lecture I asked him what was the hardest part, to which he replied setting up the end-to-end testing on his local development environment.

Azure Functions seem like they could be a great way of writing a scalable, cloud based API, however, as I know nothing of Azure, I will add this to my ever-growing list of “Things to investigate in Azure”.

This talk filled the John Stanley Bell lecture theatre.

It was time for lunch.

1pm to 2.30pm – Lunch Time Lighting Talks

After grabbing a FREE lunch bag (sandwich, crisps, fruit and snack) from the atrium, Rob and I sat and reflected on the mornings talks. We then decided to check out the lighting talks back in the John Stanley Bell lecture theatre.

There wasn’t much room, the talks were very popular, with people coming and going. However, I did manage to see two talks about the following subjects;

The OWASP Zed Attack Proxy (ZAP)

ZAP is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers. You can download and install it from the OWASP site for free and it can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications.

The General Data Protection Regulation (GDPR)

The GDPR has been engineered to match data privacy laws across Europe, so that EU citizens can protect their own data privacy and also reform the way organisations across the region approach data privacy. The GDPR was finally approved by the EU Parliament on 14 April 2016. On May 25th 2018, the GDPR will be enforced and non-compliance will be met with heavy fines.

In the future (well, May 2018) we as citizens will be empowered new individual rights such as the right to access, erasure and objection. We will be able to submit a request for deletion of data and the organisation must not only comply, but also confirm and acknowledge the data was deleted (including notification to other parties that this data was deleted).

Essentially, the GDPR is forcing organisations to be responsible for any personal data they may carry within the organisation. If the organisation is using personal data, they must declare that all data is relevant to that particular task (so perhaps an end to “Do you have home insurance?” when applying for car insurance).

In some circumstances, organisations must appoint a data protection officer (DPO) whose key role is to help monitor compliance with the GDPR and other data protection laws (especially if that organisation is dealing with large scale personal data).

My key takeaway from this talk was DON’T WAIT UNTIL MAY 2018.

2.30pm to 3.30pm – Async in C#, the good, the bad and the ugly – Stuart Lang

Async (asynchronous programming) is normally used when you have an (input/output) operation such as requesting data from a network or accessing a database. Alternatively, you may have expensive calculations that require CPU processing power. In both of these cases, if you executed your code synchronously and the task was long running, you would perhaps cause a bottleneck in your application. Asynchronous programming allows you execute a task and then immediately move on to another task before the first finishes.

Stuart began describing that Async in C#, on the whole, is good. The C# language level features for asynchronous programming can allow developers to keep applications responsive and snappy for users. The main purpose of async/await is to make it easier to write code in a world with many high latency operations.

Then, Stuart confirmed what I always thought to be true, that introducing async code and getting it wrong was worse than introducing it all. As a developer, if you decide to use async code then you have to be aware that async introduces a small performance overhead, can add additional complexity and if you get it wrong you risk introducing deadlocks to your application.

Stuart gave some examples of async code and spoke about that as a developer SyncronisationContext is your friend. The demos showed a simple countdown application where he showed uses of the SyncronsiationContext. and He then went on to describe some of the deadlock prevention methods, such as “.ConfigureAwait(false)” and ensuring that there is async from top to bottom in your codebase (replacing libraries where possible).

Overall, this was a great talk by Stuart who has clearly faced and overcome real-world problems using async code.

3.45pm to 4.45pm – .NET Core in the real world – Joe Stead

Joes talk surrounded his teams use of .NET core for within a real-world legacy application.

The application that his team were responsible for contained a lot of code that performed a lot of heavy lifting and only a little bit of UI / Web interface.

Joe discussed the meaning and variations between .NET Core, .NET Standard and flexible deployments. The deployment part was key for Joes application, he didn’t have the luxury of to say to customers, “please install the following to make our application run”. Originally his team tried to run the application with the Mono platform (allowing developers to write C# code that will run cross platform). Due to stability issues with Mono, when .NET core was released, the team made the decision to try and use the initial bleeding edge version for their application.

Joe explained that the move to .NET core was not without plenty of pain. He showed us a timeline of the application and how it moved through the last few years over different technology to where it is today (including different versions of .NET core and latest deployment techniques such as kubernetes and docker).

It was reassuring to hear that some issues faced by the team actually required Microsoft themselves to get involved when the team raised issues with .NET Core.

Joes explanation of real world issues with a sense of humour made this talk enjoyable and it was a great end to the day.