おもいついたら書く日記

CakePHP Advent Calendar 2011　22日目担当です。

昨日は、@ogaaaanさん
でした。


CakePHP2.0でAuthComponentは大きく変わったものの一つです。

1.3のAuthComponentでのユーザ認証は、基本的にはPOSTされたusername,passwordを
userModelに問い合わせに行くことで認証をおこなっていましたが、
2.0ではこの認証方法にBASIC認証と、Digest認証が追加されました。
さらにオリジナルの認証方法の追加もできるようになりました。

今回は、この認証方法にFacebookのOAuth認証を利用したユーザ認証を追加してみたいとおもいます。

作成したソースは以下になります。
GitHub
https://github.com/MiuraKatsu/cakephp-FacebookAuthenticate


オリジナルの認証方法を追加するには、Controller/Component/Auth/の下に
Authenticateクラスファイルを作成します。

今回はFacebookAuthenticate.phpを作成しました。

FacebookのOAuthに関してはFacebook提供のSDKを使用することにします。

SDK
https://github.com/facebook/php-sdk/
http://developers.facebook.com/blog/post/534/

vendorsかVendor配下にSDKを置いて
App::import('Vendor','facebook', array('file' => 'facebook/src/facebook.php'));
で宣言します。


拡張Authenticateの作り方ですが、とりあえずBaseAuthenticateを継承したクラスを作ります。
そして認証のロジックをauthenticate()メソッドにオーバーライドします。
その他の共通的なメソッドはBaseAuthenticateに記述してあるものでカバーできますので、
基本的にはauthenticate()メソッドで認証ロジックを実装するだけでOKです。

App::uses('Router', 'Routing');
App::uses('BaseAuthenticate', 'Controller/Component/Auth');
App::import('Vendor','facebook', array('file' => 'facebook/src/facebook.php'));
class FacebookAuthenticate extends BaseAuthenticate {

このauthenticate()メソッドですが、具体的にAuthComponetnの中で呼び出されるのは
Auth->identify()の中で、そのidentify()が呼び出されるのが、Auth->login()になります。

ですので、通常のloginではそのままAuth->loign()を利用し、
Callbackの中ではAuth->identify()を呼んで、最終的に認証させています。



ではまず使用するコントローラー側の説明です。

Componentの宣言は,

public $components = array('Auth');

でもいいですし

beforeFilter()のなかで行ってもいいです。

public beforeFilter(){

	$this->Auth->authenticate = array(
			'Facebook',
			);
	$this->Auth->allow('index', 'login','callback','logout');
	$this->Auth->loginRedirect  = '/users/index/';
	$this->Auth->logoutRedirect = '/users/index/';

	parent::beforeFilter();
}

$this->Auth->authenticateに指定した認証方法が複数あれば、それら全てで認証チェックされます。

public function index(){
	$user = $this->Auth->user();
	if($user['Member']['user_id']){
		$this->set('title_for_layout', $user['Member']['user_name'] . 'さんのマイページ');
	}else{
		$this->set('title_for_layout', 'ゲストさんのマイページ');
	}
}

1.3では、login処理はlogin()アクションを定義するだけで、勝手に行われていましたが
2.0では明示的に$this->Auth->login()を呼ぶ必要があります。

今回は、FacebookのOAuth認証を使用しています。
OAuth認証では、認証処理の途中でFacebookへのリダイレクトが入るので、login()ではRenderはしません。

public function login(){
	
	$user = $this->Auth->user();

	if(isset($user['Member']['user_id'])){
		$this->redirect($this->Auth->loginRedirect);
	}else{
		$this->Auth->login();
		$this->autoRender = false;
	}

}

さらにOAuth認証はFacebookへのリダイレクトの後、callback URLにアクセスし、認証が完了します。
ですので、前述したように、このcallback()メソッドの中で、Auth->identify()にアクセスし、
最終的にFacebookAuthenticate->authenticate()を呼び出しています。
このcallback()も最終的にはAuth->loginRedirectにリダイレクトされるので、こちらもRenderしてません。

public function callback(){
	$this->autoRender = false;
	$user = $this->Auth->identify($this->request,$this->response);
}

つまりauthenticate()メソッドが一回の認証内で2度呼び出されているので
呼び出し元のaction名によって処理を分けています。

最初のlogin()からの呼び出しではfacebookへのリダイレクトを行い、
facebookでのアプリ認証が許可されてcallbackされたcallback()からの呼び出しでは、
accessTokenを取得し、そのAccessTokenを利用して
Facebookのユーザ情報を入手しています。


callback()からの呼び出しでは、
FacebookSDKのgetAccessToken()メソッドを使って、AccessTokenを取得しているのですが、
getAccessToken()メソッドは$_REQUEST['state']を直接参照しており、その値でAccessTokenを取得しにいっています。
自分の環境ですと、$_REQUESTにstateが入ってこずに、$_REQUEST['url']の中に入っていました。
ですのでそれを抽出し、$_REQUESTに再度入れています。

	preg_match('/state=(.*)/',$_REQUEST['url'],$state);
	$_REQUEST['state'] = $state[1];

	$accessToken = $facebook->getAccessToken();

AccessTokenが取得できれば、あとは簡単にユーザ情報を取得できます。

	$me = $facebook->api('/me');

	$user = $this->_Collection->Auth->user();
	$user['Member']["user_id"] = $me['id'];
	$user['Member']["user_name"] = $me['name'];
	$user['Member']["access_oauth_token"] = $access_oauth_token;

	if ($this->_Collection->Auth->login($user)) {
		$loginRedirect = $this->_Collection->Auth->loginRedirect;
		$response->header('Location', $loginRedirect);
		$response->send();
	}

このユーザ情報を、Auth->login()に引数として渡してあげれば
以降ログインユーザとしてこのFacebookユーザの情報が利用できます。


この様に、自前でユーザテーブルを持ってなくても
Facebookで認証したユーザの情報でログインできますし、
もちろんDBを用意し、AccessTokenをDBに保存して再利用することもできると思います。


いかがだったでしょうか。

OAuth認証はFacebookだけでなくTwitterやMixiなどでも
利用されている認証方法です。
authenticate()をオーバーライドするだけで
Authコンポーネントから簡単に利用することができるので
CakePHP2.0を使う際にはちょっと試してみるのも、面白いかと思います。

明日は、@takuo_doiさんです。
よろしくお願いします〜！



追記
Facebookのアプリ認証の後callback url にリダイレクトされる際に
URL末尾に'#_=_'という謎の文字列がくっついてしまう、という現象がありました。
どうやらこれはFacebook側のBUGのようです。
この文字列がついているとloginRedirectなどにリダイレクトした後も、
'#_=_'がついてまわってしまうので、どこかの処理で取り除いてあげる必要がありそうです。
すいません。この辺、ほったらかしてます。

BUG
https://developers.facebook.com/blog/post/552/
http://bugs.developers.facebook.net/show_bug.cgi?id=20504



参照：CakePHP2.0Cookbook
http://book.cakephp.org/2.0/en/core-libraries/components/authentication.html

こちらなどを参考(というかそのまま)に。

あまりそのまんまだと芸がないので、

JPEGだけでなくGIF,PNGも対応させてみました。

class CopyPreventionImage {

	var $__isSoftbank = false;
	var $__isDocomo   = false;
	var $__isKddi     = false;

	function __construct(){
	}	
	
	function rawdata($image_data,$content_type){
		header("Content-Type: ".$content_type);
		echo $Image_data;
		exit;
	}
	
	function image($image_data,$content_type){
		//画像を出力
		header("Content-Type: ".$content_type);
		//転送防止
		if($this->__isSoftbank){
			header("x-jphone-copyright: no-store, no-transfer, no-peripheral");
		}
		
		//転送防止(jpeg,gif)
		if($content_type == 'image/jpeg'){
			$image_data = $this->_jpegNoCopy($image_data);
			echo $image_data;
			
		}elseif($content_type == 'image/gif'){
			$image_data = $this->_gifNoCopy($image_data);
			echo $image_data;
		}elseif($content_type == 'image/x-png'){
			$image_data = $this->_pngNoCopy($image_data);
			echo $image_data;
		}else{
			echo $image_data;
		}
		exit;
	}

	function _jpegNoCopy($image_data){
		
		// バイナリのコメント部以外を抽出
		$part1 = explode("\xFF\xFE", $image_data, 2);
		if(isset($part1[1])){
			$part2 = explode("\xFF", $part1[1], 2);
			if ($this->__isDocomo) {
				// 000Bは「copy="NO"」の文字列バイト数(9) + 2 = 13 の16進数
				$image_data = $part1[0] . "\xFF\xFE\x00\x0Bcopy=\"NO\"\xFF" . $part2[1];
			} elseif ($this->__isKddi) {
				// 0013は「kddi_copyright=on」の文字列バイト数(17) + 2 = 19 の16進数
				$image_data = $part1[0] . "\xFF\xFE\x00\x13kddi_copyright=on\xFF" . $part2[1];
			}
		// コメント部がなかったらSOIの直後に追加
		}else{
			//JPEG SOI SEGMENT "\xFF\xD8"
			$p1 = explode("\xFF\xD8\xFF", $image_data, 2);
			if ($this->__isDocomo) {
				$image_data = "\xFF\xD8\xFF\xFE\x00\x0Bcopy=\"NO\"\xFF" . $p1[1];
			} elseif ($this->__isKddi) {
				$image_data = "\xFF\xD8\xFF\xFE\x00\x13kddi_copyright=on\xFF" . $p1[1];
			}
		}
		
		return $image_data;
	}
	
	function _gifNoCopy($image_data){
		// バイナリのコメント部以外を抽出
		$part1 = explode("\x21\xFE", $image_data, 2);
		if(isset($part1[1])){
			$part2 = explode("\x00", $part1[1], 2);
			if ($this->__isDocomo) {
				// 000Bは「copy="NO"」の文字列バイト数(9) + 2 = 13 の16進数
				$image_data = $part1[0] . "\x21\xFE\x09copy=\"NO\"\x00" . $part2[1];
			} elseif ($this->__isKddi) {
				// 0013は「kddi_copyright=on」の文字列バイト数(17) + 2 = 19 の16進数
				$image_data = $part1[0] . "\x21\xFE\x13kddi_copyright=on\x00" . $part2[1];
			}
		}else{
			$p1 = rtrim($image_data,"\x3B" );
			
			if ($this->__isDocomo) {
				$image_data = $p1 . "\x21\xFE\x09copy=\"NO\"\x00\x3B";
			} elseif ($this->__isKddi) {
				$image_data = $p1 . "\x21\xFE\x11kddi_copyright=on\x00\x3B";
			}
		}
		return $image_data;
	}
	
	function _pngNoCopy($image_data){
		//tEXtチャンク
		//74 45 58 74
		$tEXt = "\x74\x45\x58\x74";
		//null(\x00)
		$null = "\x00";
		//キーワード(Copyright)
		//データサイズ 00 00 00 1B
		//テキストkddi_copyright=on/copy=\"NO\"
		if($this->__isDocomo){
			$keyword = "Comment";
			$size = "\x00\x00\x00\x11";
			$text = "copy=\"NO\"";
		}elseif($this->__isKddi){
		
			$keyword = "Copyright";
			$size = "\x00\x00\x00\x1B";
			$text = "kddi_copyright=on";
		}
		//CRC
		$crc = pack('L',sprintf("%u",crc32($tEXt . $keyword . $null .$text)));
		
		$part1 = substr($image_data,0,33);
		$part2 = substr($image_data,33);
		
		$image_data = $part1 . $size . $tEXt . $keyword . $null . $text . $crc . $part2;
		
		return $image_data;
	}
	
}

http://www.exgear.jp/blog/2008/11/method_cache_behavior/
http://d.hatena.ne.jp/lifegood/20090604/p1
こちらを元ネタにして
若干改良をほどこしました。

１．CacheBehaviorの導入

class CacheBehavior extends ModelBehavior {
	var $enabled = true;
	
	var $config = array();
	
	function setup(&$model, $config = array()) {
		$this->config[$model->alias] = $config;
	}
	
	//config設定
	function _setConfig(&$model,$config = null){
		if(empty($config)){
			$config = $this->config[$model->alias];
		}
		if(is_array($config)){
			if(!empty($config['config'])){
				$config = $config['config'];
			}else{
				$config = null;
			} 
		}
		return $config;
	}
	
	/**
	 * メソッドキャッシュ
	 */
	function cacheMethod(&$model, $method, $args = array(),$config = null){
		$config = $this->_setConfig($model,$config);
		
		$this->enabled = false;
		// キャッシュキー
		$cachekey = $this->createCacheKey($model, $method, $args ,$config);

		$ret = Cache::read($cachekey,$config);
		if(!empty($ret)){
			$this->enabled = true;
			return $ret;
		}
		$ret = call_user_func_array(array($model, $method), $args);
		$this->enabled = true;
		Cache::write($cachekey, $ret, $config);
		// クリア用にモデル毎のキャッシュキーリストを作成
		$cacheListKey = get_class($model) . '_cacheMethodList';
		$list = Cache::read($cacheListKey);
		$list[$cachekey] = $config;
		Cache::write($cacheListKey, $list);
		return $ret;
	}
	
	/**
	 * キャッシュキーの生成
	 *
	 */
	function createCacheKey(&$model, $method, $args = array(),$config = null){
		return  get_class($model) . '_' . $method . '_' . $this->_setConfig($model,$config)  . '_' . md5(serialize($args));
	}
	/**
	 * 再帰防止判定用
	 */
	function cacheEnabled(&$model){
		return $this->enabled;
	}
	/**
	 * キャッシュ個別クリア
	 */
	function cacheDelete(&$model, $method, $args = array(),$config = null){
		$config = $this->_setConfig($model,$config);
		$cacheListKey = $this->createCacheKey($model, $method, $args, $config);
		Cache::delete($cacheListKey,$config);
		
	}
	/**
	 * キャッシュ全クリア
	 */
	function cacheDeleteAll(&$model){
		$cacheListKey = get_class($model) . '_cacheMethodList';
		$list = Cache::read($cacheListKey);
		if(empty($list)) return;
		foreach($list as $key => $config){
			Cache::delete($key,$config);
		}
		Cache::delete($cacheListKey);
	}
	/**
	 * 追加・変更・削除時にはキャッシュをクリア
	 */
	function afterSave(&$model, $created) {
		$this->cacheDeleteAll($model);
	}
	function afterDelete(&$model) {
		$this->cacheDeleteAll($model);
	}
}

２．find()のオーバーライド

class AppModel extends Model {
var $actsAs = array('Cache' => array('config'=>'_app_find_'));

	function find($conditions = null, $fields = array(), $order = null, $recursive = null) {

	     // Call cache method
	          $args = func_get_args();
	          if ($this->Behaviors->attached('Cache')) {
	               if($this->cacheEnabled()) {
	                    return $this->cacheMethod(__FUNCTION__, $args );
	               }
	          }
	     // Case normal find. The model does not have cache behavior.
	          return parent::find($conditions, $fields, $order, $recursive);
	}
}

Perlの軽量フレームワークを探していて
Yacafiにたどり着いた。

Perlちゃんと勉強しなおそうと思ってたので
ソースを読むにも長さ的にちょうどいい。

で、自分で使うようにちょっといじったり。

以下、改造POINT。

・PACKはしないと思うのでPACK処理はざっくり削る
・だからview_template_nocompilerはview_templateにする。
・queryはquery_allで全部とってきて、そこから渡すだけに分ける。
・$actionは?action=fooでも/fooでも受ける。
・dispatchで、pre_$actionも呼ぶ。
・dispatchの中で、do_$action,model_$action,view_$actionを全部呼んじゃう。(model_$actionはdo_$actionがないときだけ)

個人的に一番大きな変更点はdispatch。
MVC、それぞれとりあえず無かったらスルー。あったら実行するようにした。
だから最低限$actionテンプレートだけあればHTML表示は出来る。
MVCそれぞれのはパラメータの引渡しはHASHでやってる。

modelにビジネスロジックだけ組んで、パラメータの引渡しして、テンプレートにはめ込むだけ。
見たいなのを想定。


あとはrender周りをもうちょっと頑張りたい。
携帯対応とか。
Mojo::Templateも勉強しないと。
dispatchのeval内はこんな感じ

KoushienLiveNHK：NHKの甲子園2009でのライブスコアの情報を取得してPOSTしてます。
http://twitter.com/KoushienLiveNHK

now_onair_nack5：NACK5のオンエアされた楽曲一覧から最新の放送された曲を取得してPOSTしてます。
http://twitter.com/now_onair_nack5

now_onair_tfm：東京FMのオンエアされた楽曲一覧から最新の放送された曲を取得してPOSTしてます。
http://twitter.com/now_onair_tfm

基本的にはXMLかHTMLを取得して
SimpleXMLとかHTML::TreeBuilderとかで必要な情報を拾って、文字列成型して
TwitterにPOSTするだけというシンプル構造。

DBと連携するようなものにもTryしたいな。

「むしの手記。」さんが
CakePHPのフック系メソッドの動きについてまとめられていましたので、
さらにComponentのメソッドも含めて試してみました。

結果はこちら

Component::initialize(&$controller)
↓
Controller::beforeFilter()
↓ ↓
↓ Component::startup(&$controller)
↓
Controller::Action()
↓
↓
Controller::beforeRender()
↓ ↓
↓ Component::beforRender(&$controller)
↓
↓ Helper::beforeLayout()
↓ ↓
---- View->renderLayout() ---------------------
↓ ↓
↓ Helper::afterLayout()
↓
---- View->render() ---------------------------
↓
↓ Component::shutdown(&$controller)
↓ ↓
Controller::afterFilter()
↓
Helper::afterRender()

想外だったのは、Controller の beforeRender の後に Component の beforeRender が動くこと。なんとなく Component のほうが先に動くような気がしていた。

昔、ニュースステーションで、久米宏が言っていた。

「医療において、いわゆる『神の領域』にどこまで近づいていいのか、というのは難しい問題ですよね。
どこまでが『神の領域』なのか？それを決めるのは誰なのか？
例えば、私は結核を患ったが、完治しました。
結核というのは少し前の時代であれば、不治の病であり、
つまり、その時代の人間にとっては、
私は、『神の領域』に踏み込んで、延命したことになります。
医療技術の進歩というものは、常にそういった問題があります」

多分、表現や文言は正確じゃないし、ひょっとしたら僕の脳内で勝手に補完された、行間の文章が盛り込まれているかもしれないけど。

でも、そんなようなことを言ってました。


「通常の命の営みに反する行為」って何なんでしょうね。
そういうことを言う人は、自分が病気になっても
抗生物質とかペニシリンとか使わないし、手術もしないんでしょうかね。

http://www.hitl.washington.edu/artoolkit/
ARToolKitのページ

http://kougaku-navi.net/ARToolKit.html
工学ナビのARToolKitの記事

http://kougaku.blog28.fc2.com/
で、工学ナビの中の人

http://nyatla.jp/nyartoolkit/wiki/index.php
NyARToolkit

http://d.hatena.ne.jp/nyatla/
NyARToolkitの中の人のブログ


http://d.hatena.ne.jp/nyatla/20080731/1217514293
MobileNyARWithMiku（モバイルNyARToolkit with 初音ミク）公開します。

今日は、「Make: Tokyo Meeting 02」というイベントに行ってきました。
http://jp.makezine.com/blog/2008/11/make_tokyo_meeting_02_update.html

　どんなイベントかっていうと、オライリー社が出版している「Make」という雑誌のイベントなんですが、その「Make」という雑誌が

『Hackの精神をハードウェア、DIY、サイエンス、生活にまで広げ、「自分の手でモノを作る楽しさ」「そのノウハウ」「すでにそれを楽しんでいる人の生の声」を紹介することで、テクノロジとユーザの関係を豊かにしています。』

というもので、

『その世界観を背景に異なるジャンルの「Maker」の発表の場、Maker同士が交流できる場として企画されたのがMake: Tokyo Meetingです。』

というイベントなんだそうです。
http://www.oreilly.co.jp/mtm02/
(↑より引用)

まあ、要は、自分で作ったいろんな物を持ち寄って、
みせっこして楽しもうということです。


最初に見に行ったのはホームメイドジェットエンジンのプレゼン。
２枚目の写真はそのジェットエンジンの実演。

なんか最初は空き缶でpulse jet engine とかで、
ご家庭で出るゴミでもジェットエンジンできるよ〜
みたいなノリだったんですが
ターボチャージャーにパイプを溶接するあたりから、
あまりご家庭に転がっていないものが･･･(^^;

しかし、実演で実際にジェットエンジンが稼動しているところは
なかなかの迫力で、お客さんもかなり集まっておりました。


とまあ、そんなMADな自作ものがゴロゴロしているイベント。
展示ブースのほうも、かなり面白かった。


自分的に気に入った・気になったのは

・iPhone鉄道模型コントローラ
http://ouch-ouch-ouch.blogspot.com/
GainerとPython+PyObjCでiPhoneを左右に傾けることで
Nゲージを動かしてます。
コネクタ以外のマイコン部が自作だそうです。
当然、Jail Break済みのiPhoneにアプリをインストールして操作しています。
ラジコンもあったんですが、生憎充電中でいじれませんでした。

・xfumble
http://www.tierra.ne.jp/~aki/diary/
あらゆるアプリで、emacsやviライクなキーバインド(X-Window)
firefoxのスクロールが[j][k]でできたのは、少しニヤリとします。

・Hacker's Cafe
http://wiki.livedoor.jp/hackerscafe/d/FrontPage
「自走式Webサーバ」も気になりましたが
「携帯のカメラにしか写らない文字」が気になりました。
要は、可視光線外の赤外線LEDで文字を表示すると、
人間の目には見えませんが、デジカメや携帯のカメラなら捕らえられるというもの。なるほど、と。なんかアイデアで面白いことできそう。

・手作りプラネタリウムと立体映像
http://www6.nsk.ne.jp/~higekita/
直径４ｍエアドームもピンホール式プラネタリウムもすべて自作。
プラネタリウムは台所のボールにドリルで穴を開けたそうです。
こういう夏休みの工作でチャレンジできそうなものがステキ。
ドームを使った立体映像もスゴイ！

・日曜ユビキタス・ガジェット
(プレゼン)
日曜ユビキタス環境のためのミドルウェア群「MobiServer」。
それを使ったガジェットの紹介。
ハンガーに掛けるだけで、画像を撮影してデータ化してくれるタンスが気に入った。便利。
似たようなアイデアで他にも日常で使えると面白いかなー。(冷蔵庫に入れる前にとか。)

・エアハープ
パンフには載ってなかった？
レーザを６本くらい上下に出して、さえぎると演奏される。
ホコリでたまに見えるレーザがおしゃれでよい。


以下、気になったけど見れなかったもの。無念。
・スピードケーブリング
こんがらがったLANケーブルをいかに早くほどくか競争。
Speedcabling協会とやらがあるそうな。バカでよい。

・Arduinoワークショップ
Arduinoいじってみたかった。

・［Making Things Talk発売記念トークショー］
プレゼン
『Making Things Talk』(オライリー・ジャパン社)も
売り切れていた。立ち読みくらいしたかった。



嫁さんが気に入ったご様子のもの
・渋谷手芸部
http://blog.livedoor.jp/shugeibu/
特に、毛糸紡ぎのワークショップがお気に入り。
糸紡ぎグッズをもらってきて、帰り道にさっそく羊毛も買い込みやる気。


その他の展示やイベントも、面白いものばかりでした。
なんか学園祭チックなノリも懐かしいし、
きてよかったなぁと思えるイベントでした。

次回もぜひ参加したいなぁ。

2日目も人気のセッションにはキャンセル待ちの行列ができてました。

会場のロビーにはテレビが2台あって、日本語のスピーカのセッションのスライドと音声を生中継してた。
でも、一番人気のE-Sessionは流してない。
同時通訳があるから難しいのかな。

だからE-Sessionのキャンセル待ちの列に並ぶついでに、いくつかのセッションはロビーで見てた。

それから企業ブースもあったんだけど、企業ブースで目を引いたのがアメブロのブース。
今回展示してたのは、社内の全エンジニア対象の研究論文。
アメブロはMySQL関連のソリューションを展開しているわけではないので、広報活動としてブースを出しているのだけど、
そこで今回は新しい試みとして、社員の研究論文の展示発表をしているのだそうです。

・一時期、業績がわるかったが、エンジニアを投入してパフォーマンスを上げたら、業績も上がった。
・技術力の向上が業績UPにつながる。
・技術力の向上の為の試作その１。
・技術力の向上はもちろん、エンジニアのモチベーションUPにも。
・昨年離職率0%
・マネージャー、経営層も効果を認めてる。
・対象は全エンジニア。ただ来年は新人は免除かも。
・テーマは自由。業務と関係なくてもOK。
・事前に申請。あまりにかけ離れてるのはNG(COBOLとか)
・半年で40時間は時間を割くこと。逆に言うと40時間以内でやる。
・普段の業務は特に変わらず行った。
・論文の審査をして、優秀賞、最優秀賞など表彰。
・プレゼンはしなかったけど、口頭審問はあった。
・最初からカンファレンスでの発表を想定していた。
・論文のレベル＝一般公開できるもの
・Q「社員から反対の声はなかったのか？」A「社員には自分の市場価値を上げろと常に言っている。」



メーカー系とか基礎研究やってるエンジニアとかでは、こういうことやってるところはあるけど、Web系の会社ではあまりないのかな？
しかもカンファレンスとはいえ、一般公開するってなかなかないねー。
対象が全エンジニアってのがいいねー。
前職でもFなんとか研で論文発表とか、コンベンションで発表とか、
昇格論文とかやってたなー。
対象になった人は若干貧乏くじ引いた的なこと言ってたけど、エンジニアなんだし、そのくらいのことはやってもいいよねー。
例のコンベンションも研究よりは業務事例紹介が多かった気がするし。
新人のときに一回だけやってそれっきりな人もいるしさー。

以下、セッションの話

○DBAが直面する問題と解決

-セキュリティ
--
--インストールとコンフィグレーション
やらなければならないこと
+「TEST」DBを削除すること
+不要なユーザを削除すること
++ rootをanonymous loginできないようにすること
++ anonymous user を削除すること
☆便利なスクリプト
mysql_secure_installation
->管理者パスワードの設定
->リモート管理者の削除
などなど
-- MySQLの実行
（OSの)root ユーザで実行してはいけない。
実行ユーザを決めるが、その実行ユーザはOSにログインできなくてよい
-- パスワード
MySQLでは有効期間、複雑さ、ユニークか、長さなどチェックできない
-- Loginに失敗
Max_connect_errors
DOS攻撃をうけたがどうか分かる。
デフォルトでは１０回失敗でブロックするようになる。
-- 権限
Process権限やSuper権限はおいそれとつけないように。
クライアントからの接続がMax_connection一杯になった場合でも
1connection分は、SUPER権限のユーザのために保留されている。
-- 暗号化
Encryptionで暗号化はできる。
-- ネットワーク
SSL,SSHは使用できる。
通信はインターネットには流さない。



-スケーラビリティ
性能を向上させる方法は２種類ある。
・スケールアップ
・スケールアウト
LAMPのSoftwareではスケールアウトのほうが効果がある。
-- Replication
-- データパーティショニング
5.1の新機能のひとつ
スピンドルで分けるのではなく、別の物理的なシステムに分ける
データのバックアップ、管理が複雑になる
テーブルを分ける必要はない

--バーチャリゼーション
物理的なシステムのなかの仮想環境にDBサーバを作る


※マルチテナントという考え方
複数の顧客を管理する方法

+ Unique Database Per Tenant
+ Unique VM & Database Per Tenant
+ One Database Unique Schemas Per Tenant
+ One Database On Schema For All Tenants

データ同士がお互いに混在していて、複数ユーザがアクセスできると
セキュリティ的に問題がある

１：セキュリティはOK。物理的に離れているし。でもコストがかかる。
２：セキュリティはよい。パフォーマンスの問題　I/Oが問題

３：そんなに悪くない　パフォーマンスもまあよい

４：一番コストがよい。バックアップとか。スキーマ管理とかいらないし。
アプリケーションやデータモデルのアップグレードコストもそんなにかからない。

MySQLカンファレンスまとめ　1日目

申し込みが遅れてしまったので人気セッションはとれず。
いくつかはキャンセル待ちで潜り込むことにしました。


今回は特にBOFが面白かった。
MySQLじゃなくてDrizzleでしたが、それでも興味深い話が聞けました。
Brian Aker（MySQLのアーキテクチャ・ディレクタ）と
直接コミュニケーションとれる機会なんて、なかなかないし。
まあ、もちろん日本語で発言しましたが。テヘ。

あのクラスのアーキテクターってやっぱりすごいんだろうなー。
あそこにたどり着くにはにはどうすればいいんだろうか。
とか、考えて少しへこんでみたり。

まあ、とりあえず受講したセッションの内容を覚えてるだけ。


○データベースシステムの設計で役立つソリューション

☆高可用性
稼働率９９．９９９％というのはどういうレベルか？

年間のダウンタイムが・・・
稼働率　年間ダウンタイム　対象　　　　　　　　　　実現する技術
９０％　　　　　３５日　　小規模ビジネス
９９％　　　　　　４日　　ISP、メインストリーム　レプリケーション
９９．９％　　　８時間　　データセンター　　　　　DRBD、共有Disk
９９．９９％　　５０分　　銀行、医療　　　　　　　cluster
９９．９９９％　　５分　　テレコム、軍事　　　　　


ソリューション
いくつかの事例紹介

-REPLICATION
　MySQLの標準機能
　非同期型(同期にタイムラグが発生)
　参照性能は向上する
　Webでは９５％が参照系
--構成
master->slave
　→OK
master->multi-slave
　→OK
master->slave->multi-slave
　→OK
　複数サーバからのレプリケーションを受けないので
　Masterのパフォーマンスもよい
multi-master->slave(malti-source)
　→NG
master<->master(multi-master)
　→注意
circle-master(循環型)
　→注意
　普通に構成としては可能
　ただし同列の更新など衝突が起こる可能性があるので注意


-DRBD
　分散ストレージ
　ネットワークRAID
　Linuxでのみ可能
　HeartBeatでお互いの生き死にを確認
　同期型(同期にタイムラグはない)
　Active/Passive構成
　ReplicationMasterの冗長化にDRBDを使用
　master(DRBD)->multi-slave(memory strage) とか


-MySQL Proxy
　LUA言語で機能拡張可能
--機能
　ロードバランシング
　フェールオーバー
　ロギング


--MySQL Cluster
　シェアードナッシング型
　共有ストレージ等特別なハードは不要
　MySQLとは別製品
　InMemoryDB
　Single Point of Failueなし
　元々のターゲットは通信事業者の加入者DB用


--memcached
負荷分散キャッシュ
Enterpriseで技術サポート
みんないろいろな形で拡張して利用している
UDF(ユーザ定義関数)の開発中

-製品(ソリューションの紹介)
Solaris Cluster
LifeKeepr
CLUSTERPRO X for windows
DRBD Plus
　→ディザスタリカバリ構成を安価に構築



☆セキュリティ
MySQLは権限を５Levelで設定
user / db / table / columns / procs(ストアド・ファンクション)


-MySQLがすでに実装している機能
暗号化　データ・通信経路
ユーザ権限管理
監視ツール
セキュリティ強化

-これから実装予定の機能
ロール機能
透過的な暗号化(いまは明示的にコマンド発行で暗号化)
データ監査機能
外部認証連携
→コードネームcitadel
　mysql forgeで公開中

-製品紹介
Guardium SQL Guard(エアー)
ログ収集監査
パケットキャプチャタイプのアプライアンス製品



☆バックアップ設計
hot / warm / cold の３種類
warm は　更新は×。参照は○

ストレージのスナップショットの機能でバックアップ
NetAppスナップショット、とか

-製品紹介
ZmandaRecoveryManager
バックアップ、履歴管理、リカバリ
GUIツール
MySQLのオプションとして購入


☆監視設計
-MySQL Enterprise Monitor
Enterpriseに付属
QueryAnalyzer機能が追加
監視対象にエージェントのインストールが必要
アドバイザー機能がお勧め
勝手にパラメータを変更したりはしない。
Email,SNMP連携が可能




○REPLICATIONの運用の話
-Checkするパラメータ
sync_binlog
innodb_flush_log_at_trx_commit
innodb_support_xa

-インフラ設計
MyISAMはインデックスをメモリにロードするが
データはロードしない
　→OSメモリファイルキャッシュを利用する
　→すべてMySQLに割り当てるのではなくて、OS分も確保する
　
-CPUコア数を考慮した設計
バッチ系の処理などで
ソフトウェアスレッド数＜ハードウェアコア数
のようになると、性能を使い切っているとは言えない

-ストレージ性能の考慮
やはりディスクは遅いのでメモリに極力展開するように

★BOF　Drizzle

WebApplicationに特化したDB
WebEngineerが求めるものは？
　→「Performance、Performance、Performance」

コンセプトはMicro Kernel
機能はPluginで追加する方針
ストアド→いらない。php,rubyで実装すれば
View→パフォーマンス悪いし
トリガ→ない。でもコールバックがある。

Multi-Core前提 512コアとかで動くように設計すれば
16でも32コアでも動く
メモリも大容量メモリが前提
今、ハードの値段は安いのでRichなハードウェアで動くものを考えている

ACID
トランザクション機能
デフォルトのストレージエンジンはInnodb
3種類くらいある。Googleの開発しているInnodbが一番性能がいい

文字コードはUTF-8オンリー
3バイトまでを使う。
4バイト目を使うのは古の中国語だけなので無視。

実はMySQLは車輪の再発明が多い
これを全部すててオープンソーススタンダードを採用
オープンソースコミュニティで開発したほうが早いし高クォリティ

Launchpadにプロジェクトがある
http://launchpad.net/drizzle
日本語訳プロジェクトもあるので是非参加してください。

機能や実装方法などで、DB開発者やWebエンジニアなどで
意見が分かれたときには、現場のDBAの意見を一番尊重している。


Q/A
「大規模Webサービスをターゲットにしているのか？」
→「サービス規模の大きさではなく、HighSpecなハードウェア上で動かす事を想定している」

嫁さんが土曜出勤なのをよいことに（？）
今シーズン初埼スタです。



結果
●0-2（ヨンセン、ほぼオウンゴール）



ワシントンとポンテと長谷部と闘莉王と小野とネネがいないとJ2クラスですが、何か。




結果もアレですが、内容も良くない。

オフ・ザ・ボールの動きが少ない。
足元ばかり。

高原とエジミウソンの組み合わせは
全く機能していない。
中盤（山田）がコントロール出来てないから
前線にボールが入らない。



後半、高原Out永井inでシフトアップしたけど
そうしたらエジミウソン消えちゃった。

山田は真ん中に置くにはムラがありすぎる。

それなら梅崎はどう？


現状のメンバーで行くしかないので
3-5-2より
4-3-3とかにして
「豪快すっ飛ばしサッカー（中盤を）」
にすべきでは。


以上！愚痴終了！

以下、よかった探し！

細貝の成長。ヨンセン吹っ飛ばしてた。
相馬のクロス。ちゃんと人がいるとこに上がった。

梅崎はシフトアップしてもついてきてた。


変わったこと
ホーム側のオーロラビジョンに試合中の映像が流れるようになった。

写真２
浦和美園駅にあったモデルハウス。
子育てに最適な環境。

日記を書くのが遅くなってしまいましたが
レッズ、アジアチャンピオンです。

何を書いていいやら、悩んでいるうちに、早一週間。

自分の気持ちを文章にするのはむずかしいですね。
でも、今の気持ちを残しておきたいと思い、
遅くはなったけど、書く。

以下、とりとめのない文章をだらだらと。



ボカに借りがあるのは、ミランだけじゃねーんだよ。続きを読む

◆決　戦　前　夜　レッズ本スレ2779◆

356 名前：U-名無しさん ：2007/11/06(火) 22:33:32 ID:X/1IRsWq0
すみません
mixiのレッズコミュに「バーで参戦」「自宅で参戦」とか書いてあるんですが
どういう意味ですか？
現場にいないのに参戦になるんですか？

432 名前：U-名無しさん ：2007/11/06(火) 22:53:07 ID:YBaCRj900
>>356
お前の居る場所が浦和だ。

451 名前：U-名無しさん ：2007/11/06(火) 22:58:12 ID:tPMWVB+z0
◆お前の居る場所が浦和だ　レッズ本スレ2780◆

ちょっと感動したｗマジで。

スレタイには採用されなかったみたいですが(^^;

東京戦
勝ちました


実はとある案件がらみで本日も休出。
で、休出したその足で、埼スタへ。

最近このパターン、多いかも(^_^;)

良い場所に職場があって良かった


ギリギリでスタジアムに到着したので
座席を探すのはあきらめて
前半はバックスタンド、後半はメインの通路で立ち見してました。

平川さんをジックリ見たかったので(・ω・)/


期待通りに２アシストの活躍！！

新聞では代表入りも近いとか？

やだなあ

少しがんばってBLOG書いてみようかと。


とりあえず、MixiやらSNSからは見えなくして
あの辺には書きずらそうなことも。

あえてトラックバックせず・・・

http://hi.baidu.com/%C6%D6%BA%CD%BA%EC%B1%A6%CA%AF

そのうちに挨拶くらいは・・・

浦和レッズのアウェイゲームに行こう！さんが
まとめてくれています。
http://www.cablenet.ne.jp/~mk/tour2007acl.html
ありがたや。

夢か本当か確認中

AFCにオーストラリアも入ったので
来年のAFC CLにオーストラリアのチームもでます。


そういえば以前こんなエントリーで書いた元浦和レッズ、ゼリッチとひょっとして
対戦できるかなぁ、と思って調べていたら
今はAリーグではなく
オランダ２部のHelmond Sportでプレイしているようです。

公式(?)
http://www.helmondsport.nl/v4/

選手紹介
http://www.helmondsport.nl/v4/html/dossiers/zelic.asp


オランダ語はちっともわかりません＿|￣|○