Plone conference 10-26-06: Afternoon sessions – part 1

October 26, 2006 at 4:07 pm (Uncategorized)

After the LinguaPlone session I talked with Donna Snow and Amy Chan of Disney a bit about the various woes of blogging and Plone. Amy and I went to lunch at a fantastic Thai restaurant and talked mostly about Plone but I also tortured her a bit with my geek Anime/Video game obsessions. She was an excellent sport about that. Tom – you did a podcast with a coworker of Amy’s at Disney about their Plone / Vignette implementation.

2:20 Open Source Best Practices

Munwar Shariff

I’m in this session because this is the person who mentioned during yesterday’s Plone and the Enterprise case studies that he implemented a Plone site for 15 million users. So anything he has to say after that statement, I definitely want to hear. He’s the CTO of Cignex who have been involved in over 50 Plone/Zope/etc. open source projects. He is co-author of Plonelive book.

#1 Understand business users & requirements

  • Get the big picture first?
  • Who are going to use the system?
  • Why?
  • What do they expect?

It is all about expectations management.

This phase has to be completely non-technical. Send someone who doesn’t know Plone at all.

#2 Documentation is critical for open source projects

Mandatory Documents

  • Requirements
  • Acceptance Criteria
  • Detailed Design
  • System Installation
  • Maintenance & Upgrade

#3 Always use storyboards for better understanding

#4 Always use centralized membership system

  • Centralized control
  • Centralized Identity Management
  • One copy of data to manage
  • One person / department in-charge

Use plugins in Plone to traditional DB.

#5 Define workflow & security upfront

More than 50% of your requirements speak to workflow and security.

#6 Don’t get into the hourly rates trap

Get expertise in the initial architecture phase even if it’s very expensive

#7 Choose the right open source product

There is no one size fits all solution. It’s all about right fit & compatibility.
Make sure there is time to evaluate and comparing products.

#8 Understand the licensing model

  • How do you want to use the product/project?
  • Internal/Distribute?
  • GPL – you must release any changes you make to the code base back to the community if you are redistributing the product.

It is all about protecting yourself from legal issues. You often use more than one open source product in your project, the legal terms change when you add other products with different legal terms.

#9 Choose hardware & OS upfront

  • Shall we wait till Production time frame? Scream NO! (Yay we do this!)
  • High-availability
  • Performance
  • Dev -> Staging -> Production – in one server definitely creates problems.

#10 Provide project status updates regularly

  • All the parties involved in the project should be on the same page
  • Understand issues upfront
  • Get help required to mitigate risks

This is the one best practice you must follow.

(Update format: What are the things accomplished last week, what are we doing this week, what is planned for next week.)

#11 Follow coding standards

Will save money in long term maintenance

#12 Write test case before coding

  • Set the expectations right with the developers
  • Clear technical understanding of the system

#13 Always use file system based development

Easy to debug,upgrade, maintain, control, reuse

#14 Leverage community for testing

Release 1.0 to community and 1.1 will be a stable release with Bug fixes
#15 Define production update process

Development -> test -> staging -> production

content management: acquire, store, manage, deliver

#16 Define maintenance & upgrade process

Log file analysis, Identify broken links, fix 404s

#17 Conduct post deployment performance tuning

No matter how extensively you test the system, most will fail in actual production environment

  • Understand load / concurrent users
  • Get real performance numbers
  • Test integrations
  • Tune the system

#18 Empower end users with training

Training for content managers, admins, and developers. Make sure the system is being used.

#19 Provide project end docs

User manual, installation docs, backup/restore procedures

#20 Leverage community support

#21 Contribute back to the community

Good talk. Very dense. Really wish this one was recorded.

3 Comments

  1. Mark said,

    I hope that his slides will be available. I thought that they were good.

    Thanks for the recap of some of the classes I missed.

    Question; Is anyone else at this conference suffering from info-overload? I feel like my brain is going to explode soon. (Awesome info though)

  2. kimberlystone said,

    heh… I’m expecting my head to pop right off around mid-day tomorrow. You may not want to be sitting next to me then.

    Yeah it has all been awesome hasn’t it.

  3. Munwar Shariff said,

    Thanks a lot for capturing the presentation so nicely here. Hope it is useful to the audience. I am excited about Plone and happy to see many people attending the conference.

    I have emailed my presentation (PDF format) to Jon. Jon is going to upload it to both plone.org and Conference Wiki site. You should be able to download it by end of today. If could not locate, send me an email : munwar at cignex dot com

Post a Comment