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 件のコメント:
コメントを投稿