2022-07-29.01
2022-07-29.01
Thunderbolts & Lightning; The Future Belongs To WebAssembly; R for Gaming
Thunderbolts & Lightning
It's storm season in the U.S., which means regular visits from Thor's thunderbolts and lightning. A little while ago, I picked up a Tempest weather station to pair with my Davis Vantage Vue, and also evaluate for a friend. It's a great unit with some clever tech, including a lightning sensor. Said sensor has been busy this week, causing the app to fire off tons of alerts.
If you want to get in on the lightning monitoring action, you can do so passively at Blitzortung.org, which is a "worldwide, real-time, community collaborative lightning location network" that's been around since the early 2000's. They have live maps (the dynamic one — below — is the nicest, IMO) and historical archive data, provided you also contribute lightning data to the network.
The Blitzortung community has put together a pretty sweet DIY package that is pretty straightforward to build. If you hit up the aforementioned dynamic map, you'll see there are plenty of areas that still need covering. This is your chance to become a citizen [data] scientist!
If you do grab one of the kits, drop a note in the comments letting us know how the build went.
The Future Belongs To WebAssembly
Sébastien Deleuze (@sdeleuze) has a great thread up on "How WebAssembly could impact the future of programming languages":
In it, Sébastien mentions some seriously cool, emerging tech like WIT — the WebAssembly Component Model which has some lofty goals:
Define a portable, load- and run-time-efficient binary format for
separately-compiled components built from WebAssembly core modules that enable portable, cross-language composition.Support the definition of portable, virtualizable, statically-analyzable,
capability-safe, language-agnostic interfaces, especially those being
defined by WASI.Maintain and enhance WebAssembly's unique value proposition:
Language neutrality: avoid biasing the component model toward just one language or family of languages.
Embeddability: design components to be embedded in a diverse set of host execution environments, including browsers, servers, intermediaries, small devices and data-intensive systems.
Optimizability: maximize the static information available to
Ahead-of-Time compilers to minimize the cost of instantiation and startup.Formal semantics: define the component model within the same semantic framework as core wasm.
Web platform integration: ensure components can be natively supported in browsers by extending the existing WebAssembly integration points: the JS API, Web API and ESM-integration. Before native support is
implemented, ensure components can be polyfilled in browsers via Ahead-of-Time compilation to currently-supported browser functionality.
Define the component model incrementally: starting from a set of
initial use cases and expanding the set of use cases over time,
prioritized by feedback and experience.
WIT and Sébastien both mention WebAssembly System Interface (WASI), which also has some slick goals:
Define a set of portable, modular, runtime-independent, and
WebAssembly-native APIs which can be used by WebAssembly code to interact with the outside world. These APIs preserve the essential sandboxed nature of WebAssembly through a Capability-based API design.Specify and implement incrementally. Start with a Minimum Viable Product (MVP), then adding additional features, prioritized by feedback and experience.
Supplement API designs with documentation and tests, and, when feasible, reference implementations which can be shared between wasm engines.
Make a great platform:
Work with WebAssembly tool and library authors to help them provide WASI support for their users.
When being WebAssembly-native means the platform isn't directly compatible with existing applications written for other platforms, design to enable compatibility to be provided by tools and libraries.
Allow the overall API to evolve over time; to make changes to API
modules that have been standardized, build implementations of them using libraries on top of new API modules to provide compatibility.
The thread isn't too long, and I encourage any readers who do work in any programming language to give it a read. WebAssembly is here to stay and, while I think some browser-based Wasm tricks are neat, I'm really not a fan of all the security problems we're about to see as browser use proliferates. Unlike Adobe's Flash, Wasm works amazingly well in a non-browser context and is likely the future of platform-agnostic binaries, and, I posit, will see custom hardware developed to have it be the defacto/standard way of deploying code to "the edge".
I said this on Twitter the other day, but one reason I keep mentioning Wasm (apart from how cool it is) is that you will very likely be impacted by it, if you aren't already impacted by it.
Posit (formerly RStudio) demoed Wasm-Python-backed Shiny running solely in a browser context at their recent practitioner conference. That's how close many of you are to being impacted by it.
R for Gaming
mikefc (@coolbutuseless) is an amazingly creative and talented individual. I once though I was the only one making weird/niche R packages, but Mike takes it to an entirely different level.
I was waiting for his RStudio::Conf talk to happen before dropping the remarkable work he's been doing, making it possible to write and run entire graphical games in R. Yes. R. Here are two of them:
This is pure R, using R graphics devices, and real games with sound.
I'm not going to type further, as Mike is also a fantastic 'splainer of all the cool-and-absolutely-not-useless things he builds. Go check out all his creations & explorations.
When I grow up, I wanna be Mike.
FIN
Stay cool and inside this weekend and play some R games! ☮
very cool RConf this week. caught a few sessions, now must catch up on the rest