A glance into functional programming from the point of view of the OOP developer.
The presentation is a surface analysis of some of the Gang Of Four design patterns
along with a comparison of the same problems in FP.
The demos and examples are powered by F# and C#.
We have all used code analysis tools on our projects and these are useful for identifying code smells. The issue is that most of them treat metrics in isolation and isolated metrics can’t tell you if the design is good or bad. You need more context.
In this session we’ll see how to go beyond code smells and identify design smells and inappropriate coupling in the technical architecture. We’ll define detection strategies for common design smells (like God Class and Feature Envy) and implement them using NDepend. We’ll also see how we can define fitness functions to detect dependency violations in your application’s architecture
The async and await keywords introduced in C# 5.0 (7+ years ago) are probably the most powerful feature of the language when it comes to writing scalable applications. Yet in spite of the fact that async has now trickled down in many other languages (like ES6), it’s still not obvious to the untrained eye what its purpose is in C# and what benefits it brings.
If you know someone that is still “creating new threads with await” then this talk is for you.
We’re going to go chronologically backwards from ES6 to C# to see if async and await make more sense this way.
From the early days of ASP and WebForms through MVC and Razor, web development ultimately meant also writing Javascript.
Still in preview, Blazor uses the Mono library compiled to webassembly which can be run in the browser, allowing you to write .net code that is then executed by the browser, giving us access to the DOM and all browser APIs.
While I would still use react or Angular for my web needs, let’s discover what Blazor brings to the table, why is it cool, how it can be used and what alternatives exist.