Helping people help each other

I find myself in the unique position of being able to help raise money for four organizations I care a lot about:

• Python Software Foundation
• Zope Foundation
• Plone Foundation
• Django Software Foundation

Proven track record

In 2008, I raised (with the help of many others) approximately $13,000 USD for the Plone Foundation via Plone Conference 2008. In 2010, I raised over $2,000 for the Zope/Python Users Group of DC via a unique sponsorship program. I would like to continue doing this work, but I need your help!

The plan

Before I ask for the help, let me take a minute to explain “the plan”. I would like to operate an organization whose primary purpose is to perform the following:

1. Educate people about Python software on a monthly basis via meetings featuring talks about Python software.
2. Contribute money to the various Python software foundations on an annual basis.

This is the primary, not sole purpose. If we get those two things right we can do other things to expand on both #1 and #2. But I can’t do it alone.

The help

If you like this idea, you can help me right now (if you haven’t already) by helping me help someone very important to me. Confused? Read this: http://aclark.chipin.com/flowers-for-amy-part-ii

Wrap up

In short (and please forgive brevity), I think we are on to something here in DC, with both our consistent approach to running our user group activites, and attempts to expand our efforts for the greater good. We have received a lot of positive feedback and encouragement, and I’d like to keep going, but I have to convince everyone involved that there are people out there that care about these efforts. Hence, the chip-in.

If all the “Plone people” I know would contribute just a dollar, I think we would be in pretty good shape.

I hope you will consider helping!

I was recently tasked with consolidating our various business services (website, software repository, mailing lists, ldap, etc.) on to a single virtual machine (ostensibly to save money, although it didn’t quite work out that way). The Apache modules for XDV presented themselves as an attractive technique to use, in helping me achieve my goals.

Background

Previously, I had been blissfully running http://aclark.net with NGINX, Plone 4 trunk, and XDV on a small virtual machine and absolutely loving it.

Additionally, I had separate virtual machines for my WordPress blog (blog.aclark.net) and Subversion software repository (svn.aclark.net). The isolation of these services made them easy to manage and still relatively cheap to run them all.

And in fact, I have come to rely heavily on the ability to (1.) rapidly create a virtual machine, (2.) install a bunch of vendor packages that Just Work™, and (3.) build out whatever was left i.e. whatever could not be easily installed via OS vendor packages. This usually translates loosely into “I use Buildout for my Plone sites, and an OS vendor package installer for everything else”.

That said, even though I already knew the hazards of trying to cram too many services on to a single “shared” host, and didn’t really want to do that dance again, it seemed reasonable at the time to at least try and consolidate them on to a single virtual machine (it sounds crazy in hindsight).

First choice: NGINX

Like I said earlier, the forked version of NGINX available on the HTML-XSLT website is an absolute pleasure to use. But when I pondered consolidating services I knew it would not be easy, and maybe even impossible to run WordPress behind NGINX.

Second choice: Apache

So I thought to myself, “I know, I’ll just switch to the Apache modules for XDV” and that will solve my PHP/Plone “integration” problems for the time being. (Another way to solve them would be to use the XDV middleware along with Zope 2.13‘s WSGI support; I will be trying that next.)

But not so fast.

Problems

Of course, things don’t always go as planned.

First problem

The Apache modules for XDV do not work exactly “as advertised” on any of the “modern” OS platforms I tried (Debian, various Ubuntus, and Arch Linux). They compile fine against the operating system’s Apache, but do not run properly. See this thread on the Deliverance mailing list (and I challenge anyone reading this to correct me! )

“Fine,” I thought, I’ll just create a buildout to deploy everything. I wrote a book about deploying Plone websites with Buildout. This should be easy, right?

Wrong.

Second problem

It’s hard to create such a buildout for a variety of reasons, but most noticeably in my mind is the “library soup” you may encounter on any modern system. For example, I started off by trying to include all the dependencies in the buildout. But I ended up leaving things out, like libxml2 and libxslt relying instead on the operating system vendor packages. Because even though I tried desperately to tell every other dependency about the included libxml2 and libxslt2, I still ended up with an annoying “missing symbols” error at the end (meaning I likely missed a compiler flag along the way).

These errors can be very frustrating, and even worse: sporadic. Sometimes you may inadvertently add or remove a system dependency during the build process. So you could be relying on a system package and not even know it until later when it is too late (i.e. when you are enjoying some unplanned and unexpected down time).

So there I went again. It took several days I didn’t really have, and the results were not what I expected, but I’m still somewhat happy with them. Now, I want to share this buildout particularly with folks considering using the Apache modules for XDV (http://code.google.com/p/html-xslt/). Because while it would be much easier if the Apache modules Just Worked™ with OS vendor packages, in the event that they don’t (which is what I experienced) folks may find this buildout helpful. (That, and Jon Stahl requested it on Facebook ).

Conclusion

Anyway, I’m quite happy with the buildout and I am sharing it in hopes that it will move the Apache/XDV story forward.

In addition to compiling Apache with mod_depends and mod_transform, it includes Subversion, Trac, mod_wsgi, PHP and WordPress. As I mentioned earlier, it is not really my preference to cram all this stuff in to one buildout, but as long as it is reliable and consistent, I don’t mind it too much. It also handles the theme compilation for a variety of services, which is accomplished via a command recipe that executes calls to bin/xdvcompiler.

Incidentally, I have no particular allegiance to, or dislike of Apache: more like a love/hate relationship; it can be very useful in a variety of situations, while at the same time confounding. But regardless, I would like to see the Apache XDV modules be able to deliver the same rock solid performance as the NGINX fork.

Kudos to Laurence Rowe (et al.) for the Apache modules! I hope this blog entry will facilitate a push to get people using them with their operating system vendor’s Apache packages, which may inspire Laurence to continue developing them, and most importantly to fix bugs .

Normally, I like to factor out the reusable bits first, but this buildout is presented in it’s entirety as I am using it (minus some customer bits), for whatever that is worth. Here is a look at the “main” buildout.cfg file, most of which should be self-explanatory. Click around this site to see the results:

[buildout]
#extends = http://svn.aclark.net/svn/public/buildout/apache/trunk/buildout.cfg
extends = apache.cfg
parts =
 bootstrap
 xdv
 apache
 apreq2
 apache-config
 apache-config-aclark
 apache-config-admin
 apache-config-svn
 apache-config-trac
 apache-config-ssl
 apache-config-mailman
 php
 php-conf
 mod-depends
 mod-transform
 python
 distribute
 trac
 theme-aclark
 theme-public
 theme-support
 theme-blog
 mod-wsgi
 subversion
 subversion-python
 supervisor

[apache]
configure-options +=
 --with-included-apr
 --with-ldap
 --enable-authnz-ldap
 --enable-ldap
 --enable-ssl
 --enable-dav
 --enable-dav-fs
 --enable-dav-lock

[mod-depends]
recipe = hexagonit.recipe.cmmi
url = http://html-xslt.googlecode.com/files/mod-depends-html-xslt.tgz
configure-options = --with-apxs=${apache:location}/bin/apxs

[mod-transform]
recipe = hexagonit.recipe.cmmi
url = http://html-xslt.googlecode.com/files/mod-transform-html-xslt.tgz
configure-options =
 --with-apxs=${apache:location}/bin/apxs
 --with-apr=${apache:location}/bin/apr-1-config
 --with-apr-util=${apache:location}/bin/apu-1-config
environment-section = environment

[environment]
PATH = %(PATH)s:${apreq2:location}/bin
LIBS = -lxml2 -lxslt

[apreq2]
recipe = hexagonit.recipe.cmmi
url = http://www.bizdirusa.com/mirrors/apache/httpd/libapreq/libapreq2-2.12.tar.gz
configure-options = --with-apache2-apxs=${apache:location}/bin/apxs

[libxml2]
recipe = hexagonit.recipe.cmmi
url = ftp://xmlsoft.org/libxml2/libxml2-2.7.7.tar.gz
configure-options =
 --with-python=no

[libxslt]
recipe = hexagonit.recipe.cmmi
url = ftp://xmlsoft.org/libxml2/libxslt-1.1.26.tar.gz
configure-options =
 --with-python=no

[php]
recipe = hexagonit.recipe.cmmi
url = http://us2.php.net/get/php-5.3.2.tar.gz/from/this/mirror
configure-options = --prefix=${buildout:directory}/parts/apache/php
--with-apxs2=${buildout:directory}/parts/apache/bin/apxs
--with-config-file-path=${buildout:directory}/etc/php.ini
--enable-mbstring --with-mysql=/usr/bin

[php-conf]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/php.ini.in
output = ${buildout:directory}/etc/php.ini

[apache-config-aclark]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/aclark.in
output = ${buildout:directory}/etc/aclark

[apache-config-admin]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/admin.in
output = ${buildout:directory}/etc/admin

[apache-config-svn]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/svn.in
output = ${buildout:directory}/etc/svn

[apache-config-trac]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/trac.in
output = ${buildout:directory}/etc/trac

[apache-config-ssl]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/ssl.in
output = ${buildout:directory}/etc/ssl

[apache-config-mailman]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/mailman.in
output = ${buildout:directory}/etc/mailman

[ports]
production = 80

[subversion]
recipe = hexagonit.recipe.cmmi
url = http://subversion.tigris.org/downloads/subversion-1.6.12.tar.gz
configure-options = --with-apxs=${apache:location}/bin/apxs
make-targets =
 install
 swig-py
 install-swig-py

[mod-wsgi]
recipe = hexagonit.recipe.cmmi
url = http://modwsgi.googlecode.com/files/mod_wsgi-3.2.tar.gz
configure-options =
 --with-apxs=${apache:location}/bin/apxs
 --with-python=${buildout:directory}/parts/python/bin/python

[subversion-python]
recipe = plone.recipe.command
libdir = ${python:location}/lib/python2.6/site-packages
command =
 rm -rf ${subversion-python:libdir}/svn
 rm -rf ${subversion-python:libdir}/libsvn
 cp -prv ${subversion:location}/lib/svn-python/libsvn ${subversion-python:libdir}
 cp -prv ${subversion:location}/lib/svn-python/svn ${subversion-python:libdir}
update-command = ${subversion-python:command}

[python]
recipe = hexagonit.recipe.cmmi
url = http://www.python.org/ftp/python/2.6.5/Python-2.6.5.tgz
configure-options = --enable-shared

[python-exe]
executable = ${buildout:directory}/parts/python/bin/python

[distribute]
recipe = plone.recipe.command
command =
 wget http://python-distribute.org/distribute_setup.py
 ${python-exe:executable} distribute_setup.py

[xdv]
recipe = zc.recipe.egg

[trac]
recipe = plone.recipe.command
command =
 ${buildout:directory}/parts/python/bin/easy_install Trac
 ${buildout:directory}/parts/python/bin/easy_install TracSubversionLocation

[theme-public]
recipe = plone.recipe.command
command =
 ${buildout:bin-directory}/xdvcompiler \
 /srv/trac/public/theme/rules.xml \
 /srv/trac/public/theme/index.html \
 --output=${buildout:directory}/etc/trac-public.xsl
update-command = ${:command}

[theme-support]
recipe = plone.recipe.command
command =
 ${buildout:bin-directory}/xdvcompiler \
 /srv/trac/support/theme/rules.xml \
 /srv/trac/support/theme/index.html \
 --output=${buildout:directory}/etc/trac-support.xsl
update-command = ${:command}

[theme-aclark]
recipe = plone.recipe.command
command =
 ${buildout:bin-directory}/xdvcompiler \
 /srv/aclark/theme/rules.xml \
 /srv/aclark/theme/index.html \
 --output=${buildout:directory}/etc/theme-aclark.xsl
update-command = ${:command}

[theme-blog]
recipe = plone.recipe.command
command =
 ${buildout:bin-directory}/xdvcompiler \
 /srv/blog/theme/rules.xml \
 /srv/blog/theme/index.html \
 --output=${buildout:directory}/etc/theme-blog.xsl
update-command = ${:command}

You can check out the rest of the buildout here (themed with XDV ). And if you enjoy this post, please feel free to pick up a copy of Plone 3.3 Site Administration from PACKT Publishing, due out any day now (I am expecting to review pre-finals this week some time).

For the past 14 months or so, I have been writing a book aimed at end users of Plone; folks that have little knowledge of how to do much more than add content. It is intended to make them feel more comfortable performing various site administrator tasks. Topics like theming, maintenance, and optimization are covered.

But wait, there’s more!

#1

This book aims to “lower the Plone bar for users of Python”. What do I mean by that? Basically this: I love Python almost as much as I love Plone. It lets me translate my thoughts directly into code. I fantasize that with little more than a Python interpreter, one can forge a working Plone site within minutes. But it is not just a fantasy, it is (more or less) the status quo. (Maybe even MacGyver used Python?)

So, this book begins at the beginning: by making sure folks are comfortable installing and using Python on there operating system of choice (or using the pre-installed Python). If you read Professional Plone Development, you may recall Martin Aspeli saying at the beginning of Chapter 3:

We will assume that Python 2.4 gets invoked when you run python on the command line.

This book does not make that assumption and tries to cover everything you may need to know after installing your operating system up to that point.

In Chapter 1, we cover installing and running Python on three popular operating systems: Mac OS X 10.6 (my main squeeze), Windows 7, and Ubuntu 9.10 (Debian is my main production server squeeze). Other operating systems are welcome; your mileage may vary.

#2

This book is largely a response to the whole “Oh no! I have to use Buildout to install Plone and its add-ons!” sentiment that has been prevalent since Buildout was first introduced to Plone several years ago. I don’t know if Buildout was the “right” way to go, but I do know that I love using it and I would like to help others feel the same way.

The bottom line is this: Plone made a conscious decision to “become more Pythonic” by using eggs. With that choice came more complexity from potential conflicts between eggs. Buildout is one solution to that problem. Unfortunately, it introduces other problems like cryptic error messages and a certain too-many-moving-parts-ness.

An aside…

Let me correct myself: I am fairly certain Buildout was the right way to go at the time. What I am not sure about is where to go from here. It would be nice to get back to a place where folks could just drop packages in to a directory (I don’t literally mean going back to old-style products, but perhaps we could provide that type of functionality again somehow). But I don’t have an answer for that. In the meantime, let’s make everyone more comfortable with using Buildout.

About the rest of the book…

The book teaches you to find your way around Buildout and Plone. Whether you choose to follow along and build your site from scratch using only Buildout (and a paper clip) or if you use one of the Buildout-based installers (like the Unified Installer), this book aims to make you more competent and comfortable performing a variety of Buildout-related tasks.

In Chapters 2-7, we present various buildout configuration files that correspond to specific tasks that are related to various subjects, e.g. theming, maintenance, and optimization. The reader is expected to “know how to write a buildout.cfg file” by the end. No one that reads the book is allowed in the #plone IRC channel afterward to ask about buildout (you can answer buildout questions though). Kidding… I kid…

In the final Chapter 8, we cover new technologies like XDV and repoze.zope2 which may become more mainstream once you decide to start using them (although the latter seems more like a toy to keep us busy until the real fix arrives: full WSGI support in Zope 2).

When will it arrive?

PACKT originally announced the book will arrive in March and I have been working non-stop since mid-March to make sure it gets out the door as quickly as possible; I expect it to be available Real Soon Now™. I apologize to those of you who have pre-ordered and are now waiting for it!

So get ready! I plan to have over 200 pages of draft material submitted by the end of this month. I will continue to work with PACKT to address any concerns that arise during editing. They have promised to try to ship the book by May, so we will see how it goes. I encourage you to pre-order now as that will go a long way to inspire them to work just that much harder to get it done and out to you, ASAP!

Can I write a book?

Probably. For those curious about the process (as I very much was), here is a bit about how it went for me:

1. A few years ago, Martin Aspeli had the idea for Practical Plone 3 and put out a call to writers that I responded to; I ended up contributing 2 chapters. This taught me that it was indeed a lot of work, and I got exposed to the editing process.
2. A couple years ago, PACKT approached me (and several others) about the idea for Plone Site Administration and I thought I had a good story to tell based on my experiences, so I wrote a detailed outline and they accepted it.
3. Though I had written for Practical Plone 3, I struggled to find my voice. At the same time I had a tremendous amount of consulting work to do to make a living. I sneaked in time to write drafts and eventually found my voice. To be honest, the most productive work has been done in the last 3 months.

Perhaps the biggest lesson I learned was this: stop thinking and start writing. I tend to over analyze things and spent a lot of time thinking about “how it would go” rather than just writing it. Writing is the key. Think less, write more (at which point your thoughts tends to flow more naturally anyway).

Should I write a book?

Possibly. I am sensitive to the phenomenon of “Plone book diarrhea” and I do think that there can be such a thing as too many Plone books. But I don’t think we are there yet. To me, the more books published about Plone (by PACKT or any publisher) the better. I like to see what each individual author brings to the story, even if the stories they are telling tend to overlap sometimes. So for me the answer to that question both before and after writing my book is yes. I know I am a better writer having written it, and I certainly know more about Python, Zope, and Plone and many other technologies.

In either case, you should definitely take my class.

If you are interested in learning more about Python and tools like Distribute, Pip, Buildout, etc. and you want to feel more comfortable managing your Plone site, you will not want to miss the one day class I am teaching at Plone Symposium East 2010!

The book will hopefully be out by then, but the class will go on either way.

Hope to see you there, and I hope you enjoy the book.

P.S. Looking for Plone experts? Hire ACLARK.NET, LLC.

Thank you, everyone, for the responses to my previous blog entry. I have had some great conversations with some very interesting folks and I appreciate everyone’s interest. However, I wanted to encourage everyone once more to get in touch. And also, to feel free to reach whenever you come across this blog entry and are in need of Plone help. We are always looking for a challenge.

But it is time for a change.

Image credit: http://screenmusings.org/ForrestGump/pages/fg_0885.htm

If my life were the movie Forrest Gump, this would be the part where Forrest stops running, stands in the highway for a minute… then turns around and goes home to Greenbow Alabama (which as it turns out is a fictional town, who knew?)

(Apparently this person had the same epiphany!)

Not a drastic change mind you, just a re-focus.

To that end, I would like to reach out to the community I know and love (Plone!) and see if anyone has anything for me to do. Please contact me if you are interested, and please tell all your friends too! You never know who knows who and who is looking for what.

Let me tell you a little bit about what I have done professionally and what I would like to do now, followed by some requirements I hope can be met.

What I have done:

• I received a Computer Science degree in May 1998 after about 10 years of undergrad education (transferred, changed majors, etc.)
• I’ve done a lot of system administration and network engineering, mostly for ISPs including AOLnet (back in the day).
• I have done a lot of Plone.
  • I started doing Plone at my last full-time system administrator job, and became so obsessed with it that I had to quit to pursue it full time, mostly thanks to the support of my wife Amy, and Paul Boos and Nate Aune who handed me my first contracts!
  • I have organized monthly meetings for ZPUGDC for the last 4 years or so, taking over for Joel Burton when he moved to California. We are now in the process of becoming a 501c3 so we can expand our focus and serve the community in bigger and better ways. ZPUGDC is not a full time job, but it as a passion (to be a resource for all things Python in DC).
  • I have owned and operated ACLARK.NET, LLC for the past six years. All in all this has been an amazing experience and I have no plans to stop. We are now at the point where we can compete with all the “big firms” and we intend to do so. But I need time to answer some RFQs…
  • I organized Plone Conference 2008 and wrote a book.
  • I upgraded plone.org to Plone 3, and now lead the plone.org infrastructure team member, taking over for Wichert Akkerman (more or less) when he left. This is something I particularly enjoy. No wait, I hate it. Just kidding. It is something I like, and plan to focus on it more in the future to make sure it gets done right. It is very frustrating to want to do something but not have  time to do it. I’m sure all you Plone consultants know what I mean.
• I have done some Python programming and evangelism:
  • I have paid particular attention to making ZPUGDC more Python-centric, by welcoming all Python programmers in the area not just Plonistas. This has worked out very well and our monthly attendance has gone from 5-6 to 15-20. Each month, we go around the room and talk about “what we are doing with Python”. It is always interesting.
  • I write code. I am particularly proud that working for myself has afforded me my first paid programming job (programming for system administration doesn’t really count IMO). There is a ton to learn: Networking frameworks like Twisted, Web application frameworks like Zope, Django, Turbo Gears, Pylons, BFG, etc. Continuous integration with Hudson (OK, that is Java but you can use it on your Python code ), Documentation with Sphinx. And so on.

What I would like to do:

• Open Source Software: I really like open source software. It started in the mid 1990s when I realized that there was this thing called the Internet and that people had been writing code for years and making it available for general use to anyone interested. That just floored me. I can still remember the thrill of borrowing a UNIX text book from my professor the summer before I started CS classes. At the time, it seemed like UNIX and open source walked hand in hand and I became obsessed with both. I realize now there is much more to that story, but that is how the seeds were planted. Anyway, open source is for me and I am for open source. I am not sure what that means in terms of job opportunities, but maybe I could be an evangelist like Mark Hinkle, and evangelize Your Software like he evangelizes Zenoss. Just a thought.
• Plone, Python, Zope, Zenoss: I really like these open source projects, in particular. Any paid position that involves almost any aspect of these projects would make me happy. I have pimped myself out to Zenoss and I eventually expect to hang out my Zenoss shingle and start doing add-ons, customizations, etc. for Zenoss users. But I am not quite there yet. I know Plone, and can handle most development and deployment tasks. I am particularly interested in large-scale deployments (e.g. City of Austin type clients, only with a better outcome ).
• Busy work. It sounds silly, but repetitive tasks fit my brain. Automating large scale deployments. Configuration management. System updates. These things I can do, and help you with too.
• Learn: If there is one thing I’ve learned after learning so much over the years, it is that I hardly know anything. I hope to be a part of team that offers a significant growth opportunity. It’s time to raise the bar.

What I require to work for you:

• Six month contract or longer. Whatever I sign on to do, it has to last six months or more (preferably until the end of 2010). This is the time frame I am particularly concerned about (for a variety of personal reasons). I can start April 1 or after. Repeat: it is definitely OK if it lasts longer than six months.
• Travel. I can travel almost anywhere in the world, as long as you pay for it . But seriously, working from home is a requirement, but meetings (monthly? bi-monthly?) in your city should not be a problem.
• Fun and flexibility. I do Plone for a living because Plone is fun. I work very hard to make sure your needs are met, and I ask for a lot of flexibility in return. Deadlines are not a problem, but the ability to act independently to meet the deadline is.
• Paid Plone work. Ideally someone will hire me to do all the things I already love to do like maintaining plone.org, sprinting on various tasks, perhaps joining the Plone 4.1 Framework Team. Anything and everything I can do to make the Plone project better and stronger. This of course does not have to be the main focus of the work, but it would be nice if some time could be allocated officially towards these tasks.
• Part time. Ideally I’d like to put in about 20 hours per week on some project, and spend the other 20 hours on ACLARK.NET, ZPUGDC, INC.

Above all, I am flexible. This post is about me, but I am certainly willing to listen to what you, prospective employer, has to offer. If there is a good fit, I am confident we can make it work.

I look forward to hearing from you!

Oh, I almost forgot, my updated resume is here: http://aclark.net/team/aclark/resume. Or if you prefer PDF: http://aclark.net/team/aclark/resume-pdf.

I know, because I just deployed one (a cool artist’s site if you have a couple hours to kill…). But I didn’t do it the “old way” with Zope 2 instances created by hand on clunky physical servers, I used Buildout and the Cloud.

Aside #1

As an aside: it was really bothering me lately that you couldn’t (easily) find older Plone releases at SourceForge. This is by design to avoid confusion, but still confusing. So when I needed the most recent 2.1.x tarball I decided to scratch my itch and fix the “problem”. I started gathering the hard to find releases and putting them here. OK… so I only gathered one release (2.1.4), but I swear I had good intentions. If you’d like to see any additional releases “moved” to dist.plone.org, please let me know in the comments.

Aside #2

Another aside: I should mention here the advent of a tool that promises to simplify deployment of Python-based web applications to the cloud (or supported service, which technically does not have to be “cloud-based”) via the use of APIs (in particular, the Rackspace Cloud API, which is the only one supported so far): Silver Lining! The idea of using this tool got me so excited, I spent some time experimenting with setting up a new host with it (and purchasing their service). But when I realized it was not quite ready for production (i.e. “if you want to use Silver Lining, Silver Lining is not for you” ), I ended up using the Rackspace Cloud web interface.

I was so impressed with it:

I literally moved all of my (granted, relatively small number of client sites) to their service within a matter of 1-2 months. Now, I know what you are thinking, and I do intend to explore other services (in fact, I have tried Slicehost and it was OK), but this service made my life so much easier I wanted to mention some of its key features:

• “On the fly” requisitioning. You can add/remove hosts anytime and you only pay for the time they are up.
• “On the fly” resizing of hosts. In my testing and real world experience, the resizing (e.g. move from a host with 256MB RAM and 10GB disk to 500MB RAM and 20GB disk) was painless (literally only cost a few minutes of downtime).
• The potential for all of this to be done remotely via a command line tool like Silver Lining.

Aside #3

A third and final aside: the status quo of WSGI support for Plone. Since Zope 2 is not supported by Silver Lining, the key to deploying Plone sites with it is currently to use repoze.zope2. Nate Aune has recently made some progress with this, and more work is scheduled for Plone Symposium East. My latest swipe at WSGI-Plone is here: http://svn.aclark.net/svn/public/buildout/plone/branches/3.x-wsgi/

The actual point

And finally, to the point of this blog entry! I have created a generic Plone 2.1 buildout for anyone interested. You can find it here: http://svn.aclark.net/svn/public/buildout/plone/branches/2.1.x/. Using it is simple, as described in the README.txt:

 $ svn export http://svn.aclark.net/svn/public/buildout/plone/branches/2.1.x/ plone
 $ cd plone
 $ python2.4 bootstrap.py
 $ bin/buildout
 $ bin/instance fg

Since Plone 2.1 community support has expired for this release, and since Plone 2.1 shipped with Python 2.3 (if I recall correctly), this is definitely “unsupported use of Plone”. But when you need it, you need it. I have yet to experience any issues related to the Python version, for whatever that is worth (possibly due to the fact that Plone 2.1 originally shipped with Python 2.3 and Zope 2.7, then Zope 2.8 came along which worked with Python 2.4. Just a guess).

Generally speaking, the recommended (and supported) way to install Plone is via the installers, e.g. the Unified Installer. Obviously, if you want things to Just Work™ you should be using the latest stable release, which is why I linked to the 3.3.3 unified installer (although there is no Windows installer for 3.3.3 yet, which is why it’s not released on plone.org).

That said, since both Plone and Zope 2 have been packaged as eggs  (Plone became an egg in version 3.2 and Zope 2 became an egg as of Zope 2.12 which is the version of Zope 2 that Plone 4 will use) it has become “mostly trivial” to write a buildout.cfg to install Plone with. That means that you don’t even need paster to do it. You can just fire up an editor and type:

[buildout]

parts =
  instance

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
eggs =
  Plone

Amazing!

Of course there is the nasty bit about PIL, which I get around now-a-days by adding a very specific find-link, e.g.:

[buildout]

parts =
  instance

find-links = http://dist.plone.org/thirdparty/PILwoTk-1.1.6.4.tar.gz

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
eggs =
  PILwoTk
  Plone

What you should have at this point is a working Plone, but not necessarily a repeatable buildout. The reason being we have not pinned any egg versions yet, so we are effectively asking for whatever the latest version of Plone is on PyPI. Fun for playing, not fun for production. Fortunately the nice Plone people have created a bunch of version pins for us, so we just need to use them:

[buildout]

extends =
    http://dist.plone.org/release/4.0a3/versions.cfg

versions = versions

parts =
  instance

find-links = http://dist.plone.org/thirdparty/PILwoTk-1.1.6.4.tar.gz

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
eggs =
  PILwoTk
  Plone

If you are completely new to buildout and you are thinking to yourself right now “what in the world is this guy talking about?” then you will likely want to install buildout first so you can join in the fun. Fortunately, the nice Python people have made that easy with a package called Distribute.

Following their instructions, you can do this:

$ curl -O http://python-distribute.org/distribute_setup.py
$ python distribute_setup.py

Then:

$ easy_install zc.buildout
$ mkdir plone
$ cd plone
$ buildout init

After which you will have a buildout.cfg file, and you can follow along with the above steps. Happy?

The best part about all of this is that (on a fast internet connection) it should only be a matter of minutes before you are able to do this:

$ bin/instance fg

and be staring at:

Of course, if you are running in the foreground (recommended for debugging) you should see something like this:

aclark@Alex-Clarks-MacBook-Pro:~/Developer/public-plone/ > bin/instance fg
/Users/aclark/Developer/public-plone/parts/instance/bin/runzope -X debug-mode=on
2010-01-07 12:07:56 INFO ZServer HTTP server started at Thu Jan  7 12:07:56 2010
 Hostname: 0.0.0.0
 Port: 8080
2010-01-07 12:08:14 INFO Zope Ready to handle requests

If you’d like to get a little less noisy and skip debug mode but still run in the foreground, you can use April 2008′s famous addition to plone.recipe.zope2instance:

aclark@Alex-Clarks-MacBook-Pro:~/Developer/public-plone/ > bin/instance console

Sweet, blissful, silent running Plone.

Happy Plone 4′ing all!

My first blog entry was well over two years ago. I’ve learned enough Plone since then to know that I hardly know anything! Toward the end of 2009, I begin to realize that I was doing way too much, and not getting anything done as a result. So I began offloading services wherever I could to free or low cost service providers; I can’t tell you how much happier I have been since then.

Interestingly, after waffling over the use of these services for years, when push came to shove I had no problem choosing the right tool for the job. It didn’t matter so much what selection I made. The fact that I offloaded the responsibility was the most important thing.

Which brings me back to the subject at hand. I love Plone. I think it is great software. I want to make it better. In order to do that I need to broaden my horizons and use the right tool for the job, and hopefully bring those experiences back to Plone!

Hence, introducing my new WordPress-powered blog about Plone. I’m still using Plone for aclark.net (of course). I just don’t want to “manage” the blog software anymore. I want it done for me so I can focus on other things. Since WordPress is so obviously the leading “best” weblog software, it was an easy decision to make.

(Of course, this blog was shipped using Python software.)

Lastly, I’ll say this. I want to be more prolific in 2010, and I’m hoping that using the right tool for the job will help me achieve that. It has worked wonders so far.