Overview over all blog items

We are happy to announce the availability of the EuroPython 2014 schedule containing the dates and times for trainings, talks and sprints.

If you want to participate in a training then you have to register for this particular training on the training detail page. Every training is limited to 70 participants. All trainings seats are available on a first-come first-served basis. So please register your training participation in advance and as early as possible.

The schedule will see future updates related to EuroPython side events, sponsored talks, talk cancellations etc. 

This is a short reminder that the regular ticket sale for standard EuroPython 2014 tickets ends on 23/06/2014.

After 23/06/2014 you can only purchase tickets for the (higher) on-desk rate.

So hurry up.

It's done.

It only took almost 18 months to move all of my company and personal sites into one Plone version with one look & feel.

  • www.zopyx.com
  • www.zopyx.de
  • www.produce-and-publish.com
  • www.produce-and-publish.de
  • www.andreas-jung.com
  • www.andreas-jung.com/blog
Yes, of course it uses Bootstrap. Bootstrap 2...well, time to migrate to Bootstrap XX sometime in the future :-)
Life is a never ending migration...take care....

I apologize for another Plone rant but the following issue costed my some nerves and customer money.

We are currently leading a large Plone 2 -> Plone 4.3 + Dexterity project and we are using plone.app.event. 

According to every documentation and knowledge about Dexterity we created our events in our migration script using

event = invokeFactory('Event', ..)
event.start = datetime(....)
event.end = datetime(...)

We all learned that you can set/get the value of a content-type directly through attribute access. Unfortunately those events resulted in a broken view.

It turned out that you can not modify the start and end properties of an Event instance directly but instead you have modify then through a behavior:

from plone.event.interfaces import IEventAccessor
acc = IEventAccessor(event)
acc.start = DateTime()
acc.end = DateTime()

But how bad is this? First, no documentation but much more worse: do I have for every single content-type and for every property the way how to modify it? Do I need to figure out if access attribute is the way to go or some other way (like through the behavior interface)? This approach is completely absurd. It is completely absurd for 1.X release. It is completely absurd having to teach this people developing with Plone without in-depth background. Wasn't Dexterity invented with the goal for making programming content-types in Plone much easier? Now this!? You guys are serious?

We just earned a larger Plone 4.0 project where the majority of the code appeared in a very bad shape  - basically a summary of all coding mistakes you could do. While trying to migrated the codebase to Plone 4.2.6 we figured out that rendering a simple read-only view of an Archetypes based content-type caused a ZODB write operation of 3-4 KB each time. Inspecting the code of the content class did not directly reveal any pointer to the problem. The methods called during the rendering of the 'view' view did not assign to 'self' - so there was no obvious reason for any badly written code. But how to track this down?

A good start is the troubleshooting section of the Plone documentation - in particular the usage of the debug.py script at the end of the page. Looking at the latest transaction of the ZODB showed us that the transaction is really caused by the 'Artikel' content-type that made us suspicious. But the output of debug.py did not reveal which attributes of the persistent 'Artikel' instance really changed.

The solution is to look into the __setattr__() calls of the related object. So I added a custom __setattr_() implementation to the content-type 'Artikel':

class Artikel(ATDocument):
    def __setattr__(self, k, v):
        print k,v
        return super(Artikel, self).__setattr__(k, v)

This __setattr_() implementation would be called for every change of an attribute on the 'Artikel' instance. Re-running the instance and re-rendering the object produced the following output:

_p_serial ���:S��
_p_estimated_size 3634
__provides__ <zope.interface.Provides object at 0x7f150caad490>
__provides__ <zope.interface.Provides object at 0x7f150caad490>
_p_serial ��v(w
_p_estimated_size 3301

The _p_ attributes are internal attributes used by the ZODB - they appeared normal however there were also changes to the __provides__ attribute of the instance. This happens usually when you attach a marker interface to a persistent object using alsoProvides(). So we grepped through the code and found this:

def get_average_rating(self):
     alsoProvides(self, IUserRatable)
     adapted = IUserRating(self)
     return adapted.averageRating

def get_rating_count(self):
    alsoProvides(self, IUserRatable)
    adapted = IUserRating(self)
    return adapted.numberOfRatings

Both methods are called during the rendering of the 'view' view and with every call it re-attaches/modifies the IUserRatable interface to the instance of the Artikel.....BAD BAD BAD.....moving the code to a place where is is called only once per object resolved the issue and the ZODB bloat.

Jan 31, 2014

EuroPython 2014: Early Bird ticket sale starts on Wednesday, 05/02/2014

A limited number of EuroPython 2014 tickets will be available from Wednesday on for a reduced price.

We are pleased to announce that the EuroPython 2014 ticket sale will start next Wednesday, 05/02/2014 with the Early Bird ticket phase.

There is a contingent of 300 tickets that will be sold to a reduced price in three categories:

  • Business
  • Personal
  • Student

If you are a student and want to get the student discount, please email a copy of your student identity card to helpdesk@europython.eu once the sale has started.

An email prior the to sale start will not be considered. The requests will be processed in the order they are received.

Jan 21, 2014

Produce & Publish cloud conversion service available for beta testing

The service provides a free conversion service for office formats.

I am happy to announce that the Produce & Publish cloud conversion service is now available for free for beta testing.

The conversion service is build on top of the and provides transparent access to all conversions supported by the underlaying OpenOffice/LibreOffice implementation.

The service can be used from arbitrary programming language. However we support only the native Python API as provided through the Produce & Publish Python Client Connector at this time.

The service can be used directly from the command line or through the Python API. A more detailed documentation can be found here.

For the time being this service will be provided for free and without restrictions. The only requirement for the beta phase is an access token that you can get for free by sending a short email to info@zopyx.com. The service is only accessible over SSL/HTTPS and is configured using a decent SSL/TLS configuration ("A" rating from SSLLabs).

We relaunched today the international/english version of our Produce & Publish website.

The Call for Proposals for the EuroPython 2014 conference in Berlin is now open!