The Technology Understanding Gap

Please go read this incredibly insightful reflection by Eugene Eric Kim. If you’re too lazy, I’ll clip the most important part for ya:

The following day, I co-led a session on this topic with AngusParker. Two of the participants were dealing with the specific challenge of connecting members of a national network of leaders in reproductive health, so we used that as a case study. We decided to use Clay’s contention to frame the problem, resulting in this whiteboard:

http://farm3.static.flickr.com/2349/2234544757_9be3c47dd2_m.jpg

What do you notice about this picture? Obviously, the Tools column is completely empty. That’s a dead giveaway that I’m facilitating this discussion. (That and the horrific handwriting.) Figure out the basics first. Don’t let the question about technology drive the discussion. During the discussion, one of the participants asked, “What tools can we use?” I responded, “Let’s not worry about that now.” So we kept talking and talking, and I noticed the two non-technical participants in the group squirming like crazy. So I stopped, noticed how gaping the Tools column looked, and said, “You’re uncomfortable about not having discussed the tools, aren’t you.” She nodded. “Don’t worry about it,” I responded. “The tools part will be easy, once we figure everything else out.” “Easy for you, maybe,” she said. “You already know what goes there.” That was not quite true, but I got her point, and the force of it struck me so hard, I had to stop for a moment. I looked at the gap, and I saw possibilities. She looked at the gap, and she saw a void. That was upsetting for her. It made it hard for her to think about the other aspects of the problem. It made me realize how much I take my technology literacy for granted. But it also created an opportunity to discuss how easily we are sidetracked by technology. “Tool” does not have to mean software, and making that assumption prevents us from exploring other viable, possibly better solutions.

I’ll add in a kicker: too often, people who are less technically literate think that if they only fill in the right answer in that middle “Tools” column, that their problems will all be solved. When, really, it is more important to get the Promise and the Bargain right. I like to call this pattern “magical tool thinking.” It results in a lot of wasted time and effort trying to identify that magical, right tool — effort which should go into thinking about process, objectives and how to sustain the non-technological parts of the organizing effort.

CacheFu 1.1.1 makes Plone go fast!

A big congratulations to Ricardo Newbery, who’s put in a ton of great work to release CacheFu 1.1.1, which, despite it’s tiny version number increment, is a big leap forward for this must-have Plone add-on product.  This is the first Plone 3-ready release.

While there’s a lot of discussion about using CacheFu behind a caching proxy such as Varnish or Squid, and these are in fact really good ideas if you’re running a high-volume site, it’s (IMHO), too little known that simply installing CacheFu into a Plone site being served by straight Zope, or Zope-behind-Apache with no caching, will result in an immediate ~5x speedup for anonymous users.   In other words, CacheFu ain’t just for big Plone sites; it really helps a lot on smaller, low-traffic sites too.  And at the low end, it delivers immediate benefits with zero configuration.

Update: I wrote a short FAQ on Plone.org about this.

Plone Bootcamp in Amsterdam

My good friend Joel Burton is bringing his first Plone Bootcamp to Amsterdam, March 16-22. It’s being organized by the amazing Sisi Nutt and the crew at Friends of the Earth Netherlands, so it will doubtless have a strong NGO slant.

Sisi writes:

This course is the first public bootcamp to comprehensively cover Plone 3 technologies, while still friendly for new-to-Plone and intermediate-Plone users. It will cover everything you need to build, skin, deploy, and maintain a Plone site.

Amsterdam, the Netherlands

March 16-22, 2008

$550 USD

http://plonebootcamps.com/courses/amsterdam

Just in case you are on the cusp of deciding, a word or two on the location of the course to tip the balance:

The Waag is the oldest secular building in Amsterdam. Built in 1488, it was first used as one of the city gates.

After expansion of the city, it served as headquarters for several different guilds. The surgeons were one of them, and in 1691 the Theatrum Anatomicum was opened as a room for experiments.

Nowadays, this historic room is still used as a laboratory, but this time in the fields of media and open source software. This is where Plone Bootcamp Amsterdam will take place.

http://www.waag.org/

Thank you, Plone community!

(Sent from a secret undisclosed location near the Pacific Ocean.)

Dear Plone,

PSPS 2008 Participants

Thank you for traveling from around the world.  Thank you for staying awake through your jetlag.  Thank you for dreaming big dreams.  Thank you for doing the hard work of boiling them down into priorities. Thank you for taking ownership and following up.

Thank you for trusting the process. Thank you for stepping forward into the space. Thank you for all of the great, constructive feedback. Thank you for letting me say “popcorn,” “twinkle” and “segue” while we leveraged our action items to a strong go-forward basis. ;-)

Thank you for making it easy and joyful to be in service to you.

P.S. Thank you, Google! Leslie, Tiffany (and Alex!), you were the most gracious and generous hosts a community could dream of. Thank you for going above and beyond to take great care of us. We are deeply grateful.

Support Video for Plone 3

Nate Aune is trying to raise a few bucks to support a Plone 3-compatible release of Plone4ArtistsVideo.  P4A.Video is the glue behind the scenes of his impressive new Plone.tv website and far and away the most impressive video add-on product for Plone.

Nate’s over $1200 of the way towards his $2000 goal — pretty respectable.   I’ve already donated, and if you care about the future of multimedia support in Plone, then you should donate a few bucks, too.

Easier Plone Hosting: Some Ideas

Some not terribly complete thoughts on some ideas for how the Plone community could make it easier for mainstream hosting VPS companies to offer Plone to their customers.

The problem: Plone is relatively difficult to host in the most common and inexpensive commodity web hosting accounts.

Why? Plone, like Ruby on Rails and other Python frameworks, requires long-running server processes. These processes consume relatively large amounts of RAM (256MB or more), and thus don’t “play nicely” in a typical chroot-based virtual hosting environment optimized for PHP and Perl, where hundreds of accounts are crammed onto a single server.

The elements of a better solution are lying around on the table, yet they have not been assembled. This article attempts to point out some possible ideas for innovation.

Virtual private servers (VPS) give a user true root privileges on their own instance of the operating system. Typically, the main limiting resource on a VPS instance is the amount of committed RAM. 512 MB of RAM is a good amount for a small to medium-sized Plone site under not-too-large loads.

Xarope is a set of scripts by John Lenton and Marcos Dione of Except, which automate the creation of Xen VPS instances with pre-configured Zope instances.

Also worth taking note of is the fact that Cpanel is a very popular web-based GUI for server management amongst commodity hosting providers. Its companion, Fantastico, make it possible to have “one-click” installation of many popular PHP and Perl applications.

My hypothesis: it should be possible to create a virtual machine (Xen) image that contains the following preconfigured elements:

  • CentOS or other commonly used linux operating system suitable for virtual machine operation
  • Python 2.4.x (or other current version suitable for Plone)
  • Other python packages required by Plone (PIL, OpenID, elementree, setuptools, etc.)
  • Apache or NGNIX, with rewrite rules pre-configured or script-configured for a basic single-site deployment
  • Varnish or Squid, appropriately pre-configured or script-configured for a single-site deployment.
  • Scripts to configure Apache/NGNIX/Varnish/Squid for your domain.
  • The main question the interactive auto-configuration script should ask is: “What is your domain name?” it should assume you are hosting a single Plone site on the server, at the domain name specified, IOW sensible defaults, further customization assumes you know how to configure Apache, etc.
  • It might be ideal to have these scripts be triggered via the CPanel or Fantastico web GUI, or some equivalent.
  • Plone 3.x, with sensible configuration defaults for this environment, e.g CacheFu.
  • The service provider might also choose to bundle some popular add-on products such as PloneFormGen, LinguaPlone, etc.
  • Appropriate utilities for automated backup

With this image in hand, we should approach well-regarded VPS providers, and work with them to make this “Plone Image” available as an option for their customers. I’d like to see a target price of $30-50/month for 256-512 MB of RAM.

I’d also like to see the instance have CPanel for basic server administration (e.g. email, apache settings, other non-Plone stuff), whatever the VPS provider usually providers for its customers.

Sidebar: if Repoze + WSGI provides an effective way to run Zope in an Apache mod_wsgi process, this could be an alternative configuration. This doesn’t get us around the need for a generous amount of RAM, but it may be more understandable/palatable to hosting providers, and is worth exploring.