Previous Entry Share Next Entry
Release 1.3.15
jducoeur wrote in querki_project
Today's release is terribly important for a reason that is mostly not user-visible: Querki is now running on Amazon Web Services.

Since the original prototype release at the beginning of 2013, Querki has been running on a single server, running in a local colo. That's worked decently well for us -- indeed, it's been comforting to see how well the system works in a pretty antiquated server -- but it's never made any sense for a real production environment. In particular, it's been the reason why I've been keeping the beta locked down: while we were using only a fraction of that server's resources, I haven't been sure how many users we were able to support, and we had no good way to scale beyond whatever that limit was. So if we grew too fast, we would be screwed.

Now, we're running on a three-node virtual cluster. That's essentially invisible to you, but crucial for scalability. Since these are virtual machines (and fairly small ones to start), it's relatively quick and easy for us to "grow" them as needed, and to add more machines to the cluster. Querki was designed for this from the beginning, so in principle we should be able to easily grow the system as the usage grows.

We've done a fair amount of testing in this new configuration, but there's always the possibility that we've missed something. So if you find anything that's now broken, please bring it to my attention ASAP: the goal here is that Querki's new home shouldn't matter to you, except in that the system should be more reliable, faster and more scalable going forward.

On to the more user-visible stuff, which is mostly UX-centric:

Enhancements and Features

_QLButtons and _QLLinks now have a "thinking" icon: I've gradually been evolving a best practice, that big and complex pages (such as the main Period Games Rules page, which can take a while to display) should show their sections behind _QLLink or _QLButton. But even those sections can sometimes take a couple of seconds, and a couple of seconds is a very long time. So these buttons now display a spinner icon while they are "thinking", to provide some basic feedback.

All external links now open in a new tab/window: this basically brings Querki in line with the way most modern systems work. "External" means all links outside of this Space, including links to other Spaces. Note that this applies to both QText-style links and explicit <a> tags. I believe the new behavior should be as expected, but please give a yell if you find weirdness. (Also, we're now more consistent that all external links are marked "nofollow", to prevent link-spam and keep Google happy with us.)

_refs can now be used without a Property: historically, you can use _tagRefs either restricted to a specific Property or not; if not, it shows *all* tag references to this. However, _refs required a specific Property. It has now been brought in line with _tagRefs, at least to a limited degree: if used without a Property, it will produce all "hard" (Thing-type) references to this Thing through Properties that are Restricted To this Thing's Model. More importantly...

Added the _allRefs function: I've come to the conclusion that the distinction between _refs and _tagRefs is mostly artificial from your point of view -- usually, you want both. So while I'm leaving both of them in place, I've added a new _allRefs function, which combines exactly the results of both of those. I recommend using _allRefs in place of _refs and _tagRefs unless you specifically want to limit your results.

The default Default View now includes a "Things That Use" button: one of the goals of the system is that the most-needed functions should be at your fingertips, without needing to write QL. I've found that the single most common need for QL is to find out what points to the current Thing. So that's now built in -- if you haven't created a Default View, you'll find a new button in place that, when pressed, displays the _allRefs for this Thing. This makes it easier to navigate your Space without writing any QL.

If a Comment and everything below it is deleted, simply don't show it: we currently lean towards showing "Comment Deleted", for the same reason many other systems do so -- if you completely delete a comment in the middle of a conversation, it can deeply mess up context, and even produce socially-disastrous misleading results. That makes sense, but it meant that, if you post a comment in error and then delete it, you get an annoying tombstone that you can't get rid of. So we now examine the situation: if there is nothing *below* the deleted comment, we don't even display it any more.


QL can now cope with empty List Literals: I found that, if you tried to display a completely-empty Location, with none of its fields filled in, you would get an Unexpected Error. The underlying cause turned out to be that, if you tried to show a List Literal and all of its components came out empty, it would crash the QL processor. This now simply produces empty, as expected.

Fixed the menu bar at ~900px: alexx_kay pointed out that, on his tablet, the menu bar at the top was displaying as two lines, and obscuring the stuff below that. This turned out to be a Bootstrap styling issue: if the screen width was between 750 and 992px, it would have this misbehavior. I've hacked around this by disabling Bootstrap's fixed width for that bar. It's not a perfect solution (you can still get the two-line problem if the bar gets completely filled up, and I don't love the current styling), but it's an improvement for now.

Related to that: the menu in the upper-right no longer says "Logged in as", simply to save pixel width. It just shows your login name now; that brings us in line with many online systems, so I think it should be okay.

  • 1
"(Also, we're now more consistent that all external links are marked "nofollow", to prevent link-spam and keep Google happy with us.)"

I'm mostly uninformed on this issue, but this strikes me as weird. If something *is* link-spam, then yes, google would rather not follow it. But if it's *not* link-spam, but a legitimate link, aren't you keeping useful data from Google? (If the answer is "it's too complicated to explain in a comment", that's fine.)

Short version is that I have no easy way of distinguishing link-spam from pork, and Google gets *very* cranky about this nowadays. They are quite explicit that, if you run a user-data-driven site and you *don't* use nofollow, they will punish you for it.

So for the moment, I'm going to be simplistic about it. Internal links are okay. (Not terribly useful quite yet, since our robots.txt tells Google to go away, but that should change soon.) But external links all get marked nofollow until we can figure out a more sophisticated approach, so that we're simply not useful to the SOE vendors.

(If you have a clear algorithm for distinguishing spam, I'm all ears, but I can't think of a good way to do it...)

Congrats! I know what a big deal it is to move an entire service over from one infrastructure to another. And to change your billed costs from simple to... well, more exciting. Hopefully this also provides you with developer flexibility in being able to spin up and down testing and dev environments.

Thanks -- yeah, the costs are going to be a source of entertainment, and it makes everything quite a bit more real. (We're going from one box and simply paying $70/month for hosting, to a non-trivial cluster over at Amazon that is going to cost something like an order of magnitude more.)

  • 1

Log in

No account? Create an account