Fake name generator

This is very cool - testing purposes, etc.

Musical score tools

There are, of course, a lot of different tools for musical scoring.

• Lilypond seems to be one of the biggies in terms of making pretty scores from a text definition language.
• Sibelius is one of the two major commercial software packages.
• MuseScore is an open alternative to Sibelius. These are both GUI tools for composition that also permit MIDI input, etc.
• Here's a list of six tools for notation.

Decl 2.0 syntax parser

I've been working on a lot of thoughts about the Decl reboot lately, including a ground-up rethinking of the basic way of handling syntax, and I've come to some conclusions.

Indentation is a misleading way of thinking about this. Indentation is just an indication of the two-dimensionality of text. Especially if we look at Markdown and its friends and relatives, we really have to realize that at least the block elements are there to exploit that two-dimensionality, to arrange information vertically as well as horizontally to present and shape information.

In fact, I'm getting a lot closer to just saying that Decl syntax and Markdown are sort of the same thing. And so I want to come up with a parsing language for two-dimensional text that is not a grammar built for one-dimensional sentences. Or at least is only partly a one-dimensional grammar.

Along the way, I hope to start looking at some naturally two-dimensional text items:

• Diagrams
• Musical scores
• Other timing diagrams
• Workflow charts, GANNT charts, etc.
• Page layouts and screen layouts for forms, buttons, etc.

And all that could be directly supported by at least part of the parser. Using indentation and block rules, we can do a "terraced scan", as it were, identifying blocks first and then drilling into them to identify more details.

The combination of Markdown with the Decl parser and interpreter, moreover, gives me a very natural way to implement literate programming tools in a way that finally makes sense to me.

I think this is going to be very fruitful.

Binary formats: PE presentation by the guy that did that PE poster

Excellent (if quite dense) slide show about the PE format and doing surprising things with it. Here is his Google code site.

Binary data structure construction is another kind of templating, and unboiling a data file should be pretty much equivalent to unboiling text. A form of exegesis, in other words.  Just a thought.

Name explorer

This has to be one of the neatest data explorers Í've ever seen: popularity of names by year in the United States. (And a fantastic HuffPost article about it.)

Boilerplate

So OK, what about boilerplate?  (Again...)

First, there are a number of modules in CPAN that produce boilerplate of various description, the first being naturally Module::Starter, which I use on a weekly basis. Its structure is surprisingly straightforward, but that's just another way of saying that it is expressing things in Perl that (in my opinion) could better be expressed in a specific boilerplate DSL.

There are others, such as Module::Starter::PBP by Damien Conway, based on "Perl Best Practices". Drupal::Module::Start. A Padre plugin (I did not know this until just now). There's Test::STDmaker, which takes Perl test output and puts it into a boilerplated document to conform to military purchasing standards. HTML::HTML5::Builder, which "erects scaffolding" for Web apps. Even WWW::Mechanize::Boilerplate, which I really would like to look at more closely.

In other words, CPAN contains a lot of knowledge about boilerplate, both Perl-specific and otherwise. (Another reason for a survey, yeah?) But what occurs to me is that I don't just want to look at boilerplate generation. I also want to explore boilerplate degeneration, as it were - extraction of higher-level information from a given text based on recognition and abstraction of boilerplate. This is just phrase-based parsing writ large, using more complex lexical entities, but I think it would be - well. It's a lot of what I expect an exegesis to be, to be honest; an abstract "understanding" of syntactic forms.

So there is actually a boilerplate extractor on CPAN, Text::Identify::Boilerplate, which, given a set of files, will do a line-by-line diff and extract the boilerplate. That's pretty slick!

But first, I propose Text::Boiler, which will take some kind of declarative boilerplate description and build that. Then Text::Unboiler, which will undo boilerplate (perhaps with overrides for changes to the boilerplate itself) and return to you the original record used to create the final files.

Ah. Right. Boilerplate + information = syntax. Boilerplate contains named fields, probably also lists and so forth, and the record contains those fields (which can also have default values if the record omits them). But the record can also override anything in the boilerplate. If the boilerplate also has named sections to make that easier, then unboiling should be pretty flexible indeed!

I think this is going to be a pretty profitable way of looking at things, especially in terms of exegesis, which is kind of a "manual unboiling".

Afterthought on Markdown: Hoedown

The standard Apache module for Markdown is now Hoedown, which supports lots of extensions, is written in no-dependency C, and is essentially bulletproof. It also separates the parser from the renderer, which is important if you want to index various text pieces. There is a CPAN Text::Markdown::Hoedown module which compiles and passes tests on my box; we'll see how easy it is to use (not much documentation, but that can be fixed with a pull request...)

In poking around and reading the documentation for Markdent, I found a couple of interesting proposals for Markdown extensions from Dave Wheeler: definition lists and better tables with multiline content.

So what I really want is a Hoedown-based parser generator that can add extensions at will. (Maybe later...)  Because honestly, what this is all about is different ways to use simple 2-dimensional, as opposed to 1-dimensional, arrangements of punctuation to delimit different items in text in as general a way as possible, build data structures based on that text, then render presentations based on those data structures. Each level of that process is interesting in and of itself.

Thoughts on Cookie Clicker

So back in December, BoingBoing posted a list of a few browser games. I bookmarked it because my son is interested in the gaming industry (like all teenagers, I suppose, and to a certain extent like myself).  Then a couple of days ago we took a look at Cookie Clicker.

It's fun. It's essentially an investment game: you click on a cookie to bake cookies. You use cookies to buy various implements that can bake cookies automatically. You use cookies to buy upgrades, which can adjust all kinds of variables in the game. Achievements translate into additional upgrades, and so on. There are a lot of fiddly details, it's all written with a great sense of humor, and the jargon makes it even more fun ("I got a click frenzy last night that put me over the top to buy an antimatter condenser and that got my cookies-per-second up above ten million." And so on, with the Grandmapocalypse and the larval stages of Santa Claus and reindeer giving you three billion cookies and kitten engineers that work for milk, etc.)

It's really fun. And there is a community of people who play pretty seriously. It's written in JavaScript, so its guts are wide open for the enterprising hacker. (There are even specific achievement badges if the game detects you cheating!) There's a community Wiki that explain some of the math, explain back story, and suggest strategy.

And there's an add-on, Cookie Monster, that lets you work at a higher level. It shows you costs in terms of seconds until you'll have that many cookies, it works out BCI and ROI on various investments, and so on.  (The Github development branch is here; it looks like it might be based on Node, so it's pretty interesting in its own right.)

Which got me to thinking.

This is a perfect context in which to explore strategy. In other words, we can define strategies in terms of "if this condition holds, take this action" or "if this condition holds, prefer this bias" - and run them multiple times to compare them. We could look at specific events, draw graphs, I dunno - interesting things! But in general, this kind of approach could probably map well onto real-world business decisions (and of course the theory involved is already out there).

I started down this path once before, back when Tower Generator games in Flash roamed the earth, and wrote some interesting DSLs in Python to fire events on a schedule - but I couldn't easily work with strategy at an adaptive level because I couldn't read the numbers (open-source OCR is still a no-man's land, actually.) It would be really fulfilling to do it right now - in a JavaScript game, after all, nothing needs to be OCR'd because it's already all available in the processor state.

Then, too, analyzing the design of CC while also attempting to determine what players enjoy would be instructive. Split testing of games? Sometimes people want to play the same game again so they can improve their intuitive strategy, so split testing can't be universal. But you'd have to learn some interesting things, probably involving categories of player that could all be addressed (or simply target your games - or game play during the game - to the player type).

(You could see that as the strategy of the game writer...)

The notion of an open-ended strategy game of this sort is also attractive. All this is already based on upgrades and rule-changing things - why not make it truly open-ended with a little programming language and let people come up with them in a network or something?  Just a thought.

It would also be fun to explore the idea of games within games, as CC is already exploring (he has a beta dungeon game you can access through the factories). A whole Internet of games or something, I dunno. A metagame, perhaps?

A "game toolkit" is a fun idea, as always (and see another BoingBoing feature, Playfic, a toolkit/community/hosting ... thing for Zorkoidal text adventure games).  (See also the Tower Defense generator I ran into last year.)

Multimarkdown

Multimarkdown is sort of next-generation Markdown; the main project has transitioned out of Perl into C for performance and now addresses all kinds of output.

The output I'm interested in is just the parsed structure - the DOM, if you will. I'm torn between recycling their parsing code (which doesn't actually parse everything I want, but works and works well) and writing my own parser (which usually leads to everything in flames and me losing my hat).

There is, of course, a Text::MultiMarkdown - but it doesn't quite parse correctly and would have to be subclassed to add additional features. And there's Dave Rolsky's Markdent, which does actually provide an event-based Markdown parser but comes with an entire ecosystem of modules and doesn't appear all that easy to extend (unless you're quite familiar with the Moose paradigm).

But overall, you just can't get away from Markdown these days when writing content. So I just keep coming back to it.

Mojolicious!

Here is some Mojolicious stuff:

• Its developer's blog.
• Another blog featuring lots of Mojo.
• Mojolicious + TwilML = Twilio serving stuff!

Command-line in JavaScript

So I have a convenient little library-slash-utility kit (SQP - and I can't remember what it's supposed to stand for) that I use for private tools (my invoicing, my notes, household finances, that kind of thing); it consists of a wrapper for Perl's Term::Shell and includes convenience functions for arbitrary SQL, which it knows how to format nicely, and provides a useful framework for quick-and-dirty list and modification commands.

But it's still pretty clunky, and for a while now I've toyed with the idea of putting the CLI into JavaScript and fronting the whole thing from a local HTTP server, like Mojolicious.

Yesterday, I did just that, in about four hours. Turns out Mojolicious is very easy to wrap my head around, and it's been long past time to start hacking JavaScript, so ... all is well.

I hit a number of fascinating things while poking around looking for stuff:

• Here's how easy it is to slap together a bare-bones CLI in jQuery. Look at the demo! It's freaking cool!  And that's probably the best framework for my son's planned text-based adventure game.
• Naturally I also found things about JS from the command line, like this GlueScript: a Wx/JavaScript monstrosity that has me thinking hard (it looks pretty groovy; hack up your UI in a bundlable thing and attach an embedded Perl for CPAN-y things and man, you'd be cooking with gas!)
• Another jQuery terminal - lots of features.
• I ended up going with Termlib, and not only because its author is in Vienna while I sit in Budapest; it also has no jQuery dependency and it offers AJAX command handling out of the box without my thinking hard about it. So it was a natural choice.
• Somewhere along the line I ran across PPI, a Perl DOM parser ... um, the Perl DOM parser actually.

Anyway, turns out it was dead easy to capture stdout and route it back to the browser. Where I'd really like to go with this is something a little more elaborate, though - more "textured" objects and larger text snippets returned from scripts should be placed into a return, and there should be a log.

What really kicked all this off is IPython, because Peter Norvig used it to analyze XKCD's recent regexp meta-golf (now you have infinite problems, hee) - for the exact same reason I wanted to - to play actual regexp meta-golf. IPython lets you work along interactively with data structures and hit code against them, but in a way I personally don't like. I want little editors to pop up and still keep that history and be able to switch to a notebook editor while I'm still working.  All that jazz. And if I do that in Wx (say) it will take me another twenty years - but in the browser I can do it in a couple of weeks.

So I'm gonna.

SQP is going to be my quasi-REPL, except I hate REPLs. I want a rich REPL, so that's what I'm going to write.  But of course it will also default back down to the command line if you're not in browser mode. (That actually also exists, in e.g. Perl::Shell and Shell::Perl and surely many others.)  Well, we'll see what I actually end up doing. The basic idea is the same, though. I want an interactive environment kind of like Mathematica, where I can see things in a nicely formatted way, put things into files, build files using templates and literate programming techniques, make schematics and diagrams with live links to items - who knows? All that and more.

Fountain: Markdown for scripts

Movie script, that is. Neat!

Sleuthing back doors in routers

This stuff is so cool. Guy in Holland finds a Linksys back door (blow-by-blow courtesy HNN) and figures marvy stuff out using magic. Here's another one for another situation. I freaking love this stuff.

A retrospective on Bazaar

This kind of history is pretty fascinating. I never really got into Bazaar - I was one of the ones that hit git first when people started to phase out CVS. But it was Github that really made the difference to me.