Geolocation II: Position Updates

In the previous post, Geolocation in Blazor, I started wrapping the browser’s Geolocation API in a Blazor component. That first article showed how to get the device’s current position, including how to get prototype-based JavaScript objects back across the C#/JS interop boundary.

In this post, I’ll look at using a JavaScript callback to raise a C# event when the device moves.

GitHub: https://github.com/darnton/BlazorDeviceInterop
NuGet: https://www.nuget.org/packages/Darnton.Blazor.DeviceInterop

Continue reading “Geolocation II: Position Updates”

Geolocation in Blazor

One of the joys of Blazor is never having to use JavaScript again. With C# running in WebAssembly, events like button clicks can be handled by handlers written in C# and old dogs don’t have to learn new tricks.

There are some browser capabilities that aren’t exposed and these need JavaScript interop. The first of the browser Web APIs that I wanted to use in a Blazor app was the Geolocation API. This gives us the position of the device, among other things.

The goal of this project is to create a component that encapsulates the JavaScript interop malarkey. I want to create a Geolocation service that a host application can call to get its position using only C#.

GitHub: https://github.com/darnton/BlazorDeviceInterop
NuGet: https://www.nuget.org/packages/Darnton.Blazor.DeviceInterop

Continue reading “Geolocation in Blazor”

Slippy Maps in Blazor with Leaflet

Note: Updated November 2020 for .NET 5 and a good, hard refactoring. See the JavaScript References in .NET 5 section below for the bulk of the changes.

Wouldn’t it be nice to have interactive slippy maps in a Blazor application? Yes, it would!

Wouldn’t it be even nicer if the map component completely encapsulated all of the JavaScript interop and the page it was on was blissfully unaware that JavaScript even existed? Yes, yes, yes!

The hard work has already been by Leaflet.js. All that remains is to write a simple Blazor component to talk to the Leaflet API. (You can download my Darnton.Blazor.Leaflet NuGet package.)

Continue reading “Slippy Maps in Blazor with Leaflet”

Internet Fridge: Living the Dream

Forget flying cars; the Internet fridge is the future and has been for fifty years.

Last year there was a lot of fuss over the 50th anniversary of the Apollo moon landings, but 1969 was also the year of the Honeywell H316 Pedestal Kitchen Computer.

The Apollo Guidance Computer was celebrated, with its source code released on GitHub and a training course on Pluralsight. All this despite selling only eleven copies.

The H316 was much more practical, used for storing recipes rather than landing on the moon, which hardly anyone needs to do. The AGC’s users were military test pilots with years of training; a ’60s domestic goddess could learn to add recipes to the H316 in just two weeks. The kitchen computer cost only $10,000 — $399,999,990,000 cheaper than the Apollo project.

Even with all these advantages, the H316 Pedestal sold eleven fewer copies than the Apollo Guidance Computer.

In 1969, landing on the moon was real. Having a computer full of recipes in the kitchen was a pipe-dream. Today, we no longer have the technology to get to the moon but the dream of the kitchen computer is within reach!

Smart is Dumb

The H316 sold zero units and most recent efforts deserve the same fate. Internet fridges appear regularly on @internetofshit’s Twitter feed. Peak Internet fridge was reached in 2016, a moment documented on Tumblr by Fuck Yeah, Internet Fridge.

If your dumb fridge is cluttered with drawings from kindergarten that don’t fit your fancy decor, a smart fridge with Google Calendar on it may seem like the answer – until Google changes their API and Samsung doesn’t update the fridge. Like your kid’s finger painting, it won’t be very good but you’ll feel bad throwing it away.

Smart fridges come with all the normal problems of internet-connected devices: buggy, outdated software; susceptibility to hijack by Russian mafiya botnets, the constant need to turn them off and turn them back on again. All this combined with the serious expense of a major household item.

For $6,000 you get a screen on the front of the fridge that saves you from opening the door. For an extra $20 you can get the App Enabled Smart Egg Tray and check how many eggs you’ve got while you’re on the bus.

The Internet fridge remains the North Star of the connected home, but so far it only solves problems that don’t exist. No one’s come up with a good reason to own such a whizzbang gizmo.

How Many Bulldozers Does It Take To Change a Lightbulb?

The reason internet fridges are a bad idea was explained by Stewart Brand in 1994, the same year I found out what the internet was.

His book, How Buildings Learn: What Happens After They’re Built, popularised the idea of “shearing layers”.

Buildings have parts that change at different rates. The site is permanent. The structural parts of buildings last from decades to centuries. The roof and cladding may last a few decades; wiring and plumbing something similar. The layout changes more often, and the “stuff” in the building changes constantly.

In a good building, the layers that change more frequently can be changed without tearing apart the other layers. In other words, you don’t need to bulldoze your house every time you change a lightbulb.

The specific application to buildings can be sheared away from this story, leaving Brand’s core idea of layers that change at different rates – which brings us back to internet fridges.

Fridges are great. The internet is great. Internet fridges are stupid. The reason is that the fridge layer, which should last 20 years, is strongly coupled to the crappy-Android-tablet layer, which will last two years. I bought my fridge in 2006 and it still works perfectly. If it had the PC I bought in 2006 bolted to the front of it, I would cry a little bit every time I got a beer.

What we need is a shearing layer. In software I would define an interface. A fridge’s interface is a big steel door and the clients of that interface are fridge magnets.

The $100 Internet Fridge

Snarky articles note that instead of spending $6,000 on something that will only last two years, you’d be better off nailing an iPad to your fridge. So I did almost that.

I bought a cheap Android tablet, glued some fridge magnets to the back and stuck that on my fridge. Having spent just $100 on it, I can use it without guilt for trivial tasks like timing eggs. No need to add pointless features like push notifications when the pesto hits its use-by date.

I can also write my own software for it, living the dream of the original 1969 kitchen computer, having an electronic brain full of recipes just where I need it.

In the next part, I’ll start on the software…

3D Blazor with Babylon

Babylon is a good choice for 3D graphics on the web. Anything that you can do in JavaScript you can do in Blazor, so I’m going to put some 3D in my web app using C#.

First, I’m going to create a Babylon component that I can drop onto a Blazor page and then I’m going to see if I can shift all the Babylon manipulation up from Javascript into C# with a full Babylon interop layer.

Continue reading “3D Blazor with Babylon”

How to Build a CORS Proxy for Client-side Blazor

Blazor is a godsend for C# developers who want to build web applications. I’ve found building web apps in Blazor quick and easy, but there are a couple of fish-hooks that could catch you out. CORS is one.

I had a server-side app that was working fine. Turning a server-side Blazor app into a client-side Blazor app is mostly painless, but this time nothing worked.

The app was making a call to an API but from the client-side version of the app, all the calls failed. They’d been blocked by the browser’s CORS policy.

The answer was to build a CORS proxy. Here’s what I did.

Continue reading “How to Build a CORS Proxy for Client-side Blazor”

A Fishy Tale

When I first arrived in New Zealand I was told a story – the story that the North Island was actually a giant fish. The story turned out to be slightly true.

AFishyTale01Title

Maui, a Polynesian demi-god and his brothers went fishing and Maui took them further out into the ocean than they’d ever been. He cast his line into the sea and in the murky depths it hooked on something. Something big.

AFishyTale02MauiWaka
Maui and his brothers, from Maui and other Maori Legends by Peter Gossage

Continue reading “A Fishy Tale”

Pulling in Readers, Ferociously

Venkatesh Rao’s essay Gradatim Ferociter opens with this magnetic paragraph:
One of my favorite phrases is gradatim ferociter, the motto of Blue Origin. It means “step by step, ferociously.” The phrase helped me figure out why, despite really liking Nassim Taleb’s idea of antifragility, I’ve always found it kinda depressing. The idea seems to miss a major point: growth and innovation are processes that involve necessary fragility in proportion to how fast you want to move …
Every sentence is interesting. It fires a question in my mind and then answers it.
One of my favorite phrases is gradatim ferociter
What does “gradatim ferociter” mean?
It means “step by step, ferociously.”
Why is it one of your favourite phrases?
The phrase helped me figure out why, despite really liking Nassim Taleb’s idea of antifragility, I’ve always found it kinda depressing.
Depressing? Why?
The idea seems to miss a major point:
What does it miss?
growth and innovation are processes that involve necessary fragility in proportion to how fast you want to move
Venkat has given my reading the momentum needed to read the whole thing. Every sentence has an impetus that’s hard to resist.