eZ Publish２０１３年6月勉強会「ベストプラクティス」

ベストプラクティス1ツールを理解する

eZ Publishとは

● PHPを使っています

– 多少パーフォマンスが遅い

– PHPを書ける人が多い

● MySQLを使っています

– eZ ↔ DBがボトルネックになりやすい

– データの整合性が守られています

● CMSである

– リソースを高く使う

– 柔軟性があります

CMSを理解する

● CMSとは？

● コンテンツ管理システム

● コンテンツとは？

コンテンツとは

● 開発側から見れば– ページ

– ユーザ

– 画像

コンテンツとは

● お客さんから見れば– 商品

– イベント

– 広告– 動画

– など

● ワンパターンではない● 「ページ」で統一できない● コンテンツエンジンは柔軟性と適応性が命

管理とは

● コンテンツをどの目的に活用する● システムそれぞれに目的が変わります

管理とは

● コンテンツを見つけやすくする● コンテンツの閲覧に制限をかける● コンテンツの作成に制限をかける● 承認ワークフローを利用する● 情報を構造化する● コンテンツの追加を簡単にする● など

CMSとしてのeZ publish

● 柔軟性なコンテンツエンジンを提供する– コンテンツはクラスとして定義する

– 好きな属性を追加できる

● 丈夫な管理オプション– 細かいアクセス権限を設定できる

● コンテンツ別● 行動別● 言語別● など

– 多段階ワークフロー対応– コンテンツをノードツリーとして保存（構造化）

CMSのニーズ

● プロジェクトの仕様書にあった機能● 仕様書にないのニーズもあります

– 新機能の開発のしやすさ– 冗長化に対応できる

– 組織変更に対応できる

CMSのニーズ

● プロジェクトのニーズは進化するもの● 仕様変更はある

● 適応性と柔軟性はCMSの大事なニーズ

eZ Publishを理解する

● CMSでありながらCMFであります（フレームワーク）

● 標準機能は多い● 柔軟性はとにかく優れている● でもドキュメントが少ない● ハードルが多少高い

eZ Publishを理解する

● ほぼなんでも実装できます● だけど同じコストで実装できません● 向いてるプロジェクトを理解するんは成功の鍵

eZ Publishに向いてるプロジェクト

● 柔軟コンテンツエンジンが必要● 細かいアクセス権限が必要● 進化するシステムが必要

– マルチサイト

– マルチ言語

● 特殊な機能が必要– システム連携– 検索エンジン

● コーポレートサイトはeZ Webinで秒殺

eZ Publishに向いてるプロジェクト

● 柔軟コンテンツエンジンが必要● 細かいアクセス権限が必要● 進化するシステムが必要

– マルチサイト

– マルチ言語

● 特殊な機能が必要– システム連携– 検索エンジン

● コーポレートサイトはeZ Webinで秒殺

eZ Publish図

ライブラリ eZ Components

カーネル

デフォルト機能エクステンション

パッケージエクステンション (ez webin, ezflow, ...)

フレームワーク

CMF

CMS

管理画面

ベストプラクティス2開発を始める前

機能のリストアップ

● コンテンツタイプ（コンテンツクラス）● コンテンツ属性● マルチサイト● マルチ言語● 権限● システム連携● ユーザ組織● 権限● など

機能のリストアップ：ポイント

● 汎用的にまとめる● 機能をカテゴリーでわけをする

ベストプラクティス2コンテンツクラス設計

コンテンツクラス設計

● 大事なステップ● パーフォーマンス、運用、適応性に影響する● システムの基盤となる

コンテンツクラス設計

● クラスの切り分け– 図を作ると楽

● クラスの関連● 属性の種類（データタイプ）● 新しいデータタイプの必要性？

コンテンツクラス設計：ポイント

● 親子関係● 関連関係● 固定コンテンツ● 運用コンテンツ● バーチャルコンテンツ● コンテンツセクション● など

コンテンツクラス設計：例

コンテンツクラス設計：例

コンテンツクラス設計：ポイント

● 運用側の負担をできるだけ下げる

● simple is best!● 関連属性を有効的に使う● セクションわけでコンテンツクラスの利用パータン

を広げる● 自動化できる部分は自動化する● トップページには独自のコンテンツクラスを利用す

る

ベストプラクティス３機能の設計

機能設計

● ネイティブ機能と開発必要機能をリストアップする

ネイティブ機能

● eZ Publishは標準機能が多い

● ドキュメントされていない機能もあります。。● 標準機能はしっかりテストされています、品質が

高い● ですが、標準機能のテンプレートに無駄と古い

コードもあります

● GUIや設定ファイルを通して利用できる機能も多いので、デフォルトの設定ファイルをしっかり見ましょう

カスタム機能

● コンテンツクラスとテンプレートは必ずカスタム機能になります

● カーネルや元のコードに変更加えずにほとんどのカスタム機能を開発できます

● エクステンションベース● テンプレート言語は拡張できる

● eZ PublishのAPIとeZ Componentsは使えます

● 外部ライブラリーも追加できます

機能開発：ポイント

● カスタム機能はコストがかかります● できるだけネイティブ機能で実装をする● カスタム機能はできるだけ汎用的に作って、再利

用と機能変更を頭に置く

プログラミングポイント

● いきなりコードを書くのはだめ！● スパゲッティコードはだめ● クラスベースで開発する

● 擬似コードから書く（特にAPIの場合）

● SCM（GITなど）は必ず使いましょう

● コメントはしっかり書きましょう

ベストプラクティス４エクステンションの設計

エクステンションで実装できる機能

● テンプレートとデザイン● 設定● モジュール● テンプレート言語のオペレーター● カーネル機能のオーバーライド● ほとんどの機能を実装できます

エクステンションの設計

● 機能はエクステンションでわけます– 関連する機能はどうエクステンションにまとめます

– 再利用できるエクステンションは独自エクステンションで完結させます

● コードはエクステンション毎でGITなどを使って管理します

● 設定はできるだけエクステンションでまとめます

エクステンション切り分けの例

● メインエクステンション– デザイン

– テンプレート

– 特殊機能やオペレーター– 設定

● 汎用的デザイン（再利用可能）● 汎用的オペレーター（マイクロ言語と）● 再利用できるモジュール（単独機能）

エクステンション切り分けの例

テンプレート

● テンプレートフォルダーとファイル名をわかりやすく設定する

– articleクラスのビューfullの場合override/class/article/full.tpl

– /info/privacy の独自ページの場合override/page/info/privacy/info.tpl

● フェッチにはできるだけ制限をかけます

● node_view_guiとattribute_view_guiを利用してテンプレートを細かく因数分解して

テンプレートの実装レベル

● テンプレート > オペレーター > PHPコード

● テンプレート言語のロジックはパーフォーマンス的にわるい

● テンプレート言語で５行以上のロジックはテンプレートオペレーターにまとめる

● オペレーターのコードはできるだけPHPクラスでまとめる

● そうすると実装も早い、コードもわかりやすい、デバッグも楽

● コードをコメントする

高度機能開発

● eZ Componentsはいろいろ使えます

● eZ Publishのautoloads機能で外部機能を使いやすい

● eZ PublishのRESTやJSON APIで外部システムと連携できる

まとめ

● コメントされてるコードとわかりやすいコードはなにより大事

● エクステンションは有効的にわける● テンプレートはできるだけ簡単に

● 必要に応じてeZ Componentsや外部ライブラリーを利用する

● 再利用できるものは再利用します

ベストプラクティス４権限の設計

権限設計

● ロールは組み合わせるもの！● 再利用できるロールは再利用します● セクションとサブツリー制限を活動して、同じロー

ルで複数のパータンを対応します● マルチサイトの場合は各サイトの匿名ユーザを設

定します● ロールはユーザ単独にも割り当てることはできま

す● １つのユーザは複数のグループに所属することが

できます

ベストプラクティス４パーフォーマンスと冗長化

パーフォーマンスと冗長化

● CMSはリソースを高く使うもの

● eZ PublishのボトルネックはDB– DBは同期の問題があるから、簡単にサーバ増やせな

ません

● 細かいパーフォーマンスチューニングする前、ボトルネックはしっかり判断しましょう

– 404はできるだけ減らしましょう

● フェッチは多くのリソースを使っています

– 標準のフェッチよりeZ Findを使えばDBの負担は下がる

パーフォーマンスと冗長化

● eZ Publishのキャッシュより、Varnishを使うのはおすすめ

● 軽いサーバを利用する、nginx、lighttpdなど

● フロントサーバを増やす

● DBサーバにメモリを増やす

● クラスターモードを避ける（rsync等を利用）

その他のベストプラクティス

その他のベストプラクティス

● 開発環境とプロダクション環境はできるだけ統一します

● デプロイ、プロダクションサーバにバグフィックスを当てるなどはGITを使うと楽

ご清聴ありがとうございました！