OpenCore Software

It occurs to me I never wrote about what I did for the rest of the sprint after my first couple of posts.  Mostly I spent the second half of the week floating around the big room; I didn’t really do any more long focused work after the first couple of days of pairing with Robert and Martijn. But here’s a rambling overview; sorry it’s so disorganized

KSS 

I looked very briefly at KSS, the “Ajax framework without Javascript” which lets you apply behaviors to a page with something very much like a stylesheet.  I had originally seen KSS a bit over a year ago when Whit pointed me to it, but it seems like it’s come a long way since then.

For one thing, their website is a lot easier to understand. It looks a whole lot more attractive; there’s a lot more up-front explanation of the project; and they picked a consistent name for the project.  (It’s now all just KSS; from what I remember, last year they were talking about KSS, Kukit, and Azax, and I was very confused.)  I guess nice packaging really does help.

Part of me is still wary of it but I think my reason is silly; I just have a gut feeling that it doesn’t make sense to try to bury Javascript and pretend it’s not there, and that KSS is just for people who don’t like Javascript (and I like Javascript, dammit! At least in theory) and instead you may as well leave Ajax for people who don’t mind it.  I’ll say again, though, I think this is a stupid thing to think.  Robert pointed out that it more or less accomplishes the same thing that Nick and I did with Octopus over the summer, so I’d be interested in doing a direct comparison there and seeing what one of our NUI forms would look like with KSS instead of Octopus.

Anyway, Jeff did a lot of work with KSS at the sprint, and Jeff hates Javascript, so I’m also curious to hear his impressions of it.

z3c.autoinclude

I also did some scattered work related to z3c.autoinclude throughout the rest of the week. At Martijn’s suggestion I wrote to the grok dev list about it, and there were a couple of very good suggestions that came out of that like doing better logging and exposing a convenient way to get information about what files to include without actually doing the autoinclusion, so that you could build alternate inclusion mechanisms on top of z3c.autoinclude like a build script that writes out inclusion statements to a static, tweakable site.zcml. I’ve gotta say it was satisfying and pretty exciting to be talking about my code to people I’ve never met, and changing it based on their recommendations, and hearing completely new ideas about how to use it.

Vudo

I spent an afternoon pairing with Malthe Borch on Vudo, a concept for a new content management system built in Grok with easy Jottit-style content creation and draggable, recombinable page elements. (I don’t think they’ve made a website yet but here’s a video interview from the sprint about it.) I worked with him on a custom traversal hook to create a new object at any URL that isn’t already associated with an existing object, object attribute or view. It was interesting to hear how they’re talking about implementing their system, since a lot of their desired UI sounds like things we’ve talked about too. (Jeff, I tried to find your “draggable page building GUI” blog post to link here, but I couldn’t find it, sorry.)

Gibberisch and Bullschit

On the last full day, looking for something totally different to play with, I sat down with Kai Lautaportti and Tarek Ziadé who had decided to write a random text generator. After spending about five hours trying to get started with git (which never ended up working for Tarek — though, despite all our frustrations, in the end I was sold on it at least as a branching and offline supplement for SVN) and talking about Tarek and Kai’s competing one-line generation algorithms, we had “Gibberisch”, a working library and console script that gave us vaguely plausible paragraphs using a customizable bank of sentence parts. Then Tarek started working on an alternate method while Kai and I banged out “Bullschit,” a proper RESTful text-generating web service in Grok powered by Gibberisch. (We also built an awesome demo.)

I really like the way Grok does REST, by the way: it’s ridiculously easy to create a RESTful interface to any object, and unlike Pylons or our Z2/Plone/Z3 system (the only other things I’ve really tried to do any REST with) I didn’t have to fight with it at all to get it to do what I wanted and no more — it autoset really sensible headers, didn’t set any unsensible headers, and didn’t complain at all when I overrode its convenient automation.  A RESTful interface in Grok is implemented as a distinct layer or skin, which I think is a really good idea: so to access /foo/bar RESTfully you use a URL like “++rest++mylayer/foo/bar“ — it lives in its own completely separate namespace so you can have a RESTful service and a user-facing web application sit side by side without interfering with each other.

I was originally blogging on my harddisk using emacs.  As whit pointed out, this isn’t really ‘blogging, since its not on the web.  So I wrote an app called bitsyblog (which I’ll talk more about + use later).  Still haven’t deployed it yet and really don’t want to take more sprint time to do so, though its essentially done.  So I’ll do some old fashioned xinha based blogging on our site.  Before posting several days of content I’d like to point out why I like the idea of bitsyblog (which basically blogs with a POST) versus TTW blogging.  To write this blog, I have to navigate to openplans and this blog page, which is, what a minute (so there’s no point in writing a blog if its just a quick observation, unless its really important).  Its a context switch — if I’m on the command line or in emacs, I have to quit what I’m doing to write a one-line blog.  Also, I can’t use my editor of choice.  Anyway, enough complaining, more blogging.

———————

And some more stuff.  It kinda degenerated into test posts somewhere.  I’ll probably for the time being use bitsyblog to blog locally and then do copy + paste to here.  Other than that, things are great!  Now I’m back to working on the KSS commenting app.  KSS is cool and so far I’ve learned more about JS from KSS than I ever knew before (which isn’t saying much).   But progress is slow for not knowing it more.  Still, learning, doing some demo stuff.

There’s been a lot of interest at the sprint in Grok. I’d been meaning to check it out for a few weeks now, since Robert mentioned it to me, and it looks pretty cool. It’s basically “Zope 3 on Rails” — it eliminates the need for up-front design and configuration and dramatically reduces the code redundancy of working in Zope 3, by almost entirely eliminating ZCML (instead using code conventions to figure out how to hook components together), allowing you to write and use classes without interfaces, and generally hiding a lot of the complexity of Zope 3 in favor of simple, rapid application development.

So I tried writing a toy application with Grok last night. It does a great job of “hiding” Zope 3 — it really feels very different from Zope 3 development and a lot more like working in Rails or Pylons. You just write models, views and templates and everything just works. Ironically, I actually found it kind of difficult to get very far with it; I think my brain is just used to thinking in a Zope 3 style, because I found it very hard to keep track of my twenty lines of code without formal interfaces and explicit configuration to refer to.

But there’s why Grok is so cool. Underneath it really is just Zope 3; Grok itself is basically just an alternative configuration language sitting on top of Zope 3, albeit a really impressively integrated one. So I’m fully able to write pure Zope 3 code in a Grok application using the Zope 3 standard practices, and someone else can write Rails-style code in the same application and, if they want to, can incrementally build structure and gradually insert Zope 3-isms, building interfaces around their existing classes only after the code has started to take shape and is already up and running. It’s hard to come up with any downsides.

The Snow Sprint has been great so far. Robert and I have spent most of the past couple of days pairing with Martijn Faassen on some code to autoinclude ZCML from a package’s requirements. The idea is that the ZCML directive can be redundant, since your requirements will already be specified in your setup.py’s install_requires section; there’s no need to additionally specify the inclusion of all your required Zope packages somewhere else. As an aside, this is a major part of the philosophy of Grok: eliminating the necessity for redundancy in Zope 3, particularly by getting rid of ZCML directives.

The project caught my eye at first because it’s very similar to another automatic ZCML-loading story Whit and I were working on a couple of months ago. z3c.autoinclude is intended to silently include ZCML for required packages; ZCMLLoader, meanwhile, includes ZCML for optional packages, either by looking for installed eggs with a particular entry point (so the includable packages tell you to install them) or by looking in a central config file (so you decide which packages to include). If we can get z3c.autoinclude fully working I’d like to rewrite some of ZCMLLoader to use its code; it’s easier for package developers (in ZCMLLoader I never figured out a way to make it completely invisible — your installable packages need to put in some annoying code specific to ZCMLLoader) and I could use the same test setup for ZCMLLoader, which we never bothered to figure out how to test when we started writing it.

This was very different, though: from the start, Martijn was very insistent that we do proper test-driven development. It’s a good thing he was, because we really had no idea how to test the code, since it involves inspecting eggs for dependencies and ZCML files, which meant that we’d somehow need to install eggs in our test setup. We’ve actually spent a lot more time figuring out the tests than anything else, but I’m really glad we did; the tests feel like good documentation, and when Robert and Martijn did a big refactor the other day the tests made it very easy to determine whether the code was working. I feel like it’s the first time I’ve really been sold on TDD. The pairing has been really fun too; we’ve all got pretty different development styles and even just seeing that has felt valuable, and any of us working on our own would have given up on the testing work after a couple of hours — working together on it just made it a lot more fun, and even though we were each often ready to give up, there was always one of us who felt optimistic and kept us going.

Working with setuptools wasn’t particularly easy — somehow it’s just very easy to get lost in its tangle of similar classes.  Somewhat oddly, we ended up making our package depend on zc.buildout, since it contains an programmatic API for easy_installing eggs into your working environment, which we needed to do with our dummy test packages in order to do proper testing.  The code itself is much more straightforward than the tests — given a package, it inspects each of that package’s installed requirements for conventional ZCML files (configure.zcml, meta.zcml, overrides.zcml) in their top-level packages and installs whatever ZCML it finds.

So, anyway, the tests are now all passing, with a couple of moderately complex test cases involving multiple dependencies and multiple namespace packages within a project. Unfortunately we haven’t been able to get it to work fully in a “real life” situation yet, but I think we’re close.

Martijn says setup.cfg is evil

I’m still not clear on what it does, though.