jducoeur: (querki)

TL;DR: info about Querki releases has moved to the new Querki News Space. There's cool new stuff there.

Some of you may have noticed that the Querki Development Journal has fallen silent. That mostly has to do with LiveJournal: under the circumstances, keeping Querki's news outlet on LJ seems less and less useful, so I've basically abandoned it.

That doesn't mean Querki has stopped moving forward, though -- far from it. I've picked up a dayjob with a small consultancy; this has the downside that I have somewhat less time to focus on Querki, but the upside that Kate is no longer stressed about my lack of salary. The boss and I have an agreement that he's paying somewhat less than my usual rate, in exchange for which I'm not taking as much of a leadership role as I usually do; that's specifically so that I can continue on Querki, which is getting disconcertingly close to the point I originally defined as "done enough".

There are a few major features left, and one of them was introduced a few weeks ago: Publications. This has been on the roadmap almost from the beginning, originally named "What's New" -- basically the notion that there should be a formal concept of declaring new stuff in the Space, and pushing that to RSS, a Recent Changes page, and so on. We're finally getting to one of the long-time dreams for Querki: the ability to create structured blog-like-entities in Querki, so that your Cookbook or Songbook or FAQ or whatever can be subscribed to, and folks can see what's new there automatically.

Anyway, what used to be the Querki Development Journal has now become the Querki News -- actually running in Querki, which makes me ever so happy. (Dogfooding is a way of life for Querki.) For the time being, I'll mention here when there are announcements there; before long, it will have its own feed on Dreamwidth. You can find the announcement of Publications there and even more info in the documentation.

Up next: Publication Spaces will gain real RSS feeds! And not long after that, we begin to open up Conversations and Comments to the public, so that Querki can be seriously used for blog-like-entities...

jducoeur: (querki)

(Only interesting to programmers, and this time really only interesting to folks who actually build front end pages. But really interesting for those of us who do that.)

Okay, I'm probably late to the party here, and the serious front-end people already knew about it, but last week Otto Chrons (one of my fellow Scala.js geeks) happened to point to an article that mentioned Chrome's current Performance tab. So I took a look, and found it downright revelatory. That turned into the focus of this weekend's Querki release.

If you have Chrome, go check it out: Inspect a page, go to the Performance tab, and reload the page. Poof, you are presented with a wonderland of data. Here is a representative image from Querki, behind the cut tag. (Ignore the nonsensical function names -- that's because the code has all been optimized.)

Read more... )

At the top, it shows a summary of what the CPU was doing while you reloaded. This makes it starkly obvious when the page is just sitting there, waiting for stuff from the network. Below that is a sort of icicle view of exactly what happened when, with each task broken into sub-tasks, and sub-sub-tasks, and sub-sub-sub... you get the idea.

Honestly, it smacked me across the face: it turned out that one reason Querki's page load was so slow nowadays was that it was taking over two seconds to parse a bloody text file, because I hadn't optimized the parser properly. An hour or two of hacking on that, and I'd reduced it by over 80%. Check.

Then there is all that downtime: basically, it would completely lay out the basic page, then go fetch the big scripts, and only once those fed in did it start to process. This led to me reading into the new Preload tag. This is very new (as in, it's been around for about a year), and only supported on Chrome and Opera, so it's not a panacea -- but it does help a lot of the market. Basically, it lets you say "I am going to need this resource soon, so start loading it Right Now". If it's supported by the browser, and you have enough network connections, it starts fetching it in parallel, so the scripts can start to execute as soon as things are ready for them. That seems to shave another second or so off of load time.

Overall, it's a huge win, and the result is that Querki's initial page load is now down from averaging about 6-7 seconds on the desktop to sometimes getting as low as 2 seconds under optimal circumstances. (Among other things, this means that navigating to your index and then over to another Space is much faster than it had been.)

I haven't managed to fix everything yet: there turns out to be another fetch that is sometimes causing delays, which Preload doesn't seem to work on. (Basically, because it's an AJAX request.) That's going to need a serious rewrite, I think. But I hadn't even realized it was a concern until getting whapped upside the head by the Performance tab.

So to summarize: if you're building webpages, Chrome's Performance tab is your friend. It's dense, but chock-full of useful information to help you understand exactly what's taking how long at load time...

jducoeur: (querki)
There's been a lot of discussion recently about the asymmetry implicit in "free speech" online. Many services naively subscribe to the principle that More Speech is Better, and that the way to defend yourself against harassment is through more speech. In practice, that's largely bullshit. (See this article from Yonaton Zunger for one good exploration of the topic; it's what got me thinking about the problem more concretely today, on top of [personal profile] siderea's related article a little while ago.)

At the moment, none of this is really a concern for Querki: I initially started with the hyper-safe approach that *only* members of a Space can comment in that Space. This is precisely the opposite of most websites: it means that you at least aren't going to get harassment from outside the community, and you can always boot somebody out of the Space if they turn into a problem.

But in the medium term, that's too limiting: many Querki Spaces are public, and their use cases are going to *want* to allow public commentary. (Part of the inspiration here is that Querki is about to become a viable blogging platform, and public comments are, I believe, necessary for many blogging use cases.) The plan has always been to put moderation front-and-center in such cases, but as I get closer to actually implementing this (it's only a couple of steps down the Roadmap now), I'm starting to chew on this asymmetry, and its implications.

Oh, and keep in mind: while I'm framing everything below in terms of comments, the same policies are likely going to apply to *contributing* to this Space. That is, we're eventually going to provide ways for non-members to suggest new Things in this Space. I *think* the considerations are the same as for comments, since "Things" tend to be text-heavy, so the potential for abuse is the same.

Here are some thoughts and plans, but I welcome your ideas and comments -- this is *not* easy stuff, and I want to get it right, at least in the long run. The following is a combination of long-planned features and thinking out loud about how to make them better.

(NB: Yes, I'm probably overthinking this, and not all of the below will be implemented immediately. But I think it's best to take the problem seriously from the outset.)
Assumptions and Theories )Designs and Features )
What Else? Ideas? Comments? This is a challenging and important topic, and one I care particularly passionately about doing well. I'm open to any brainstorming folks might be interested in here...
jducoeur: (Default)

Another day, another use case: I finally got around to taking Kate's and my old "Restaurants we should try" spreadsheet and turning it into a nice rich Querki Space. I've only just started to flesh out the list of places we have already been, and give them ratings, but if you're interested (or simply want a look at a typical Querki use case), you can find it here on Querki. Being Querki, it's all cross-referenced by restaurant type, neighborhood, and so on. (And I've put the Location in for most of them, so there are automatic Google Map links to show where they are.)

And if anybody would like a site like this themselves, just speak up: I haven't gotten around to turning it into an App yet, but it will only take me a minute or two to do so. Once I do so, it will be quick and easy for you to sign up and set up your own Restaurants Space. (I suspect that this is only interesting to the foodies, but we certainly have friends who like this sort of thing...)

Adtech

Mar. 29th, 2017 08:42 am
jducoeur: (Default)

Here's an interesting article about "adtech" -- those automated algorithms that companies like Google and Facebook use to spy on you and serve up advertisements that they think you will respond to. The major upshots are:

  • Adtech is at best wildly ineffective, and at worst actively damaging, for brands that are trying to advertise.
  • The core precepts of adtech is going to be illegal in Europe starting next year.

I'm not sure how accurate all this is -- it sounds a tad self-serving in favor of traditional advertising, so I take it with a grain of salt -- but I suspect there's a substantial grain of truth in it. It clarifies a distinction that the tech world has been trying very hard to blur, between direct sales and branding. It appears to me that adtech works a little for direct sales, but I suspect the article is right that it's inappropriate for serious branding.

I find myself ever more glad that Querki's business plan is specifically not built on the "spy on the users for purposes of advertising" model, which is looking ever more rickety. Asking people to pay for a service is old-fashioned, but it at least makes sense...

jducoeur: (querki)

What I set out to do: add "Unsubscribe" links to the bottom of all emails sent from Querki, so we properly comply with CAN-SPAM requirements.

What I find myself doing: implementing not just Guest Mode (the long-long-desired ability to use a Querki invitation without having to become a member), but today implementing Shareable Links (because Guest Mode lets me do so with adequate security, and there are a pile of great use cases enabled by it). Yes, those are both sequiturs from where I started -- building proper "Unsubscribe" requires having a concept of Identity for an email address, and the ball of twine started rolling away from me as soon as I got that far.

They're great new features, and should make a ton of use cases much more usable. But man, this is not what I had expected to be doing with my week...

jducoeur: (querki)
Here's an *immensely* speculative idea, looking for thoughts from the folks who've used Querki (or simply been listening to me burble about it for all these years).

As I read through Ars' review of the new Google Home (tl;dr: it's the Google version of the Amazon Echo), which mentions that they're going to be opening up APIs, it occurs to me that Querki is going to need to interface with this sucker. I mean, I keep my shopping list in Querki; I'm obviously going to want to be able to say, "Ok Google, add milk to my shopping list". Or "tell me what I need to buy for Chicken Pizziola Mexicana" from my Recipes Space. Or "show me the lyrics to The Mary Ellen Carter" from my Songbook. Etc, etc.

Of course, wanting this is a far cry from making it happen, and none of this is even *remotely* easy. I'm not even sure to what degree it'll be possible to hook into the Google Assistant, to parse the stream. But we clearly *want* to be able to define listeners like this for Querki Apps eventually, so that you can easily build a Space or App in Querki and then hook it right into the listener system if you want. So I'm starting to ponder it.

(And yes, security is an issue. Fortunately, Querki is already designed to cope with interfacing securely to external identities; that's going to become front-and-center pretty soon, when we add Facebook integration.)

Hmm. And if we can do this, we potentially can use the same system for interfacing with text-chat systems, so that you can easily build chatbots on top of your Querki Apps. I'm not actually sure how useful that is, but it's the current hotness in the industry, so it would be nice to be *able* to do it, if it turns out to be real. (I'm pretty sure that this voice integration stuff *is* real, and is going to become important.)

Anyway, thoughts are welcomed -- other use cases, thoughts about architecture, whatever. None of this is going to happen soon, so I'm looking for brainstorming. Feel free to comment either here, or on the tracking Issue in Querki itself. Thanks!
jducoeur: (Default)
One of the interesting lessons of working on the Querki project has been to be suspicious of the phrase "user error". It's a commonly-enough heard term in programming -- dismissing a bug report on the grounds that the user just didn't read the documentation closely enough. It's often accompanied by just the *tiniest* bit of sneer (or sometimes, not so tiny), that the user is obviously a bit dim for not *getting* it.

That's *never* a good response, but in a consumer-facing application it's downright capital-B Bad. I tend to think of this as the heart of UX, or at least a major artery: if the user isn't understanding your product, your first response should be to look for problems in the product, not problems with the user.

I've been slapped upside the head with this a bunch this week: [livejournal.com profile] alexx_kay has been doing some building, and logging a pile of bugs. Some of them are simple, straightforward, ordinary bugs, but several of them have been provoking an internal monologue along the lines of, "Well, that doesn't *work* that way... but of course you *expected* it to work that way... annnnnnd your expectation is perfectly fair and consistent with the rest of the system, a clear improvement... so I guess I need to tweak things to make it work that way".

There's a lesson here, for both programmers and users. I've mentioned it before, but it always bears repeating: users who send you bug reports like this are worth their weight in gold, and the correct response to bugs like this is "thank you". Down in the trenches, it is *terribly* easy to develop tunnel-vision, and your users, especially the serious ones, often spot inconsistencies that you overlook. (Folks building stuff in Querki, *please* don't be shy about sending 'em in.)

Or, to put it more simply, people sending in bug reports are usually *doing you a favor* by doing so. Treat them accordingly, and value their input...
jducoeur: (querki)
See the latest release notes on the Querki Development Journal for details, but suffice it to say, Querki now has its own Cassandra cluster, and we're going to be transitioning most of the application data over to that (from the existing MySQL database) in the next month or two.

It feels almost trendy, but we're finally joining the NoSQL Age...
jducoeur: (querki)
One of the more radical plans I have for Querki, which I'm about to start playing with, is a UI with multiple "levels", so that you can choose the complexity you're comfortable with.

The thing is, Querki has several distinct audiences:
  • The *vast* majority of users just want solutions. They don't want to build anything, they just want to use what's out there, that suits their data needs. They will be using other peoples' Spaces, and creating Spaces based strictly on existing Apps.

  • Of the remainder, most are just going to want to create relatively straightforward Spaces -- building something customized to their needs but not especially fancy.

  • And then there are the programmers, who will be creating the really fancy Spaces and Apps and tuning the details to be Just So. Querki is *fun* for programmers -- once you have the hang of it, you can build pretty powerful stuff much more quickly than in traditional environments.
The thing is, there's a ton of power here for the programmers, that the average end user not only doesn't *need*, they actively don't *want* it -- it occupies conceptual space for no benefit. There are lots of features ranging from the fine-grained Security page to the Model Designer that are usually irrelevant for that first category.

At this point, I have a fairly good idea of which aspects of the system are useful for which of these audiences, and the notion I want to try is that the folks from the first set will see a much simpler, stripped-down and focused environment, whereas the programmers will see all the bells and whistles. (And the folks in the middle will see some but not all of it.) This is all self-selected, mind, and can be changed at any time.

The question is, what do I call these "levels"? I've been thinking Easy, Standard and Advanced, but in talking with Kate about it last night she reacted quite viscerally against those terms: she thinks they're basically meaningless to the target audiences. She recommended User, Builder and Programmer instead -- names based on the audience rather than the degree of functionality.

I think she's got a good point here, but I think it's worth a bit of brainstorming. So -- opinions? Suggestions? Obviously, we can change these terms later if we need to, but it's always easiest if we can hash out this sort of argument in advance and get it right the fight time...
jducoeur: (querki)
Howdy, all! Major milestone today: Querki has now officially transitioned from "closed" to "open" beta. In practice, that only means one change, but it's an important one: there is now a Sign up button on the Querki homepage. No more complicated invitations or anything like that -- you can now just sign up and start using it.

The standard question is "What's it for?" At the moment, I'm answering that in terms of the pain point we're solving:
Any time you are tempted to build a spreadsheet that isn't mostly numbers, you probably want Querki instead -- it's the right tool for the job.
That is, most non-numeric spreadsheets are really trying to be poor man's databases. And when they are very, very simple, that kind of works. But as soon as the number of rows gets to be more than a couple of screenfuls, or the data stops being one trivial grid of rows and columns, or you need interesting types like pictures or addresses, it starts to Suck. That's because spreadsheets really are mainly intended for juggling numbers; everything else is sort of trying to use a hammer to drive screws.

Querki, on the other hand, is totally designed for this: it was designed from the get-go to help individuals, communities and small businesses manage Small Data. Everybody's got Small Data they need to manage and collaborate on: problems that only involve hundreds or thousands of records, but which often get pretty complicated once you get going. Querki builds in all the "infrastructure" -- everything's in the cloud, available from your desktop, tablet or phone; everything is as secure as you tell it to make it; and everything's collaborative, so you can share with whoever you need to. You just tell it about the data, by designing a Model, and you're ready to go.

I have to caveat that there still isn't much hand-holding to teach you how to "think in data"; it's still somewhat challenging for non-technical users to build a Space, although it's fairly easy to use one that somebody else has built. If you do have some technical background, though, it's pretty easy to understand all the key concepts of Querki by analogy:
  • A Space is basically a database plus a website.

  • A Model is similar to a class (if you know object-oriented programming), a table (if you know databases) or a spreadsheet (if you know spreadsheets).

  • An Instance is roughly the same as an instance (in object-oriented programming), a record (in databases) or a row (in spreadsheets).

  • A Property is roughly the same as a property or field (in programming), or a column (in databases and spreadsheets).
There's vastly more -- I'll show off a few of the cool public Spaces in coming weeks -- but that's pretty much what you need to know in order to start creating useful Spaces. You create a Space; you design one or more Models that represent the data; you add Properties to those Models as needed; and you start creating Instances based on the Models. (And you Share with whoever you want to work with.)

So if this sounds like it might be useful to you, please come try it out. Send me comments, questions and bug reports. There is absolutely no such thing as a stupid question here: I need to know what isn't obvious, because those are by definition aspects that I need to work on.

Come have fun, and Welcome to Querki! And please, spread the word...
jducoeur: (querki)
This isn't yet certain, but Querki will probably be down for several hours tomorrow afternoon/evening, as we move to our new home.
jducoeur: (querki)
Really, today's XKCD summarizes my elevator pitch remarkably well:
jducoeur: (device)
Anyone interested in the design of software (or anything, really, but particularly software) really should take a read through this short but correct article.

Its point is simple: software is often designed for (in the telling of the famous physics joke) perfect spherical users, who are all cooperative and well-intentioned towards each other. Unfortunately, the real world doesn't work like that -- there *are* assholes out there. Not a gigantic number, but it doesn't *take* a gigantic number to mess everything up: the old adage "It only takes one bad apple to spoil the bunch" is nowhere truer than in the online experience. The proof is all over the Web.

I suspect Querki is going to get some pushback for some of its baked-in decisions, such as the fact that there is not, and probably never will be, a way to enable anonymous, unmoderated commentary. This article is a good outline of why: my consistent assumption is that a small but non-trivial number of the users are going to be bad actors, who are attempting to harm others or the service itself, or are simply assholes; the whole system is designed around that assumption. Dealing with that, and taming the resulting complexities, is one of its biggest ongoing design challenges...
jducoeur: (Default)
As I dive into the craziness that is fund-raising for Querki, I may as well blog about it for posterity. No deep thoughts, just a bit of diary entry for amusement, and for those who might want to go down this road someday.

Tonight's outing was to Entrepalooza, MassChallenge's annual shindig. Roza and I got there on the casual side of 6pm, since I had figured that a a large and loud party like this would have folks gradually arriving over the first hour or so. Wrong-o: there were a couple hundred people in line ahead of us.

The event was held at the Royale, a pretty large club in the theater district downtown. As expected, it was loud and crowded (presumably not helped by the fact that they were pushing $5 "VIP" tickets, with all the Harpoon you could drink), but in fact a good deal more useful than I'd expected. The focus was mainly on service offerings for entrepreneurs -- accelerators, gatherings, newsletters, tech services and so on. Each had its own eensy-weensy table on the floor, and was pitching its services to the mobs of entrepreneurs and would-bes wandering around. We found several that seem like they might be noticeably helpful for us, including the MIT Enterprise Forum, the Venture Cafe Foundation, TIE and The Capital Network. Between those, my calendar for the next few months is starting to look a lot busier.

I was gently amused that, while we're still very early on this road, we are a *lot* further than most of the people present -- we wound up in conversation with several earnest 20-somethings who had a clever idea and not much else. (I listened to one of them, pitching to an accelerator, smoothly transition into, "Do you maybe have any intern openings?".) Having an actual product in beta, that's been through well over a hundred releases, looks positively baked by comparison.

I remembered to grab my "I write code so you don't have to" button, which got a lot of inquiries. I may yet make that a semi-official slogan for Querki, since it gets to the point quite nicely.

I'm finding the overall sensation vaguely familiar, which is comforting. I've learned that, at the outset of any major project, I have an overwhelming sense of, "OMG, we're doomed! I don't know what I'm doing! Doomed! DOOOOOMED!". So I spend a while -- anywhere from days to months -- poking at the problem, looking at it from all the different angles, understanding what goes into it, and so on. Eventually, there comes the day that I look at the problem again, and say, "Oh -- okay, that's easy."

(Mind, that's the engineer's definition of "easy", which means "not hard", which means "I'm quite sure that it's physically possible to solve this". It still might take years of work -- but now I understand *what* work needs to be done, so it's no longer scary.)

That seems to be roughly where we now are. We need to raise a sum of money that, while not especially much by enterprise-software standards, is still dauntingly large -- enough to hire a bunch of people, and push Querki through to a serious launch. The process is a bit of a black box, and that little voice in the back of my mind is going, "Doomed, I tell you! DOOOOMED!". But I'm starting to feel like I understand the resources that are available for learning the process (how's that for indirection?), and have some hope that, while this isn't ever likely to be easy-easy, there is some hope of achieving not-Doomed in the foreseeable future...
jducoeur: (Default)
[For the programmers]

Here's a delicious little security alert about a vulnerability in eBay, which potentially allows malicious vendors to steal your eBay credentials and such. I recommend reading down to the details -- the JSF**k hack itself is kind of brilliant.

The moral of the story is that any time you see the phrase "code validation" in the context of JavaScript you should worry. Trying to make sure that code isn't going to do anything malicious is almost arbitrarily difficult. You should either allow JavaScript -- in which case you better make sure you have a way to sandbox it and you understand all the possible attacks -- or forbid it outright. Unless you understand the problem *very* deeply, I recommend the latter.

(This is why Querki only allows a subset of HTML and CSS. A large subset, but we intentionally disallow any approach I can find that might allow JavaScript in. In some ways this makes me sad -- it limits the flexibility of the system -- but security is the higher priority...)
jducoeur: (querki)
  • Time to track down the bug: 3 minutes

  • Size of the fix: 1 line

  • Time to add enough pieces to the new test harness to *validate* the fix: 8 hours
It's necessary, and it'll pay off in the long run, but *man*, I had forgotten what a pain in the ass it is to build a good Selenium-based harness. On the plus side, this little fix required adding a lot of the critical pieces -- enough to express several of the common Querki operations as one-liners...
jducoeur: (Default)
[For the programmers -- this is a pretty technical intermediate-level "mistakes to avoid" lesson. Likely useful to folks who are learning programming, and ruefully amusing in a headdesk way to the experienced programmers.]

Today's fire-drill for Querki was a bug report (from [livejournal.com profile] alexx_kay, who has my deepest thanks for pointing it out) that, under certain circumstances, his browser window was hanging. Not showing an error, not popping up alerts -- just becoming completely unresponsive. There was a 30 minute hunt to figure out what the heck was going on, and a quick release to get the fix out. Here's what happened, and the lesson to learn from it.
Click for the sad details )
jducoeur: (Default)
Okay, here's a curious question: what sets of gender-neutral pronouns do you prefer?

The thing is, I'm writing LARPs in Querki nowadays -- that was the original motivation for the system (a dozen years ago), and while it's now only one use case among many, it's one that matters to me. In preparation for talking it up a bit at Intercon, I'm starting to get a first-draft LARP App ready, so that other folks can use Querki for LARP writing and management.

Gender has become a fairly hot topic in the LARP community: many people prefer to write relatively gender-neutral, not actually assigning genders to many or all of the characters until relatively late in the process. I tried this out myself for A Respectful Calm last year, and it was a fascinating exercise in pushing through my own assumptions: in the end, I would up with five "hard-gendered" characters, and 24 neutral. (That is, five characters were intrinsically gendered by the nature of their stories; the rest were left neutral until after casting.)

In order to do that, I had to create a way to write in a gender-neutral fashion in Querki; I did that by adding functions for the various pronouns. So for example, if you are writing in the context of a Character, you would say [[sie]] to mean "he or she". This works quite nicely in Querki -- a character sheet can refer to, say, B Ari (the CSI investigator) by pronoun as [[B Ari -> sie]], and that will become "he" or "she" depending on the final gender assigned to the character post-casting. Or in the Who You Know section of the character sheet, where any given entry refers to a specific character, you can just use [[sie]] and it'll interpret it appropriately. (I also added some special magic sauce in Querki to match case: if you say [[Sie]], it'll come out as "He" or "She".)

Of course, you can also leave the characters ungendered, and it'll just use the gender-neutral forms directly, but in my experience that's pretty unusual. Or you can completely ignore this whole mechanism and write in the traditional pre-gendered way -- this is more about allowing gender-neutral writing than requiring it.

It was an experiment, but I found that, once you get used to it, it becomes fairly natural. And the exercise changes the way you *think* about the characters, which opens up more design space: I found that there were a lot of characters where my original mental model had been for a particular gender, but in practice they worked fine (if, often, with subtly different culturally-influenced connotations) with the other. Indeed, about a third of them wound up cast opposite to my original expectations, and they worked well. It was quite refreshing.

But the thing is, I pulled the actual pronouns out of my ass. I used "sie" because it's the he/she I've come across most often, but wound up skating out onto thin ice as I figured out the rest of them. I wound up with:
  • Sie -- he / she (subject)

  • Hir -- her / him (direct object)

  • Hirs -- hers / his ("this thing is hers / his" -- I don't even remember which part of speech this is)

  • Hirp -- her / his (possessive -- this one was when I realized I was out of my depth)
The underlying mechanism is flexible, so folks can add their own variants if they like, but I'd prefer that the upcoming LARP App be based on the best consensus I can come up with.

So -- what set of gender-neutral pronouns do you think is best? Any particular reason, or just personal taste? I've found that I needed at least the above four parts of speech in order to write a complete character sheet, so I'm looking for suggestions that include all of them; I'm also quite open to more-complete sets. Also, to be useful, each pronoun must be at least as distinct as their standard gendered variant, since the point is to be able to translate these into their gendered forms automatically.
jducoeur: (querki)
Today's project is starting to implement Multiple Choice. (AKA enumerations.) The concept has existed for a long time, but it's a manual PITA to create a multiple-choice Property, and I'm tired of it, so I'm turning it into a proper Type. That's complicated, but so far well in hand.

But as part of it, I've been staring at all these places that are using the Link Type, which is the underlying basis of Multiple Choice. Link is *the* most important Type in Querki -- it's a reference to a specific Thing, basically the equivalent of a "pointer" in most programming languages. (Multiple Choice is implemented as a Link Property to a particular Model, whose Instances are the options to choose from. That's very powerful when you need the power, but like I said, a pain in the tuchus to build one; time for a proper wizard that hides the details of what's going on for the common cases.)

Anyway, I am suddenly realizing that "Link" is also a terrible name. Specifically, while it is *technically* quite accurate, that accuracy is mostly irrelevant: the pointer gets auto-dereferenced in almost all circumstances, so the fact that it *is* a pointer is rarely useful to the end user. Mostly, it's taking brain space for no good purpose -- as far as the user is concerned, it's just a Thing. So I should probably change the name of the Type.

I can't just call it "Thing" -- that's already the base Model for the entire Querki universe, and is quite central -- but I'm tempted to use "Something". That's vague, but that's kind of the point: when you're referring to a value of type Something, it can literally be any non-primitive value in Querki. (Including Properties, Types, People and so on.) In practice, you can restrict the Model that a given Property can point to, and we'll eventually enhance the functions to preserve this typing in the code -- basically implicit generics -- but conceptually, it's just "Something".

The vagueness kinda bothers me, but I don't have a better idea yet, and it seems to relate in an appropriate way to the concept of "Thing" -- a value of type "Something" contains one or more Things. Opinions?

Profile

jducoeur: (Default)
jducoeur

August 2017

S M T W T F S
  1 2345
6 789101112
13141516171819
20212223242526
2728293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags