タグ別アーカイブ: PHPカンファレンス2010

PHPカンファレンス2010へ行ってきました。(その2)

PHPカンファレンス2010で講演を聞いてきた時のメモ書きの続きです。聞き違いの部分などもあるかと思いますがご容赦下さい。

9/25 テックデイ
—————————–
基調講演 「PHP Then and Now」
—————————–
PHPの歴史
1993年 mozaicウェブブラウザ
1994年 PHP1
1995年 PHP2:今のような構文になった。オブジェクト指向ではなかった。

2005年 完全なオブジェクト指向へ

最新ver5.3:
・ver4に比べて高速
・スタック実装の改善
・例外処理も高速でシンプル
・コンパイラも高速かつサイズ小
・Win版は40%性能改善
・全体的に5~15%高速化

目玉となる機能:
・closuresの実装
処理の間に関数を呼び出せる
・namespaceの実装
バックスラッシュを1文字で扱える
・メソッドがどのクラスで実装したのか分かるようになった(__CLASS__)
・ガベージコレクションの実装/工夫
・NOWDOC、gotoの追加
・__DIR__の追加
・php_fpmの実装
・php.iniのユーザ向けファイル→.user.ini
・opensslの強化、openidの実装

変数でクラス名、メソッド名を指定できる

日付取得処理の改善:
・第三木曜日をイテレータで取得できたりする
・datecreateformat

この講演の資料:
talks.php.net/show/phpjp10
で公開される

古いバージョンのPHPソース:
museum.php.net
でダウンロードできる

—————————-
フレームワークアップデートLT
—————————-
CakePHP:
・リファクタリングが進んでいる
・PHP5専用になる
・PHPUnitの導入
Lithium:
・PHP5.3専用のフレームワーク
・ドキュメント 1.0のリリース時に用意される
Ethna:
・2009年10月2.5.0リリース
・UTF-8化
・国際化対応
・3.0開発中
racho:
・Object.php
・Doctest
・PHP単体で動く
Agavi:
・IISのサポート
・Azureのサポート
・例外処理の連結
codelgniter:
・世界第二位
・2011/2/19に東京でイベント
・軽い、覚えやすい、拡張が容易
ZEND:
・ドキュメントのアップデート
・コンポーネントの追加
Symfony:
・2.0開発中
・Httpkernel
・HttpAceralator=レスポンスをキャッシュ
・profiler

————————–
HiPHoP for PHP
————————–
facebook:
・ユーザは80億分/1日ぐらいの時間をサイトで使っている
・毎月30億枚の写真がアップロードされる
・1億人が利用している

PHP:
・言語の中で最も処理に時間がかかる
・メモリ使用量が多い

facebookでは、PHPのソースを他の言語でも再利用している

HipHoP for PHP:
・PHPのソースをC++に変換
・C++をコンパイルして実行

処理の流れ:
ソースの分析→型の推定を行う→コードを生成/出力

HipHoP用にソースを書き直さなければならない部分もある:
・eval()、create_function()
・順番(関数の定義順)は意味がなくなる
・コンパイルには時間がかかる→インタプリタを使う(HPHPi)
・apacheなしでも動く

HipHoP:
・オープンソース化されている
・PHPエクステンションをサポート
・5秒かかっていた処理を1秒に短縮
・実際の処理時間は2分の1程度になる
・PHPの最適化が限界に来たので開発された

————————————————-
Microsoft ♥ PHP ~ 2nd Stage ~
WebMatrix 登場!
————————————————-
IIS7でPHPサポート:
実行環境までマイクロソフトが作成している

SQLserverと接続するドライバも開発されている(PDOも使える)

PHP環境作成ツール:
Web PI→PHPのインストーラ=Web環境を作成する
Web Matrix→Webサイトを構成する

上記のツールの特徴:
・IISを個別にインストールする必要はない
・簡易的に様々な開発が行える
・DBクエリの実行も行える
・テンプレートも存在している(ASP用)
・ブラウザを切り替えて表示を確認できる
・SEOのチェックができる(外部サイトも可能)

http://microsoft.com/webに情報がある

————————————————-
文字コードに起因する脆弱性とその対策
————————————————-
Unicode: /¥ → MS標準: ¥

多対一の変換になるもの=文字化けが発生する

UTF-8:
・1〜4バイトで文字を表現
・5C問題は発生しない

半端な先行バイトによるXSS

5C問題:
・shift_jisで0x5cのコードが存在する文字を利用することによる問題
・SQLインジェクションに利用される

charsetの定義は正しく行う
→脆弱性が発生する場合がある

対策:
・最新のPHPを使う
・文字コードの指定をさぼらない
・mb_xxxxxx関数を使う

————————————————-
PHPストリーム概説
————————————————-
ストリーム:
・何でもファイルのように扱える、標準入出力みたいなもの
・Get、Postの指定、リクエストヘッダ等

ストリームフィルタ:ストリームを加工できる

————————————————-
新潟アクセス修飾子のご提案
————————————————-
アクセス修飾子:
public
protect
private

zendエンジンを修正することで修飾子を追加することができる

エラーメッセージの出力部分を探してそこからソース解析する

zend中間表記+パースの部分を修正する

————————————————-
PHPの中の人によるパネルディスカッション
————————————————-
PHPによって容易にウェブにアクセスできるようになった

PHP6での国際化:
・いまのところプランはない
・Unicode対応を急ぎすぎた

様々な機能を追加:
・使いやすさが減少して行く心配がある

型のチェックを厳しくするとソース全体へ影響を与える

内部をすべてUTF-8化する取り組み→4年位続いている

PHPのコミッタ:世界で1500人位いる

一人がすべてを決めるのではなく、
グループがコンセンサスをとりながら開発して行く形が望ましい

ユニコード対応:
マルチバイト圏の開発者はまだ少ない

facebook側:理想を言えばPHPの方でユニコード対応してほしい

————————————————-
ライトニングトークス
————————————————-
■CodeIgniterをベースとしたCMS「seezoo」をオープンソースでリリース
seezoo:
・CMS
・codelgniterを使っている
・2010/10/1に安定版をリリース

■日本一の twitter bot サービス twitter bot GENERATOR
twittbot:
・twitterボットを作成できる
・138万/1日つぶやき
・twitter全体のつぶやきの1%を占める

■激安VPS + nginx + PHP-FPM
nginx:HTTPサーバ、メモリを消費しない

■PirumではじめるオレオレPEARチャンネルサーバー
Pirum:
・PEARチャンネルを管理するツール
・PEARからインストールできる

■PHP で 3D プログラミング
phpopengl:OPENGLを使っている

■やったーPHPでPEGパーサコンビネータできたよー
OpenPEARPEG:
・パーサコンビネータ
・パーサを記述できる

PHPカンファレンス2010へ行ってきました。

先週のことになりますが、PHPカンファレンス2010という催しで講演を聞いてきましたので、その時のメモ書きを公開させて頂きます。聞き違いの部分などもあるかと思いますがご容赦下さい。USTREAM等でも当日の様子が公開されているみたいです。

9/24 ビジネスデイ
———————————————————————————–
基調講演 「GREE Platformの現状と今後の取組について」
———————————————————————————–
お題:
・どのようにしていきたいのか
・オープン化してみて

2010年7月の会員数→2100万人以上(mixi、モバゲーも同じくらい)

Nintendo DSの販売数=3000万台
→GREEも同じスピードで成長

30代以上の会員も3~4割存在

GREE:オープン化でアプリの充実を目指す(会員数3000万を目指す)

ソーシャルゲーム市場は数億円規模に:
2011~2012年には本格的になる見通し

ソーシャルゲーム:
・開発費を抑えてスモールスタートが可能
・広告費も段階的に増やして行け、かつ高い利益を目指せる

運用/PDCAの重要度が高い

2010年6月末オープン化開始:
・改善を続けていかないとプラットフォームとして育たない
・画面/仕様を変更
・パートナーさんのアプリをCMで紹介(GREEが全額を負担)
・コンサルティングを行う

オープン化の結果:
・ユニークユーザー数の増加
・自社開発ゲームへのネガティブな影響はなし
・サイト導線を改善し、課金額・会員数も増加

4つのポイント:
・オープン=参入しやすい
・サービス改善=変更・改善を繰り返してゆく。トラフィックも変わってくる
・コンサルティング=データの提供、データに基づいたアドバイス(パートナーとともに成長してゆく)
         ゲームはそのまま公開してうまくいくケースは少ないので、ベータ期間を設けたりする
・プロモーション支援=年末までに30タイトルのTVCM(GREEが全額負担)

今後の展開:
・スマートフォン対応(アンドロイドがくる)
・アジア・北米への展開

—————————————————–
モバイル ソーシャルアプリの開発と運用
—————————————————–
ウノウ(株):フォト蔵を運営

まちつく:300万インストール

オープンソーシャル:
・ユーザはプラットフォームを介してアクセスする
・友達・自分情報を取得できる
・APIを利用する
・OAuthで機種/個人を特定する

OAuth(opensocial_php_client)→グーグルコードのサンプルソースが参考になる

OAuthが使えるライブラリ:
・OAuth Consumer And Server Library for PHP
・Pear OAuth
・PECL OAuth
→Pear OAuthが一番良い

毎回データを取りに行くと遅くなる=キャッシュ、キューを使う処理が必要

APIがつながらないことが多いので、そのための処理が必要

オープンソーシャルのサポート側:
・問い合わせが多いのでシステム化が必要(1日最高でメール1000通)
・問い合わせを減らす工夫が必要
・重い負荷のかかった機能を一旦切り離して停止させる覚悟も必要

オープンソーシャルの運用:
・エンジニアに負担をかけないようにする
・ユーザアクセス数の少ない時間帯にメンテナンスを行う

オープンソーシャルの設計・企画:
・友達リストを取得するような処理は重いので避けた方がよい
・APIをできるだけ使わないようにする
・一日一回しかできない機能=午前4時などに更新するようにするとトラフィックが安定する
・やっている時にニヤッとしてしまうような機能がソーシャルには重要

オープンソーシャルの開発方法:
・Proxyサーバ、sandobox+firemobilesimulatorを利用
・もしくは通常のサイトとして開発

システム構成:基本はLAMP環境
・memchache→これがないと死ぬ
・Q4M
・Nginx→プロキシ
(下記二つは運用・設定ファイルの更新に利用)
・Puppet
・Capistrano

DB:
・可能な限りメモリを増やす
・ボトルネックはDISKアクセス
・できるだけデータをメモリにのせる
・レプリケーションはあまり効果がない
・マスター分割すると性能が2倍になる(ただし開発コストも増大)

フレームワーク:
・symfony(ORMに詳しくなくても実装できる)

swfEditor:swfのバイナリを書き換えられるツール

—————————————————–
~モバイルオープンソーシャルにも対応!
~ OpenPNE Ver3.6紹介
—————————————————–
手嶋屋:OpenPNE(2005年スタート)を開発、オープンソース化した会社

SNS:情報ネットワーク社会のさきがけ
   週100~150サイトが新規開設されている

エンタメ系のSNSが多い(オンラインゲーム、ファンクラブ、ケータイゲームなど)

OpenPNE:日立、NEC、セイコーエプソン、バンダイ等で使われている

OpenPNE3.0:
・つぶやき機能を追加
・日記、ランキング、コミュニティもあり
・機能は着脱可能、モバイルでも利用可能
・モバイル対応

Symfonyを利用している:
・OpenPNEのプラグインはSymfonyのプラグイン機能を利用している
・OpenPNEソースはSymfony開発時に参考になる

Ver3.7以降、最新のモバイルオープンソーシャルに対応していく:
・twitter機能に対応
・iPhoneにも対応予定

OpenPNEを利用している150万ユーザークラスのサイトも存在している

資料はあとでブログに公開される(という話でした。)

—————————————————–
大ヒットソーシャルアプリの裏側
—————————————————–
ソーシャルアプリ:
・SNSの機能が使えるアプリ
・APIなどを利用する
・集客コストがかからない
・OpenSocialAPIを使うことによる開発コストの削減

誰も考えないようなテーマ、独自の機能を考えることが重要

他社との差別化をしないと生き残れない

恋したキャバ嬢:
・大ヒット
・負荷がすごい(最大2000PV/sec)

競合他社とテーマが重なった場合、新規機能を追加して差別化をしていかないとだめになる

手戻りが発生するとリリースが遅くなる(機会損失)
→自ら提案することで企画の意図が分かるようになり、手戻り減につながる

企画と一体になる=楽になる

負荷について:
ユーザ固有のデータ=アクセス、更新頻度高
→ソーシャルアプリでは特に負荷が高い、マスターDBへの負荷集中

Ganglia=オープンソースのモニタリングソフト

Symfonyがベース

画像合成処理:
・キャッシュは非効率
・ローカルファイルはI/Oアクセスが増える
・素材ファイルのみキャッシュ+GD高速化で対応

マスターDB対策:
・なるべくDBに接続しない
・クエリ最適化
・使わなければ接続を切る

DBコネクションの節約方法:
・memchacedの利用
 DB更新時にキャッシュも更新
・APCキャッシュ→更新が少ないときに有効
・KVSの利用(TokyoTyrant)
 1.データ消滅の心配がいらない
   →頻繁に更新されるステータスに有効
 2.不整合が起こりうる
   →例外が発生してもユーザが得をするかたちで解消できるような処理の流れを作る
・スレーブDBを利用
 レプリケーションの遅延は起こりうる 

APIとの通信:
・レスポンスタイムアウトは普通に起こりうる
・APIへのリクエスト→DB更新とは分ける

—————————————————–
Scaling the Worlds Largest Social Gaming Network
世界最大ソーシャルネットワークゲームのスケーリング
—————————————————–
Zyngaのミッション:ゲームを通じて世界とつながる

ソーシャルゲーム:
・プレイが簡単で楽しい
・他人とつながる

月間ユーザ2億4000万
ゲームの体験者数:3億2000万

拠点は世界にある:
・世界のインターネット人口の10%がプレイしている

Facebookのトップゲーム:Zyngaが占めている

一週間に1000台のサーバを増設することもある

データ量1PB

システムの構成:
Webサーバ ー memchache - DB

サーバはすべて水平方向にスケール:
・キャッシュし、非同期

完全に自動化、API化されている

APIレスポンスキャッシュ内蔵

KVSを利用

DBはデータストアとしてのみ利用する

持続型memchached(membase)を利用
→分散型KVS
・速度、柔軟性がある
・クラスター内に存在している

利用しているもの:
membase
mcmux
(上記2つはオープンソース)
pecl-memchached
FontLabel

ゲームごとに作り方が違う

既存のソースを流用しているため、
特定のフレームワークに頼る必要は無い