Zope

Read and review Python Testing: Beginner's GuideGrok 1.0 Web Development for Packt. (The links are trackable to my blog, but I'm not getting anything out of it. Other than free copies of the e-books, which I already received, in ... [More] exchange for a promise to review them on this blog.) Help folks set up continuous integration (most likely , while powerful, has a steep learning curve). Think about becoming the buildbotmaster for Zope. Originally I intended to volunteer to set up a few buildbots for various Zopeish projects (ZTK, BlueBream, Grok, Zope 2) since half of the existing ones were down or broken. Then various people fixed some of the broken ones and other people chimed in mentioning existing buildbots that nobody else knew about. There is a need for somebody to coordinate all this activity: make sure we have up-to-date test results for all kinds of projects, aggregate them in one place, chase up build slaves for exotic OSes (i.e. Windows)... I don't think I'm well suited for this kind of organisational activity. Push along the various scratch-my-itch open source projects (, ). No idea what, but I've been wanting to do something for . Something small, given the copious amounts of free time I have. Then there's the paying work. On the plus side, there are opportunities for fun there (today I slashed functional test run time by a half, by adding a small caching decorator in front of a single function. and rule!) You know what, scratch the Zope buildbotmaster idea. Maybe I can do something technical there, e.g. a cron script to ping the various buildbot, scrape HTML/parse emails and aggregate build results. Maybe. I hope I don't get again. Because that would suck. Again. Been there, done that, didn't even get a T-shirt. I really ought to read Getting Things Done. Reading it has been on my todo-list for [Less]

---

On Tuesday we started what will hopefully become a tradition: weekly IRC meetings for Zope developers. Topics covered include buildbot organization and maintenance, open issues with the ZTK development process, and the fate of Zope 3.5 (= BlueBream ... [More] 1.0). to the mailing list. My take on this can be summed up as: Zope ain't dead yet! The project has fragmented a bit (Zope 2, Zope Toolkit, Grok, BlueBream, Repoze), but we all share a set of core packages and we want to keep them healthy. Next meeting is also happening on a Tuesday, at 15:00 UTC on #zope in FreeNode. [Less]

There was a short zope-dev meeting on #zope today. I'm not a zope-dev, but after they were done, I asked a question^W^W^Wgriped a bit about the new "eggified" Zope 2.12 install procedure. A big discussion ensued. I learned / noticed a couple of things:

It's been busy month for the Plone community as events filled up the 2010 calendar, the Plone Foundation announces its newest members, and the final alpha release before Plone 4 moves to Beta testing.

The new product collective.discussionintegration.plonegazette provides the integration of PloneGazette and plone.app.discussion.

]

---

Now there are more than .

Andrew Sawyers, Chris Shenton, Shane Hathaway, and Reed O'Brien worked on an example "BFG Cookbook" application, intended to run in the Google App Engine cloud. They succeeded in indirecting the storage of the recipe entries, with working backends ... [More] based on the GAE Big Table API, ZODB, Mongo, and an in-memory (nonpersistent) storage. Reed also worked on re-doing the Mongo-based URL shortener he wrote at last year's sprint, this time using the Ming bindings. He is working to have an example which uses none of the packaages, in order to show how BFG can be used in a variety of ways. Chris McDonough and Chris Rossi have been sprinting with the Pylons and TurboGears folks on a package code-named "Marco." Marco moves some of the dispatching logic of BFG down into a package intended to be useful as the basis for a version of Pylons: if it succeeds, Pylons and BFG would become "personality" layers on top of the shared Marco library. Tres Seaver has been working on a CMS architecture which he has been mulling for a long while now, code-named "Bonzai". The architecture decouples "asset repositories" from the "site layout" applications which consume them, imposing a RESTy service layer between the two. In reaction to the perhaps overly cute mascots adopted by a certain other nameless framework, the BFG sprint team has adopted the "flying" or "war" pig as a mascot ( [Less]