Zope

On behalf of Gogo I take the opportunity to announce here the artSprint ]a[ 2010 to be held at the academy of fine arts in vienna. Any topic from Python over art to rocket science is welcome. Currently planned are topics in the cloud of Python, UML ... [More] , node-trees, HTML-forms with YAFOWIL, Pyramid, recurring events in Plone, we may start an Arduino microcontroller playground (beginners level), small art exhibition and if you have an idea -> come and bring it with you. When? January the 31st (Monday) to February the 4th (Friday). More Information? -> http://www.coactivate.org/projects/artsprint2011 - Join us! [Less]

Some folks don't use debuggers.

Diazo theming is fast We recently started an upgrade to Plone 4 of our website. After few days everything was done except the theme. To avoid delays and get our website up and running as fast as possible we decided to go with XDV/Diazo since we ... [More] already used it for a python e-commerce and Plone with a shop. We took our old theme and converted it to a static html/css and applied some simple rules. Within couple hours we had a Diazo theme that looked the same as before but we did manage to add some mobile css.   Lessframework - CSS3 and HTML5 To learn some CSS3 and mobile skinning we tried out the Lessframework project. A simple CSS3 and HTML5 project that shows you how to define different stylesheets for different resolutions.We also looked at mFabrik but it didn't fit our timeschedule this time.   Diazo/XDV is getting adopted We wanted to write more about how we did the theming here but Aclark.net beat us so we'll just link to them :)   Time to rethink the web After reading the excellent presentation by Bryan Rieger. We already know what other steps we need to do to make our website mobile friendly. This presentation tells us that the mobile internet is much bigger then iPhone and Android, it definitely convinced me that my argument "the other mobile users do not use internet" is wrong so our ecommerce solutions will be ready for the mobile industry.   Do you want Plone 4 site or a mobile solution? Contact Sasha Vinčić at +46708 840 660 or online form. [Less]

The WebLion team is organizing the annual Plone Symposium East 2011 at Penn State in State College, PA (USA) and has announced the following dates  for the symposium as well as training and sprints the same week. Training May 15-17Symposium May ... [More] 18-19Sprints May 20-21 The event includes talks, training, and sprints and is intended for decision makers, developers, integrators, website administrators, and content owners. One of the event's major themes is Plone in education. They've also opened the call for proposing talks and training at the event. Everyone interested is invited to make a proposal. More information will be posted on the Symposium East 2011 website as it is released. [Less]

We’re from the world of Zope and Plone, so we have a long history on the topic of frameworks and pluggability.  We’ve helped foist the good, the bad, and the ugly on large populations of developers over the years.  So we’re continuing to learn the ... [More] right balance on frameworkiness. Chris wrote a very good email yesterday on the Pylons mailing list on the topic of Pyramid’s pluggability story.  The “Pylons Project” wants to have a story over the long haul.  But we’re still in the mode of thinking, learning, listening, and then building. To summarize Chris’s note (at least from my POV): Pyramid provides a pretty attractive extensibility story for application developers. Pluggability is harder, because a plug-in will need cooperating systems (storage, authentication, etc.) and Pyramid isn’t going to have opinions on all that. Your application will have opinions, though, thus you can provide plug points built with Pyramid’s extensibility story. A plugin-story’s success is directly related to the ruthlessness of the decisions and opinions being made.  The more you define the surface area by making the choices, the more viable the plug point.  Over-generalization is the enemy. The Pylons Project would like to make an application on Pyramid that has opinions, provides higher-level services, and thus has a strong plugin story. At the end of the day, the Python world has a lot of great alternatives already for web frameworks.  Anything new that tries to emerge needs fresh ideas.  I feel like extensibility and pluggability are still areas ripe for new thoughts. While many might want less (e.g. single file microframeworks) but there might be a constituency for those that want more. [Less]

I’ve wanted for a while to write an introductory piece on Pyramid.  That is, how to use Pyramid to do a style of development that I find very simple and intuitive: traversal and ZODB. Alex Marandon wrote exactly the article I wished I would have ... [More] written.  He doesn’t presume you know Zope.  He then takes the (from my POV, super-easy) ideas of traversal and persistence, and introduces them in a simple, obvious way. [Less]

There have been questions about JCR vs CMIS recently (Is JCR Dead?), and I thought I'd expand a bit on why we at Nuxeo decided to drop support for JCR. Nuxeo used JCR in the past with great success; we've been on the JSR-170 and JSR-283 Expert Group ... [More] and it is a very nice spec. Several versions of our Nuxeo EP framework used Jackrabbit as a content store. However for some time we've decided to not rely on it solely, and for more than two years, since Nuxeo 5.1.6, we've had an alternative storage engine, the Nuxeo Visible Content Store (VCS) (http://doc.nuxeo.com/display/NXDOC/VCS+Architecture). Since Nuxeo 5.4 VCS is the only content store, and it's optimized for all the things we require of it. The reason why we wanted an alternative storage, and why we now rely exclusively on it instead of maintaining costly compatibility with a second storage engine, is that Jackrabbit had a number of limitations: Opacity of the in-database storage. We wanted data stored in a SQL database to be real SQL tables with visible data. This is helpful for many things, be it imports, backups, debugging, etc. While the goal of JCR to be the "SQL of content" is noble, the reality is that all our customers want data to be in a SQL database, not in something they don't know. We had had previously the same problem with Zope and its ZODB btw. Serializing Java objects in database columns is really not our idea of a clean storage. Limitations of the relational model. We wanted to be able to express arbitrary relational queries between objects, and the Jackrabbit query implementation, based on Lucene, really didn't allow for that, or not with adequate performance (see point 3. below also). There was a lot of work trying to optimize that in Jackrabbit, but I only saw it as a futile exercise in reinventing SQL JOINs and the tens of years of work behind current implementations of the extremely intelligent planners and optimizers of successful SQL database engines. Performance. There were also unresolved performance problems with nodes containing a huge number of children, inherent in Jackrabbit's way of storing children information. I haven't kept up with the latest Jackrabbit releases but at the time this was killing us, and there was no simple fix available. Over-strict versioning model. The JCR versioning model is fixed by the spec, and does not allow for instance for small changes of metadata on versions that were very useful to us, like updates to the number of readers of a doc. Needless dynamicity. An important credo of JCR is that you can have "free-form" content, and can add or remove properties to nodes anytime. While this is in theory a great idea, and may appeal to the WCM-inclined, it also has a large performance impact, and is really not something that any of our customers want in their databases. Customers want well-defined and fixed schema. DBAs want to know beforehand what the tables will look like. Now, Nuxeo VCS can of course add or remove fields in its schemas, but it's an administrative step, and is not done in the normal course of an application's life. But the cinch really was the first point, a proper SQL representation. At the lower level the VCS architecture really resembles the JCR concepts of nodes and properties, but it stores them cleanly in tables (see the above URL for a description). For a time we considered overlaying a JCR API on top of it, but that has not proven necessary because there was little customer demand for it, and because we have a higher-level document abstraction that hides this anyway. Now that CMIS is getting recognition, we believe it's a better way to expose a document store than the Java Content Repository API. We are on the CMIS Technical Committee, and we now have a CMIS interface on top of Nuxeo (http://doc.nuxeo.com/display/NXDOC/CMIS+for+Nuxeo), about which we're very happy. [Less]

A postmortem of a set of poor API design choices in Pyramid.

Another turgid and self-serving entry about the Pyramid web framework; this time about design and implementation decisions related to optimization.

2010 has shaken off its mortal coil. It has gone the way of the dodo. Time to take a good look at my weblog statistics after yet another year of blogging. I started keeping track of the amount of writing I did two years ago or so. ... [More] Measuring something is knowing it (it sounds much better in Dutch: meten is weten). Writing is important for me. It helps me collect my thoughts. It helps me think things through more. And, importantly, it allows me to give back to the community: open source gives me a lot and by writing about it I get to do my bit to give something back. If writing is important, I've got to keep at it. One entry a month isn't good enough. On average, I write some 100 entries per year, so about one every three or four days. So I keep an eye out for those statistics, to see if I'm slipping. I'm a bit disappointed at not making the number I made last year: 94 instead of 130. So I've set myself a preliminary goal of... one post per day. I'm totally unsure if that's feasible, so I'll see how far I manage it in January. Here's to lots of python, django and cycling posts in 2011! [Less]