Plone Konferenz: Day 3

This presentation attempted (and in my opinion succeeded in) making the case that an entire web application can be built in Javascript. At this point, I am not too hard to convince anymore. As Philipp von Weitershausen demonstrated at the 2011 Plone conference in San Francisco, Javascript is plenty fast, so no concerns there. Daniel also claimed that the error logging problem can be solved with some tools that send log events back to the server (did not write down names). Javascript quite naturally allows teamwork with a separation of concerns between people working on the templates, the CSS and the scripts. Of couse, there is JSON to handle sending data back and forth between client and server. One thing Daniel did not talk about is the server side, and that's about my only complaint. He also touched upon compression of HTML, CSS and Javascript. And he mentioned A/B testing for interface design.

The whole presentation was based on the experience Daniel gained rewriting an e-commerce application in Javascript, but there was no demo or details of the project.

The title may seem a bit hyperbolic, but by the time we got to the demo it became clear that it was no exaggeration. Red Turtle pulled off an amazing feat here.

I can't remember if it was the Emilia Romagna region, or the European Union that partially funded this collaborative effort between Red Turtle and two other local companies. The premise was: we use a lot of different tools to fulfill our project management needs, but there isn't a single one that does it all. So we are going to have to build it. But why reinvent the wheel? Just use all the tools we currently use as components of a "mega mashup".

Pyramid for main application, good support for third-party authentication thanks to Velruse. The Pyramid admin UI is the glue that holds everything else together, with one common page frame for Plone, Trac, Google Apps.

Plone for SSO, intranet and knowledge management, easy to integrate with Pyramid and Trac

Trac for bug tracking, flexible reports, supports WSGI, easy to integrate with Pyramid, using a few plugins

Google Apps, oauth, scheduling, document management.

Twitter Bootstrap: CSS framework. This allowed to build a beautiful UI with progressive enhancement out of the box.

It was amazing to see in the demo that through Pyramid all the components could use each other's data.

I have a few misgivings about this one. For one, the sound volume was so low that I could hardly hear the moderator or the two contenders, and my jetlag-addled mind took that as a cue to seek some sleep whenever it could. For the other, I had never really heard of TYPO3 before, and I doubt I will in the US, so that too contributed to my interest being fairly sluggish. On the other hand, the idea was good, and since TYPO3 is a very popular LAMP-based CMS in Germany, everybody else seemed to be really into it. It might be interesting to do a "shootout" between Plone and Drupal in the US. TYPO3 seems to have a pretty powerful backend UI, with what looked to me like a Deco-like drag-n-drop tile based layout system. Timo scored a point and a round of wild applause when he demoed Diazo to instantly "steal" the TYPO3 skin and apply it to an OOTB Plone site.

Prof. Helmbrecht is the director of Enisa, the European Network and Information Security Agency. And Enisa uses Plone. His talk was pretty interesting, from a perspective of how an agency such as Enisa has to look forward to all kinds of emerging threats. E.g.: cloud computing: governments may not want to put their sensitive data, or the sensitive data of major national industries, in the cloud if there are no guarantees that the data will not get stored in datacenters outside of its borders, especially in a country that could potentially become hostile. But on the other hand, the economies of scale that make cloud computing possible would break down if such restrictions were to be imposed on it. In the end, any unrealized risks might at some point in the future become reality, as the botnet and stuxnet cases proved. Then there is social networking, and the risks involved in mobile apps and HTML5.

He also talked about how most of the advisory reports produced by Enisa are put together by teams of independent experts, and some discussion arose at the end around the question of putting a Plone community member on one of those committees. We could certainly contribute a lot, and so it seems like a good idea.

I feel it was a very smart strategic move on the part of the Konferenz organizers to invite Prof. Helmbrecht to keynote for us.

Open Spaces

I joined the open space that picked up where yesterday's left off.

In the spirit of making things easy that should be easy, and after realizing, as a group, that there was no consensus or even clarity on how to duplicate a content item, it was decided to start writing a wrapper API that would allow to accomplish some common tasks with one simple (and easy to remember) method call.

We discussed various approaches. In the end we decided that what would make things the easiest would be a PHP-like API for about 20 of the most desired tasks, and not to worry that it may not be "pythonic". Treating objects like python dicts (e.g. a User) would cause significant complications (e.g. a User could be an ACL object, an LDAP user, or a membrane user, each of which has to be treated differently), and we don't want to have to cover all possible cases. We also thought that our API would be split into two sets: one set that will simply be the "easy" and "recommended" way to do things from now on. The other that would only be around as long as the thing it's trying to work aorund is fixed for good, and would subsequently be deprecated.