Blog

JAM Session2

8月 30th, 2010 in tech/study
Comments →
 

2010年8月7日から始まったJAM – HTML5 and FlashのSession2。
お題は「MediaRSSをフィードとするフォトビューアをつくってください」
OrganizerはGoogleさん。
あのGoogleのお題にしてはシンプルだなぁと思った人も多いかもしれませんが、
このテーマの裏にさらに壮大なテーマを含んでいることがわかります。
この MediaRSS(mRSS) というのは、
Yahoo!が開発したマルチメディアベースのRSS配信における規格です。
mRSSが生まれた背景にはお金の見え隠れする話もあったと思いますが、
1つはコンテンツホルダーの権利を大切にするという目的が含まれています。
(mRSSの仕様をよく読んでみると分かると思います)
これをGoogleがテーマに挙げてくるということは、自身がモットーとしている
「Don’t be Evil (悪をなさない)」
を示しているのではないでしょうか。
また、この間グーグルとヤフーの提携の話がありましたが、
ヤフーは検索エンジンを使わせてもらう代わりに、サービスのデータをグーグルにフィードします。
もう既にmRSSの形でグーグルにデータを提供しているサービスもあると思いますが、
画像検索や動画配信などのマルチメディア領域のサービスにG/Y!双方が力を入れていく上で、
必要不可欠な要素の1つがMedia RSSであると。
JAM Session2のお題からそんな事を伺い知ることができます。
HTML5とFlash、さらにその後ろでGとY!のJAM。
結果が楽しみです。

——————————————————
こんな事を書きつつ、僕自身JAMには参加していないのですが、
「RubyKaigiが終わるまでプライベートではRuby以外書かない」
という自分ルールを愚直に守っていた為、参加できませんでした。。
さすがに今からじゃ間に合わない><
——————————————————

 

wonderfl API Rubyクライアント

8月 16th, 2010 in tech/study
Comments →
 

wonderfl APIをRubyから簡単に利用するためのライブラリを作りました。
Rubygemsに公開されています。
wonderfl | RubyGems.org | your community gem host
・RDoc ドキュメント
(Wonderfl::Client の所を見れば使い方は分かります)
File: README.rdoc [RDoc Documentation]

wonderfl APIの現在の仕様として、、リソースが存在しなくても、認証に失敗しても、全てHTTPステータスコード 200を返却してくるまずい仕様なので(せっかくリソース指向になってるのに；)、異常系処理を書いてる時に困った人も多いかと思います。このライブラリではAPIのエラー内容に応じた例外を投げるようにしています。それ以外は薄いラッパーなのでキャッシュ機能などは備えておらず、JSONレスポンスを解析する程度しか内部では行っていません。

導入方法

gemを利用してインストールできます。

$ gem install wonderfl

また、このライブラリを利用するにはapi keyが必要です。
wonderfl build flash onlineにて作成しておきます。

使い方

詳細はRubygemsのページから辿れます。RDocも適宜参照してください。
基本的に Wonderfl::Client クラスの各メソッドを呼ぶだけです。

Wonderfl::Client
get_user(‘user name’)
get_user_codes(‘user name’)
get_code(‘code id’)
get_code_forks(‘code id’)
#!/usr/bin/ruby

require 'rubygems'
require 'wonderfl'

begin
# Wonderfl::Client オブジェクトを生成、引数にapi key
  client = Wonderfl::Client.new('your api key')
  client.api_key = 'your api key'  # 後でapi keyを設定することも可能

# ユーザー情報を取得、引数にユーザー名
  user = client.get_user('wellflat')  #=> Wonderfl::User

# 各ユーザー情報を参照
  puts user.icon  #=> "http://wonderfl.net/img/comon/~.gif"
  puts user.external_url  #=> "http://rest-term.com/"
  puts user.name  #=> "wellflat"
  puts user.description  #=> "web engineer"

# 作品情報を取得、引数にコードID
  code = client.get_code('code id')  #=> Wonderfl::Code

# 作品の各情報を参照
  puts code.thumbnail  #=> 作品のサムネイルURL
  puts code.forked_count  #=> forkされた数
  puts code.favorite_count  #=> favoriteされた数
  puts code.title  #=> 作品のタイトル
  puts code.as3  #=> 作品のAS3.0コード (巨大なコードもあるので注意)
... # 他にもいろいろな情報を取得できます

# ユーザーの投稿した作品情報を取得
  user_codes = client.get_user_codes('user name')  #=> Wonderfl::UserCodes

# ユーザーの投稿した作品数
  puts user_codes.count

# 作品のタイトルを列挙
  user_codes.each do |code|
    puts code.title  #=> title 以外でももちろんOK
  end

# forkされた作品情報を取得
  code_forks = client.get_code_forks('code id')  #=> Wonderfl::CodeForks

# forkされた作品数
  puts code_forks.count

# forkしたユーザーの名前を列挙
  code_forks.each do |code|
    puts code.user_name
  end

rescue Wonderfl::BadRequest => e
# 各メソッドの引数が不正な場合

rescue Wonderfl::Unauthorized => e
# 認証に失敗した場合 (api keyが不正)

rescue Wonderfl::NotFound => e
# 指定したユーザーや作品が存在しない場合

rescue Wonderfl::InternalServerError => e
# wonderfl APIがレスポンスを正しく返却できない場合
# (APIの仕様変更などによりJSONレスポンスが解析不可の場合も)

end

コードを見てもらえば分かるように、各エラー内容に応じた例外が発生するようになっているのでそれぞれに対応した異常系処理を書くことが簡単になります。また、取得した情報が数値なら(forked_count 等) Integer 型、日付なら(created_date 等) Time 型に内部で変換しています。

また、現在取得できるユーザー/作品情報について載せておきます。

・ユーザー情報 (Wonderfl::User)

  • icon
  • external_url
  • name
  • description

・作品情報 (Wonderfl::Code)

  • thumbnail
  • as3 (get_user 利用時のみ参照可)
  • parent
  • modified_date (get_user 利用時のみ参照可)
  • compile_ok
  • created_date
  • forked_count (get_user 利用時のみ参照可)
  • license
  • swf
  • diff (get_user 利用時のみ参照可)
  • user_icon (get_user_codes, get_code_forks 利用時に参照可)
  • user_name (get_user_codes, get_code_forks 利用時に参照可)
  • title
  • id
  • favorite_count (get_user 利用時のみ参照可)

注意事項

BANされないように、取得結果をキャッシュしつつ利用するといいです（このライブラリにキャッシュ機能を付けることも考えています）。あと、要望や不具合などがあったらお知らせください。

実は、このライブラリはけっこう昔に作ったものなので、スコアAPIのクライアントは備えていません（要望があれば追加します）。APIの仕様が運良くまだ変わってないようなので今も動作しているだけだったりします。。（不具合があれば修正します）

gemのライブラリを作った個人的な目的としては、gitに慣れることとRSpecの書き方を学ぶことの2つがありました。会社ではバージョン管理にsubversionを使っていてgitを使う機会がなかったので。RSpecについては、振る舞い駆動開発というものを体験しておく必要性を感じたからです。どちらもある程度理解することはできたので目的は達成したかなと思います。rakeの使い方にも慣れるという嬉しい副産物も(^^

また、Flash使いの人はサーバサイドの言語にPHPを選択する人がほとんどだと思いますが、Rubyが使えるとRailsアプリケーションと連携したりと作品の幅が広がるのでオススメです。

 

Tags: , ,

Javascriptでカラーヒストグラム

8月 1st, 2010 in tech/study
Comments →
 

画像のカラーヒストグラムをJavascriptで。

jsdo.it：Color Histogram using Web Workers – jsdo.it
サイト内：HTML5 Color Histogram using Web Workers

Web Workers を利用しています。
Workerプロセスに画像データを渡し、Worker内部で各チャンネル毎にヒストグラムを計算して返却。
通常のWorkerでは、Workerインスタンスとバックグラウンドプロセスが1対1で対応しているため、
並列処理を行うといっても特に難しいことを考える必要はありません。
(pthreadを扱うような難しさはなし、SharedWorkerを利用する場合は多少注意が必要)

また、IE以外の主要ブラウザでは、Workerに単純なObjectが渡せるようになっており、
この対応のおかげでWeb Workersの利用用途が増え、自由度が上がりました。
ただし、Web Workersを利用する時は少しだけ気を付けることがあって、
例えば、Worker内部からはDOMオブジェクトにアクセスできません。
これはビューとビジネスロジックの分離を強制させてくれるので良い設計に繋がります。
制作寄りの方々はこの制限を不便なものだと最初は捉えるかと思いますが、
今後、HTML5が普及してJavascriptの重要性が高まり、大規模なプロジェクトが増えるはずです。
そういった時に設計から任せられるデザイナは重宝されると思います。

個人的にHTML5関連で興味があるのはストレージ周りなので、
Indexed Database APIの情報/実装が揃ってきたら、そちらの方の調査をしていく予定です。

 

Tags: ,

Javascriptで3D入門

7月 19th, 2010 in tech/study
Comments →
 


>> My 3D Library Test – jsdo.it
3D表現にはあまり詳しくないのですが、Javascriptの勉強ということで3Dライブラリを書いてます。
jsdo.itの文化に合わせてビジュアル的な要素を持ったサンプルで試していこうと。
Actionscript3.0ネイティブとPapervision3DライブラリのAPIを両方参考にして書いたので、
クラス設計も曖昧で試行錯誤中ですが、そこも含めて少しずつブラッシュアップしていこうと思います。

以前、jsdo.itに投稿した
Heart Surface – jsdo.it
Möbius Strip – jsdo.it
の2つは、座標計算や描画処理を全て1つのオブジェクトに詰め込んだ使い捨てのコードでした。
ライブラリを書くとなると、座標計算周りはただ計算するだけでいいので悩む所はないのですが、
FlashでいうところのDisplayObject(?に当たるものまで自前で書かないといけないので大変；
計算と描画を綺麗に分けて書くのが難しいです。
その点、Actionscriptは強力なクラスライブラリ/API群が備わっているので羨ましい限り。

あと話は変わって、jsdo.itのJavascript/HTML/CSSの書き分けとして、
Javascript/CSSは別の作品から読み込むことができるので、HTMLと密結合してない方がいいです。
（例えば、タグのid/class名が直接Javascriptのエリアに入り込んでしまう等）
Web Workersを利用したコードも結局DOMと切り離した書き方をすることになりますから。

引き続き、HTML5の勉強を進めていきたいと思います。

 

Tags:

MySQLパラメータチューニングメモ

7月 10th, 2010 in tech/study
Comments →
 

MySQL関連のメモ。一応、本業はインフラ屋なので。

実際に業務で見ている主にメモリ周りのパラメータについて。
特別なノウハウ等は入っていない基礎知識程度です。

MySQLのバッファには以下の2種類のタイプがある。
パラメータチューニングの際にはこの2つのタイプの違いを意識しないといけない。

* グローバルバッファ (mysqld内部で1つだけ確保される)
* スレッドバッファ (スレッド毎に確保される)

スレッドバッファに多くのメモリを割り当てすぎるとコネクションが増えた途端すぐにメモリ不足に。
物理メモリ以上のサイズを割り当ててしまうと、スワップが発生して逆にパフォーマンスが落ちる。

innodb_buffer_pool_size (グローバル)
InnoDBのデータやインデックスを保持するために使用するメモリバッファのサイズ。グローバルなのでたくさん割り当てると良い。
innodb_additional_mem_pool_size (グローバル)
InnoDBの内部データなどを保持するために使用するメモリプールのサイズ。エラーログに警告が出たら増やせばいい程度。
innodb_log_buffer_size (グローバル)
InnoDBの更新ログを記録するために使用するメモリバッファのサイズ。大きなトランザクションがある場合はこれを大きくするとディスクI/Oを減らせるが実際はそんなに必要ない。
sort_buffer_size (スレッド)
ORDER BYやGROUP BYの時に使用されるメモリバッファのサイズ。スレッドバッファなので大きくしすぎてメモリ不足にならないように。
read_rnd_buffer_size (スレッド)
ソート後にレコードを読むときに使用されるメモリバッファのサイズ。これもORDER BYやGROPY BYを行う場合のパフォーマンスに影響する。
join_buffer_size (スレッド)
インデックスを用いないテーブル結合時に使用されるメモリバッファのサイズ。
read_buffer_size (スレッド)
インデックスを用いないテーブルスキャン時に使用されるメモリバッファのサイズ。
key_buffer_size (グローバル)
MyISAMのキー(インデックス)を保持するために使用するメモリバッファのサイズ。グローバルなのでたくさん割り当てると良い。ただし、MyISAMを利用してない場合は他のパラメータにメモリを回す。
myisam_sort_buffer_size (スレッド)
MyISAMでソート時(REPAIR TABLE, CREATE INDEX, ALTER INDEX)に使用するメモリバッファのサイズ。ORDER BYやGROUP BYを行う場合のパフォーマンスに影響する。

* その他

innodb_log_file_size
InnoDBの更新ログを記録するディスク上のファイルサイズ。
1MB～innodb_buffer_pool_size/innodb_log_files_in_groupの間で設定する。

MySQLには他にもたくさんパラメータはありますが、とりあえず見ておくべき項目を挙げました。
最近はInnoDBばかり使っているので、MyISAM関連はあまりわかりません；
ちなみに、MySQL 5.5ではデフォルトストレージエンジンはInnoDBらしいですね。
ただ、業務で5.5導入するのは当分先になりそうです。。

 

Tags: