社長BLOG

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と組み合わせたパートでは必要

※この内容はアドバンスドサクセスレベルで検討している項目

sfXXXPluginはコアに吸収する。

◆symfony由来のプラグイン

OpenPNEの/plugins/ディレクトリには、OpenPNEが提供するプラグインの他に、sfXXXで始まるsymfony由来のプラグインがいくつかある。これはOpenPNEユーザーにとっては全くのノイズなので、コア側に吸収してしまったほうがいい。

OpenPNE/plugins/ディレクトリは、OpenPNEのプラグインのためのディレクトリなのであって、
symfonyアプリケーションのためのものではない。
※sfXXXPluginを置いて動作させることを否定しているわけではない

すっきりさせて、シンプルにしたいね。

12月はHOUOUプロジェクトスマートフォン対応の大事な一ヶ月になる。

すでに解決方法が分かっている基礎部分は淡々とこなしていく。

淡々と進める基礎部分

・招待、新規登録関連の不整合の修正
・画像のメール投稿
・携帯電話だけどUIDを使わず、クッキーを前提とした認証

このあたりはサラッと済ませておく。大事なのは次に来る、コア、プラグイン全体を通した、便利で生産性の高いアクションフレームワークだ。

アクションフレームワーク案

現在検討中のアクションフレームワークは、これまでのOpenPNEが利用してきたsymfonyのスタイルとは異なる。
自分がsymfonyについて好きではない部分、野生のカンでやばそうな部分を避けてつくる。

理解のためにざっと画像をこしらえた。

◆アクションフレームワークの図 ※クリックして拡大

・もととなる一覧ページは通常のアクションで取得する
・その際に、エラー画面や、つぶやき表示のテンプレートパーツも一緒にロードし、HTML内部に埋め込んでおく
・検索、一覧、投稿などの各アクションはJavaScript(jQuery)でJSON形式のAPIに対して行う
・結果のJSONは埋め込んでいたテンプレートパーツに当てはめ、画面に表示する

という方式だ。

メリット

・レスポンスがHTMLタグ構造を持たないデータのみのJSONになるので、HTML転送量が少なくなる
・AJAXを積極的に利用し、ページ全体をロードする画面遷移を少なくできる
・アクションがAPI形式になるためサーバサイドのテストが容易になる
※独立したAPIはテストがしやすい（クライアントサイドのテストは、モック？スタブ？を相手に人力で行う）
・ガジェット内部だけで、すべてのアクションフローが完結するので、ガジェットが真にポータブルに進化する
・これまでよりもシンプルで簡単にOpenPNEを拡張することができる
※symfony&Doctrine vs HTML+jQuery なので、symfonyわからなくても拡張できるようになる。
・JSONAPIは使い捨てではない。PCでもスマートフォンでもサーバサイドでも、iPhoneアプリからでも利用することができる。

デメリットはプロジェクトにおいて実績があまり無いこと。
これはタイムラインプラグイン（ゴルゴンハニー）を先行して人柱として対応することで、
経験を積んでいく。

明日リリースするゴルゴンハニーでは、PC版のアクションフレームワークに、今回のモデルを採用している。
そしてしっかりと、スムーズに動作している。
スマートフォン版の対応をいち早くすることで、今回のアクションフレームワークの確かさを確認したい。

スマートフォンのUI研究

今回つくりこんだのはこの6点。

詳しく見たい方はモックアップの詳細にアクセスを。

取り組んだ部分の特徴を紹介する。

１列目

◆１列目

最上位ナビはスマートフォンの全ページで表示する。
・メニューを呼び出すロゴマーク
・通知センター表示
・投稿ボタン

の3つで構成する。
ボタンを押した場合は、画面を遷移する形ではなく、
ダイアログ形式で一時的に上に、既存の画面の上にかぶさってくるような操作感覚になる。

◆かぶさるイメージ１MENU

◆かぶさるイメージ２ 通知センター

◆かぶさるイメージ３ 投稿

投稿画面だけは、ちょっと機能が違うので、かぶさるというよりも、
移動して投稿が終わったら元の画面に戻ってこられる。という感じになる。

２列目

２列目も共通のデザインにしている。
ホーム、フレンド、コミュニティの基本情報を示す。
◆コミュニティ、フレンドの基本情報

１，２列目の組み合わせで、UIに共通性とリズムを持たせる。

◆共通性のリズム

メンバーページ

メンバーページは、履歴書のように基本情報を写真できっちり見せるようにする。
更新性の高いタイムラインなどのコンテンツは、１件のみ表示として、リンク先で閲覧できるようにしてみた。

◆メンバーページ（フレンド）

グループも全く同一のページ構成にする
◆グループページ（コミュニティ）

通知センター

通知センターはポップアップタイプにしてみた。
◆ポップアップ型通知センター

実際にクリックして動作を確認してみると、導線がおかしい部分が確認できる。
balsamiqモックアップツールは最高だ。