There was a nice debugzope script at the times when Zope 3 was packaged as a tarball. You could interactively dig into ZODB make your changes and commit.
Now at ZTK / egg / recipe / buildout times I was missing this. Therefore I created the recipe z3c.recipe.paster:debug.
(some code taken from grok ;-)

Add it to your buildout.cfg like this:

[debug]
recipe = z3c.recipe.paster:debug
app=app
where app is a z3c.recipe.paster:serve recipe.

Some more fixes:

• Sleep(100) on waiting for an external plugin to finish -- BAAH, Sleep(0) hogged the CPU
• never (try to) write back the .ini file -- well you might not have permission and I(!) am the one who writes the config
• PortNumber -- specify which port to bind to, well 4949 what else? but was a simple copy paste
• LogConnections -- ability to turn off that insane connect logging every 5 mins
• MasterAddress setting -- limit the IP address of the remote (master) server connecting. Right now to only 1 IP, but how many munin masters will you have?

Still need to adjust external plugins to be able to use existing munin-node plugins.
Goal would be to install (active)perl and run the existing munin plugin that's usually written in perl. Who wants to reimplement that again with e.g. python?

patch binary

Who said monitoring a windows server is impossible with munin?

There is munin-nodewin32 on github, but it was a bit crippled with external plugins.
The problem with monitoring memory usage was fixed in svn but not yet compiled.
Here is a patch and binary that fixes that.
After that it's easy to write plugins (in python) to monitor what you want.

There's a script called debugzope, that sounds like a debugger. But in real life you can examine the whole ZODB with it. You can even make changes to the ZODB or ZEO. All in all quite handy if you have to correct a few objects in the database, also on a live system.

$ bin/debugzope

Now the variable root becomes your DB's root. All configuration should be taken from the live system in which context it was started.

>>> root
zope.app.folder.folder.Folder object at 0x01C31C70

You can do any changes (and anything) using the usual python commands. The whole Zope infrastructure is in place.

Don't forget to commit when you are ready:

>>> import transaction
>>> transaction.commit()

Otherwise all changes will be reverted on exit!

debugzope(.bat) is usually available if you use the old zopeskel style deployment. The next task is to figure out how to do this with a buildout based deployment.

Who said that Google Docs and Spreadsheets is not working with a nokia mobile?
OK - it's not pleasure, but at least I can see what I wrote after some hacking.

This is the spreadsheet. Read only, the guys check the browser. At least I can see something.

This is the Docs. It is almost working! Click on the tabs is working:


Trying to login through docs.google.com results in:
Adding /?browserok=true at the end of the URL does not help too much. The document list is empty:

Stay tuned for more.

That was done using a nokia E61, SW: 3.0633.09.04, with the stock-builtin browser.

Just bought a nokia E61 to play around.
Tried to update the firmware in it. The nokia software updater did not even start up.
The error message was: "Network connection lost. Check your network connection or wheter a firewall is prventing the application from working properly".
Nope, no firewall problem. Internet explorer was "working offline". Thanks Bill.

Project home is now z3c.zodbtracing on svn.zope.org.
Read more here: http://svn.zope.org/z3c.zodbtracing/trunk/src/z3c/zodbtracing/
Performance can be an issue if using this storage, but that's not for production, just for debugging so don't come whining.