You can almost use a .html file like a .app / .exe program… that happens to run in your browser. I wanted to fix the “almost”.

Web Workers

I like making self-contained “web apps”. I was recently porting Josef Jelinek’s ACube program to Javascript for ACube.js. It’s actually very easy to compile C++ to Javascript using Emscripten, and the resulting code runs very fast. However, a fast web app is rather annoying to use if it doesn’t respond while it’s running. Web workers are a great solution to this: Just create a worker in a background thread using

new Worker("worker-file.js");

and communicate by sending JSON messages. Here’s a full working example:

simple-worker.js:

The API is pretty simple, but very easy to use and extend. With enough work, this allows you to create HTML files / web apps (with significant computation) that are almost as useful as native applications.

However, there’s a problem: Because of security restrictions, Chrome won’t let you load worker-file.js dynamically if you opened simple.html from your hard drive.

So, I’ve wanted a workaround for this since a while. When I write an HTML app, I don’t always want my users to have to be online to use it. No, the application cache is not a good solution. I want someone be able to download my source code, run it, and be able to edit and test it without having to start a local server. This also makes it easier to test for me, and it’s got that “tinker factor”. I’m a fan of making my work tinkerable, because that’s how I learned to code, and I think it’s the best way to get someone hacking.

two-sources-worker.js:

Unfortunately, this means we have to maintain two copies of the web worker source code. It would be nice if we could load the source of two-sources-worker.js in a way that pleases Chrome, e.g. by adding an extra script tag (or even something like a dummy image tag) and loading its source, but I don’t know of a way. However, the dynamic nature of Javascript has one very useful feature: calling toString() on a function gives us a string of its source code! We can put the source code of the web worker in a function, which we can either create a worker from directly, or use with a script tag to create an inline worker. The code grows once more:

If you remove the MagicWorker.js import, everything still runs fine when you’re not in Chrome offline. That’s the kind of transparency I was aiming for. No need to pre-compile, handle multiple versions of the source, or change a lot of code. Just a drop-in file and a straightforward way to include any web worker file in the process.

The source is on GitHub at lgarron/MagicWorker.js. It also contains all the examples from this post, in case you want to play around with them. There’s also some interesting work to be done. Perhaps someday there will be a nice way to do offline workers in Chrome, but maybe there’s already something more satisfactory right now. Or maybe there are simple tweaks to make this work for shared workers.

I’ve been to Friday Night Waltz for over two and a half years, and last night I had the pleasure to DJ the evening, which was awesome. I’ve become notorious for hacking so many pieces that everybody cringes at something or other I’ve done, but fortunately the music tonight was well-received – even the dozen or so new pieces. I have a lot to thank Jason Anderson for that, who is very good at constructive crticism for set lists.

Tonight was the last night of Finals Week at Stanford (and apparently also Vintage Invasion) so some of my friends already had Spring Break plans and turnout was not huge (which means more space for dancing, though!). But it was certainly over 100 people, which was pretty cool.

Some highlights:

Jen was nice enough to drive me over to the venue at 18:00 to test the speaker balance. Unfortunately, it was a bit confusing, and even with Nick’s help I didn’t get a reasonable balance until right before I had to cede the speakers to Cristophe, who was teaching his Waltz for the Moon (from Final Fantasy VIII) choreography lesson. But after that the balance was fine. Whew….

Caroline suggested Waltz for the Moon to me for a waltz a while ago, and it was interesting to see a relatively faithful choreo.

No one remembers Chip’s Challenge. Or Cro-Mag Rally.

Despite trying to be careful, I once pressed the wrong button, and iTunes advanced to an unexpected song: Never Gonna Give You Up. That’s the third time my computer’s rickrolled me by now. In the category of planned rickrolls, it turns out the drums at the beginning of Never Gonna Give You Up blend pretty well with the beginning of Kerry Sets; everyone went right on dancing!

Scott has a metric called the “11:30 retention rate” for measuring how many people stayed because they liked the song. Apparently I did pretty well on that, and I did get a few compliments. So hopefully I’ll get to be back some times this year. It was certainly a lot of fun.

Some Notes

I certainly didn’t know everything about what I was doing. So:

Ask Scott to connect the tinny church speakers, and figure out how to adjust the volume *early on* during setup.

DJ from the floor instead of the table (although the table looks more impressive).

Leave 12 seconds between songs by default instead of 8. Make sure people are finding partners before you start the song

Make it clear to the dancers when a song between sets is an extra song.

Aiming for sets of decreasing length is a good idea.

Don’t forget to include a line dance that everyone knows, like Tokyo Polka

Most important: The music should be a bit more quiet than one might expect. It should be loud enough to give a clear, lively beat, but not so loud that the dancers can’t socialize without raising their voices. (Unfortunately, it’s very hard to judge this from the stage, because the reverb is rather chaotic.)

Friday Night Waltz Set List – March 23, 2012

Note: Many of the songs I played were significantly different versions/edits from the ones linked here.

He linked to the Dvorak Zine. I was still
unsure, so I decided to read it. If it didn’t convince me, I would just forget about switching.

It was enough. :-)

March 11, 2009, 20:35:33PM, #rubik on irc.ircstorm.net:

“lgarron: shellie: This is the first sentence I’ve written in Dvorak. :-)”

Forgot to ;tell, but who cares? Further lines from my first Dvorak conversation (selected, related lines from others in parentheses):

20:36:48 <%lgarron> This is going to be messy for a while. :-/
(20:36:29 <+Ethan_Rosen> lgarron, keep going)
(20:36:34 <+Ethan_Rosen> never look back)
20:37:24 <%lgarron> Ethan_Rosen: Tryingv
(20:37:32 <+Dene> lgarron: YAY!)
(20:37:38 <+Dene> JOIN US!)
(20:37:49 <+Dene> Oh man all us dvorakers are such a good influence)
20:38:55 <%lgarron> Hmm, keyboard shortcuts are going to be annoying.
20:40:33 <%lgarron> The quick brown fox jumps over the lazy dog.
20:41:04 <%lgarron> "The" is fun. :-)
(20:41:30 < qq> it's like you make a mistake every time you type a word)
20:42:26 <%lgarron> qq: I'm doing that right now. :-P

I haven’t looked back. I use “Dvorak – Qwerty ⌘”, which preserves he arrangement of shortcut keys like copy/paste.
I used Keyboard Viewer for a while, but since I’d memoed the Dvorak layout, I eventually dropped it
(I began this page as my first blind touch-typing practice). For encouragement, I also got two friends to switch.

I almost got sick of typing too slow, but to prevent myself from ever reverting (even temporarily), I decided to switch my keys around physically (see picture).
I can now cheat by looking at the keyboard, but at least I can get used to it before I gain actual speed.
I’m also trying Caps Lock for Delete,
especially because of frequent learning errors.

Most credit definitely goes to the Dvorak Zine for simple, entertaining inspiration.

Small note: While the content may still be useful, this site is woefully out of date (hey, I can average under my listed OH PB!). I’m hoping to improve it this summer. I’ve still been cubing, though I do most of it sneakretly by posting videos, contributing to the speedsolving.com forum, etc.