社長BLOG

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

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

・設定ファイルは一つにする（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対応するべき部分は非常に少ないとのこと。
都道府県選択の部分については、対応が必要とのこと。

大掃除で放出対象に決まった。

昨年テスト用に使っていたものだが、ずっと社内で使い続けるものでもないので、無料放出する。
価値が高いうちに、最適な人に使ってもらいたい。

※希望の方は、この記事のコメントか @tejimaまで、ご連絡ください。

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に暫定対応。

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

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

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

◆iSCSIサーバ Terastation
http://buffalo.jp/products/catalog/storage/ts-rhtgl_r5/

◆2年前くらいのDell タワーサーバ T100 2台
http://www1.jp.dell.com/jp/ja/premier/servers/server-poweredge-t100/pd.aspx?refid=server-poweredge-t100&cs=jppremier1&s=premier

◆2年前くらいのDell SC1435 1Uラックサーバ
http://supportapj.dell.com/support/edocs/systems/pe1435sc/ja/index.htm

他。4年前のPowerEdge880 SC440とかもたくさんあるけど、いらないよねぇ？

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
こんなのも分かりやすいんじゃないかな。

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

ソーシャルは時間を浪費しすぎおり、次の時代が来るとのこと。
そのなかで企業向けソーシャルに嵐が起きると言っている。

３番目の嵐：「企業向けソーシャル」

７２％の企業はソーシャルを採用したがっている。なぜなら顧客との交流、顧客の満足度、チームのコラボレーションなどがソーシャルを通じて改善するからだ。

引用元: 「ポスト・ソーシャル時代が来る」　ジョージ・コロニー – Market Hack.

OpenPNEで嵐を起こそう。