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.

Beware Documentation By Topic

Yes, I know its supposed to be 'Browse', but while looking up some documentation and being distracted I took 'Browse' as 'Beware'. Since it was Grok I immediately thought of rampaging cavemen.

Heh. Fridays...

Ruby Security Problems

On the surface:

http://www.ruby-lang.org/en/news/2008/06/20/arbitrary-code-execution-vulnerabilities/

Digging deep:

http://www.zedshaw.com/rants/the_big_ruby_vulnerabilities.html

In my world, Ruby is the dark side. Tantalizing and yet there is a rock of stability about Python that I really enjoy, even if I can't define what I mean. Maybe its the security to know that the language is deep as it is broad?

Anyway, at least for today I'm grateful I've stuck with Python.

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

MVC public service videos

The railsenvy guys do it again with a series of public service videos on model-view-controller. I especially like the third and fourth videos. Unlike their RoR versus videos, these are tool neutral.

http://railsenvy.com/2008/6/3/mvc-videos

Must use ubigraph

I finally spent a few minutes playing with Ubigraph, a 3-d animating tool for generating nodes and edges graphs on the fly. The API is straightforward xmlrpc which Python handles very well. The result is nothing less than amazing.

Granted the documentation needs work. But even what exists lets you do a lot of really fun things. I look forward to finding ways to use this amazing tool. As I go forward it will be interesting to compare the very complete (some say cluttered) Graphviz feature list with that of Ubigraph.

Its all good though. This makes a great companion for Graphviz. Thats because Graphviz can generate things in many static image formats where as Ubigraph renders inside an OS window that I guess you can capture via Flash or Quicktime. So both have their place in my world.

How not to build a view

I like simple, sweet, and easy to use. Which means sometimes Zope 3 style things are awesome, and other times it sucks. What's worse is implementations you have to maintain where someone took something very simple and made it very complex.

In our case study, lets see what a predecessor to me did using Plone and a lot of Five:

1. Extended the ATEvent type.
2. Created a view using portal_catalog. This creates an object which calls another object which calls a specific function to grab relevant data from each brain object and place that data in a dictionary.
3. Made the view, 2 objects and functions bolded above not as extensions as other bits that existed elsewhere but coded them individually.
4. Tied it together with zcml.
   

The end result was a results object containing brains and a counter. Um... okay. I understand this was done so that the Plone template serving this would have the batch features and all, but this is over engineering.

I think a better solution would have been this:

1. Extend the ATEvent type.
2. Create a utility package with code to be reused in creating batches later.
3. Make the view call the utility package so you don't have to code much.
4. Tie it together with zcml.

I like this method. The better developers I work with and the gurus I admire will tell you any time you write the same section of code more than once you should look at code reuse techniques. Either wrap your code in functions, use inheritence, or play with polymorphism. All that good stuff.

Sigh.

At least I get paid to maintain this code. Finally it isn't in the NASA effort.