Problems in the caffeinecirculationsystem

Today I committed last modifications to Plone Finnish translations to Plone collective. Overall there were quite a lot of things to translate as Finnish translations were reviewed last time over 2 years ago when Plone 3 first time appeared. Plone has developed quite a lot since that and 3.x branch has had missing translations for Finnish users far too long (and still has - I made translations for the 4.x branch only). One thing what troubles me is that I'm not entirely happy about all the translations I made. For some words I found it damn difficult to try find the same - or at least almost the same - expression from Finnish dictionary. The expression power of our language isn't just there yet and trying to browse how people have translated same words in other projects proved the case. There just aren't Finnish equivalent words for the certain English words. What those difficult words were then? Here's few ones popping in my mind: commit, checkout, revision, portlet.

Since we splitted our one huge Plone site to several smaller ones we've been looking for the correct procedure to keep things running smoothly and to make updates as painless as possible. So far we haven't found the right way and every update has had some problems. Some of the problems are related to the fact that we have about 24 sites to maintain and adding a new content type to all of them means lots of work. Below are all the steps needed for update (and solutions we've founded so far). 1. Add your new product to buildout.cfg eggs and zcml list. Do this 24 times and you'll find yourself thinking there has to be better way. Luckily there is; you can extend your buildout.cfg with some general config file (eg. deployement.cfg). Most tutorials describe a way where you have those two files living side by side in filesystem and you run buildout with -c deployement.cfg option, but this doesn't remove the actual problem. We have our deployement.cfg living in diffe

Nice summary about Kanban and Scrum. http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf ..and to make things less serious: http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

I recently had situation in work where I needed to update several of our Plone sites with few addon products. So far we haven't thought how we'll manage our sites update story as we've basically just recently entered to the amazing world of buildouts and several Plone-sites instead of one huge plone-site with zeo. Gotta say I had few ideas popping in my head when I was manually running buildout scripts for each of our sites and stopping and restarting them after buildout was completed. My first though was to just simply write some script which does the job and then I was already imaging some web based service so we could manage our sites buildouts ttw. Well.. that might be a bit overkill.. at least for the starters, so I went back to roots and wrote a small python application which does the job. Basically it just takes the list of buildouts and runs buildout-script with -Nv parameters and restarts the site. Source code is below and in the github . #!/usr/bin/python2.5 from

For some reason I've always had problems with python-ldap and openldap with Plone when I'm using Ubuntu. I've always managed to solve the problem by somehow building openldap from sources and been happy ever since. Now with fresh Ubuntu install I bumbed once again to the same problem and decided to write a reminder how I get things working again. This time I used Panyasan's buildout example with one extra environment line. Without that line openldap won't compile on ubuntu. Instead of compiling succesfully it throws me an error "ubuntu getpeereid.c:52: error: storage size of ‘peercred’ isn’t known" Here are the important parts: [buildout] parts = zope2 productdistros instance zopepy openldap python-ldap ... [versions] python-ldap = 2.3.6 [openldap] recipe = zc.recipe.cmmi url = ftp://gd.tuwien.ac.at/infosys/network/OpenLDAP/openldap-stable/openldap-stable-20071118.tgz extra_options = --with-sasl --with-tls --enable-slapd=no environ

1. Migrating is fun fun fun! Let's face it - migrating Plone site from old version to new one can be either painful or very painful experience. If you need to do it for one site only, you don't even get the reward of the fact that second time will be so much easier. Third time you'll start wondering what was the hard part in it. This post is intended to be description how we did plone migration from older version to new one with big, live and heavy traffic site . We're still middle of migrating rest of our sites and therefore I'm going to upgrade this description when I'm having more time. Also note that this is written with one go from memory and as doing the migration is quite complex thing to do including many tasks there might be some errors. I hope this gives some ideas to others struggling with the same topic and also raises some discussion why this is so complex to do when it shouldn't. I'm also happy to get comments how we could have done this be

CMS Wire recently posted a light weight comparsion of open source CMS and their multi-site management capabilities. According to article none of the three popular CMS ( Plone , Drupal and Joomla ) include multi-site management in their core CMS. Article was more about third party addons and what they have to offer for multi-site management needs. Six Feet Up companys Lineage -product shines on this comparsion with it's easy to use separation of certain folder inside Plone site as independet site with certain users, workflows, theme and navigation. Although Lineage is already released it still has some dependencies which are not met with Plone 3.2.1 (but should be in Plone 3.3), so installation needs some additional lines to buildout. You can find more information from Plone Software Center . In the Plone-sites we're developing and maintaining, we've traditionally wanted to keep sites theme pretty much the same within all different departments and faculties. With Lineage