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.

Pluggable Authentication System for Plone

It took me a little to get started, because the paster template for Plone 3 Pluggable Authentication System (PAS) products doesn't work for me. Not sure why, so I submitted a ticket.

Anyway, once I figured out that it was the template, and not me, things went very fast. PAS is rather straightforward when you get the hang of it. The quick summary of how to do a PAS plugin as how I've done it:

• Grab the gmail auth plugin and use that as your base.
• In your 'content type', import and register the appropriate method and in the content type's class, create the appropriate method.
• Follow the PAS documentation on Plone.org for different actions you might need to do.
  

Yeah, very basic. I also figured out how to detail properties that can be set via the ZMI. Easy, but the documentation is not as easy to find as it should be.

I might document things in more depth since in some ways this took much longer than it should have considering the simplicity of the end code. I'm sure the Plone folks would love a detailed set of PAS examples to reinforce the current documentation, and I seem to enjoy doing that quite a bit.

Heh, while I'm at it, maybe I should finish my KSS documentation that I left hanging since the Naples Plone Conference in 2007?

Anyway, my quick review of PAS is that its really powerful. That each element (Authentication, Authorization, Challenges, etc) is seperated into its own plugin/module means that you can switch out components without jeopordizing the security and role system that might already exist. So, for example, if you want to use LDAP for authentication and SQL for authorization and a Smart Card to handle security challenges, you can do that without having do rewrite the core Plone engine. Another big bonus is that to do the actual replacement of individual plugin/modules is really easy once you figure out how. And that is pretty damned hot.

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.

Trials and Tribulations of avoiding vi

So I'm stuck working today with a Solaris box. That means no Emacs. Heck, that means even no nano! Instead all I have is vi. Oh no!

Sure, some of you think vi is great. More power to you. Its just not something I like to touch, even if I grant automatic respect to anyone who uses it well. Just like watching any competant craftsman doing their daily tasks, watching a good vi master is pretty fun.

I've been spoiled by Redhat, Ubuntu, and Mac OS X. They come with Emacs installed, and if you have a few rights, you can add in new text editors. On Mac OS X I'll use Textmates, but otherwise I'll make do with Emacs or even Nano if I must.

If I could have argued successfully for more rights on the Solaris box, and had the rights to download software, I would have gotten Emacs working on that machine. Alas, the chance of that happening is around the same amount as a presidential political candidate not selling out his morals and ethics. Which means it ain't happening.

So, my work around?

I had access to the python shell. I wrote the file in there and saved it to a text file. Annoying at times, but less painful for me than trying yet again to figure out vi. I got my stuff done pretty quick and went on to other things.