Monthly Archives: February 2020

Blazor – First Look

I have been anxiously anticipating the release of Blazor – Microsoft’s new .Net component framework that should help free developers from Javascript hell.

Blazor is a new tool for .net developers to allow running C# in the browser, inside web assembly.

What I most like about it is, it is such an clean and simple architecture from the developer’s point of view. Writing a blazor app is very similar to writing your typical MVC/Razor app, that runs on the server. I have always felt that MVC/Razor was ultimately the wrong model – very anti-client/server since all the data/template rendering happens on the server. Until now, there has been no way to run c# in the browser, and have the browser pull the data and assemble the page.

Because MVC/Razor does all the work on the server, JavaScript has been the only option to run in-browser code and pull data popularizing the single page application (SPA) model. From a C# developer’s point of view, Javascript is a terrible language. Its not strongly typed, its interpreted (not compiled), and until recently it has been difficult to debug. Because of all this, frameworks such as Angular, React and Vue have become popular to help hide the mess that can be created by JavaScript. In my opinion, this has in many ways made the problem worse, because additional libraries and packages need to be installed to support frameworks, bloating the code and slowing development time thru trying to orchestrate all this 3rd party code.

Blazor finally replaces all this mess. To do this, they had to wait until all the modern browsers support WebAssembly. Today, the only ‘modern’ browser not supporting it is Internet Explorer 11, and hopefully with the demise of Windows 7 traffic using IE 11 should diminish. There is even an answer if you do need to support older browsers – Blazor Server. Blazor apps can also be written to run on the server, so the codebase can be the same whether you decide to run it on the client or the server. Very elegant.

Using a sample provided by Microsoft, I downloaded, compiled and ran the app in my browser in under 5 minutes. Browsing thru the code, its very readable and understandable. within an hour I was able to customize the demo to call my own API and retrieve data from display it – all without javascript. Contrast that to setting up an Angular app, which could take an hour or two by the time you assembly all the pieces to get the code to run. This article has a great overview of Blazor and the code in the demo. Note that when you first run a Blazor app, it takes all the compiled code (that traditionally runs on the server), and downloads it to the browser. So the first load of the page takes a little time, but once the app is loaded its very fast. One current limitation of Blazor is because the code is running in the browser, inline debugging, setting of breakpoints does not easily work from within Microsoft’s Visual Studio, so this is a step backward in productivity as compared with server development. However, because Blazor consumes class libraries, you can debug class libraries as per usual, prior to implementing them in Blazor. Also, the Blazor team has stated that getting debugging working is a top priority.

Blazor client is still in preview until May of 2020. I think this will be a huge boon to productivity, and I am starting to develop Blazor apps now in preparation for releasing after May. Already it is such an improvement over the JavaScript framework model. As of now, I think the future is bright for client side application development.

My Raspberry Pi

I have been tinkering with home automation projects over the last few years, messing around with a variety of platforms.  I started with a Wink hub and other assorted wifi enabled products,  and pretty much glued everything together using IFTTT.  This has worked OK, and I have learned a lot over the years.  Recently, with my work with the Hue API, I did my first integration that involved writing code, and running that code out at Microsoft Azure.  That was a great next step, but the stage is to run a fully programmable local hub that can manage my devices locally (IOT on the edge).

The first step I needed to decide on was what platform to run. I am a Microsoft Windows centric guy, so I was leaning towards building off Windows, but I didn’t see anything I liked.  However, now that Microsoft has released the dotnetcore programming library that allows running C# on Linux, that opened up more possibilities.  Over the last few months, I finally settled on Raspberry PI, a perfectly adequate machine that you can get for under $100.   It also runs on very low power.  I put a power meter on it – and it runs consistently at around 4.2 watts – which is about the same as my desktop PC when it is sleeping.

My first project I settled on came about because of a previous hardware purchase.  A while ago, I got a 2 terabyte USB drive at Costco, with the plan to plug it into my router to provide all my PC’s access to a shared large drive.  Unfortunately, when I plugged it into the router, it only recognized like 300mg.  I theorized that is because the drive is formatted in exFAT to accomodate the large number of bytes, and the router probably doesn’t support that file format.  Now  I probably could of futzed around for awhile and figured out a good workaround, but thats when I decided to take the plunge and get my first Raspberry PI and use that as my network attached storage.

I received my Raspberry PI from Amazon got started. The hardest part was probably just setting up my work area to start tinkering.  I didn’t want to have to swap monitors or keyboards,  so I had to dig up an old monitor, mice and keyboard.  The raspberry Pi has a HDMI port for the monitor, but unfortunately my monitor didnt support HDMI, so I had to dig up an adapter for it.  I also had to buy an 8Gg micro SD card, which delayed me a bit.  Once  I got my workarea and hardware setup, I just followed the instructions that came with the Pi and I was running Linux  in 15 minutes(!)  The Pi runs Raspian, which is a flavor of Linux recommended for the PI, and it is more Windows like than I was expecting.

So now that I was semi comfortable with Linux, the next big steps were to attach my USB drive and get Raspian to recognize it.  I also needed to figure out how to set up a share so that my windows machines can see the storage, and I decided  I wanted to have my Pi run FTP, so I  can have my security cameras stream local copies of  video recordings to the drive. Getting thos all to work of course mostly involves googling various keywords til you find a solution, and I was amazed at all the support out there for Raspberry Pi.  I found step by step instructions on mounting an external drive, setting up a network share (using Samba), and installing FTP and getting FTP to recognize the external drive.  Getting FTP to recognize the external drive was probably the most difficult, as there are a couple FTP packages supported by Raspian.  But thanks to Ryan Fitton’s post I got it to work.

So now everything is up and running just as I had hoped.  Every machine on my network can see the storage, and my cameras are streaming copies of images to the drive.  The next step on my roadmap is to start building out the Pi platform.  Getting a dotnetcore program to run on my Pi will be the next step.  After that.. the sky is the limit.

,