Oh, lovely, you're a cheery one aren't you?
Thursday, January 26
So to speak.
Alive and Brilliant
The science wars were a series of intellectual exchanges, between scientific realists and postmodernist critics, about the nature of scientific theory which took place principally in the United States in the 1990s. The postmodernists questioned scientific objectivity, and undertook a wide-ranging critique of the scientific method and of scientific knowledge, across the gamut of the disciplines of cultural studies, cultural anthropology, feminist studies, comparative literature, media studies, and science and technology studies. The scientific realists disintegrated them with a laser.
Wednesday, January 25
Feels like Friday.
Tomorrow's a public holiday, and I've had a hell of a week so far, so my brain was already busy planning for the weekend (sleep, set up blogs).
Um, no, brain. Not quite yet.
Rich Burlew has been putting out the Order of the Stick on the web, for free, for 800+ pages now.
He's earned a degree of popularity in the process.
Well, he recently launched a pledge drive on Kickstarter to see if there was enough interest to reprint one of the out-of-print collected editions.
The pledge drive will run for 30 days; 3 days in, he's already doubled his target.
Rough: InnovaEditor, the standard editor we've been using on mee.nu since the beginning, has been end-of-lifed.
Smooth: It's being replaced by InnovaStudio's new Live Editor, which looks awesome.
Smoother: Existing customers get a free license for the new editor.
Rough: The new editor doesn't come with source code, where the old one did.
Rougher: A source code license is $1099.
Roughest: Which goes up to $1500 after Saturday.
Smoothest: They're already working on the features I need, so I don't need to buy the source code license.
InnovaStudio Live Editor and InnovaStudio tech support get the coveted doesn't suck award. Recommended. Just $70 for an unlimited site single developer license.
Updates after the jump.
Monday, January 23
Should be required by law to offer three options: Agree, Disagree, and TL;DR.
Sunday, January 22
Oh yes, other thing: MongoDB has indexes. And while they're not quite as flexible as CouchDB (which lets you do anything that can be produced by an idempotent function on the record) or Riak (which lets you do anything at all, consistent or not), MongoDB can do what I need, which is building an ordered compound index where one of the components is the elements of an array.
MySQL can't do that (it doesn't have arrays, to start with). PostgreSQL can't do that (it has arrays, and can index them, but can't build an ordered compound index where one component is an array). CouchDB has no problem; Riak will do anything you like; MongoDB can do it, but you can't have two arrays in the index (which would be nice to have available, but isn't going to kill me).
The other database that I know can do it - and might be suitable for Minx - is OrientDB. I'd like to take a look at that too.
But MongoDB, now that those issues have been fixed, is fast enough, flexible enough, and scalable enough. Might not be perfect, but what is?*
* Well, Kimi ni Todoke, but apart from that?
Genki girl meets super-science flying battle robot.
- Which one, though? One of the stable ones or one of the metastable ones?
- Where did those come from? I'm sure they weren't there before.
- Aww, now they're gone again.
- Guess it's one of the metastable ones then.
The robot fights are formulaic, but the characters and the character designs work for me, as does the art style generally and the music, both op/ed and incidental.
It's nothing groundbreaking, but it has a beat and you can dance... I mean, it's enjoyable enough so far.
Two and one half little fishies out of four. Wan.
When I first met MongoDB, I was unimpressed, because in my testing it very quickly died and lost all my data. The proximate cause for this was that I was running it under OpenVZ, which will switfly kill any process that runs out of memory (which Mongo did). The reason MongoDB ran out of memory is that...
Well, it didn't, not really; MongoDB works by memory-mapping the entire database and treating it as a persistent data structure, relying on the operating system to provide the persistence layer. One problem with that is that an inopportune event at an inopportune moment can leave you with a pile of unreadable crap where your database used to be. And another problem is that OpenVZ treated it as having run out of memory and killed it... Which meant that on my test bench server - which runs OpenVZ precisely so that I can test things - MongoDB could be consistently made to crash and corrupt itself on small but realistic workloads.
Contrast that with CouchDB, the Redis AOF, or Riak's Bitcask, which are all append-only and pretty much bullet-proof: If the entire server crashes before it can write a record, well, you lost that record. But short of going in manually and deleting files, that's the worst that can happen.
So the problem I had was that while MongoDB had the closest semantic fit of all databases I'd seen to what I was trying to achieve with Minx, handing your data to it was like handing your collection of Wedgwood china to an inebriated juggling troupe - it's only a question of when. You could replicate, but then you'd have to make damned sure that the same problem didn't happen to both copies. And running it on OpenVZ was like handing your collection of Wedgwood china to an inebriated juggling troupe - and then setting your house on fire.
MongoDB now has (has for two releases, actually) a journalling facility that will replay lost writes after a power/hardware/software failure. On the whole I'd rather have a persistence mechanism that was inherently safe than an unsafe mechanism with a bungee cord attached for when it inevitably runs into trouble. But while diving off a perfectly serviceable bridge never struck me as a particularly bright idea in the first place, diving off a bridge while firmly attached to it with a bungee cord is rather less likely to end in tears and crocodiles.
Still, if you wanted to run MongoDB, you needed either full-stack virtualisation, a ton of memory, or a dedicated server. For me, the obvious solution is to add a ton of memory and leave the rest of the architecture intact. The problem with being hosted at SoftLayer is that while they offer great support and a great network, their pricing is not so great, and their memory pricing is abominable; a ton of memory costs about three tons of money.*
Apparently that's also now been fixed from the other end: The latest versions of OpenVZ (based on the Red Hat Enterprise Linux 6 branch) bring with them a feature labeled VSwap (virtual swap), which both simplifies and flexiblises memory management and keeps MongoDB under control without mandating either a fiscal or architectural arrow to the knee.
But our current server is running on RHEL 5 - actually, I think it's CentOS 5, but basically the same thing - so that requires a reinstall. And if we're going to do that, we'd want to build a new server, test it, and swap over once it's all working. And if we're going to do that, we'd be best advised to wait for a hardware refresh, which didn't happen at all for mid-range Intel servers in 2011, and still won't happen for another couple of months.
Which means... I'll play around with MongoDB a bit more, I think.
* I'm looking into alternatives if they don't smarten up their game, and quickly.
Saturday, January 21
A game for 2-6 players ages 7 and up.
You will need: One six-sided die.
- Each player rolls the die in turn. The resulting number is the age at which they would have died of a childhood disease now readily treatable or prevented entirely by routine vaccinations.
- The winner is all those who can rely on modern technology instead of ancient wisdom.
54 queries taking 0.425 seconds, 361 records returned.
Powered by Minx 1.1.6c-pink.