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

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

3. eZ Publishとは
● PHPを使っています
– 多少パーフォマンスが遅い
– PHPを書ける人が多い
● MySQLを使っています
– eZ ↔ DBがボトルネックになりやすい
– データの整合性が守られています
● CMSである
– リソースを高く使う
– 柔軟性があります

4. CMSを理解する
● CMSとは？
●
コンテンツ管理システム
●
コンテンツとは？

5. コンテンツとは
●
開発側から見れば
– ページ
– ユーザ
– 画像

6. コンテンツとは
●
お客さんから見れば
– 商品
– イベント
– 広告
– 動画
– など
●
ワンパターンではない
●
「ページ」で統一できない
●
コンテンツエンジンは柔軟性と適応性が命

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

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

9. CMSとしてのeZ publish
●
柔軟性なコンテンツエンジンを提供する
– コンテンツはクラスとして定義する
– 好きな属性を追加できる
●
丈夫な管理オプション
– 細かいアクセス権限を設定できる
●
コンテンツ別
●
行動別
●
言語別
●
など
– 多段階ワークフロー対応
– コンテンツをノードツリーとして保存（構造化）

10. CMSのニーズ
●
プロジェクトの仕様書にあった機能
●
仕様書にないのニーズもあります
– 新機能の開発のしやすさ
– 冗長化に対応できる
– 組織変更に対応できる

11. CMSのニーズ
●
プロジェクトのニーズは進化するもの
●
仕様変更はある
● 適応性と柔軟性はCMSの大事なニーズ

12. eZ Publishを理解する
● CMSでありながらCMFであります（フレームワー
ク）
●
標準機能は多い
●
柔軟性はとにかく優れている
●
でもドキュメントが少ない
●
ハードルが多少高い

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

14. eZ Publishに向いてるプロジェクト
●
柔軟コンテンツエンジンが必要
●
細かいアクセス権限が必要
●
進化するシステムが必要
– マルチサイト
– マルチ言語
●
特殊な機能が必要
– システム連携
– 検索エンジン
● コーポレートサイトはeZ Webinで秒殺

15. eZ Publishに向いてるプロジェクト
●
柔軟コンテンツエンジンが必要
●
細かいアクセス権限が必要
●
進化するシステムが必要
– マルチサイト
– マルチ言語
●
特殊な機能が必要
– システム連携
– 検索エンジン
● コーポレートサイトはeZ Webinで秒殺

16. eZ Publish図
ライブラリ eZ Components
カーネル
デフォルト機能エクステンション
パッケージエクステンション (ez webin, ezflow, ...)
フレームワーク
CMF
CMS
管理画面

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

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

19. 機能のリストアップ：ポイント
●
汎用的にまとめる
●
機能をカテゴリーでわけをする

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

21. コンテンツクラス設計
●
大事なステップ
●
パーフォーマンス、運用、適応性に影響する
●
システムの基盤となる

22. コンテンツクラス設計
●
クラスの切り分け
– 図を作ると楽
●
クラスの関連
●
属性の種類（データタイプ）
●
新しいデータタイプの必要性？

23. コンテンツクラス設計：ポイント
●
親子関係
●
関連関係
●
固定コンテンツ
●
運用コンテンツ
●
バーチャルコンテンツ
●
コンテンツセクション
●
など

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

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

26. コンテンツクラス設計：ポイント
●
運用側の負担をできるだけ下げる
● simple is best!
●
関連属性を有効的に使う
●
セクションわけでコンテンツクラスの利用パータン
を広げる
●
自動化できる部分は自動化する
●
トップページには独自のコンテンツクラスを利用す
る

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

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

29. ネイティブ機能
● eZ Publishは標準機能が多い
●
ドキュメントされていない機能もあります。。
●
標準機能はしっかりテストされています、品質が
高い
●
ですが、標準機能のテンプレートに無駄と古い
コードもあります
● GUIや設定ファイルを通して利用できる機能も多
いので、デフォルトの設定ファイルをしっかり見ま
しょう

30. カスタム機能
●
コンテンツクラスとテンプレートは必ずカスタム機
能になります
●
カーネルや元のコードに変更加えずにほとんどの
カスタム機能を開発できます
●
エクステンションベース
●
テンプレート言語は拡張できる
● eZ PublishのAPIとeZ Componentsは使えま
す
●
外部ライブラリーも追加できます

31. 機能開発：ポイント
●
カスタム機能はコストがかかります
●
できるだけネイティブ機能で実装をする
●
カスタム機能はできるだけ汎用的に作って、再利
用と機能変更を頭に置く

32. プログラミングポイント
●
いきなりコードを書くのはだめ！
●
スパゲッティコードはだめ
●
クラスベースで開発する
● 擬似コードから書く（特にAPIの場合）
● SCM（GITなど）は必ず使いましょう
●
コメントはしっかり書きましょう

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

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

35. エクステンションの設計
●
機能はエクステンションでわけます
– 関連する機能はどうエクステンションにまとめます
– 再利用できるエクステンションは独自エクステンション
で完結させます
● コードはエクステンション毎でGITなどを使って管
理します
●
設定はできるだけエクステンションでまとめます

36. エクステンション切り分けの例
●
メインエクステンション
– デザイン
– テンプレート
– 特殊機能やオペレーター
– 設定
●
汎用的デザイン（再利用可能）
●
汎用的オペレーター（マイクロ言語と）
●
再利用できるモジュール（単独機能）

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

38. テンプレート
●
テンプレートフォルダーとファイル名をわかりやす
く設定する
– articleクラスのビューfullの場合
override/class/article/full.tpl
– /info/privacy の独自ページの場合
override/page/info/privacy/info.tpl
●
フェッチにはできるだけ制限をかけます
● node_view_guiとattribute_view_guiを利用
してテンプレートを細かく因数分解して

39. テンプレートの実装レベル
● テンプレート > オペレーター > PHPコード
●
テンプレート言語のロジックはパーフォーマンス的
にわるい
●
テンプレート言語で５行以上のロジックはテンプ
レートオペレーターにまとめる
● オペレーターのコードはできるだけPHPクラスでま
とめる
●
そうすると実装も早い、コードもわかりやすい、デ
バッグも楽
●
コードをコメントする

40. 高度機能開発
● eZ Componentsはいろいろ使えます
● eZ Publishのautoloads機能で外部機能を使
いやすい
● eZ PublishのRESTやJSON APIで外部システム
と連携できる

41. まとめ
●
コメントされてるコードとわかりやすいコードはな
により大事
●
エクステンションは有効的にわける
●
テンプレートはできるだけ簡単に
● 必要に応じてeZ Componentsや外部ライブラ
リーを利用する
●
再利用できるものは再利用します

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

43. 権限設計
●
ロールは組み合わせるもの！
●
再利用できるロールは再利用します
●
セクションとサブツリー制限を活動して、同じロー
ルで複数のパータンを対応します
●
マルチサイトの場合は各サイトの匿名ユーザを設
定します
●
ロールはユーザ単独にも割り当てることはできま
す
●
１つのユーザは複数のグループに所属することが
できます

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

45. パーフォーマンスと冗長化
● CMSはリソースを高く使うもの
● eZ PublishのボトルネックはDB
– DBは同期の問題があるから、簡単にサーバ増やせな
ません
●
細かいパーフォーマンスチューニングする前、ボト
ルネックはしっかり判断しましょう
– 404はできるだけ減らしましょう
●
フェッチは多くのリソースを使っています
– 標準のフェッチよりeZ Findを使えばDBの負担は下
がる

46. パーフォーマンスと冗長化
● eZ Publishのキャッシュより、Varnishを使うの
はおすすめ
● 軽いサーバを利用する、nginx、lighttpdなど
●
フロントサーバを増やす
● DBサーバにメモリを増やす
● クラスターモードを避ける（rsync等を利用）

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

48. その他のベストプラクティス
●
開発環境とプロダクション環境はできるだけ統一
します
●
デプロイ、プロダクションサーバにバグフィックスを
当てるなどはGITを使うと楽

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