I have decided to keep this blog for professional use and move everything related to storytelling, role-playing games or improv acting to a new location. Without further ado, let me introduce Space·Time Will Tell! At the menu: a comic book tutorial for Fate RPG! using Tarot-like cards for storytelling! several elevator pitches for stories I haven’t had the time to write! the Space·Time Deck! the Ronin Time Bureaucrats! adventure and excitement!
Two years ago, I was working on a research project called “Project Link” as part of the Connected Devices branch of Mozilla. While this branch has since been stopped, some part of Project Link lives on as Project Things. One of the parts of Project Link that hasn’t made it to Project Things (so far) was Thinkerbell: a Domain-Specific Language designed to let users program their SmartHome without coding. While only parts of Thinkerbell were ever implemented, they were sufficient to write programs such as: Whenever I press any button labelled “light” in the living room, toggle all the lights in the living room. or If the entry door is locked and the motion detector notices motion, send an alarm to my SmartPhone. Thinkerbell also had: semantics that ensured that scripts could continue/resume running unmonitored even when hardware was replaced/upgraded/moved around the house, including both the server and the sensors; a visual syntax, rather than a text syntax; a novel type system designed to avoid physical accidents; a semantics based on process algebras. Ideally, I’d like to take the time to write a research paper on Thinkerbell, but realistically, there is very little chance that I’ll find that time. So, rather than letting these ideas die in some corner of my brain, here is a post-mortem for Thinkerbell, in the hope that someone, somewhere, will pick some of the stuff and gives it a second life. Note that some of the ideas exposed here were never actually implemented. Project Link was cancelled while Thinkerbell was still in its infancy.
In this entry, I’d like to discuss one of the most interesting and unusual aspects of the Binary AST: how we gain performance by turning proof-building into validation, and why this is very good news for performance (and maybe not so good news for file size).
A long time ago, the Rust language was a language with typestate. Officially, typestates were dropped long before Rust 1.0. In this entry, I’ll get you in on the worst kept secret of the Rust community: Rust still has typestates.
“The key to making programs fast is to make them do practically nothing.” - Mike Haertel, creator of GNU Grep. Binary AST - “Binary Abstract Syntax Tree” - is Mozilla’s proposal for specifying a binary-encoded syntax for JS with the intent of allowing browsers and other JS-executing environments to parse and load code as much as 80% faster than standard minified JS. It has recently cleared Stage 1 of the TC39 standards process, and while the final byte-level format isn’t completely nailed down, we’re confident that the final implementation will deliver the impressive performance improvements promised by the prototype.
A few weeks ago, Mozilla pulled the plug on its Connected Devices Experiment: a bunch of internal non-profit hardware-related startups. One of our main objectives was to determine if we could come up with designs that could help turn the tide against the spyware-riddled and gruyère-level security devices that are currently being offered (or pushed) to unwary users. One of the startups was Project Lighthouse. We tried to provide an affordable, simple and privacy-friendly tool for people suffering from vision impairment and who needed help in their daily life.
It’s no secret that all projects die, eventually, and that most projects die before they have had a chance to have any impact. This is true of personal projects, of open-source projects, of startup projects, of hardware projects, and more. A few days ago, the IoT project on which I was working did just that. It was funded, it was open-source, it was open-hardware, and it still died before having the opportunity to release anything useful. In our case, we got pretty far, didn’t run out of funds, and were a little polish away from putting our first alpha-testers in front of a pretty advanced prototype before a higher-level strategy pivot killed a number of projects at once. Ah, well, risks of the trade. Still, working on it, we managed to learn or come up with a few tricks to increase the chances of surviving at least long enough to release a product. I’ll try to summarize and explain some of these tricks here. Hopefully, if you have a project, regardless of funding and medium, you may find some of this summary useful.