Best Practices
While 'best practices' change as we evolve Plone and learn what works and what doesnt. We must document them or we risk hurting ourselves in the long run.
The Phone Calls
Its not a conspiracy theory. I am on the phone, all the time, with people around the globe. Most of my jabbering has something to do with Enfold Systems and Plone. Other times its keeping up the social ties that keep me connected to developers, partnered companies, and friends. Recently I was on the phone with a great developer chewing the fat about 'best practices'. Of course that word was only muttered by myself (which I find myself constantly saying such words, and if I could see myself 5 years ago - I would either castrate myself or wash my mouth out with soap^H^H^H^Hzope) not the other developer -- he chooses his words wisely and rarely talks about 'community'. He knows that his involvement is limited to things that impact his life; he's clients need to be happy and he has a gas coding in Python and he enjoys Zope. Its amazing how similiar he is with a lot of developers in the world of open source, Zope, Python, etc. At one point he was burning the midnight oil to push the boulder forward; now he picks his battles and is more upfront what he is willing to work on for himself and others. NOTE: Clients *pay* him to work on what they need. He cant get around that. Anyway.. he wants to document the development process and manage people's expectations - so he doesnt have to clean up the toilets after some newbie clogs them up and the Zope system overflows from rubbish choking the toilet.
Guts on the Table
In the land of open source - you see how the sausage is made. And its not pretty. It's people working their ass off to code. Some code is great; lots of it sucks. But the thing is -- no one can predict where it (any code) will be at some (future) point. Most of the people working their ass off are doing it because its their passion. And my friend's passion is helping other people; besides coding. With all of the guts on the table; people are easily confused. What is a good product? What is the best way to extend the system? etc. etc. How do we answer these? We can write books but we learn valuable lessons every day and the books are outdated very quickly. Now only the guts are on the table, which can scare and confuse people. It's also a weird experience for people coming into the community.
There is no Talk there is only Do
Since people see all of the guts and its as easy to participate as posting a email -- everyone is a back seat surgeon. Saying what should happen. But most commonly the charge is This is Wrong and That is Right. Offering the Correct Way (Tao of Snot) amounts to little more than adding unwanted noise; unless you are being constructive. And if you are gonna to bother to be *that* constructive you might as well just Do It and punt on the talking about whats wrong. Show people whats right. The guy on the other end of the phone - is big on Doing not Talking, at least not into talking about doing.
How Things are Done
I just made a post talking about Best Practices of Plone Development. Of course it was ramblings similiar to this web log post. But it was narrower in scope - I hope it benefits someone. In fact the email title was Best Practices for Sustainable Development - cant git more ConsultingSpeak than that -- I love it. So this guy asks, "How do I do this" and the entire time I'm writing this I'm wondering, "Has this guy programmed anything in Python outside of the context of Plone?" And I think thats what is bothering my buddy on the phone. He is realizing that a lot of people who are doing things like Managing Skins/Scripts Through The Web (affectionately known as TTW) are doing it because they have no Python Programming context. To say it bothers him is a understatement.
Been There
I came to Python through Zope. I did everything through the web. It was "The Hook". The problem was no one told me that what I was doing was not durable. Also I dont know if I had the capacity to understand (over the internet - in person, if someone sat me down - i would have understood) that what was happening and what I was trying to accomplish -- was basically programming Python using a Web Framework and a Object Persistence System. NOTE: I had never used any form of persistence besides insert,update,delete in a relational database; much less a persistent object system or something so transparent and easy as ZODB. So a lot of the magic and power of Zope that I saw and was being "led" into using, was simply ZODB and Python. But I was doing it the wrong way -- in the Zope Management Interface not on the file system. Not with tests. Not with a framework such as CMF/Plone. Not with a community that has upwards of 3-4 conferences per year (2 Plone conferences, 1 PyCon and 1 O'Reilly - add EuroPython and OSCOM and you have a lot of Zope/Plone presence). Now we do. And we have Been There Done That. We should really share our experiences; talk at conferences; leave evidence of our knowledge via documentation. And people who receive this knowledge should feel compelled to redistribute it publicly.
My Friend My Friend
He is quite pissed about the state of documentation but also pissed about how newcomers expectations are being handled. He wants people to understand how to use the technologies we all use on a daily basis. He wants to raise them by their bootstraps and get them to speak, think and act like competent developers. Not to pigeonhole them into a web interface - but show them the power of Zope/ZODB/Python and let them make their own informed decisions. I think he would like: People to use version control (SVN), people to use doctests, people to understand python, people to understand persistence and then work themselves into leveraging Zope the way they need it. He wants them to make their own decisions. I commend my ernest friend.
There are less important things to care about
I, on the other hand - sort of care a tad less. I believe tha people can be sandboxed into use Archetypes to create "content types", simple "tools" and write tests. Then use something like Entransit to formally delivery the content out of Plone and into data sources like XML and RDBMS that is then served by a technologies that fit their brain (read ASP, JSP, PHP, Python). I know, in my heart - My Friend is right. But I know in my slackgland that people are lazy (like myself) and just want something to work and arent interested in upfront pain. Zope to me was the "last admin interface I ever had to write" -- I could use Zope and I would never have to make an administrator interface again; I could focus on using the data that came from the content authors. I'm still tha way. Plone is the ultimate Content Management System that excels at content authoring and overall production. Entransit is the repeatable way to push content into another system; then use your skills to go from there. I have less important things to care about than building a better mousetrap or teaching people that bobo is superior to servlets or ASP.
WTF is the Point?
Ugh. I'm not sure where I am in this post by now. I can say in full confidence we need a Zope/Plone Best Practices document/tutorial - that is kept up-to-date. Everyone needs to tune out the people offering advice without commitment to putting in the elbow grease. I urge everyone to write documentation and solicite feedback -- those who incorporate feedback and cultivate contributions are the people who will help the community and project the most and personally get the most out of participation. Finally I would like to thank My Friend and all other people in the Zope/Python communities
for being such great people. I cant express how much fun it is to see Zope/Plone grow -- all the while introducing new people to the Python language. Zope is the best damn application server on this or any other planet. We just need to be a tad more convincing.