Thoughts while doing sysadmin

Task: pruning some context tables that contain far too much very old information.

I'm struck again by the fact that my memory can't retain SQL syntax for longer than about a month. When I need to add an index, I have to look it up again. And of course there's no record of what I did last time unless I go back through anything I might have noted down on paper.

I need an administrative tool that can encapsulate actions taken - and log them. People have successfully used VCS systems to keep track of changes to SQL, but a workflow enactment kind of thing would be better. (Perhaps in combination with a VCS system.)

So again: the action.

Database administration systems are a dime a dozen, of course. It wouldn't be hard to slap something like that together based on the transaction patterns a couple of posts back, in combination with this notion here. Deserves some thought - especially given that the same concept could be extended to Unix commands in general. Administration of cron jobs, whatever.

In a larger sense, a sysadmin domain would be able to construct a picture of a system of some nature that could be used to inform the construction of this type of action. This thread of thought is still really vague, but I keep coming back to it. (And have for decades.)

Final solution: wrote a Perl script for each table that gently removes 10K records at a time, and put it in the crontab to run every 10 minutes. Building an index would lock the tables for hours, disabling the database for an unforeseeable period. This is the kind of thing that I should be able to reuse effortlessly.

The case for segregation of natural language

So this is something I thought of yesterday in connection with my as-yet-nascent natural language production library - in a way similar to the idea of separation of layout from program-generated code, there should really be a separation of "mechanical" language - language generated by lookup or traditional methods - from fluent language.

That's not really very clear, is it?

Here's what I'm proposing, essentially. The starting point is internationalization - which is hard if you want to do it right. It's hard because natural languages deal idiosyncratically with number and gender - just as a start. So you can't use simple fill-in-the-blank methods for generating phrases, once you start worrying about Japanese and Russian and Hebrew.

What I'm proposing instead is some kind of semantic structure that would express a given thought that should be expressed. This structure would then be expressed in a more sophisticated manner - and if necessary would require additional information, like the gender to be used for the addressee. (I presume that Hebrew normally assumes masculine gender if the addressee is unknown.)

But that means that we've got several layers of layout. First is the language-independent layout, into which we could insert lorem ipsum. Next is set pieces - paragraphs of explanatory "brochure" or instructional text that can be translated en masse and inserted wherever needed. And finally there are the interactive segments - error messages, responses to requests, and the like - that need more careful handling for fluency.

It's kind of inchoate, and less revolutionary than it seemed while I was walking the dog. But I don't want to forget it.

Flex and Exambuff

How did I never hear of Flex? It's an application-based compiler for Flash, effectively, used for building "Rich Internet Applications" (i.e. Flash apps) without the need for a lot of the animation stuff that makes Flash so weird to use for the software designer.

[sdk] [brief article]

The reason I even ran across it is that a chap named Tim Ruffles wrote an entire site (for commenting on scanned exam papers) that he's open sourced because it just wasn't working out for him. [article] [github] [site] The actual working-with-papers part is all in Flex.

I am very strongly considering making this another target for Decl.

d3.js - data-driven documents

Oh sweet Lord this is a nice-looking library that I plan to love for the rest of my life.

Programming language design

Interesting article on some of the design shortcomings of Go: Go rocks - How can we avoid something this bad in future?

Transaction patterns

From February on "Web app design":

Oh, wait: a mother lode of so-called "transaction patterns" used in a toolkit for building database administration sites. It is incredibly detailed. These transaction patterns, by the way, constitute a language for user-level interaction with Websites that is not restricted to the Web domain - they'll work just fine in the Wx context as well. So they should definitely be analyzed, but they can't just be relegated to WWW::Publisher. I'm not really sure where they should go. Probably a new domain. Database::Declarative? I just don't know!

It took me a few minutes to find this post just now, as I hadn't really marked it very effectively. Now I'm doing so. The concept of the transaction pattern is a good one.

Basic CSS of a grid layout

Nice breakdown. This is the kind of thing I want to look at macro-izing, like, next week. I've started work on CSS::Declarative again, and next on the checklist is macros.

Extended examination of app building in HTML5

One of the Opera devs is porting a C++ game into HTML5 as a kind of exercise. Worth reading.

databranches

Using git as a distributed database. Intriguing.

"Asynchronicity": checklist pattern

An interesting article about asynchronous building of page parts. Start off a checklist of parts (using, e.g. memcache), then time out at a given time, check the keys for parts that successfully got generated, and build your page with what you've got.

The point being that you end up with a much more resilient server - if a database is down for some reason, the rest of the page gets built and things degrade gracefully. Neat idea!

ClickEquations

Here's an interesting app which does ... I can't actually tell what it does. Looks cool, though, so I can't bear to lose the link. Seriously - some kind of data-oriented business stuff.

REST APIs

This is something I've given little thought to, so far: RESTful APIs. Nobody understands them. Another link from the same blog. Private media types - who knew?

Target domain: dates and times

Time.

Automata as macros

Interesting article on using Scheme macros to encode automata.

It goes through the steps from writing a crude interpreter for an automaton to writing a nice macro to produce higher-performance code. That's cool.

Target domain: cryptography

Lifetimes of cryptographic hash functions. This kind of ties back into the best-practices thing, but it's a solid domain knowledge target.

Web intents

Web intents seem to be a new way to link apps together to get tasks done. Worth a read when my mind is clear sometime.

Interesting programming language roundup

It's time for link dumping, boys and girls.

• Bandicoot, a set-based language. Looks kinda half-baked, but intriguing.
• OMeta, an object-oriented language for pattern matching. Very intriguing. [pdf]
• Another article on Coffeescript.

Target domain: Android apps

I mean, come on - this is the perfect target domain.

Tutorials.

Fexl: small functional programming language

Fexl. This guy even runs Fexl as an embedded interpreter in Perl. (Which is unfortunately not on CPAN.) Interesting stuff.

Joshfire framework

Wow, this is really close to what I want to do in the Web publishing sphere!

The Joshfire framework allows you to describe an app in terms of a data tree and a UI tree - and the app will then be expressed for different platforms! It's Javascript and HTML5 and entirely too close for comfort!

Very cool.