The realization of that had a profound impact in my life. As programmers, technically minded people that we are, we tend to focus on ourselves and rarely share our knowledge, except to show it off at conferences here and there. We do it mostly to please our ego. Dorneles was nothing like that. He didn’t present at many conferences, though he was always there as either a participant or an organizer. He didn’t write lengthy blog posts full of technical details. In fact, he didn’t blog at all since 2007. He didn’t create brilliant frameworks. Instead, his contributions were mostly invisible, through IRC, IM or Skype, directly between him and the person seeking his help. It was very common for him to carry about five parallel conversations over IM, helping people all over the world without breaking a sweat. He would happily pull out his laptop or phone at a table in a blink to teach someone a trick. The endless stream of messages on twitter following his death should serve as proof that his way was much more effective in causing an impact in the world than a horde of highly skilled programmers ever could.

As other people well put it, Dorneles could never lose that smile on his face. Nothing could make him curse or complain. He was a mixture of cheerfulness, innocence, tranquility and awkwardness that would immediately conquer people’s hearts with no effort. He was like that young little brother that makes you blush at a family dinner for being excessively goofy, but that you love so much you would never reprehend.

To me and my wife, Dorneles was closer than family. My wife suffered more from his loss than for the loss of her lovely grandma, or from her uncle that died a slow death from brain cancer a couple years ago.

In retrospect, I can now see that he did treat me like an older brother, always eager to take on my advice. When he was alone in a big empty office in Caxias do Sul, following the break with the other partners at X3ng I told him to move to Garibaldi because we could rent a similar office for much cheaper. I suggested that he should reunite with his wife and two kids, which were living with her mom, and that raising them in Garibaldi would be much better for their education and overall quality of life. I said it would be nice if he had a car so that he didn’t need to call a cab at 3am when his kids were sick (he refused to buy a car for years, since he had cars stolen several times). At a time he was having trouble getting regular pay, I suggested he should work for Enfold. I told him to go to more conferences and sprints, so that he could put faces to the names on #plone. He was easily convinced. And all of these things had a great impact in his life.

I regret not spending as much time with him as I could in the last year. But many are the good memories that we’ve shared. Back in November 2009, when my backpack with laptop and cameras containing all the pictures from my vacation in New York got stolen on our first day in Houston he calmly told me: “Don’t worry, you can buy all those things again. They didn’t take from you the most precious thing: your life.”

I regret that he didn’t find the time to visit my 3mo old twins. But I’m glad that after my visit last Saturday, he went to visit his 2 weeks old nephew and his dad on the Sunday. I’m glad that we spent a good 2h last Saturday sitting around, chatting about the most diverse subjects while I was at his place waiting for the rain to stop.

Dorneles was a sushi lover. He once walked for tens of blocks in Houston on a cracking hot summer day just to eat sushi, and lived to tell the tale. That’s perhaps the most un-American thing he could do. The first thing we did when we met in Houston in November 2009 was to go out for sushi. When Nate came to Brazil, he took him out for sushi, and that’s perhaps the most un-Brazilian thing he could do. His love for sushi passed on to his kids. For several weeks I told my wife that we should invite his family out for sushi. We were waiting for the right occasion, and it never happened. In his memory, I think we should do it anyway.

The good news I want to announce is that the buildout-based Plone Installers for Windows have been updated, and a few bugs have been fixed in the process. Namely:

1. Running ‘bin\buildout.exe’ would not show any output. That was because it was generated by running ‘bootstrap.py’ with ‘pythonw.exe’, so that a command prompt would not flash on the screen. I added an extra step at the end that re-runs ‘bootstrap.py’ with ‘python.exe’. So a command prompt will flash quickly, but at least it works right.

2. The version of ‘setuptools’ being shipped in the buildout installer was still ‘0.6c8’, which did not work with Subversion 1.5. At least one person was affected right away by this, and I only found about it because I was watching the #plone channel closely.

To fix those problems I had to make two extra releases, because they came to my knowledge after the release was already uploaded. So if you downloaded an early build of the Plone 3.1.6 buildout-based Installer for Windows, go and fetch the latest build. Otherwise, if you are willing to play with Plone 3.2.0a1, go and fetch that instead.

This week, with the Plone Conference 2008 going on in Washington and the fact I did not attend this conference, I finally made enough time available to get my hands back into Zope again.

So it’s my pleasure to report that after about a week of hard work and a handful of workarounds that will need future cleaning, Zope 2 does now startup under Python 2.6.

My expectation with this now out of my way is that other developers will start looking at adjusting third-party applications (hint: Plone) to run on Python 2.6 as well.

The code is available on the gsoc-python-2.5 branch of the Zope repository, and the lucky guys at the Plone Conference will be amongst the first to hear the good news through Matthew Wilkes, which registered for a stealth Lightning Talk which should get at least some people puzzled. I would love to be there and see their faces when Matthew unveils the surprise.

Big thanks go to Tres Seaver for helping me figure out a change needed in Zope’s private version of ‘medusa’ and to Ranjith Kannikara, our GSoC student through the Zope Foundation, and his friends which did a good chunk of the hard work, namely figuring out changes to the C-based ‘Acquisition’ module and cleaning up string exceptions.

NOTE: This is not intended for production yet, it is just a technology preview to get developers to try out and start porting their own projects. Many bugs still exist, some of which might take up to a month to get fixed. Most importantly, the RestrictedPython implementation has not been fully audited for the new builtins and language constructs introduced since Python 2.4.

EnSimpleStaging is based on ZopeVersionControl, another great product which provides for keeping a repository of versioned objects inside the ZODB. One issue we’ve hit constantly with EnSimpleStaging was that certain methods from ZopeVersionControl depend on an actual transaction being commited to properly detect that an object has changed. While in real life this specific method will always work flawlessly due to the way using ZopeVersionControl and EnSimpleStaging works, in a test case it was very hard to test this, due to the fact that a test case is run within a single transaction which is aborted at the end of the test.

Sometime ago I’ve learnt that ZODB has a nifty feature: it is possible to wrap any Storage instance with a DemoStorage. After you do that, you can commit changes and they will be committed to the DemoStorage but not to the base Storage. That would solve not only my problem with ZopeVersionControl, but can potential solve a whole lot set of problems due to expensive setup methods in test cases.

That fact has lived in the back of my mind for longer than two years, until today I set some time aside to investigate a way to implement this cleanly in a way that could be used for my tests. Searching around, I’ve found at least a couple occurrences of other people trying to do the same. I didn’t find any solution though, so that either indicates they just gave up or that they found a solution but didn’t care enough to share it. In fact, the title of this post was borrowed from one of the message subjects, in hope that it will make it easier for other people to find a solution in the future.

My solution (with a test do demonstrate that it works) was based on Jim Fulton’s suggestion to look at zc.selenium. I’ve simply adapted it to the Zope 2 reality, using ZopeTestCase’s provided hooks and `Zope2.bobo_application` (which is the Zope 2 equivalent of the publication object from Zope 3).

Hopefully this will be of use to more people, specially to the folks that were seeking for ideas about how to implement this. It would be even better to just add this to ZopeTestCase proper, I think. Maybe someone will be interested in doing that.

I have already visited the US in June, when I attended the Plone Symposium in New Orleans. On that occasion, I stayed in the US for ~30 days. This time around I was planning to bring my wife and dog (the cute Yorkie pictured at the top of this blog).

One thing that worries me though is that I’ve never took my pet on any flights, so I have no idea how pet-friendly airlines are. Just to get from Sao Paulo to the US (Houston) it’s a ~9:30h flight. My dog is usually cool with traveling. Earlier this year I drove nearly 8h to the beach and we stopped twice on the way, but she did not pee until we arrived at the destination.

So I’m putting this out there, looking for any feedback from people that took their pets on flights.

I’m subscribed to Google Alerts for the keyword Plone, so whenever a new article or page mentioning Plone get’s picked up by Google, I get an email alert.

Today, I got an alert from an article published by Burlington Free Press. The summary in the email alert had the following text:

Northfield teen clocked at 104 mph while talking on cell phone
BurlingtonFreePress.com – Burlington,VT,USA
… driving 104 mph on Interstate 89 told police she was unaware they were
trying to stop her because she was talking on her cell plone, state police
said. …

http://www.burlingtonfreepress.com/apps/pbcs.dll/article?AID=/20080617/JS02/80617032

See all stories on this topic:
http://news.google.com/news?hl=en&ncl=http://www.burlingtonfreepress.com/apps/pbcs.dll/article%3FAID%3D/20080617/JS02/80617032

Notice the text says ‘cell plone’. Clicking on that link though tells you the article doesn’t exist anymore. If you click on the second link the article shows up and it’s published under a different url, which probably means someone was quick to detect the error, correct and re-publish the article under a different url. Not quick enough for Google’s indexing system though, which was able to index the article before the correction. If you search Google for “cell plone” the original article shows up as the 5th link right now. Unfortunately, the link to the ‘cached’ version of the page does not return the original page.

me: i mean, i had made a list of things already

Alexander: yup, but I’m sure there are more

me: those are the high-level yeah
for example, you can run with the python security policy
implementation, so that’s one thing less
acquisition needs to be ported though, or at least faked :)

Alexander: what about the __parent stuff that just landed in 2.11 (or
was it trunk?)

me: that’s implemented in Acquisition yeah
ExtensionClass, Acquisition and persistence are the 3 top modules
oh, BTree is a nasty one
probably better off trying to go to a non-ZODB based Zope by that time

Alexander: yeah, I suspect we should ditch the ZODB if we want to be
on App Engine

me: at the same time, there’s this project about porting Zope to Jython
if that’s successfull, it should run on pure python too
or maybe not, depends on which way this student goes

Alexander: right, the App Engine concerns are more than just what runs
as pure Python, though :)
database, memory usage, etc

me: but, what about the relstorage backend?
idea

Alexander: that’s why I included Martijn ;)

me: ok
so, yeah, those are my ideas
can’t think of much else

Alexander: ok
that’s a great start, thanks
now make sure the email or blog post covers the additional thoughts ;)

me: maybe the DirectoryViews stuff
the filesystem access is restricted right?
but i guess you can read files just fine?

Alexander: I have no idea :)

me: oh, k
number of files would be a problem
we should have all products running off zipped eggs by now
that would reduce the amount of files
but unfortunately no one worked on that

Alexander: I have to run, but feel free to continue in email ;)

me: ok

Alexander: trunk of Plone is mostly eggs, no?

me: but nothing is ready to load files off zipped eggs

Alexander: I see

me: i believe mcdonough did some work on that

Alexander: ok, see you later :)

me: ok
zcml would need to grow support for zipped eggs too

If you have more ideas, feel free to comment.

I am amazed to see the progress he and the folks helping him had so far. This is definitely all that I dreamed for when I started with the idea in January 2006. It is great to see that even though ideas take a little longer to get implemented in the Plone community that they do not simply get abandoned, but there’s always people willing to pick up an idea and turn it into reality.

Many thanks for Tarek for all of his work. Once this gets rolled out into the new plone.org it will make the life of us developers so much easier when making releases that we will ask ourselves “how could I live without this for so long”.

How would that be possible you ask? Well, a couple things are required.

The Repoze guys have Plone running as a WSGI app, AFAICT. So the hosting part is pretty much settled. You just deploy an app that sets up a Repoze WSGI App.

Then comes the storage. Plone, being based on Zope, uses the ZODB. But the Google App Engine doesn’t allow writing to the filesystem. The solution? Having a RelStorage backend that uses the DataStore API.

The final step would be getting rid of the C extensions in Zope, and having Zope run in Pure Python. Fortunately, there’s a student application for this year’s Google Summer of Code project that intends to port Zope to Jython! That should help with this last step by providing Pure Python implementations of the C extensions, if it gets approved.

I am really excited by the possibilities that this opens up. And would love to see someone pick up this project and turn it into reality.