.NET tanker & tips

.Net, jQuery og andre nørdede emner

SDD day 2 & 3 - Impressions and takeaways

May 23
by steffen 23. May 2019 20:23

As a part of my attendance at the SDD Conference in London, I have decided to write small blog posts summing up some of the impressions from the talks I attend. The format will be rougher since the posts have been written during the day and finished in the evening at the hotel.

This post is a summary of my impressions and takeaways from the second and third day of the SDD conference.

Version ASP.NET Core APIs

Philip Japiske (@skimedic) gave a walkthrough of the new versioning capabilities in .NET Core. Every public-facing API's are facing the same issues with regards to versioning. An API - like any other code - will almost always be a living thing, where new requirements will show up and change the endpoints and functionality.

In order not to introduce breaking changes to the existing API, that is being consumed by customers, a proper versioning strategy must be put into place. This was previously a manual process that the team agreed on, but with the new Microsoft.AspNetCore.MVC.Versioning.ApiExplorer assembly, this can be streamlined significantly by expressing which endpoints are supported in which versions of the API. By decorating a controller with the [ApiVersion("2.0")] data annotation, you can express which versions of the API the controller is currently supporting. It is even possible to have multiple decorations if the controller is supported in multiple version of the API.

Build RabbitMQ Microservices in C#

Queuing technology is here to stay. Richard Blewett gave a short introduction to one of the biggest actors in this technology stack: RabbitMQ. To support big spikes in load it is a common approach to implement a queue that can handle the messages. This can be handy if the request does not need an instant response (e.g. sending some data for processing). Each request can be put into the queue and the consumers can handle one at a time without being a bottleneck. RabbitMQ is written in Erlang and is optimized for performance - rumour has it that Google has a queue implementation that handles 1.000.000 messages per second!

One of the neat tricks that RabbitMQ has is the ability to add a 'topic'. The consumers can filter on this topic so that they only pick up the messages that they actually want to. It is a very simple approach, but the simplicity is what makes it so powerful. RabbitMQ is definitely on my list of things I want to learn more about.

Vue.js

One of the things that I am focusing on learning at the moment, is the different frontend javascript frameworks. Vue.js is Google's take on this and it plugs in very nicely with the ASP.NET MVC background that I have. Vue is extremely lightweight coming in at only 33k and also has its own logic with regards to manipulating the DOM, which means that you can also cut away jQuery saving even more bandwidth. It can work side by side with jQuery, but only if you actually have a specific need for jQuery (maybe legacy code). 

Vue supports all the cool stuff like two-way data binding and can easily be plugged into an existing Razor based MVC view. This means that you can use you traditional view models from MVC, to hand down data to Vue, which will use the data on the client-side. 

The first impression was very good and I will be digging into the pros and cons of Vue vs React and Angular soon.

UI Design crash course for software developers

I am not a designer, but as Joe Natoli (@joenatoli) pointed out it is very often that the developers (backend and frontend both) end up doing design work. In this talk Joe went through a few guidelines that will help anybody - even a developer - design UI that isn't horrible (might not be beautiful UI, but at least not horrible). 

Each element in the page must be in harmony with the other elements. This essentially means that it is important to align the elements vertically and horizontally as much as possible. If you draw a line from each vertical and horizontal edge on an element, this line should align with as many other lines in the screen. Also, make sure that the spacing between each element is the same.

If certain elements belong together, make sure to enhance this relationship by grouping the elements close together. This provides structure to the page and will make it easy for the user to understand the relationship between elements. Grouping can also be done with contrasting colours, but distance is superior for this, so choose to place elements close together overusing colour if possible.

One should be very aware of the concept of contrast. Black and white is the best contrast you can get and provides the user with very easy reading experience. Be aware of using very vibrant colours. Red on yellow might have great contrast, but can be very straining for the eye to read.

One should always try to keep the 'noise' as low as possible. Often there is simply too much content on a page, making it seem very messy and noisy. 'Less is more' is the goto motto, when deciding what to have on the page.

Tags: , , , , ,

.NET Core | RabbitMQ | SDD | Vue.js

SDD day 1 - Impressions and takeaways

May 21
by steffen 21. May 2019 20:44

As a part of my attendance at the SDD conference in London, I have decided to write small blog posts summing up some of the impressions from the talks I attend. The format will be more rough since the posts has been written during the day and finished in the evening at the hotel.

This post is a summary of my impressions and takeaways from the first day of the SDD conference.

Keynote - Flow: the worst software development approach in history

The two speakers, Sander Hoogendoorn (@aahoogendoorn) and Kim van Wilgen (@kimvanwilgen), had a very entertaining keynote, discussing all the "horrible" things that Agile methodologies are bring to the software development world. I might have been a little slow out of the blocks this morning, but I was a little confused by the talk and it took me quite a while to figure out that the bashing of agile, was meant as a joke and what they were really trying to do was to set the stage for a summary of what really is important in agile software development.

The keynote was entertaining but a little lightweight for my taste. The points made at the end, could easily be boiled down to a few slides taking 10 minutes. Bottom line was: focus on building great software - use what fits you from the agile methodology and scrap the rest.

Getting started with .NET Core

Jeremy Clark (@jeremybytes) is a favorite speaker of mine. Great humour and lots of knowledge packed into a talk that is kept as simple as possible, to ensure that everyone can follow. This time he talked about .NET Core 2.2 and all the good stuff it brings to the table. The main point here is the fact that .NET Core is cross-platform that actually works. This means that it is a perfect fit for Docker containers that can be deployed to many different operation systems.

Apart from being cross-platform, I also really like the light weight nature of .NET Core. You have to manually add all the assemblies that you need, and even though that might seem a little tedious, the biproduct is that your applications does not end up with a s***load of assemblies that is never really used, making the application much more heavy than actually needed. 

The last great thing that I want to mention, is that fact that .NET Core comes with dependency injection baked in. All too often I see applications that is not using any form of DI and hopefully the fact that .NET Core has this from the get-go, will make more developers discover (and understand) the beauty of DI.

Modernizing legacy .NET apps with Docker - revisited

Elton Stoneman (@eltonstoneman) gave an extremely fast paced talk about how to modernize a legacy webforms application using Docker. The abstract of the talk sounded like it would be on an introduction to Docker, but this talk was definitely for developers who already had experience with the technology. I tried as best as I could to hang on to what was going on, but I did not gasp all of the content. It would have been nice to cut away 1/3 of the examples and slow down to make sure that all the points made actually got across, instead of speed talking 100 km/t for 90 minutes.

That being said there is no doubt that the Docker container technology is a very interesting topic, that opens up a wealth of possiblities with regards to deployment and elimintation of technical debt. The great thing about Docker is that you can create a reverse proxy, which transfers the requests to a web application to different containers. This means that you can have a "main" container running you legacy code and another to run a subcomponent of the system that you have rewritten in a new technology (like .NET Core), without this being visible to the user. By doing this you can slowly and surely eliminate technical debt, by rewriting small components of the application one at a time - and even deploying them without taking down the entire application.

AI for C# developers: introducing ML.NET

Jeff Prosise (@jprosise) gave a great introduction to Microsofts first take on a machine learning framework: ML.NET. So far if you wanted to mess around with AI and Machine Learning (ML), you had to learn Python and/or R. With the introduction of ML.NET this is not quite true anymore. Eventhough ML.NET is only in version 1.0 and is still missing support for deep learning and more advanced AI topics, you will be able to go a long way creating ML models in C# and being able to use those models natively.

A great feature of the framework is the ablility to take pretrained models created in TensorFlow and use these as a stepping stone to a more specialized model. This means that you do not need the gigantic amount of computer power to train the models, since the heavy lifting has already been done for you. By importing one of these models and adding the specific training that you need, you have very efficient and complex model at a very low cost. Very cool stuff!

Tags: , , , , ,

Machine Learning | SDD

Is Blazor the new Angular killer?

May 20
by steffen 20. May 2019 14:44

As a part of my attendance at the SDD conference in London, I have decided to write small blog posts summing up some of the impressions from the talks I attend. The format will be more rough since the posts has been written during the day and finished in the evening at the hotel.

This post has been written as a short summary of Dino Esposito's pre-conference workshop at https://sddconf.com/

Microsoft new toy

At the Build conference in May 2019, Microsoft announced that the experimental Blazor project, would be picked up as a fully supported product. Version 1.0 is expected to launch together with .NET Core 3.0 in September 2019. 

Blazor is a brand new way of developing web applications, where the new WebAssembly standard is used to run C# code directly in the browser. This means that there is no need for Javascript og Typescript, since the WebAssembly sandbox has the same rights as Javascript and therefore can interact with the DOM and all the other stuff that can be done from the browser. The neat trick is that you can do everything in C#.

The current version is 0.9 and has some features, but there is missing some vital implementations e.g. authentication. The current version does show a little bit about some of the thoughts the Microsoft team has about the upcoming product. 

In the broad perspective there are two different flavours of Blazor: client only Blazor and server side Blazor.

Server side Blazor

The server side Blazor approach is expected to be shipped together with .NET Core 3.0, while it is unknown when client side Blazor will be shipped.

The server side approach is built using SignalR. When the server is hit SignalR will create a WebSocket connection from the browser to the server and this channel will be used to transfer the rendered HTML from the server to the client throughout the session. 

This approach solves the issue with the huge initial download in the client side approach and also looks a lot more like a vanilla flavour ASP.NET MVC Core application, making this approach very comfortable for developers who already knows this. 

The downside is that the server will have to maintain many concurrent WebSockets and you have to handle disconnect scenarios gracefully. However this issue is the same across most applications using the WebSocket technology.

Client only Blazor

The client only approach is running on a version of Mono that can interpret C# in the WebAssembly sandbox. When the server is hit with the first request, all the pages from the website and all the assemblies that is needed to run those pages are sent back to the client. The downside here is that the initial load is quite long pending your download speed. The upside side - which is pretty cool - is that for all subsequent actions the user makes on the page, the content is loaded instantly without hitting the server (unless you explicitly ask to hit the server), because everything has been loaded upfront. 

Depending on your scenario this could be a very attractive tradeoff. It actually makes you web application work a lot like an app, since all the code needed for running the application has been downloaded to the computer/device. 

The obvious downside is that if you have many pages and/or use many different assemblies the initial download will bloat very fast and will degrade the user experience.

Angular killer?

The new Blazor framework has a lot going for it. It is directly developed by Microsoft, it cuts away the need for having a codebase with multiple languages (e.g. C#, javascript, Typscript), removing the need for thrid party frontend frameworks lige Angular and React.

In the current form I do not believe that it will kill neither Angular, React or Vue - it is simply not good enought. But it will definitely be a competitor, the question is how big a competitor it will be. A lot depends on how the 1.0 version will look like. The version that I have seen demoed today in May 2019 is not ready to take on the mature Angular, React and Vue frameworks. 

The server side Blazor seems like a good idea. I like the fact that all code is in C#, which makes it easy to maintain, it's possible to unit test everything and the conceptual model is easy to understand.

The client only Blazor confuses me a little bit more. I find it har to figure out what Microsoft are trying to achieve with this approach. It could make sense to use as a substitute for native app's - but since it is running in the browser it will lack all the cool bells and whistles that native apps have. The fact that you have to download all the pages and dependencies to run it in the client does not sound like a sound idea to me. 

What will the final verdict be? We'll know when Microsoft launces version 1.0.

 

Tags: , ,

c# | Blazor