社長BLOG

シンプル・スピード・スマートフォンのOpenPNE3.7 HOUOU開発プロセス。

スマートフォンで案の定少し苦戦しているんだけど、次のシンプル、もどんどん実現する。
こちらは基本的には機能を取り外していくだけだからそんなに難しくない。

※これまで機能を使ってきてくれていたユーザーに取り外す意義を説明するのが一番大変だけど、、、

◆非推奨機能として別項目に移動
・ホーム画面レイアウト設定
・HTML挿入
・バナー
・誕生日お知らせメール
・デイリー・ニュース関連
・デイリーニュースガジェット設定（携帯メールアドレス向け）（PCメールアドレス向け）
・OpenID発行関連は全然使われていないので、一旦本体から除外しプラグイン化
・バンドルプラグインは一旦八割方アンバンドルする
・/plugins/sfXXXを移動して空っぽにする
・OpenPNE.yml ProjectConfigration.phpがよくわからないので、できればない方がいい

このあたりは、3.8リリースではOpenPNEのパッケージからは除外する予定。
OpenPNEは少し複雑になりすぎているので、この開発系でシンプルにして再出発する。

機能改善をチケットにするのがあんまり好きではない。
チケットにすると安心してしまって、その機能や必要性について深く考えることをしなくなるから。

常に要望を耳にしたり、そのことが頭の中に浮かぶような機能からなおしていくのがいいと思う。
ということで、前にも書いたけど覚えていることを棚卸しておく。

・設定ファイルは一つにする（OpenPNE.yml ProjectConfigration.php databases.ymlは多すぎる）
・/plugins/sfXXXXPluginは/lib/vendor/symfony/pluginsに移動するあ
・/public_html で稼働できるようにするその場合（そのばあい、キャッシュファイルやxxx.ymlが危険になる）
・デザインテーマを充実
・機能を半分に絞って洗練させる
・携帯から始まったOpenPNE、スマートフォンのカバーを完璧に
・./symfony openpne:install symfonyって何ですか？エンドユーザーはsymfonyを知らなくていいはず
・./symfoy タスクリストから、開発系は除外し、開発者向けプラグインに分ける
・スピードアップ

社内でのミーティングメモを共有。

HOUOUを本線にマージするために、HOUOUがOpenPNE本線の基準を満たしていない部分を対応していく。

ナビゲーションMENUの国際化(i18n)対応
ナビゲーションは管理画面から、各国語版の文言を設定される。
国際化対応するために、サーバサイドで国際化対応済みのHTMLを生成し、クライアントでレンダリングする。
（PC版などと同じ方式）ここではスマートフォンAPIは使わない。

クライアントへのDATA受け渡し
APIKEYは何か？URLはトップレベルか？ディレクトリ階層下か？
現在使っている言語設定は何か？

これらのデータは、クライアント側に渡される必要があるので、共通のHTML部分にレンダリングすることに。
データが増えるようなら、HTMLで渡すよりも、専用のタグを切ってデータを受渡したほうがいいかも。

スマートフォンAPIのi18n対応
確認したところAPIサイドではi18n対応するべき部分は非常に少ないとのこと。
都道府県選択の部分については、対応が必要とのこと。

APIはデベロッパーにとってのUIだ

エンドユーザーにとってのユーザーインターフェース（UI）とは、もちろん画面遷移やボタンの配置など、実際にエンドユーザーが操作するもの。

デベロッパーは直接画面を操作しない。彼らはAPIを通じて機能を作ったり、SNS本体を操作する。

そういう意味で、デベロッパーが直接操作するものは一般的なUIでは無くAPIなのだ。

そのデベロッパーのUIであるAPIをユーザーフレンドリーにして、簡単に使ってもらえるような仕掛けを考える。

URLを開くだけでとりあえず簡単に使える

初期のTwitterのAPIはとにかく感動した。これを入力するだけでAPIにアクセスできてしまった。

curl -u username:password -d status=”twittering from curl” http://twitter.com/statuses/update.xml

Twitterの初期、スタイリッシュなアプリやサービスが多く出てきて楽しかったのは、APIの操作が簡単だったというのが大きい。ヴィジュアル寄りのデベロッパーが、手軽に開発に参加できたからじゃないか。

※現在はBASIC認証が廃止されたので、以前に比べるとかなり難しくなっている。

HOUOUでは現在のところ、OpenPNEはスマートフォンAPIへのアクセスに、サイト内に埋め込まれたAPIKEYを利用する方式で進めている。OAuthよりも全然簡単だが、BASIC認証よりは難しい。

エラーメッセージを工夫して、
「あんたクッキー積んでアクセスしとるね。権限はあるんだけど呼び方が間違ってるよ、あなたのAPIKEYはXXXXXXXXXだから、今の方法じゃなくてこんなhttp://xxx.com/api/request?apikey=xxxxxxx&aaa=bbbbb でアクセスしてみてや、、、」

なんて、アドバイスをしてみるといいんじゃないかな？と思った。

全部のリクエストでやっていてもいけないので、curlコマンドや、通常のブラウザで直打ちをした場合には、丁寧な返答をしてあげるといい。

いよいよ月刊HOUOU12月号のリリースが近づいてきた。
今予定している内容を共有しておく。

HOUOU12月号内容

OpenPNE3.7系に合流
HOUOUは事情があって単独で進めていたが、12月号で本線と合流する。

スマートフォン不具合対策
・新規登録（携帯キャリアメールによる登録ができない問題の改善）
・画像投稿（メールによる画像投稿に対応）

上記の不具合に対応

スマートフォンUI対応
・ログイン
・ホーム
・メンバー
・コミュニティ

これら各画面がスマートフォンUIに暫定対応。

実質今週いっぱいが勝負だ。

通知センターとは、アクティビティのうち、メンバーに確実に読ませたいものをまとめたものだ。

プッシュ、未読、既読管理、スティッキー表示管理をアクティビティに対して加えたもの、と定義する。

HOUOUプロジェクトを初めてから1.5ヶ月が経った。
スマートフォン対応も土日の合宿でだいぶまとまってきた。

そろそろ、ブロック気味になっている「シンプル、スピード、スマートフォン」以外の要望のインタビューもしていきたいところ。

第一弾として、手嶋屋のホスティングチームから、ホスティングに適したOpenPNEにするにはどんな改善をすればいいか？
と聞いてみた。結果を共有する。

キャッシュの自動削除

画像キャッシュ(web/cache以下)など永続的に保存されているWEBサーバのデータを自動で削除できるようにする。
日付またはサーバのディスク容量に応じてOpenPNE側で自動で削除。
symfonyのタスクで、定期的にガベージコレクションするような形が望ましい。

これによりWEBサーバのサイズ肥大化を防ぐことができる。とのこと。

CRONTABの一本化

現在複数に分かれているOpenPNEの定時実行(cron)を1つに集約する。
定期実行系は1つのフロントスクリプトに集約する。

フロントスクリプトは極めて頻繁に動作し、SNS内のDB設定などを読みながら、実際に実行すべきタスクを決められた時間に実行する。

イメージとしては「0/30 * * * * admin /some/sns/cron/action.php」でRSSの更新もディリーニュースも実行できるようにする。

CRONは設定トラブルが多い場所なので、アプリ側で一本化できると便利だとのこと。

タスクがエラーコードを返す

インストール・アップデート（タスク）実行時に適切なエラーコードを返すようにして欲しい。

symfonyコマンド等の終了ステータスを正常終了0、DBエラーなら1、ファイルパーミッションなら 2 のように意味付けをして適切に返信されるようにする。シェルスクリプトからOpenPNEをインストールするとき、エラー発生時にOpenPNE固有の問題かそうでないかを切り分けることができ、問題解決の手がかりを得やすくなる。

ログ出力の細分化

現在ログ出力は、DEBUGかそれ以外か？というようなざっくりした分け方であり、ホスティングを安定して行うための適切なログレベルを定めたいとのこと。
以下のようなレベルのエラーは、DEBUGとは独立してレベルを定めたいとのことだ。

・ファイルパーミッションのエラー(読み込み・書き込み・実行；失敗したファイル名・実行ユーザ名)
・DB接続エラー(DBサーバに接続できなかった、ユーザ認証の失敗など、なぜDBに接続できなかったかも含めて)
・メモリ不足(使用したメモリ容量も含め)

root権限が無くてもインストールできるように

メールによる日記投稿機能を利用するために、メールサーバの設定が必要になる。
メールのエイリアス設定が、rootに近い高レベルなアクセス権限を要求する。
もっと簡単にしたいそうだ。

OpenPNEはアプリなんだから、PHPアプリレベルのアクセス権限で全機能を提供できるようにした方がいい。
一般の利用でも、メールサーバの設定が一番大きなトラブルになる。

・UIデザイン
・スマートフォンAPI
・両者の繋ぎこみ

という取組みをしていて、今スマートフォンAPIをじゃんじゃん作っている。

そのレイアウト案を共有する。

APIはデベロッパーに対するUI

通常のUIは一般のユーザー向けに努力してつくる。
APIもそれ以上の力をかけて取り組まなければいけない。APIはデベロッパーにとってのUIなのだ。

完璧な、機能美にあふれるAPIレイアウトをデザインしなければならない。

◆APIレイアウト案の図

デザインポリシー

APIレイアウトのデザインで考えている点も共有しておく。
階層を２階層で統一する
/activity/post
/member/list
など全部のAPIは２階層にする。Twitterは1階層だったり3階層だったり分かりにくい。

APIを増やしすぎない
リンク、アンリンクなど似通っていて単機能なものはまとめる
/community/join leave
/member/link unlink
などは、ひとつのAPIにまとめた。

英文法にとらわれず、わかりやすさ、使いやすさ重視
/member/communities など複数形で変化するのがややこしい、全部
/member/community_list でいいんじゃなかろうか？Globish的な視点という気がする。
/member/friend_list
こんなのも分かりやすいんじゃないかな。

こんなことを考えながらデザイン中。

スマートフォンのUIHTML構造には、ハンバーガーレイアウトを採用する。

ハンバーガーレイアウトって何？

ハンバーガーレイアウトとは、画像のようにHTMLタグをなるべくネストしないでパーツをハンバーガーの具材の用にスタックしていくレイアウト方式。

◆ハンバーガーレイアウトのソースコード

◆３つのパーツ

このような３つのパーツを積み上げていくことでデザインする。
スマートフォンは基本的にタテ一直線のレイアウトなので、この方式でもうまく行く。

それぞれのパーツがなるべくネストしないでコーディングしていくことで、
HTMLやCSSの構造をなるべくシンプルにするというのが狙いだ。
また、HTMLデザインをアプリへ組み込むときのトラブルも少なくできるとおもう。

ネストしているバージョンも作ってみたが、ネストしていてもしていなくても同じ見た目のものが表現できた。
BootstrapのGridレイアウトのおかげで実現したと言っても過言ではない。

今後、アプリ側からグルーピング目的のためにネストさせる必要もあるだろうが、
その時にも、デザインのためのネストは少ないほうがやりやすいと思う。

デザインサンプル

サンプルはGithub上で公開している。
詳しく中身を確かめたい方は、Githubレポジトリを。

スマートフォンUIのHTMLとCSSを作っている。

なるべく楽をしたいなと思い、Bootstrapを利用することにした。

なんでBootstrap？

フレームワークではなく、一部ずつライブラリ的に利用できるので、少しずつ試すのに向いていた。
対してjQueryMobileはフレームワークであり、ちょこっと使うのには難儀した。踏み込んでトラブルが起きたらもどってこられなさそうなイメージがあった。

現在Bootstrapは調査目的で採用しているところだ。
※いまのところ非常にうまくいっている。

スマートフォン用グリッド

Bootstrapには標準でグリッドレイアウト用のツールキットが備わっている。

◆Bootstrapのグリッドシステム

ただし940ピクセルを基本単位に作られているので、スマートフォンには向かない。

これをスマートフォンの既定横幅である320ピクセルに合うように改造する。
BootstrapはLESSを使って設定値を変えて再コンパイルできるようになっている。便利だ。

いろいろ値は試してみたが、
・12分割
・１ブロックサイズを23ピクセル
・スペーサーを4ピクセル

とするとぴったり320ピクセルになることがわかった。
エクセルでいろいろシミュレーションして、最適なグリッドのサイズを決定した。
※中学校受験の植木算という奴だね

◆エクセルで最適なグリッドピクセルサイズを決定

こうしてできたグリッドを元に作ったHTMLサンプルがこれ。

◆スマートフォングリッドサンプル

◆フレンドリスト

viewport設定

スマートフォン用OpenPNEの横幅は320ピクセルとした。iPhone3G(S)のサイズ。
それよりも大きなAndroidやiPhone4などからのアクセスは、viewportを指定し、あらかじめ拡大表示で使うようにする。

◆viewport設定

ローテーション対応も、特別なリキッドレイアウト対応はせず、ブラウザの機能でそのまま拡大表示をする方式に。

iPadはお年寄り向け

デバイスごとに専用のUIをつくるのは大変だし、iPadでわざわざクロウトがOpenPNEやるとも思えない。
UIは全く変えずにどんどん拡大していき、文字やボタンが大きくなる分お年寄りが使いやすい。
という戦略にした。

・iPhoneタテ表示　＝＞　幅320ピクセル：標準クロウト向け
・iPhoneヨコ表示　＝＞　幅480ピクセル：標準でボタンが押しにくい人向け
・iPadタテ表示　＝＞　幅768ピクセル：お年寄り向け
・iPadヨコ表示　＝＞　幅1024ピクセル：お年寄り向け、最大表示
※Androidやその他のタブレットも同じ

◆iPadヨコで最大表示

作ったbootstrap.css

今日のコミットはこれ。
Github

できあがったスマートフォン用bootstrap.cssはこれ。

課題メモリスト

取り組んでいる間に思いついた課題やメモ。

・フレンドリストはグリッドで表示したほうが圧倒的に柔軟性が高く見通しがいい。さらにこのグリッドはサーバサイドではなく、クライアントJSでレンダリングしよう。革命的に楽になる。
・320ピクセル用に画像を作成すると、iPhone4SやiPadでは画像がにじんで見えるので見た目が悪い。画像だけは高解像度で作ってviewport指定をした場合、きれいに表示されるだろうか？
・アイコン画像は手嶋が暫定で作成した。誰か素敵なの作ってくれないかな？
・