社長BLOG

スマートフォンの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指定をした場合、きれいに表示されるだろうか？
・アイコン画像は手嶋が暫定で作成した。誰か素敵なの作ってくれないかな？
・

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—

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

Firefoxがピンチ？という記事で、湯川さんがOSSについてのコメントをされていた。

それにしてもオープンソースって新しい時代の究極のビジネスモデルとして期待されていたのに、どうして機能しなくなったんだろう。ちょっと考えてみたい。読者のみなさんはどう思われます？

この記事を読んで誤解された方がいそうなので、
オープンソースプロジェクトに関わる専門家の端くれとして説明する。

ソースがオープンになっていればOSS

オープンソース＝ビジネスモデルではない。

OSSの本質は「ソースコードがオープンになっていて、自由だ」ということ。
単なるソフトウエア、ソースコードの利用方法についての概念でしかない。

この「ソースコードがオープンだ」という概念が、これまでのソフトウエア業界ではなかった様々な価値を産み出すことにつながる。

オープンだから、世界で一番このプロジェクトに関わるべきエンジニアが、地域や職業、社会的ポジションなどに関係なく、自由に開発に関与することができる。
オープンだから、誰かが開発をやめても他の誰かにスムーズに引き継ぐことができる。
オープンだから、ビジネス化し儲けをあげて常勤のスタッフを雇い、さらに拡大していくこともできる。
そしてオープンだから、大きくしたプロジェクトを縮小することだってできる。流行らない自由だってあるんだ。

Firefoxのあゆみ

そもそもFirefoxはエンジニアが自分たちの好きなソフトウエア開発をしていたら、たまたま時代の光を浴び、たまたま検索連動広告という金脈も掘り当て、たまたま強力なビジネスモデルが見つかった。

それでもオープンソースはオープンソースだし、流行れば流行ったで自由だし、流行らなければそれも自由だ。
Firefoxはオープンソースとしてのプロジェクト運営のひとつの道を歩んでいるだけであって、例えGoogleとの契約がこじれて収入が激減したとしても、オープンソースそのものが機能しなくなったわけではない。

湯川さん勉強して

湯川さんのコメントは

「オープンソースはビジネスモデルの一形態としてはどうして機能しなくなったのだろう」

と書き間違えたんだと思う。間違っても

「オープンソースはどうして機能しなくなったのだろう」

と言っているわけではない。そう思いたい。実際にオープンソースは様々な分野で利用され成功している。
そもそも「オープンソースで失敗」という言い方自体が難しい。オープンソース自体は失敗することがとても難しい。
会社は潰れたら失敗、商用ソフトウエアは開発費よりも売れなかったら失敗、ビジネスは儲からなかったら失敗だ。
オープンソースは、会社が潰れようが、ビジネス化されなかろうが、オープンソースとしてその成果は残る。これがオープンソースが失敗しにくい。という理由だ。

今回の湯川さんのコメントの失敗は、オープンソースというエンジニアの創造性の産物を、単なるビジネスモデルの一つとしてしか見られていないというように、自分のようなエンジニアから見られたこと。

TechWaveはもうちょっと「エンジニアの創造性」について考えてくれるといいな。

自分が知る限り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に発展するだろう。

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