社長BLOG

OpenPNEのテーブルは数が多すぎる。
性能に問題がないなら、MemberConfigやSnsConfigまたは汎用のKVSタイプのデータ構造にマージしてしまえばいいのだ。

実装の事情やパフォーマンスの面で実際にはここまで削れないかもしれないけど、ざっと方針を共有する。
かなりアグレッシブだけど、これでテーブルを4割削減できる。
モデルが多すぎるとインストール時に詰まったりするので、こちらもなるべくシンプルに。

◆事業仕分け案

OpenPNEの命名規則をもっと洗練させよう。
例えばMemberConfigには pc_address password secret_answer
などがサラッとキーワード化されているが、これはOpenPNEの根幹をなすほど重要なので、ほか特別したキーワードとして定めたい。

このような決め事は、SnsConfigにもあるし、Profileにもある。
さてどんな風にするか？

大文字作戦

全部大文字にして、他の設定値と区別するというアイデアがある。
PC_ADDRESS PASSWORD SECRET_ANSWER

接頭字作戦

特定の接頭字を付けることでグルーピングすることもできる。
op_pc_address op_password op_secret_answer

ドメイン作戦

ドメインのようにどっと区切りでグルーピングする。文字通りパラメータのドメイン管理がしやすい。
OpenPNEプロジェクトのものなのか、他のプラグインのものなのか？が分かりやすい。
pcaddress.op.jp password.op.jp

ちなみに自分としては、命名規則についての権限を分散させることができるので、ドメイン形式を一番押している。
プラグイン作者がMemberConfigにデータを置きたい場合には、paramname.mydomain.com
などと好きな値を設定できるしね。

木村

・いまは、金曜だけの作業（土日の手嶋荘カンヅメで取り返す）
・APIキーの埋め込み方法について MediaWikiのAPIKEYによる実装方法を参考にする
・APIキーが必要な理由
＝＞外部からAPIを呼んだ場合でも、APIKEYを使う（＝クッキーを使う方法よりもいい）
・スマートフォンAPIにはクッキーを使わない
・に埋め込む
・APIキーを全ページに組み込む（フィルターはつくらず、layout.phpに直接埋め込む）
・SMTのテンプレート、スマートフォンAPIはコアに入れる

柏木

・opSMTAPIPluginのAPIサンプルJSONをたくさん作った
・forwardIf はフィルターのコストが高いので $this->execute(“actionSMT”);に変更する
・SMTを語尾ではなく先頭に（Templateのソートで区別がしやすい）

手嶋

・スマートフォンのテンプレートを、ガシガシつくる
・とりあえず手持ちの簡単な実装方法で進める
・今後最適な世間の認証方式やAPI方式が現れれば、そちらに変更する
・APIのURLは階層がガタガタなのは駄目だ。分かりにくい。

◆反面教師：TwitterのAPIレイアウト

・APIは/api/entity/action?key=value&key2=value2 形式に統一
・スマートフォンAPIに優れたテストケースがあることが重要だ

NextAction

・APIKEYの全ページへのセット
・設定画面でのKEY表示＆RESET
・APIの実装（実装、テスト）
・手嶋屋での3.7修正コードのマージ
・バナー機能の削除　http://p.pne.jp/d/201112091608.png
・/plugins/sf**を移動

今回のHOUOUプロセスでは取り組めないが、将来的に実現する２つのチャレンジを共有しておく。

過去にも何度か記事にしているが、OpenPNEの将来像をイメージしながら現在の開発を進めることは有益だと思う。

OpenPNEは組織プラットフォームだ

まず前提として共有したいのは、OpenPNEがネット上に組織の居場所をつくるためのプラットフォームを目指すという方向性についてだ。

OpenPNEはmixiではないし、Twitterでもないし、Facebookでもない。渋谷のスクランブル交差点のように人ばっかりたくさんいるSNSをつくることを目的としたソフトウエアではない。

OpenPNEはさまざまな組織がネット上に安心して交流できる居場所をつくるためのソフトウエアだ。

グループの概念

現在OpenPNEにはコミュニティ機能があるが、これを「グループ」というもっと一般的な概念に拡張する。
グループは特定の機能を指すわけではなく、SNS中で特定のメンバー集団を表現するための機能だ。

SNSの全メンバーを表現するグループ
部署やサークルなど特定の集団を表現するグループ
誰かとリンクしているフレンドを表現するグループ

など、SNSの中で複数のメンバーをひとまとめに管理する機構は、すべてグループとして管理する。

グループメンバー・メンバーグループ

これはUnixから拝借した機構だ。Unixはメンバーをつくると、自動的にそのメンバーと同名のグループが作成される。
逆にグループがあるということは、それに相当するメンバーがいるということが予測できる。

OpenPNEにこれを適用したらどうなるのか？
tejimaというメンバーを作ったら、tejimaというグループが暗に作成される。
逆にfootsalというグループがあれば、footsalというユーザーがいてもいいかもしれない。

この概念をOpenPNEに持ち込むと価値がある。
まだまとまってないけど、こんな使い方を考えている。
「tejimaのフレンドはtejimaグループに所属させる」
「footsalグループのメンバーはfootsalグループに所属させる」

すなわち、
tejimaのフレンドであるということと、footsalバーチャルユーザーのフレンドであるということは等価である。
逆に言うと
tejimaグループのメンバーであるということと、footsalグループのメンバーであるということは等価である。

メンバー、グループパーミッション

ソーシャル・ネットワークに置ける最重要事項は、リンク機構とそのリンクに基づくコンテンツのパーミッション（共有範囲設定）だ。こちらもUnixからパーミッションについての概念を拝借しようとおもう。

手嶋のフレンドのみに公開というコンテンツはこんなパーミッションになる。
tejima:tejima r-xr-x—

手嶋のフレンドのみに公開（Wikiモード）というコンテンツはこんなパーミッションになる。
tejima:tejima rwxrwx—

SNS全体に公開（Wikiモード）というコンテンツはこんなパーミッションになる。
tejima:tejima rwxrwxrwx

手嶋がフットサルグループに投稿したとなると、こんな感じ。本人とフットサルグループのメンバーだけ閲覧可能にする。
tejima:footsal r-xr-x—

まだ練りが甘いけど、このまま進めていけば素晴らしいデザインができそうな気がする。

自分が知る限りOpenPNE2には外部キー制約をセットしないで使っていた。

Ver3からは制約を儲けているが、これがトラブルの種にもなっている。

OpenPNEに外部キー制約を設ける価値はどのぐらいあるのか？

OpenPNE2時代は「そろそろ制約つけて論理的整合性を保てるようにしないとなぁ」なんて思ってたんだけど、
実際Ver3で制約をつけてみたら、メリットよりもデメリットのほうが多いんじゃないか？って気になっている。

その割にはpc_addressにユニーク制約になってなかったり、このあたりはちぐはぐだ。

12月にスマートフォン対応の足がかりをつくる。

アクションフローについて検討した。
色々なやり方がある。フレームワーク自体を拡張するもの。
特殊なサブクラスを作ってそこでスマートフォン用の拡張処理を行うもの。

暫定、とりあえずこのやり方で実装していこう方針がまとまったので共有しておく。
なお、このやり方で最後まで行くというよりは、なるべく愚直なやり方で積み上げていって、実績が整ったところでエレガントな実装方法にアップグレードしていこう、という堅実な方式だ。

pc_frontendを使う

方針の一つ目、携帯電話向けの実装と同じように、新しくsmt_frontendをつくるか？
という方式も検討した。

この場合、ほとんどPCと同じ挙動をするのにわざわざ分ける価値がないととりあえず判断した。
pc_frontendに詰め込んでいって、原理的に破綻してからでも遅くない。

拡張用サブクラスは作らない

これもとりあえずの対応。HOUOUの終了時にはうまーく処理をまとめた拡張が出来ているかもしれない。
ただ現段階では愚直な作戦で行く。

スマホ用のlayout.php

レイアウトテンプレートはスマートフォン用に用意する。

HOME MEMBER COMMUNITY SNS
の4種類を基本レイアウトにする。一本化しないで4レイアウトファイルにする。
OpenPNE3PC版のlayoutは深くてちょっと見通しがわるい。layoutAやBが直感的に分かりにくい。

view.ymlでどのレイアウトを選択するか明示する。

◆4つの基本レイアウト

indexActionしか使わない

投稿、削除、検索などは、スマートフォンAPIを新設して利用するので、基本的にはページ表示用のindexActionしか使わない。search post delete などのその他のアクションはスマートフォンAPI側を使う。

Actionは共有しないが流用する

スマートフォン対応で一番楽に実装できそうなのは、Actionを共有し、テンプレートやCSSだけスマートフォン用に振り分けるという物。

今回このやり方はひとまず採用しなかった。ざっと調べたところ

・テンプレートにアサインすべき値がぜんぜん違う。PCのほうが余計にアサインする。
・PCとスマートフォン同じUIの遷移をしないケースが沢山ある

このに点があるので、Actionの共有を必須にするのはやめた。
ただ、全く同じアクションフローの場所は、内部で元のアクションを呼び出したり、コピペするのはかまわない。
これを共有したからと言ってテスト工数が減るわけでもないので、スマートフォン用には独自にアクションをつくることにした。

とはいえこんな感じでつくる。

※実際には動かないコード、雰囲気だけね。

PC用のアクション関数の中に、スマートフォン用のチェック関数を入れて、リダイレクトする。
凄くベタに書いている。
テンプレートも

こんな感じでベタに書いていく。スマートフォン対応されたActionは先頭にこの$this->forwardIf()という関数が付くようになる。対応していなければそのままPCのActionを呼び出す。

とりあえずこれでしばらく実装してみて、経験を蓄積してから、拡張クラスを設計していこうと思う。

実際のソースコードができてくると、もうすこし理解しやすいとおもう。

OpenPNE3はsymfony1.4ベースだ。
しかし、現在のSymfonyプロジェクトの主力はSymfony2に移っており、symfony1.4の進歩は今後、全く期待できない。

ただ、だからといっていきなりフレームワークをスイッチするようなバカな真似もできない。
つくってもらっているプラグイン全滅なんて、ひどいことしたくないし。OpenPNEコミュニティに対する反逆だ。

それでもコア開発としてフレームワークやORマッパーの変更が避けられなくなったとき、
どうすれば移行することができるのか？

ガソリンからハイブリッドに

ベースフレームワークがどーしたこーしたというのは、
OpenPNEコア開発者が考えることであって、OpenPNEのユーザーやOpenPNEのプラグイン開発者にはあまり関係がない。OpenPNEのユーザーはOpenPNEのユーザーだから、symfonyのユーザーではない。

車がガソリンからハイブリッドに変わったからと言って、ドライバーやカスタムカー業者に過度な対応を迫らない。
昔のタイヤやパーツ、運転感覚まで全部捨ててください。と言ってしまったら、さすがにだれも使ってくれないだろう。

OpenPNE APIの確立

では、OpenPNEがすべき事は何か？

それはユーザーの大部分が利用するOpenPNEのAPIを確立し、それを普及させることだ。
それはWEBベースのAPIかもしれないし、PHPのベースの内部データへのアクセス方式かもしれない。

今のOpenPNEはユーザーに対して、拡張したければ大元のフレームワークであるsymfonyをたたいてください、とお願いしている状況だ。なんとテーマをつくるデザイナーに対してまで。

使われるAPIを整備し、プラグイン作者や拡張するユーザーの大部分がこのAPIを利用することで事足りるようになればいい。

そうすれば、API仕様だけを維持すれば、ベースフレームワークやORマッパーを変更しても文句がないだろう。

スマートフォンAPIから

HOUOU12月号では、スマートフォン用のアクションAPIを整備している。
このAPI群は順調に発展すれば、スマートフォンだけでなくOpenPNE全体で使えるAPIに発展するだろう。

気合を入れて作っている。

通知センターはとにかくやりたい機能だ。ただし、実装はそれなりに大変だと思う。

◆通知センターの見た目

とりあえず手っ取り早く対応する方法を考えてみる。

重要なアクティビティのリスト＝通知センター

アクティビティ（タイムライン）は普段どんどん流れていってしまう情報だ。ログインしてタイムラインを確認したときだけしか、仲間やSNS内の今の活動を知ることができない。

通知センターは、このアクティビティの中で、確実に読むべきもの、を知らせる機能だ。

通知すべきアクティビティデータに外部からメンバーごとにフラグをつければよさそうだ。

通知センターをMemberConfigに

手っ取り早く対応するので、とりあえずMemberConfigに格納することにした。
KEYはNOTIFICATION_CENTER
VALUEに通知センターのデータ構造をシリアライズして格納する。

◆通知センターのデータ構造

データの使い方として、リレーショナルである必要はないので、とりあえずMemberConfigに入れておいても性能劣化は気にならない。
※どちらかというとACTIVITYDATA_IDから実体を得るところが重い。クライアント提供用JSONデータ構造ごと格納しちゃったほうがいいかも。

ORDERは通知センターでの並び順
ACTIVITYDATA_IDは通知対象のアクティビティの実体
NOTIFYはすでに通知済みかどうか？

通知センターのバッジ表示はNOTIFICATION_COUNTに置く。

◆バッジ表示

いつ実装するの？

HOUOUプロジェクトでは、どう考えてもアドバンスドサクセスレベルなんだけど、

スマートフォンUIをつくっていて、通知センターがないのはかなり痛いと思ってきた。

とりあえずやっつけ対応をしてみて、みんなに使ってもらってから考えたい。

モックアップはサクサク作れる。
これを実際に実装するのは大変だけどね。

◆ログイン画面

◆通知センターをよりリアルに

◆プライベートメッセージ（フルサクセス）

◆日記

HOUOU12月スマートフォン整備のために、スマートフォンAPIを整備する。
整備の方法についてのメモ。

API仕様について

API整備、UIデザイン、繋ぎ込みを３人が別々に引き受けている。
まずは仕様ベースで、お互いが分業できるようにする。

API仕様は、最初こんなスプレッドシートで議論していこうぜなんて話をしていたのだが、

◆議論用スプレッドシート

ドキュメントつくって、サンプル実装してなんて馬鹿馬鹿しいから、
いきなりgithub上に　/web/test/timeline/list.json list.ERROR.json のように実際のサンプルデータを作っていっちゃったほうがいいね。

という話になった。
ということで、スマートフォンAPIプラグインのレポジトリに置くことにした。
https://github.com/houou/opSMTAPIPlugin

その他メモ

・スマートフォンの新規登録問題、携帯アドレス変更問題はクリアできたようだ（柏木さん）
・Bootstrap使って楽できないか？ http://twitter.github.com/bootstrap/
・それほど重要ではない設定変更画面にjQueryMobileを使って試してみよう
・アクションとテンプレートの振り分けにはこの辺を参考にしてみよう
・ログインとプロフィール変更はシステムが複雑なので、なるべくCSS対応だけにしよう
・モックを全画面分充実させないと
・HTML+CSSも作らないと
・JSONのデータはJSONViewがあると見やすいよ
・スマートフォンHTML5で書いていく

◆JSONViewでJSONデータを表示した図