Zope

Wow, it's been 10 years already. I started with zope at the end of 99, when I was tasked to find ways to build web sites. Found zope and fell in love with python. Trawled archive.org, and I see that I was quite active back then; between 2000 and 2004weofije...

Simon Pamiés recently released notes from a talk and a tutorial he gave at the 2010 Zope Conference in Dresden. Both the talk and the tutorial are about repoze.bfg.

Hi All, New release out, this one brings compatability with zc.recipe.rhrc... This package provides a buildout recipe for creating a Zope 2 instance based around a deployment. The deployment concept originates from zc.recipe.deployment and allows ... [More] the deployment to control where resources of a particular type are created. While zc.recipe.deployment is suited to production use, you will likely find that gocept.recipe.deploymentsandbox is more useful for development. This recipe is only compatible with Zope 2.12+. Full information can be found here: http://www.simplistix.co.uk/software/zope/zope2instance Lemme know if you have any problems, comments or suggestions... cheers, Chris [Less]

Summary: last month I set up Hudson as our continuous integration server. And I constantly show Hudson's front page on a laptop in a visible location, which increased interest and usage a lot! Before... Somewhere in February, after ... [More] working here for a month, I set up a buildbot. I'm all in favour of some practical project automation. Having some machine automatically testing your code every time you make a change is one of the essentials. It also forces you to make your builds repeatable without any manual steps (so: buildout!), which is a good thing, too. Problem: it did test everything pretty fine, but almost nobody looked at it. I saw Hudson a couple of times already in some blog posts, but last May's djangocon.eu in Berlin made sure I wanted to replace buildbot with Hudson, see for instance Eric Holscher's talk. Social effects In August I installed Hudson and everyone started loving it. What did I do? I installed Hudson on our buildbot machine and configured a couple of projects. And switched off the buildbot and redirected all URLs to Hudson. I showed it to a couple of colleagues. I asked for an old laptop and got it placed in a visible location in our development room with a full screen Hudson front page. What was the effect? Highly visible. So for a few days, everyone who got into the room wanted to know what it was. Instant invitation for a demo! Most people now know that our software is automatically tested and that it catches errors from time to time. Nice visualization and nice graphs for code coverage, code neatness and overall health. Nice visualization really means you want to look at it. Highly visible if something goes wrong. You really really want to fix your broken test. As soon as something is red (especially when demoing Hudson to a visitor) they want to know who the culprit is :-) I've got pep8/pyflakes reports in there, too. So you see which code is neat. So you finally get a bonus for paying attention to your pep8 coding style. The effect? Many packages suddenly got miraculously neater. As you see the code coverage in a graph over time, the amount of tests also miraculously increased. More trust in the software. I noticed it myself when adding automatic jslint javascript checking: important, as just a single missed semicolon can throw off internet explorer in our javascript-heavy web apps. And even one missing semicolon is a flogging offense in our Hudson setup: a Red Dot... So having jslint running all the time made me feel much safer. The boss also looked at it and suggested a different picture than the boring green ball. So the "successful build" icon is now his photograph with a green halo glow :-) Talk about management buy-in... Visibility? Just when I was about to make a photograph, our sysadmin shut down the machine. "What?" "Oh, I'm just attaching a bigger monitor". Hurray! I had not even requested that and suddenly we have a nicer bigger more visible monitor. Technical implementation There are a couple of how-to-integrate-hudson-with-django-or-python tutorials on-line, just google for them. I'll just make some quick comments here: There's not only python in there! A colleague added R projects in there. You'll need to get your tests to spit out xml output. We now run our tests with the "nose" test runner by using django-nose. Next to the setup.py I added a setup.cfg with the following content, this tells nose to spit out xml: [nosetests] with-xunit=1 Cobertura plug-in: code coverage measurement. This also needs xml output. With coverage.py, you just need to call coverage xml. "Violations" plug-in: switch on 'pylint' checking for your code. I don't actually use pylint: I run pep8 and pyflakes over the code. You do need to redirect both tools' output to a text file and fix the output up a bit to match what the plug-in expects. Effectively: every line that contains [E is an error, [W is a warning. I copied someone's perl command-line for this. Pep8 is warning level, pyflakes is error level: pep8 dir_with_python | perl -ple 's/: [WE](\\d+)/: [W$1]/' > pep8.txt pyflakes dir_with_python | perl -ple 's/:\\ /: [E] /' >> pep8.txt I included the rhino command line version of jslint. An error here means the script returns with a non-zero exit code, which means a test failure for Hudson. All the above items are run in two or three script steps in Hudson. In the end I grouped everything together a bit in python scripts, btw. Hurray for Hudson! [Less]

August saw no advance on the book due to vacation time and the mad overwork period that usually follows. However, the draft for chapter two is now available on github, for those who'd like to review it.A word of warning, though. People with ... [More] experience on the ZODB will most likely find the material and tone are way too entry-level to be useful for them. That is because the audience that we will try to reach with part one of the book are Python developers in general. We assume no knowledge of the ZODB, not even of its existence.If you look at the book outline, you'll see that the book is divided in three parts. The first part is this beginners guide, while the second part will contain much more detailed and advanced information. So, what I'm saying is, please be patient. I'll try to get going something from the second part for the next update. [Less]

Looking at your code coverage is a good idea. But I found it a bit tedious to remember the correct --with-coverage switch for the test runner and then to remember the correct line to generate reports and then to open them in my ... [More] webbrowser. So about a year ago I made a small package "tha.coverage" that would do all of that. One single command to get your coverage reports generated and opened in your webbrowser. Someone asked for the source code because he wanted to make modifications. Oops, internal in my old company's svn. One email later I got the source code: "put it on bitbucket and rename it". There are now two fresh packages: createzopecoverage, the original tha.coverage that works with the zope testrunner. createcoverage, the same for running regular tests with the "regular" coverage.py. In both cases, I assume you're using buildout and that there's a bin/test that runs your tests. Just run bin/createcoverage (or bin/createzopecoverage) to get your coverage reports. See createcoverage's pypi page for some more information and configuration hints. [Less]

I just came back from an exhausting but highly inspirational 2 days of talks and demos about Semantic Mediawiki and various extensions and use cases: SMWCon Fall 2010 (hosted at the Open University in Amsterdam). Some of my personal highlights (in ... [More] no particular order): Semantic Maps as presented by Jeroen de Dauw. This was a bit of an eye-opener, as I had previously briefly thought about using something like this, but decided it wouldn't be worth the bother if it involved having to type in a lot of coordinates. Well guess what, you don't have to: it provides full geocoding functionality, effectively allowing you just to type in a street address. It ties in with Google maps as well as Open StreetMaps, Yahoo maps and OpenLayers. Overall it looks just massively useful. WikiTags by Jesse Wang: a very impressive demo on how to link the world of (semantic) wikis to the world of MS Office. Automated annotation of terms in MS Word, live links between Outlook and the wiki, quick and easy adding of e-mail messages to the wiki, etc. etc. The thought behind this effort appeals to me: don't rage against the machine but accept that MS Office tools are the daily working environment for many people and organisations, and cater to that. The Suite of Halo extensions presented by Daniel Hansch: although I was already aware of the Halo extensions I had not yet completely grokked the full range of features and improvements it encompasses. In particular its support for fine-grained access control is something that captured my attention. On the ToDo list to take for a test drive. SparqlExtension by Alfredas Chmieliauskas and Chris Davis: particularly impressive about this demo was the way in which this extension enables integration of (RDF) data from many different sources and creating all sorts of reportings on that data. Can't wait to tweak this one to talk to a Sesame server and start testing it on our internal group wiki. Rudi van Bavel and Michael Cariaso both showed very interesting stuff involving the creation, maintenance and use of SNPedia, a wiki containing huge amounts of human genetic data. To be honest, though, I found all presentations and demos, not just the ones mentioned above, interesting and engaging. The atmosphere throughout the two days was positive and pragmatic, with lots of interesting group discussion going on. It was great to see people from so many different background coming together to share experiences and show new and innovative ways in which the SMW platform can be used and extended. [Less]

I've spent a thought-provoking week in Germany, primarily in the company of people from the greater Zope community in Europe. By "the greater Zope community," I mean projects such as Plone, Zope 2/CMF, the Zope Toolkit, Grok, and BlueBream. My week ... [More] started in Halle, Germany, at Gocept's offices in a meeting called a "Zope Summit." 19 people gathered to try and figure out what we could [Less]

Jean-Paul Ladage of Zest Software speaks during the Dutch Plone User Day 2010 in the Euromast, Rotterdam. 50 percent of young people in The Netherlands already uses Internet on their mobile phones. For all ages that is 28 percent. The software on ... [More] mobile phones has become more user friendly and the costs have gone down. A show of hands in the room reveals: almost everyone has mobile Internet, Twitter more than half, Facebook or similar (Hyves in The Netherlands) on mobile is hardly used. What do you need to consider? Which mobile devices are the most used in your target audience? If it is an intranet and everyone in the organization uses an iPhone, it becomes much simpler. Symbian is 43%, Blackberry 19%, Android 18%, iPhone 15%, Windows Mobile 5%. For which screen resolutions do you want to optimize? 176x208 pixels: hardly worth the trouble to support this. 240x320 pixels is the most widely available size currently. For Plone there is Plone Go Mobile. This is a suite of tools within Plone to manage new content for mobile or optimize current content. Automatic redirection from for example http://zestsoftware.nl to http://m.zestsoftware.nl. A portlet that offers managers the option to make an item available specifically for web, or mobile, or both. You can (for some content types) give an alternative title, description or text. Tip: keep the title the same (better for SEO, search engine optimization) and only specify a different description and text field (where needed). At Zest Software we want to offer mobile websites, so we have recently done this for our own site. (Compare our web site and mobile site.) We have mostly focused on news items, agenda and weblog. We also gave special attention to navigation. You can also change content to for example make a phone number clickable, so that you can immediately call that number on your phone or save it to your address book. An alternative can be: Mobi, by Infrae. Inspiration comes from MITs mobile web implementation. It is more general, so also applicable outside of Plone. Remark by Kit Blake: this morning we made release 1.0; it uses WSGI. For some technical notes by Zest Software, see http://projects.zestsoftware.nl/guidelines/guidelines/mobile-development.html Testing: partly with the Open Wave emulator, partly simply with our own mobiles. See the slides (in Dutch). [Less]

Geir Bækholt talks at the Dutch Plone User Day 2010 in the Euromast, Rotterdam. Plone 4 was released two weeks ago. It has taken longer than we thought, but we think it was worth the wait. It was meant to be a minor release. "Plone 5 is going to ... [More] have large changes, so let's make this 4.0 release a little one." We totally failed at that. It is the biggest release ever. To get new functionality into Plone, we use a 'PLIP' process. A PLIP is a PLone Improvement Proposal. The Framework Team accepts or rejects these PLIPs. For Plone 4 we had 58 plips, which is the biggest amount ever. The process was more documented this time, so that probably made it easier for people to get their improvement proposal in. In the end, 27 plips made it into Plone 4.0, some have been postponed. The release manager of Plone 4 is Eric Steele; works at Penn State University in the USA. He probably had no idea what he stepped up for. ;-) Okay, so what is new? Plone 4 is a lot faster. We focused on that. We tested plips for their effect on speed. Hanno Schlichting was the hero here. These are long term improvements, certainly also in the infrastructure. We use Zope 2.12 and python 2.6, which helps reduce memory usage. Plone 4 is about 50 percent faster than Plone 3. Compared to other open source CMSes (all out of the box, without tweaking) we perform very good as well. We are faster than Joomla, Drupal and Wordpress when you look at requests per second. BLOBs: Binary Large OBjects. Large files are no longer stored in the ZODB (Zope Object DataBase) but in blob storage. This means less memory usage, less database growth, less pushing small objects out of the cache. On one site we saw the memory consumption go from 14 GB to 3 GB. We got a new visual editor: TinyMCE. Kupu has shipped with Plone since 2005. It has wonderful features and was good at the time. We were happy with it, but it was hard to maintain a visual editor that mostly only we were using. Instead TinyMCE is an existing editor maintained by others. So we just need to take care of integration in Plone, which Rob Gietema of Four Digits has done a lot of work for. It also works on Plone 3. Now it is part of Plone core. Future development will be based on TinyMCE. It has better image upload, table editing, inserting hyperlinks, etcetera. Probably this is the most important user interface improvement in Plone 4. Plone 4 has a new look. If you have stared at the green and blue boxes for ten years, you will be happy with the new theme. It is a refreshing change. A grid based theme. The old theme has been improved over many years; the new one is younger and smaller, so may be missing some fixes. The old theme is still available, so that should make the upgrade experience of a theme from Plone 3 to 4 much smoother. There is also a basic theme without actual theming, which can work nicely as basis for an own theme. JQuery Tools is shipped and used. We use it for 'modal dialogs', popup-like dialogs for those times when loading a complete new page makes no sense. User management has improved. Full names are used everywhere. You can login with email addresses, when you turn that on. Defining your own member data is more flexible. You can assign portlets to groups. We have full text indexing for Eastern languages. For Western developers that is very hard to do. It makes Plone usable for half a billion people more than before. When you startup Zope for the first time without a Plone Site, you are much friendlier greeted. We should have done that much sooner. Hanno has done this, probably in half an hour. :-) It is probably the simplest upgrade of any Plone upgrade ever. It is a big version, do your backups and stuff, but you should be fine, at least when upgrading from any Plone 3 version. Some work is being done do make it possible to export for example a Plone 2.1 site and import it in a fresh Plone 4 site, if you run into problems. What is next? Upgrading an add-on package from Plone 3 to Plone 4 is not much work. If you need this for an add-on, just send a friendly email to the maintainer. Plone 4.0.1 is expected to be released tomorrow, 4.0.2 at the end of September, then each month. Usually I advise to wait for the first bugfix release, but for Plone 4 I don't have the feeling that is necessary; but 4.0.1 is there soon anyway. Now about the mid-term, 2010-2011. Plone 4.1 probably early next year. Expected: Amberjack guided tours of the user interface, improved commenting, new collections (renaming them did not help, so we did some heavy restructuring to make them lighter), SiteAdmin role (basically Manager without ZMI access), password policies. Plone 4.2: we don't know how far away this is. Chameleon template engine for faster rendering (probably about 20% speed improvement), architecture preparation for Deco, content governance (which person is responsible for maintaining it, is it still up to date), batch editing. Plone 4.3 may not even happen, we may be close enough to Plone 5 by that time. Somewhere on the horizon is the magical Plone 5. It will improve the user interface for editing and put us at the front of the pack there, using Deco and tiles, unified content types, new editing interface. Remark from the room: it would be good to get a performance comparison between Sharepoint 2010 en Plone 4. Note: if you are Dutch you may want to go to the Dutch version of my weblog to see some extra entries (at time of writing only one, but there will be more) in Dutch about this user day. [Less]