Kim shows us a collection of tools that can be useful during development.
When you want to get started with Plone development, you need to know where to get help:
collective-docs.readthedocs.org(update 2014-08-08: link not working anymore)
- Search via DuckDuckGo, Google, Stack Overflow or the Plone mailing lists
- IRC (
- Plone books
To speed up buildout, you can:
- Use version 1.6+
allow-hoststo limit where buildout is looking
- Use timeout
-Nso buildout doesn’t look for newer packages
- Create a shared local buildout cache
- Check out Ross Patterson’s blog post about buildout performance improvements.
Use mr.developer to check out the code of eggs in your buildout so you
can easily develop on them. (And to update them all at once when you
continue working on a later moment, use
The package sauna.reload picks up changes in the files of your packages and restart Zope automatically. But somehow Zope is restarted very quickly. For Plone 3 use plone.reload, which requires manual action to reload Python code or ZCML.
With collective.recipe.omelette it is easier to look into the code of Plone and third party addons.
plone.app.debugtoolbar shows debug information and it allows you to do stuff you normally need to do from the ZMI.
plone.app.themeing allows you to install a zip file with the theme (works with Diazo).
If a site is unresponsive, you can use
investigate. You can use it print a stack trace for all threads so you
can see what’s going on. Kim used to use
but mr.freeze can do more, like drop Zope to a
pdb debug prompt.
Continuous integration with Travis CI for open source GitHub projects or Jenkins for internal company projects. Travis can be used for closed source projects but they don’t advertise with it and it’s quite expensive.
plone.api is still under development but already very useful!
products.pdbdebugmode allows for post-mortem debugging, but it can conflict with sauna.reload.
Finally: see collective.exampledevtools for more details.