I have been a “drone nut” for quite some time. I was a member of the AUVSI and I was even part of a (very short-lived) startup that involved building consumer-grade drones for photography, search & rescue, and other uses. I’ve written ground control software and even dabbled at modifying autopilot code running directly on drones.
Quite possibly the single most difficult (and rage-inducing) aspect of writing code for the drone ecosystem is that your code is interacting with hardware. Worse, this hardware can change configuration rapidly, meaning the motor you thought you could control over PIN 5 had been…
Throughout my career, one of the first things that I’ve done when encountering a new technology is ask myself whether this technology can be used to create a MUD, a multi-user dungeon (or dimension). MUDs, at least historically, are multi-user, online, text-based adventure games. It’s quite possible that there are some MUDs that are older than some of the people reading this post. Just because a technology is old doesn’t mean it’s bad. I’m going to over-simplify a bit, but MUDs tend to come in two flavors:
Yesterday I was working on an S3 Provider to provide blob store capabilities to WebAssembly modules in the waSCC ecosystem. If you’re not familiar with the waSCC project, the idea is to take non-functional requirements (or cloud-native capabilities) and dynamically bind them to portable, secure WebAssembly modules that contain pure business logic. Our goal is to make it so you can write your business logic and plug in whatever key-value store, message broker, or blob store you want. …
Since the first day I heard about Dark, I’ve been pestering its creators for access to the private beta. After the first round where they selected people based on a use case they wanted hardened (like choosing the most useful humans to be the first colonists to land on “New Earth”), they sent invites to those of us who didn’t specifically want to test that scenario. They were now ready for the less useful among us to start breaking things. To say that I was excited would be quite the understatement.
I admit it. I freely admit my guilt. I have neither excuses nor shame. I admit that I regularly buy programming books just so that I can curl up with them in a good chair and go through them from cover to cover, without ever opening a laptop. I thrive on the rabid consumption of new knowledge, no matter the subject.
That’s right, I’m that guy that reads a book multiple times. The first time I go through because I’m excited and inspired about some topic, and I don’t want to lose the momentum by putting the book down —…
Collectively, our industry has a long and difficult history of re-inventing things as something that may still not solve the original problem. Those who adhere to the not invented here (NIH) philosophy are constantly re-building things as their own. All too often, we end up re-inventing the wheel as a square simply so that we can claim this new thing as our wheel.
Are we doing that with WebAssembly outside the browser? If you take only a cursory glance at some of the features of wasm host runtimes in the cloud, it might indeed seem like we’re just re-inventing J2EE.
The other day, Microsoft started making a bit of a splash on the tech news and social media feeds with the announcement of their new open source project called Dapr. I was immediately intrigued when I read Dapr’s logline:
An event-driven, portable runtime for building microservices on cloud and edge.
Compare this to the elevator pitch for waSCC:
waSCC is a WebAssembly host runtime that securely binds cloud-native capabilities to portable modules.
When I set out to build Waxosuit a few months ago, my knowledge of how data could flow between the WebAssembly guest⟷host boundary was fairly shallow, and limited to what little I knew of the wasm-bindgen project (a Rust crate that generates JS/Rust bindings for building browser-based apps). If you’re not familiar with the low-level details, WebAssembly on its own is only capable of accepting and passing simple numeric parameters. You can’t pass strings or structs or binary blobs between host and guest as native parameter types. So if you want robust function calling, you’re going to have to build…
For the past several months, I’ve been working on an open source project called Waxosuit — a secure, cloud-native host runtime for WebAssembly modules. This project is written in Rust and takes advantage of a number of incredibly powerful Rust libraries and tools for manipulating and interpreting WebAssembly modules.
Since before I wrote the first line of code, I’ve always anticipated creating a Go SDK for building guest modules (currently Waxosuit only has a Rust guest SDK). I started looking into the Wasm ecosystem for Go and was surprised to discover a number of gaps.
I’ve been developing back-end systems for a long time. Distributed systems; complicated, resilient back-end applications; and microservices has been my specialty and passion for as long as I can remember. I wrote a book on Cloud Native Go, a book on building Microservices with ASP.NET Core, and dozens of other books on various technologies. But more important than the books is that I’ve been building this stuff and shipping to production for decades, so I’ve made countless mistakes and learned just as many lessons from them.
Frankly, I’m sick and tired of typing. I’m not sick of coding — just…
In relentless pursuit of elegant simplicity. Tinkerer, writer of tech, fantasy, and sci-fi. Converting napkin drawings into code for @CapitalOne