I love being a developer. I love writing code, juggling objects, doing configurations, doing database stuff, styling HTML, and implementing themes. What I do hate is deployment. So while I feel empowered by tools like distutils, zc.buildout, and variations therein, actually doing that sort of work is very tedious to me. In both my dayjob and side consulting I have very good people to do that sort of thing for me so all I need to do is basic deployment work.
However, I readily admit this is a shortcoming. One I should work to fix.
The good people of Six Feet Up had a deployment workshop this month that I did not attend. If I wanted to I might have been able to press for it as a class, but had other things on my mind. I'm wondering if it is offered again if it makes sense to go next time.
Sunday, November 30, 2008
Monday, November 24, 2008
Current plan for FeedFeeder v2
Somehow this blog post stayed in draft mode forever. But it details the plans I have for FeedFeeder v2, plans that seem to be pretty solid.
The problem with my previous FeedFeeder v2 architecture is that it tampered with something that was not broken; the basic FeedFeeder architecture. Why do code cartwheels when the use of Collections can do all the work for you?
The new idea is to have each FeedFolder be responsible for a single feed. Attributes to handle special cases (generally broken feeds your customer demands you handle) will be hung off the FeedFolder in which FeedItems will be generated and reside. If you need to combine multiple feeds then you just use a Collection. No need for a special FeedDefinition content type, keeping the architecture simple and ensuring that the code remains straightforward.
The quick-and-dirty UML above is nearly identical to the way FeedFeeder v1 is built. I've just added a 'rules' lines attribute. It could be more accurately be called 'feedParserEdgeCases', and will let you correct some of the funny cases you get when your customer says, "I need to have our site recieve feed from Joe Schmoe's bad feed and it has to happen next week!" In the case below, JoeSchmoe has decided to change the Title attribute in his Atom feed to JoeSchmoeTitle.
The credit for this goes to the Van Rees brothers. They looked at my crazy thoughts, forced me to defend them, and tossed in great ideas when they grokked the rantings of my insanity. ;)
The problem with my previous FeedFeeder v2 architecture is that it tampered with something that was not broken; the basic FeedFeeder architecture. Why do code cartwheels when the use of Collections can do all the work for you?
The new idea is to have each FeedFolder be responsible for a single feed. Attributes to handle special cases (generally broken feeds your customer demands you handle) will be hung off the FeedFolder in which FeedItems will be generated and reside. If you need to combine multiple feeds then you just use a Collection. No need for a special FeedDefinition content type, keeping the architecture simple and ensuring that the code remains straightforward.
The quick-and-dirty UML above is nearly identical to the way FeedFeeder v1 is built. I've just added a 'rules' lines attribute. It could be more accurately be called 'feedParserEdgeCases', and will let you correct some of the funny cases you get when your customer says, "I need to have our site recieve feed from Joe Schmoe's bad feed and it has to happen next week!" In the case below, JoeSchmoe has decided to change the Title attribute in his Atom feed to JoeSchmoeTitle.
'JoeSchmoeTitle => Title'Basically the idea will be that through a simple dialogue like the one below, you'll tell FeedFeeder to take the value of JoeSchmoe's custom title and put it into the correct FeedItem attribute. And you'll be able to do it without any custom/hard coding!
The credit for this goes to the Van Rees brothers. They looked at my crazy thoughts, forced me to defend them, and tossed in great ideas when they grokked the rantings of my insanity. ;)
Friday, November 14, 2008
Subscribers Zope 3 style
Vernon Chapman shared this with me. Very elegant.
configure.zcml (brackets replacing XML open/close because Blogspot sucks!)
configure.zcml (brackets replacing XML open/close because Blogspot sucks!)
[subscriber for="Products.CMFCore.interfaces.IActionSucceededEvent"handlers module
handler=".handlers.vernstuff_content_thing" /]
def vernstuff_content_thing(event):
"""This will do all the work"""
action_as_string = event.action
content = event.object
# Do whatever you like here