社長BLOG

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

◆通知センターの見た目

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

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

アクティビティ（タイムライン）は普段どんどん流れていってしまう情報だ。ログインしてタイムラインを確認したときだけしか、仲間や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データを表示した図

symfonyとDoctrineはどう頑張っても難しい。

OpenPNEの動作を変えたり、機能を拡張したい場合に、symfonyまで知っている必要はない。
もちろんフレームワークのコア部分まで理解して拡張することができても、もちろんいい。

Firefoxの拡張はC言語を知らなくてもJavaScript+CSSでできる。
コアまで深く拡張したければ、そうすることもできる。

というような仕掛けが理想だ。

スマートフォン用APIの未来

今、HOUOU12月号でスマートフォン用APIを整備している。
これはスマートフォンUIをつくるために作ってはいるが、これが発展すれば、
JavaScriptでOpenPNEを拡張できる、新たなフレームワークに進化するだろう。
Firefoxのように、簡単なJavaScriptだけ知っているだけで、OpenPNEを拡張できるようにしたい。

スマートフォン用APIはまず、スマートフォンの基本部分を実装するためにつくるが、
今後は、いろんな用途に使えるように発展させる。

・スマートフォンUIが整備できる
・OpenPNE簡単拡張用に使える
・サーバーサイドAPIとしても使える
・スマートフォンアプリからだって使える

一度の整備で４倍使えるAPIに進歩させるぞ。

APIはスピードアップにも寄与しそうだ

スマートフォンの対応にAJAXを積極的に使っていこうと考えているが、
今のところテストで使っている限り、すこぶる調子がいい。

jQueryTemplate + JSON APIの組み合わせはsymfonyにとっても福音なのではなかろうか。

どうせスマートフォンでAPI群を整備していくので、手が余ればPC版のスピードアップのために
従来のアクションから、API方式に切り替えていってもいいかもしれない。
体感速度はかなり早くなると思う。

アクティビティの投稿欄を消す

現在OpenPNE3に含まれているアクティビティ機能だが、
本来は”外部アプリケーション”や”OpenPNE内部機能”の活動（アクティビティ）を”表示”するための機能だ。
なので、本質的にはつぶやき機能が付いている必要はない。

つぶやき機能としては、タイムラインプラグインが十分役立ってくれるので、
バンドルされているアクティビティはリードオンリーにしてしまおうかと思った。

コミュニティ＝＞グループ

「コミュニティ」という表現は、SNS界隈ではmixiの方言になりつつある。
SNSが登場する以前からの共通概念として「グループ」の方が理解しやすいし、
自分のイメージや将来構想とも近い。「クラスタ」なんてのも考えたんだけどね。。。

TwitterのリストやGoogle+のサークルは意味不明なので使わない。

柏木さん、木村さん、手嶋で行ったミーティングの内容を共有する。

基本的には、昨日書いた12月の方針を元にして作業をすすめる。

手嶋荘で3者作業
仕様策定が複雑になるので、3者が集まって作業する。
・12/10 14:00〜19:00
・12/11 09:00〜19:00
・12/17 09:00〜19:00

※手伝い参加大歓迎

スマートフォンに対する意思決定事項
・スマートフォンは分業体制する API整備＝＞木村　UI HTML作成＝＞手嶋 アクション開発＝＞柏木
・PC対応していないページはスマホモードからは遷移させない（Facebookスタイル）
・スマートフォンモードからPCモードへの切り替えは、SNSのトップ画面に遷移する
すなわち、フルPCモードか、機能が限定したスマートフォンモードかがはっきり分かれるようにする。
スマートフォンモードとPCモードを頻繁に行ったり来たりするような事はしない。
・jQueryMobileは12月中に非主要画面で利用テストし、正式採用するか決める。主要画面では利用しない

スマートフォン用API
・スマートフォンのWEBUIはAPIを新規に整備してこれを使う
・APIはスマートフォン対応のために整備するが、PCから、サーバから、アプリからも同一のAPIが利用できるようにする
・APIリクエストの認証とユーザー識別は、クッキー、トークン、サーバサイドIPなど多くの手段を用意する
・スマートフォンAPIは分業するのでスプレッドシートに仕様を記載していく
・jQueryTemplateは使う

雑多な事項
・手空きが発生したら雑多な項目をクリアする

HOUOUからはjQueryを全面採用し、AJAXでの運用に適したJSON形式のAPIを大量に用意する準備を進めている。

これらの整備が完了した後は、ガジェットの作成スタイルがこれまでと根本的に変わることになるだろう。

従来のアクションフロー

日記機能を例に考える。

日記機能の個々の要素（投稿フォーム、一覧画面、個別記事画面）はそれぞれパーツに分けることができる。
例えばホーム画面に表示する最新日記一覧は、ガジェットとして独立している。

せっかくパーツに別れてはいるのだが、フォームのアクションフローがいけてない。（閲覧はまだマシだが）
日記を投稿した後の遷移が固定されているため、ガジェットとして配置しても、投稿以後の遷移が統一されてしまう。
＝＞実質的には固定されたページにしかガジェットを置けない。

◆全ページ遷移するアクションフロー

HOUOUのアクションフロー

ブラウザサイドでレンダリングすることで、単一のガジェット内で、インデックス表示、フォームアクション、結果表示のすべてのフローを完結させることができる。これによって、ガジェットのポータビリティが増す。

例えば、特定のコミュニティのページに、自分の日記の投稿ガジェットを設置しても、動作に不整合が起きなくなる。
（実際にこれをする価値があるかは別として、、、）
ホーム画面に好きなコミュニティの掲示板ガジェットを配置しても、正しく動作する。

◆ガジェット内のみで完結するアクションフロー

ガイドラインはどうなるの？

ざっと考えたガイドライン【案】

ガジェット作成のガイドライン案
・ガジェットアクションはAJAX（OpenPNEのJSON API）を使う
・HTMLレンダリングはブラウザサイドで行う
・フォームはページ遷移せずガジェット内で完結させる

OpenPNE HOUOUプロジェクト12月号のテーマは「スマートフォン」だ。

HOUOU12月号方針 HOUOU_DECEMBER

スマートフォン対応の基礎部分を固める。プラグイン一つを完全にスマートフォン化してみて、本体との整合性を検証する。

HOUOU_DECEMBER 課題リスト
・ネットワーク無しOpenPNE＆プラグインインストール
・開発版OpenPNEのリリース作業
・スマートフォン招待関連の不具合修正
・UIDを使わない認証
・画像メール投稿
・アクションモデル決定（READ View系）
・アクションモデル決定（WRITE Form系）
・プラグインとの連携
・ログイン画面
・ホーム、フレンド、コミュニティ画面
・PCUI/スマホUI切り替え機能（クッキー設定）
・スマホ非対応画面はPCに振り分ける
※そもそもPCUIすら遷移しない方法も検討（PCブラウザ使ってね方式）
・スマートフォンの場合はなるべく再ログインしなくて済むように（クッキー延長、ログインフォームのID/PASS保存）
・主要画面以外をjQueryMobileを使って楽できるか？
・スマートフォン用アクションAPI（JSON）整備
・タイムライン機能（ゴルゴンハニー）側スマートフォンUI整備

細かいところ

・バナー機能を削除
・/plugins/sfXXXXプラグインを/OpenPNE/vendor/symfony/plugins/に移動
・設定ファイルを3=>1ファイルに
・MySNS=>OpenPNE
・OpenPNE君=>運営者に
・PC横幅1024化
・コミュニティ＝＞グループに名前を変える（モデル名は変えずに表記のみ）
・コミュニティ＝＞グループに名前を変える（モデル名も変える）

OpenPNE HOUOUプロジェクトの11月号HOUOU_NOVEMBERの開発が一段落した。

HOUOUプロジェクト11月号 ( HOUOU_NOVEMBER )

・最小限のプラグインでインストールが完了する
・デフォルトガジェットレイアウトを最小にする
・インタラクティブインストールを回避するオプションを追加
・prototype.jpを廃止しjQueryに変更する

HOUOU11月号はコンセプトを”シンプル”に定め、OpenPNEを全くの裸の状態から再スタートすることを目指した。
※あまりにもさっぱりしすぎて、何に使うんだこれ？と思うかも

このシンプルな裸のOpenPNEに寄り添う形で提供するのが、
HOUOUプロジェクトの目玉機能のひとつであるタイムライン機能だ。
Twitter、Facebook相当のタイムライン機能を実装していく。もちろんスマートフォン対応で。

この機能はプラグインとして実装され、HOUOUプロジェクトと並行して開発を進めている。

毎月のHOUOUと並行して同時にリリースするので、
プレーンなHOUOUと、目玉機能のタイムライン、両方の進化を楽しみ、見守っていていただきたい。

HOUOUでは、スマートフォン進行のために、JSONAPIを整備しようと考えている。

APIはどんなふうにデザインするのが良いか？というメモ。

一人がすべてデザインする

ポイントその１。APIは実装も大事なだけど、何よりもデザインが大事。
各プラグインごとにバラバラにつくっていても良いAPIにはならないので、
主要なプラグインも含めたAPIを一人がデザインする。

使えるデータ構造

論理的に正しい、構造的に正規化されている。なんてことはAPIに取ってどうでもいい。
スマートフォンのフロントエンドから使いやすいことが何よりも重視される。

たとえば、
JSONのリクエスト結果に、Memberモデルに含まれていない画像のURLもセットにして送ってあげる。とかね。
このあたりはTwitterのAPIデザインがとにかく素晴らしい。いい感じでいろんなデータを連結して送ってくれる。
そのいい感じのサイズ感が絶妙である。

プラグインが増えたときどうするの？

問題なのはプラグインが増えたときに、そのAPIはどう対応するか？ということ。

それは、次のような形で対処しようと考えている。

APIのリクエストエントリポイントは統一する
投稿、リスト取得ぐらいのシンプルなAPIのエントリポイントは統一する。
API構造は アクティビティのupdate APIをベースにして、どのプラグイン向けのリクエストかメソッドタイプを追加できるイメージ。

レスポンスはバラバラでも構わない。利用するアプリ側ががんばって解釈する。

最初はルーズに対応しておいて、人気が出たプラグインのAPIは専用に整備していくというスタイルにする。

自動テストで品質管理

APIアクションは画面遷移を伴わないので、自動テストに向いている。
結果もJSONだから、結果比較が非常にしやすい。
APIの開発はテストケースとセットで行う。
このパートでは、人力のテストはほとんど必要なくなる。
※スマートフォンUIと組み合わせたパートでは必要