Announcing Garbaginator!

While working on Packaginator at the PyCon 2011 sprints we discovered some serious issues in the way that Django handles garbage collection. After a huge amount of work, we managed to isolate and fix the problem. This 'fix', as it were, was only possible by doing a very sophisticated 'hack' of critical internal components of the Django Web Application framework. We also discovered that similar issues occurred in other existing Python application frameworks such as Pyramid, Flask, Web.py, Web2Py, Grok, Twisted, Tornado, Google App Engine, and Rails.

Since then the Packaginator community has been fiercely debating what we should do with our newly created set of hacks. After a lot of arguments going both ways we've decided to come up with our own application framework and release it to the world under the GPL license.

This brand new application framework ignores the lessons learned from all the other Python frameworks and embraces the cutting edge concept of Not-Invented-Here. It focuses less on features and enhancements over existing systems and much, much more on the critical concept of formal Garbage handling.

Some of the critical modules include:

• RubberGloves (for handling dirty objects)
• Django-Garbaginator
• Flask-Recycling
• Pyramid-Garbaginator
• Web.2.py Garbaginator Bridgerator ('cause people always get Web2Py and web.py confused with each other so we bridged them together)
• BlueBream

Check out the home page at: http://garbaginator.cartwheelweb.com

Fork Garbaginator on GitHub: https://github.com/cartwheelweb/garbaginator

Note: This was an April Fool's Day Joke

How to sell Python panel at Pycon

Do you want to use Python but are you fighting Fear, Uncertainty, and Doubt (FUD) in your organization? Does any of this sound familiar to you?

• Python is just a scripting language.
• Python is too new to use in real production environments.
• Language X has better benchmarks doing obscure math so it is better for web development.
• Python sounds great but we've already spent so much on this expensive tool that does things badly!

A lot of people want to use Python, but their customer, management, school, government, or organization won't let them. Python is a great tool, but can be challenging to get in the door. This panel will explore how companies and individuals have successfully introduced Python, what tools are available to sell Python, how to fight the good fight, and what pitfalls there are to avoid.

Panel Questions
For this event at Pycon I've got some stock questions ready but I want the community at large to suggest some more.

Speakers
For this panel I choose five speakers from the broad categories of academia, government, commercial organizations, and non-profit who have had a known impact in their organizations:

Academia
C. Titus Brown is an Open source hacker, Artificial Life/Digital Evolution, B.A. Math (Reed), Earthshine research, Ph.D. Developmental Biology and Regulatory genomics (Caltech), Python testing tools, Python Software Foundation member, Assistant Professor (Michigan State U.) - dev bio, genomics, metagenomics, software engineering. 

Note: A lot of my personal understanding on how to do web tests outside of Selenium is thanks to a Pycon tutorial given by Dr. Brown and Grig Gheorghiu back in 2008. 

Government
Chris Shenton is a partner at Koansys LLC, a consulting company whose clients include US Federal Government agencies, Internet startups, and non-profit organizations. He is a free software and UNIX bigot, advocating for the use of both in organizations large and small. He's been involved with the Washington DC area's Python/Zope/Plone user group ZPUGDC for years, and recently was appointed to its board. 

Note: Chris has the dubious honor of introducing me to Python in 2005 and was pivotal in promoting the adoption of Python for use in NASA's Science Mission Directorate. 

Large BusinessThe Vice President of Engineering at Evite/IAC, Dan Mesh is the person credited by other Evite staff with bringing Python to life in that business. 

We used Evite for our just passed LA area hackathon and plan to use it for future events. 

Non-Profit Organizations
Rich Leland is an Application Architect at National Geographic where he uses Python on a daily basis to work on nationalgeographic.com and its ecosystem of web sites. He is also the founder of django-district, a group for Django users in the Washington, DC area. In the past life he worked for Discovery Channel as Designer and Lead Web Developer. 

Small Business
Frank Wiles is President of Revolution Systems, Lawrence, KS. Expert in Internet infrastructure scaling and performance. Primarily focused on Django and PostgreSQL. 

Note: I credit Frank with providing me with a great opportunity to work with an awesome code base but also the encouragement and support to get me through my first year as a freelance consultant.

Why you should go to Pycon

Because you are new to Python
If you want to get better at Python then Pycon is one of the better avenues to learn. Think of it as a nine day data dump of Pythonic knowledge straight to your brain!

When it comes to the fundamentals of Python, the tutorials are a great way to hit the ground running. How do you think I learned? Also, there are dozens of beginner talks designed to introduce you what highly qualified people think you should be doing. Finally, the sprints are a great way to work with real experts for days - because even the most advanced projects needs people to knock out the invariable score of simple bugs, do documentation and write additional tests.

Also, Zed Shaw is going to teach his Learning Python the Hard Way tutorial throughout the conference. (follow that link!) To summarize, besides going over his lessons and some basic conference coaching, he's going to take his class to conference talks and then bring them back to apply what was learned. He won't be doing it alone either - a number of other python folk are going to volunteer their time to help, and I'm going to be one of them.

Because you are old to Python
A good chunk of the tutorials are designed specifically for experienced Pythonistas wishing to expand their knowledge (OMG Raymond Hettinger). And then as we all know the conference itself has scores of advanced talks designed to challenge you. Finally, what better place to work on your favorite project or get people to work on your project then the massive Pycon sprints ?

Want to do Python related technology full-time? What better place to look then where amazing companies and organizations hang out with the intention of hiring people? And invariably some of those hiring groups will be hosting parties too...

Because you are recruiting
Looking for good staff to do Python, Django, Plone, Pyramid, wxPython, NoSQL, Linux admin, Unix admin, BSD admin, Windows admin, Science, or Engineering work? Pycon will be where 1500 of the best and brightest people on the planet will hang out for over a week and some of them will be interested in new opportunities. Sponsorship is a great way to get yourself noticed by hundreds of Pythonistas.

Because it is cheap
Until January 25th Pycon registration is at its early bird prices. Even when it goes up it is still a pretty good deal. Admittedly the biggest expense is the hotel ($159/night) but there are decent and much cheaper hotels ($80/night last I checked) within a few blocks of the conference.

Stupid Template Languages

For years I've been absolutely certain that I really prefer stupid template languages any time I'm generating HTML. The less the template language can do the better. Since I spend most of my time coding in Python you might assume this applies just to Python, but I think it also applies to anything where you have the power to readily mix HTML generation and code.

The biggest annoyance I have with smart template languages (Mako, Genshi, Jinja2, PHP, Perl, ColdFusion, etc) is that you have the capability to mix core business logic with your end views, hence violating the rules of Model-View-Controller architecture. While the web can be hard to match to MVC, in general you aren't supposed to do that sort of thing. I've made the mistake of putting core logic in the wrong places in the past, but I'm proud to say I've gotten good at avoiding that particular mistake.

I don't work in a vacuum.

I often work on projects crafted by others, some who decided for arcane/brilliant/idiotic reasons to mix the kernel of their applications in template function/macros. This is only possible in Smart Template Languages! If they were using a Stupid Template Language they would have been forced put their kernel code in a Python file where it applies, not in a template that was supposed to just render HTML or XML or plain text.

What it comes down to is that Smart Template Languages designers assume that developers are smart enough to avoid making this mistake. Stupid Template Languages designers assume that developers generally lack the discipline to avoid creating horrific atrocities that because of unnecessary complexity have a bus factor of 1.

So what is a Smart Template Language?

In my own vernacular, template languages that let you write functions/macros are what I call a Smart Template Language. Some of them are brilliantly executed, the example of Jinja2 comes to mind, but invariably I suffer through abuse of its Macro control structure as implemented by others.

Misery Cubed a.k.a. Genius Template Languages

Next comes Genius Template Languages, which take things a step further. These template languages allow you to not only define functions/macros, but also let you embed unrestricted Python (or Java or Ruby or whatever) in the template. This 'feature' lets you code your entire application in the templates!  In the Python world what comes to mind is Mako and Genshi, but I'm sure there are many other tools with this 'capability'.

I like Stupid Template Languages!

Stupid Template Languages don't let you define functions/macros. They don't let you embed Python code. They barely let you define variables and often have simplistic control architectures.

For Django efforts, which is about 70% of my work, I like the Django Template Language (DTL). Since it is used by a huge community, there are a ton of useful apps which have it as a dependency. Switching away from it would mean cutting myself off from a large ecosphere of tools I can use to not reinvent the wheel.

Back in my Zope/Plone days I really, really enjoyed the Template Attribute Language (TAL) because it was stupid too. If I needed an XML generation template language and could import it easily I might consider using it again, or perhaps Chameleon, which is a new, improved version . The downside is that they come paired with another tool paired with it, METAL, which gave it macros. My own experience with METAL is that it was all too easy to do what we developers do with Smart Template Languages.

But DTL and TAL are slow!

So what?

If you want to boost your performance, first try caching. There are a ton of tools you can use, with Varnish being one I keep seeing in action. Read the docs on your favorite web framework's caching engine and apply what you learn. And Djangonauts should read up on Mike Malone as much as possible.

If after all that the site still delivers slow content and it appears to be a template language issue, then identify the bottleneck content and consider alternatives for that one portion. My favorite response is a bit of AJAX. Use your framework to render the content as JSON and have JavaScript parse it into legible content, a task which JQuery makes trivial.

Release classifiers in distutils/pypi

Thanks to Doug Napoleone I'm now aware there is already a convention followed for the python and framework versions, but it appears that not enough people are aware of it. This post is pretty much a reposting of the second comment of the post immediately preceding this one and Doug gets full credit for this post. I'm just repeating his message:

The release classifiers in this post should be included in the standard distutils documentation. For the moment, you can see the full list of classifiers here:
http://pypi.python.org/pypi?%3Aaction=list_classifiers

For the python language version the classifier is:

Programming Language :: Python :: x.y.z

With each version on it's own line. That way you can browse the repository by python version (see the bottom of the page):

http://pypi.python.org/pypi?:action=browse&c=214

There is also support for frameworks which you can see on that page as well. There it is done with:

Framework :: Django :: x.y.z

There is Zope, Plone, and a number of other frameworks already there.

In the example you gave the proper, and supported way of writing the metadata is:

Programming Language :: Python
Programming Language :: Python :: 2.4
Programming Language :: Python :: 2.5
Programming Language :: Python :: 2.6
Programming Language :: Python :: 2.7
Framework :: Django
Framework :: Django :: 0.96
Framework :: Django :: 1.0
Framework :: Django :: 1.1
Framework :: Django :: 1.2.1
Framework :: Django :: 1.3

Now it becomes a matter of education and illumination. This should be in the standard distutils documentation and arguably the home page of PyPI (or easily found there). And Django Packages will be supporting this functionality in the near future.

A request for new pypi classifiers

This request is to help enhance Django Packages, PyPM Index, and other projects. This would also help the Python community at large.

Would it be possible that a standard be established for listing in PyPI classifiers which versions of a package is known to operate? Using James Bennett's django-registration at http://pypi.python.org/pypi/django-registration as an example (see my bolded, last two lines to understand what I'm trying to demonstrate):

Development Status :: 5 - Production/Stable
Environment :: Web Environment
Framework :: Django
Intended Audience :: Developers
License :: OSI Approved :: BSD License
Operating System :: OS Independent
Programming Language :: Python
Topic :: Utilities
Python Versions :: 2.4, 2.5, 2.6, 2.7
Django Versions :: 0.96, 1.0, 1.1, 1.2.1, 1.3

The metadata system I'm writing about in this blog post is specified on the distutils documentation page.

I picked a Django package but this could be for Zope, Pyramid, PyQT, or anything.

If we had something like this in place then people could quickly identify on PyPI and other resources if a tool can be of use to them or if it needs to be updated to the latest code base. If this already exists, then can someone point me at the existing specification so I can promote it?

Edit: Noah Kantrowitz suggested I take a look at the 'requires' keyword which is part of the distutils spec. However, this does not show up in the PyPI API (http://wiki.python.org/moin/PyPiXmlRpc) and so doesn't fit our needs.

My pre-history with Plone

In the late 1990s I was working at a job doing a mix of Foxpro development, windows system administration, and help desk. I enjoyed the Foxpro development (laugh if you will) and despised the other stuff. So I was always looking for work in other places where I could be doing pure development. However, lacking much work experience at that time, or knowledge of other programming languages, or a college degree, that made switching positions really hard.

Well, one day, probably in 1999, I stumbled across a job opportunity down in Fredericksburg. I I got an email inviting me down for an interview for Zope Corporation, or maybe its predecessor. The job meant working with an obscure language called Python and a web based development system called Zope. Python seemed pretty interesting, and doing development through the browser seemed fascinating. I even looked up some articles on Yahoo (this was before Google and Wikipedia).

Alas, I did not take the job. Python seemed too different and obscure and I was already stuck in the closet with Foxpro. Fredericksburg would have involved a move from the Washington, DC area and my ex-wife and I were even then scraping the bottom of the barrel for money. We lived on the metro, lacking a vehicle between us, so just getting down to Fredericksburg was nigh impossible. So I stayed with Foxpro, eventually finding work in a few other languages before finding my current home in Python in 2005.

What might have been

In an alternative history had I interviewed and been hired for the Python/Zope job I might have worked with Guido van Rossum during his tenure at Zope Corp! I might still be deeply entrenched with Zope and subsequently Plone. My linux skills would be much better. Fredericksburg would be my home, not Arlington so I probably would not be working for NASA right now. I would have never founded NOVA-Django. Finally, the armies of Iceland would have conquered the world.

A very different universe indeed.

Next: My history with Plone

DC sprints location is official!

All the details can be had by following this link:

http://groups.google.com/group/NOVA-DUG/web/dc-branch-of-the-eurodjangocon-09-sprints

I'm rather excited by this event. It is the first in what I hope becomes a DC tradition of doing 'local mirrors' of python conference sprints with involvement from all the area python groups. This way, more people get to contribute, our community works better together, and the networking opportunities can abound.

On the other hand, I wish I had found more time to organize this event. And that I had found a good location inside of Washington, DC. I suspect this first effort will have a low turnout, but I won't mind being pleasantly surprised. ;)

My hope is that this year alone we might be able to exploit similar efforts in 2009 for the Euro Pycon, DjangoCon, and Plone Conferences.

With that in mind, I'm going to insist that these local mirror sprints be completely framework and tool neutral. For starters, under the hood, aren't we all just doing python? Plus, I'm of the very firm belief that any major system with initiative has things to teach, be it lessons learned or neat ideas. For example, Jacob Kaplan-Moss uses zc.buildout, which grew out of the Zope community. And while we might not have the ability to listen in on actual conference sessions, think about the chances we'll get to look at each other's tools and methods.

Jinja2 in zope

Getting Django Tempates inside of zope is not trivial. Yet getting Jinja2 to run inside of zope is easy! Use easy_install (or whatever) to fetch Jinja2 from PyPi and then from the zope debug shell:

>>> from jinja2 import Template
>>> t = Template('{{ name }} rocks!')
>>> t.render(name='Guido')
u'Guido rocks!'

So what does this mean?

It means that right now you can have Django style templates inside of Plone, Zope, Grok, et al. However, you can't mix TAL and Jinja2 in any way via template inheritence.

Off the top of my head I can think of two possible use cases:

1. You have the HATE for XML based template languages and just need something else for all rendering of all content including HTML. This is actually a very feasible option for Grok and pure Zope application development, yet functionally impossible for Plone. Too much of Plone is woven into TAL to make this work.
2. You are using lots of AJAX via KSS, JQuery, YUI, plain old JavaScript, etc and want something handy to help you write content coming from the server side. This is feasible in Zope, Grok, and even Plone.

The downside of using Jinja2 is that you are adding more complexity to the mix. I like simplicity. I would be very careful about using Jinja2 in Zope products, and would only consider option #2.

Thanks to the the indomitable Ian Bicking for suggesting Jinja2.

What I would change in Plone: Templates

These are my thoughts. My thoughts are not those of the luminaries in any community, but just your average Joe Developer. I formed these thoughts over Pycon 2009, and my experiences with Plone, Zope over 2 odd years and Django over the past 4-5 months. A lot of this is therefore inspired by my recent experiences with Django.

Item #1 - Plone/Zope needs Django Templates out of the box

You heard me.

I like the Template Attribute Language (TAL). TAL is stupid. Stupid in that it is very hard to encrypt my templates with business logic. I like this because I recognize I have no discipline when it comes to breaking the Model-View-Controller paradigm if a framework lets me. I also like TAL because it lets me create XML type documents very easily.

I like the Django Template Language (DTL). DTL is stupid. Stupid in that it is very hard to encrypt my templates with business logic. I like this because I recognize I have no discipline when it comes to breaking the Model-View-Controller paradigm if a framework lets me. I also like DTL because it lets me create non-XML type documents very easily.

I like both languages. Some people do not. Advocates of one template system style say very snarky things about the other template system style. Inevitably it comes down to that one is XML focused and the other is not. And from their point of view, they are completely right.

So I think that a version of DTL should be ported to the Plone/Zope world. And for Plone, it should be made readily available out of the box. This port should do all the default DTL filters and as many of the default tags as possible.

Which would I use? I would use either. More importantly, people who love XML based templates could use what they want and people who hate XML based templates could use what they want.

Everybody wins.

Item #2 - Plone TAL documentation needs a cheat sheet of the good functions

For Django, I can go to the DTL tag/filter page and find a handy reference on all the tags and filters available out of the box with Django.

Where is the same with Plone? The documentation has gotten really freaking good, but where is this sort of handy developer reference?

Yes, I have learned that you can use string methods on strings, and that there are various utility methods you can call if you know the name of the right portal object, but these are not in one easy-to-find location.

We Joe Developers need and love this sort of thing.

Heading off to Pycon 2009!

Tomorrow I'm boarding a flight to go from Washington, DC to Chicago, IL to experience another Pycon. Pycon is the big Python Conference here in the USA.

You can thank the NASA Science Mission Directorate and Indyne Incorporated for sending me to Pycon 2009. I would like to toss out a hearty thank you to the following people for helping me get to this conference:

• Ruth Netting
  
• Jim Consalvi
  
• Corin Turner
• Kathryn Luke
• Malik Abdul Mahmad
• Candace Solomon
• Meredith Mengel
• Vicky Niblett

You can thank these people in person at Pycon:

• Katie Cunningham
• James Saint-Rossy
• Chris Shenton

I can't wait to meet old friends and make new ones. To again gawk at the feet of Guido van Rossum and other luminaries like a gushing schoolgirl over a boy band (All with the proper decorum of course).

While I'm there I guess I need to sheepishly admit to Bruce Eckels an apology. My idea was off. Lets just say that Pycon needs to keep corporate endorsements in the vendor area. It doesn't need help anywhere else. ;)

I am taking a whopping four tutorials, then attending the full conference, then working hard through four days of sprinting. I had thought of volunteering to help with a session or two but backed off since I am not paying my own way there. Instead I will stay focused on the task at hand, which is learning, networking, and contribution to various projects that NASA SMD is interested in supporting.

Look me up if you are there. I'll be playing with the other Python, Django, Plone, Pinax, and Zope kids.

My conference schedule:
webcal://us.pycon.org/2009/conference/schedule/ical/1c68d36a70bd61ea4d0de3a5d5d7e9b8g104/

For those of you who sent me resumes, you are not forgotten! We had hoped to get formal responses to everyone by Pycon but that was not in the cards. Feel free to chat if we bump into each other.

Subscribers Zope 3 style

Vernon Chapman shared this with me. Very elegant.

configure.zcml (brackets replacing XML open/close because Blogspot sucks!)

[subscriber for="Products.CMFCore.interfaces.IActionSucceededEvent"
handler=".handlers.vernstuff_content_thing" /]

handlers module

def vernstuff_content_thing(event):
"""This will do all the work"""
action_as_string = event.action
content = event.object
# Do whatever you like here

Can't seem to use zope debug mode anymore.

I drop out very quickly from my Mac OS X laptop running 10.5. Going to go home and try it on Ubuntu. Grrr... this is a royal pain.

Update: This was because I had a broken version of readline on my Mac. I did sudo easy_install readline and now it works.

I've not quite done LAMP, or have I?

It hit me just now that while I've played with all the individual bits of LAMP (Linux, Apache, MySQL, Python), I've never actually done LAMP per se. I tend to play with Plone/Zope professionally, and in my goof off time I prefer to delve into wxPython, with my Django work being all too rare. I'm wondering if it might be worth it to do some formal LAMP work, and there might be available work at NASA for it real soon.

On the other hand, according to the Wikipedia entry on LAMP the 'M' in LAMP can mean 'middle-ware'. In which case I am professionally doing LAMP every work day.

Thoughts on Python interfaces

Python does not have interfaces. Yet people have implemented interfaces in Python via some really innovative code (PEAK and Zope 3 comes to mind, but Trac also has them). Those people have great arguments for interfaces, claiming documentation and enhancement of system structure. From what I gather the theory is that if you use interfaces its easy to create truly componentized architectures because you know what to expect from a component.

Now that said, I find it really amusing how often interfaces end up being just so much boilerplate. By this, I mean an empty, (or marker), interface. We are given to understand that one can do so much more, but sometimes a framework demands an interface in a particular place, and often that interface is just plain empty.

I've never played with PEAK elements beyond easy_install. I've toyed with the innards of Trac and been shocked by what makes up the core of that so important software tool. Zope 3 is weel organized and I've done some shockingly fun stuff there after I got over the Zope 3 ZCML hump. And in all of that, I barely saw the need for interfaces. So often I wonder if interfaces are needed.

Well, upon reflection for those systems interfaces work surprising well. The underlying code for Trac might be questionable but anyone can make a plugin by following rules obviously managed by the interface system. Zope 3 is really nice once you get past the curve because you can make components and tie them easily in knots with ZCML (or with python in the case of Grok).

The point of these thoughts? Nothing really. I can live with or without interfaces, and use them in the frameworks that need them.

I missed a class taught by Lennert Regebro?

http://regebro.wordpress.com/2008/01/20/what-is-wrong-with-the-course/

It was way back in January. I never heard of it! Did they not advertise?

I doubt I would have gone because at 1500 GBP (about $2900) plus travel expenses (about another $1000) for three days it was way too much to either pay myself or get NASA to fund. Especially since the Plone boot camp is $500 for five days and was held locally.

Still, if I had known, I would have contacted him and begged for a more affordable class held in the Washington, DC area. I bet I could convince ZPUG-DC to host him and Jorgen, I'm sure of it. It would be worth it because Lennert is a really great guy and maybe if I had hung out with him more at Pycon I would be a better plonista today.

Later today if I get a chance I will email him and see what can be done.

Me Grok generate Add and Edit forms!

So the first bit of documentation in the grok docs didn't work. Grok has evolved a lot so this is understandable. My thought when I dropped the effort in frustration was that my knowing of where the URLs for the add and edit forms were off. Since the docs I was first working on lacked the URL of what I where I was supposed to go that answer seemed to make sense.

My co-worker suggested I go to the explicit name of the view, which in the Zope 3 world is '@@' this or that. A good suggestion but that didn't work. More on that in a bit.

Examining the Developer Notes I discovered that the docs I was using were out of date. I changed my code to fit the notes, pointed Firefox at the URL named after the form classes, and it just plain worked. Code changes were minimal. And I'm posting to the Grok folks that the form docs are out of date.

Anyway, you can go to /myview or /@@myview in Grok. Which is good. For some reasons that others explain quite well, Zope 3 has this whole big thing with '@@' and '++' in URL bars to explicitly name views, adapters, utilities, oversized SUVs, bad American food, et al. I'm sure some people can't live without them but honestly since Grok avoids them it makes things feel more... pythonic.

Anyway, the add & edit forms, now that I can make them work, are wonderful. Pretty HTML forms with validation done in moments off a little python code.

Me Grok Smash!

So as I started on yet another graphviz application for the web, I decided to go with a new framework. I would use Grok!

Grok comes out of the Zope community, and has its foundation in the rather mature components of that application server. The difference is that tying bits of Grok together does not rely on seemingly arcane xml files. You just code in Python and a bit of TAL for the views. If you want you can leverage in more bits from the Zope world, such as zope.formlib and other interesting bits.

It is a matter of public record that I have a like/hate relationship with zope.formlib.

There are some really nice things I discovered about Grok:

• Intuitive.
• Only one magic bit, in that class defined as views look for their lowercase template automatically, and you can override this if you like.
• The framework is out of the way.
• Inheriting models is a cinch.
• Lets you play with either the ZODB or SQL ORMs.
• Easy use of TAL.

Some negatives:

• A possible gotcha when you instantiate an object inside another object requires you to do a super(MyObject, self).__init__() inside the object's __init__. Not sure why I should have to write this out and it might be I did something wrong.
• Um... still trying to find faults.

I'm rather pleased. Grok has grown up lots since I really looked at it in late autumn of 2007. I look forward to working with it more.

Umlizer lives!

Still is an early alpha release but nevertheless it lives! At this moment it currently handles all the formats I want for version one and has been tested against all target Plone versions. In other words, it meets the requirements I set for this tool, and now what remains is cleanup, documentation, and more testing.

What is Umlizer?
Umlizer is a Plone 2.5x/3.x package that introspects your Zope Object DataBase (ZODB) and then returns a view of your database in the specification that you want. Currently Umlizer provides the following formats for its view:

• DOT for rendering into UML via graphviz
• UML in JPG rendered via graphviz if graphviz is installed
• HTML list for easy reading
  
• Comma Seperate Values (CSV)
• 3-d animated graph rendered via ubigraph

Before you ask this is a very Plone specific tool. Django already has a similiar tool called DjangoGraqhviz.

Why Umlizer?Umlizer was designed to represent the complexity of the Nasa Science site architecture, which was originally a rather complex UML diagram. The XMI for that UML diagram became corrupted, and we did not have a backup. Training people on the database has thus been a chore since, whether they be developers or content editors. In a couple other projects I've noticed that going through Plone code to figure out an architecture can be a pain. So what about a pretty diagram?

For nearly a year I tooled around with different iterations of this effort. In general, each of these iterations relied on protected Python scripts in Plone, which are limited and forced the user of the tool to make many steps before getting a view. These scripts were fragile and arcane, and just plain sucked. Different views of the data were impossible to generate. The latest version of this hack had really nice code, but was a hack.

So I thought, why not try to make it a Zope 3 style Plone package again? My previous attempt in September of 2007 tanked, but my skills in this arena had really improved thanks to training, a cancelled Zope 3 effort, and lately my co-worker Reed's insistence on using it and my need to maintain and extend his work.

Also, in the Plone community, thanks to Jens Klein we have ArchGenXml which is why we used UML in the first place. When I met him in Italy in October of 2007 for Plone Conference 2007, he told me about a pet project of his called Genesis. From what he said at the oldest pizzeria in the world is that Genesis is ArchGenXml with a very modular architecture. So I was determined to make this as modular as possible, trying to work outside the confines of Plone and isolating individual pieces as much as possible.

After about a week of playing with this along with my other duties, Umlizer is working at an alpha level!

Where can we get Umlizer?
That is a very good question. Because of our internal need for documentation this was done under the auspices of NASA. One of the things on my schedule tomorrow is asking for permission to release Umlizer as an open source package. Since there is nothing sensitive about Umlizer, I don't see anything preventing its release.

Should I write a book?

I could be writing a technical booklet of sorts that might grow into a full technical text. Maybe for Plone 3, Zope 3, Grok, or Django. I think I would really prefer writing something for Django. Some concerns:

• Time. Where would I find it?
• Is the pay worth my effort?

Some alleviations to my concerns:

• My consulting has been going slowly. Time could come from there.
• Writing a book would get me more and better work thanks to recognition