But I also want to do some serious programming: one of the frustrations of the past year is how little raw engineering I've been able to do. The first month or so is going to be focused on the high-priority project of The OP Converter.
After that -- well, the question has always been whether my next step is to join a new startup or found one. And this past week, I've found myself shifting from the first to the second.
Mind, I've been pondering startup ideas for months. I even registered a couple of domains for one of them, focused on the interesting but fuzzy idea of sharing information about places in the real world -- this seems to be fascinating solution in search of a problem. But what seems to have finally fired me up is the idea of returning to the Querki project, which I've been neglecting for *many* years.
Once upon a time, I invented a system called ProWiki. This was an incredibly grungy piece of code, a big blob of Perl based on the very first wiki systems. On the surface it looks like a very simplistic wiki, but under the hood it contains a then-radical idea: the notion of fusing an object-oriented database with a wiki, to make it easier to keep track of *stuff*. I built ProWiki for my LARP writing, and still use it for that today, but the system has always been clunky, hard to use and painfully fragile. (It's a wonder the bear dances at all, as they say.)
So for about six years there's been a project lurking in the back of my mind to write what I dubbed Querki, the "queryable wiki". The idea would be to do this right: to build a system on modern technology, that would be fast, terribly easy to use, and in all ways state of the art. For all these years, I've been amassing architecture notes and other thoughts about the system, pondering both the requirements and how to build it.
And for no obvious reason, this past week, it all clicked into place. I've done a deep architecture revamp, and have a rapidly-growing ream of documentation about the features, the design, the goals and the use cases.
And the thing is, I've convinced myself that there is a business there. Which is where I may be calling on my friends, as outlined in the next post...
2012-06-14 03:06 pm (UTC)
2012-06-14 04:38 pm (UTC)
(And in this case it goes beyond merely UI design or even workflows: I'm seriously considering doing some relatively radical things to the data model to simplify usage. The DB specialists are going to flip out and call it a toy, but I think that may be exactly the right reaction...)
2012-06-14 04:55 pm (UTC)
2012-06-14 05:11 pm (UTC)
From an OO standpoint this is slightly horrifying -- it limits the namespace considerably -- but I don't think I care, since my target audience is apps that have a very modest number of classes. The result is going to be a very *weird* sort of OO -- but then, the idea of doing prototype instead of relational is weird to begin with.
And by simplifying the namespace, it makes a lot of things more *consistent*: you can count on "Ingredient" meaning exactly the same thing in every table, you can write cross-table queries without having to worry about the class hierarchy (and still get a highly interactive and helpful query editor), and so on. I found it crucial in my LARP ProWiki to be very, very consistent about the namespace, so I might as well reify that and take advantage of it.
This sort of thing is why it matters that I am intentionally not targeting enterprise use. If I say that my goal is to make it easy to build *simple* applications, generally with fewer than a dozen types and no more than tens of thousands of records, I can do all sorts of things that don't necessarily scale...