2011年9月20日火曜日

OpenPNE3.7以降の方向性の案

OpenPNE3.7以降の方向性について書いてみます。

まず簡単にオープンソースなSNSエンジンの意味の確認から入ります。
ストールマンも言ってるようにFacebookやGoogleなどのプロプライエタリなソフトウェアにソーシャルグラフなどのデータを置くコンピューティングは、
最終的にエンドユーザに不自由を強いるはめになると思っています。(FacebookやGoogleがある日サービスをやめたら?ある日良くわからない理由で強制退会させられたら?)
なので、FLOSSなSNSのソフトウェアを用意し、個人もしくはコミュニティの意志でソーシャルグラフなどのデータを扱える状態にするのは価値があることだと思っています。

# ストールマンが言っているのは↓な感じのこと
# Richard M. Stallman曰く、「Gmailを使うのは愚かなことだ」 | スラッシュドット・ジャパン オープンソース
# http://opensource.slashdot.jp/story/08/10/02/037222/Richard-M.-Stallman%E6%9B%B0%E3%81%8F%E3%80%81%E3%80%8CGmail%E3%82%92%E4%BD%BF%E3%81%86%E3%81%AE%E3%81%AF%E6%84%9A%E3%81%8B%E3%81%AA%E3%81%93%E3%81%A8%E3%81%A0%E3%80%8D

全然たたき台なんで、フィードバックなど是非〜

■ユーザ体験の方向性
(1) 負荷性能の向上
  「昨今の経済状況」や「コンピュータリソースの増減でシビアに課金するクラウドサーバの台頭」を受け、
  より少ないコンピュータリソースで高いパフォーマンスを出すWebアプリが求められていると思います。
 
  具体的には、最低でもOpenPNE2.14より良い性能を出す事を基準とし、
  http://openpne-dev.blogspot.com/2011/09/mediawiki117wordpress321openpne23.html の条件で、
  * メモリ使用量は、現状の20MB -> 8MB程度まで減らす
  * 秒間PVは、現状の約21PV -> 50PV程度まで増やす
  事を実現するというのはどうでしょうか?

(2) スマホ対応
  「2010末頃からの急激なスマートフォンユーザの増加」を受け(東京都でスマホ率が40%ぐらいになったんでしたっけ?この辺のマーケティング資料出せる人いたら是非ください)、
   OpenPNE3がスマートフォンでも快適に操作できることが求められていると思います。

(3) 他SNSとのシームレスな連携
  「既存の巨大SNSでのソーシャルグラフを使ったSNSの増加」を受け、
  今までの独立したSNSで「新規登録・招待・認証・フレンドリンク」を行うSNSの他にも、
  FacebookやTwitterなどのソーシャルグラフをオープンにしているSNSのアカウントやソーシャルグラフAPIを使い、
  「新規登録・招待・認証・フレンドリンク」ができるSNSが求められていると思います。
 
  具体的には、
  http://mangafuldays.jp/
  http://liblar.com/
  http://shopal.jp/
  http://booklog.jp/
  のような感じです。
 
  ガチで新規にソーシャルグラフを構築していく感じじゃなくて、こういうのが最近多いですよね。

(4) タイムライン型への移行
  「Facebook、Twitter、Google+などのタイムライン型SNSの台頭」を受け、
   今までの「機能毎のタイムライン->リンク遷移してコメント」以外に、
  「トップページに全活動の一元的なタイムライン->その場でコメント&Good or Bad」というユーザ体験ができるSNSが求められていると思います。
 
■技術の方向性
(A) フレームワーク・O/Rマッパーのオーバーヘッドの最小化
  「ユーザ体験の方向性 (1)負荷性能の向上」の解決の為の施策です。

  負荷性能測定方法の策定と負荷性能基準値の策定をした上で、
  「Silex&PDO」とか「Symfony2&Propel2」とか模索し、負荷性能基準値を満たすようにするというのはどうでしょうか?

(B) 標準バンドルプラグインを減らす
  「ユーザ体験の方向性(1)(2)(3)(4)」全ての解決の為の施策です。

  現状のコア&標準バンドルプラグインを全てカバーしつつ開発を続けるのは非常にコストがかかるので、
  まずコア&数プラグインに絞った状態からはじめて、低コストでハイパフォーマンスな開発をするというのはどうでしょうか?

(C) 「テスト済み」な状態を維持する
  「ユーザ体験の方向性(1)(2)(3)(4)」全ての解決の為の施策です。
 
  SNSは機能と機能の連携が非常に多いソフトウェアだと思います。
  適切な自動テストが無い状態で機能追加・バグ修正を行うと、その影響で思いもしないバグが起きたりします。
  その修正に時間をとられたりすると、非常にコストがかかり開発資源を浪費します。
 
  具体的には、
  * 自動テストの基準を定めた上で自動テストを用意し、常に自動テストが通る状態を維持する
  * CI(継続的インテグレーション)をjenkinsとかでやる
  というのはどうでしょうか?

(D) 「脆弱性が無い事を確認済み」な状態を維持する
  「ユーザ体験の方向性(1)(2)(3)(4)」全ての解決の為の施策です。
 
  (C)とほぼ一緒なのですが、
  SNSはユーザのロールによって「閲覧できて良い情報」と「閲覧できては駄目な情報」が複雑に設定されており、
  適切な自動テストが無い状態で機能追加・バグ修正を行うと、その影響で思いもしない脆弱性が起きたりします。
  その修正に時間をとられたりすると、非常にコストがかかり開発資源を浪費します。
  
  具体的には、
  * 自動テストの基準を定めた上で自動テストを用意し、常に自動テストが通る状態を維持する
  * CI(継続的インテグレーション)をjenkinsとかでやる
  というのはどうでしょうか?
 

0 件のコメント:

コメントを投稿