ですが、本日12/23に発売のvol.66でのクックパッド特集で寄稿させていただきました。
第三章「ユーザを向いたものづくり」が僕の担当です。サービス開発の進め方について余すこと無くクックパッドでのプロセスを全部まとめています。ユーザを徹底的に向いた開発手法について興味のある方は是非一読ください。
僕以外の記事もインフラ、開発基盤、スマートフォン開発、DevOpsと多岐に渡る分野の内容になっていて、かなり面白い内容になっていると思います。
読もう！ WEB+DB PRESS！
]]>今年の目標、というかここ1,2年の目標で「本にモノを書いて自分が得た知見、考えをもとに価値を提供する」みたいなものをずっと考えていました。それがひょんな所からかなって、Web+DB PRESS vol.66で記事を書かせていただきました。
今回の記事の後も技評の稲尾さんとは仲良くさせていただいているので、今後もいろいろ僕なりのものを提供し続けられればな、と思っています。
仕事については、全体として良くも悪くも個人的にはスカっとできない感じがずっと続いていたと思います。。
一方で、震災の時にやった「限られた食材で工夫」の話だったり、ここ最近のいろいろ責任が増えた中でリリースしたものだったり(割といい数字が出た)を振り返ると、やっぱり自分は追い込まれてる時のほうがいい結果が出やすいのかなぁと感じています。縛りのある中の方がパフォーマンスが出やすいというか。
どんな時でもお前なんとかしろよ、な話ではあるかと思いますが、2012年は縛りをいい感じに自分でうまく設定して、パフォーマンスを上げていきたいですね。
gem初めて作ったのはいい経験でした。
同じように、最近YouTube絡みのコードも書きました。
それぞれニッチなとこを狙ったものではありますが、自分も日常的に使うものになってるし、音楽に絡むコードを書く楽しさはこれらのコードを書くことを通じて再確認したので、来年もこんな感じのコードは書き続けたいな、と。
仕事でもっと圧倒的な結果を出したいですね!!!!1 それを元にして自分の知見だったり考えだったりをもっと外に広げたい、サービス開発エンジニアとしてはこれはやっぱり一番強く思っています。あと、仕事以外では、デバイス絡みでなんか作りたいと思っています。思っているというか構想はあるので、少しづつそれも実現していきたいですね。(最近また復活してきましたが)blogももっと書きますぞ!
と、いうわけで来年もよろしくお願いします!
]]>YouTubeでかっこういい動画を見つけたときに、iTunesで音だけでも聴きたい！な時は割とあるかと思いますが、それを実現するスクリプトです。実行権限を追加して
taifu http://www.youtube.com/watch?v=KPWfBfFFrwsx
で、wavデータを標準のエンコーダ設定でエンコードして何事もなかったようにiTunesに追加します。（要VLC.app）
「TAIFU_NAME」「TAIFU_ARTIST」「TAIFU_ALBUM」の名前でタグ付けされているので、iTunes上から「TAIFU」で検索したら追加された曲が見つかるはずです。あとは自分の好みのタグ情報に更新ください。オプションで渡すことも考えたけど、iTunes上で編集したほうが楽だったのでやめました。
「あーこれいつでも聴いていたいな〜」なものを見つけたとき、ご利用ください！
]]>ですが、本日12/23に発売のvol.66でのクックパッド特集で寄稿させていただきました。
第三章「ユーザを向いたものづくり」が僕の担当です。サービス開発の進め方について余すこと無くクックパッドでのプロセスを全部まとめています。ユーザを徹底的に向いた開発手法について興味のある方は是非一読ください。
僕以外の記事もインフラ、開発基盤、スマートフォン開発、DevOpsと多岐に渡る分野の内容になっていて、かなり面白い内容になっていると思います。
読もう！ WEB+DB PRESS！
]]>musicalの0.0.2をリリースしました。(インストールなんかの細かい話はこちら)
リッピングしたwavデータを自動的にiTunesのエンコード設定(mp3/AAC/Appleロスレス...)に従ってエンコードし、アーティスト名とDVDタイトル名を与えることでタグ情報付きでライブラリに追加します。たとえばDVDをドライブに入れた状態で、次のように実行します。
musical --title "TOUR あいのわ" --artist ハナレグミ
そうすると、
の順に処理がすすみ、最終的にはiTunesのライブラリにこのように取り込まれます。
各チャプタのタイトルは今は自動にタグ付けする仕組みはないので、そこは自前で編集を。ここもうまく自動化したいのですが、DVD自身にはトラック情報を持っていないので、amazonなりから情報をうまく吸い出すなりいい方法を模索してます。
--title, --artistを与えない場合は、それぞれ「LIVE」「ARTIST」の名前でタグ付けされます。また、半角スペースを挟む情報の場合(上の例だと、「TOUR あいのわ」)は、「"」と「"」で囲って渡してあげます。
iTunesを操作する処理については、rb-appscriptを利用しています。rb-appscriptは、AppleEventをブリッジしてrubyから扱えるようにしたライブラリで、AppleScriptに対応したアプリケーションは、全て制御することができます。
一見、すごく便利で万能すぎるように思えるんですけど、ドキュメントが全くないのが辛いとこ。(単純にファイルをライブラリに追加するだけでも相当苦労しました。) 基本的に、method_missingで実装されているので、APIを把握してないと何も開発できません。。最初は、AppleScriptのAPIをdeveloper.apple.comからAPIを探しまくってたのですが、全然見つからなくて途方に暮れてたら意外にも手元にすでに存在してました。
「アプリケーション」「ユーティリティ」から「Appleスクリプトエディタ」を起動し、「ウィンドウ」>「ライブラリ」から「iTunes」を選択すると、AppleScript用のAPIが表示されます。(ちなみに裏技的に、Appleスクリプトエディタのアイコンに、iTunesのアイコンをD&Dしてもこのライブラリウィンドウは起動します。すごい使いづらいですけど。。)
これを元に、上で述べたファイルを追加+エンコードの基本的な操作をまとめるとこんなかんじになります。
見てわかる通り、割と直感的な操作が可能になっていると思います。基本的にはgetで情報を取得、setで更新し、このときにAppleEventが発行されています。(なので、できるだけget/setの数は減らすほうがイベント発行の節約になって、パフォーマンスが上がる)
また、普段irbやpryなんかで簡単な操作をしているときに、APIを確認するまでもなく、ざっとプロパティを確認することくらいはもうちょっと手軽な方法で確認できます。ASDictionaryをインストールしておくと、各オブジェクトに対してhelpメソッドを利用できます。たとえば、現在iTunes上で選択中のトラック、current_trackには次のようなプロパティが存在することを確認できます。
$ pry
[1] pry(main)> require 'appscript'
=> true
[2] pry(main)> include Appscript
=> Object
[3] pry(main)> its = app("iTunes.app")
=> app("/Applications/iTunes.app")
[4] pry(main)> its.current_track
=> app("/Applications/iTunes.app").current_track
[5] pry(main)> its.current_track.help
==============================================================================
Help (-t)
Reference: app("/Applications/iTunes.app").current_track
------------------------------------------------------------------------------
Description of reference
Property: current_track (r/o) : track -- the current targeted track
Terminology for track class
Class: track -- playable audio source
Plural:
tracks
Inherits from:
item (in iTunes Suite)
Properties:
container (r/o) : reference -- the container of the item
id_ (r/o) : integer -- the id of the item
index (r/o) : integer -- The index of the item in internal application order.
name : unicode_text -- the name of the item
persistent_ID (r/o) : string -- the id of the item as a hexidecimal string. This id does not change over time.
album : unicode_text -- the album name of the track
album_artist : unicode_text -- the album artist of the track
album_rating : integer -- the rating of the album for this track (0 to 100)
album_rating_kind (r/o) : :user / :computed -- the rating kind of the album rating for this track
artist : unicode_text -- the artist/source of the track
bit_rate (r/o) : integer -- the bit rate of the track (in kbps)
bookmark : short_float -- the bookmark time of the track in seconds
bookmarkable : boolean -- is the playback position for this track remembered?
bpm : integer -- the tempo of this track in beats per minute
category : unicode_text -- the category of the track
comment : unicode_text -- freeform notes about the track
compilation : boolean -- is this track from a compilation album?
composer : unicode_text -- the composer of the track
database_ID (r/o) : integer -- the common, unique ID for this track. If two tracks in different playlists have the same database ID, they are sharing the same data.
date_added (r/o) : date -- the date the track was added to the playlist
description : unicode_text -- the description of the track
disc_count : integer -- the total number of discs in the source album
disc_number : integer -- the index of the disc containing this track on the source album
duration (r/o) : short_float -- the length of the track in seconds
enabled : boolean -- is this track checked for playback?
episode_ID : unicode_text -- the episode ID of the track
episode_number : integer -- the episode number of the track
EQ : unicode_text -- the name of the EQ preset of the track
finish : short_float -- the stop time of the track in seconds
gapless : boolean -- is this track from a gapless album?
genre : unicode_text -- the music/audio genre (category) of the track
grouping : unicode_text -- the grouping (piece) of the track. Generally used to denote movements within a classical work.
kind (r/o) : unicode_text -- a text description of the track
long_description : unicode_text
lyrics : unicode_text -- the lyrics of the track
modification_date (r/o) : date -- the modification date of the content of this track
played_count : integer -- number of times this track has been played
played_date : date -- the date and time this track was last played
podcast (r/o) : boolean -- is this track a podcast episode?
rating : integer -- the rating of this track (0 to 100)
rating_kind (r/o) : :user / :computed -- the rating kind of this track
release_date (r/o) : date -- the release date of this track
sample_rate (r/o) : integer -- the sample rate of the track (in Hz)
season_number : integer -- the season number of the track
shufflable : boolean -- is this track included when shuffling?
skipped_count : integer -- number of times this track has been skipped
skipped_date : date -- the date and time this track was last skipped
show : unicode_text -- the show name of the track
sort_album : unicode_text -- override string to use for the track when sorting by album
sort_artist : unicode_text -- override string to use for the track when sorting by artist
sort_album_artist : unicode_text -- override string to use for the track when sorting by album artist
sort_name : unicode_text -- override string to use for the track when sorting by name
sort_composer : unicode_text -- override string to use for the track when sorting by composer
sort_show : unicode_text -- override string to use for the track when sorting by show name
size (r/o) : integer -- the size of the track (in bytes)
start : short_float -- the start time of the track in seconds
time (r/o) : unicode_text -- the length of the track in MM:SS format
track_count : integer -- the total number of tracks on the source album
track_number : integer -- the index of the track on the source album
unplayed : boolean -- is this track unplayed?
video_kind : :none / :movie / :music_video / :TV_show -- kind of video track
volume_adjustment : integer -- relative volume adjustment of the track (-100% to 100%)
year : integer -- the year the track was recorded/released
Elements:
artworks -- by index
==============================================================================
=> app("/Applications/iTunes.app").current_track
実際は、さきほどのAppleスクリプトエディタのヘルプ情報から引っ張ってきて表示しているだけですが、都度手元で確認できるのは便利です。ざっとAPI全体を眺めて把握した上で、手元で動かしながら動作を確認するのが開発を進める方法として良さそうです。
当面、次の内容くらいはどうにかしたいです。
あとrb-appscriptめちゃめちゃ可能性を感じるので、こいつでもうちょっと遊んでみたいですね。API見ているだけでムフムフします。。！
]]>
brew install ffmpegしたときのエラーはlibmp3lameが3.98.3以上のものが見つからないというエラーでした。ところが、
$ lame --version LAME 64bits version 3.99.1 (http://lame.sf.net) Copyright (c) 1999-2011 by The LAME Project Copyright (c) 1999,2000,2001 by Mark Taylor Copyright (c) 1998 by Michael Cheng Copyright (c) 1995,1996,1997 by Michael Hipp: mpglib This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.
と、なっているので、lame本体は3.99.1の最新のものがインストールされているようです。要はこいつが認識されていないよう。
最初は、(他の)ライブラリのインストールが失敗していて、正しく認識されないことを疑ったのですが、どうもそうではなさそう。
インストールされていないことは無さそうなので、一体どのバージョンがインストールされていると見なされているんだろう、、途方に暮れつつも共有ライブラリのバージョンの確認方法がそもそもよくわかりません。。。とりあえず、libmp3lameのインストールされている場所を確認してみます。
$ locate libmp3lame /usr/lib/libmp3lame.dylib /usr/local/Cellar/lame/3.99.1/lib/libmp3lame.0.dylib /usr/local/Cellar/lame/3.99.1/lib/libmp3lame.a /usr/local/Cellar/lame/3.99.1/lib/libmp3lame.dylib /usr/local/lib/libmp3lame.0.dylib /usr/local/lib/libmp3lame.a /usr/local/lib/libmp3lame.dylib
なんかいっぱい出てきました。下の/usr/local/lib以下のものは、実際はそれぞれ/usr/local/Cellar/lame/3.99.1/以下のシンボリックリンクになっているようですが、一番上のものが何やら疑わしいです。普通、バージョン情報なんかは文字列として埋め込まれている可能性が高いので、stringsで覗いてみると
$ strings /usr/lib/libmp3lame.dylib | less l3_side->main_data_begin: %i , 3DNow! Warning: many decoders cannot handle free format bitrates >320 kbps (see documentation) xr^3/4 3.97 LAME3.97 http://www.mp3dev.org/ 32bits mpg123: Bogus region length (%d) mpg123: Can't rewind stream by %d bits! 333333? ...
むむむ。LAME3.97とすごい怪しいバージョン番号ぽいものが見えます。。。! では、他のファイルはどうなのかと思い、/usr/local/lib以下のものを調べてみると
$ strings /usr/local/libmp3lame.dylib | less Error: can't allocate VbrFrames buffer strange error flushing buffer ... Error: MAX_HEADER_BUF too small in bitstream.c Internal buffer inconsistency. flushbits <> ResvSize bit reservoir error: ... This is a fatal error. It has several possible causes: 90%% LAME compiled with buggy version of gcc using advanced optimizations 9%% Your system is overclocked 1%% bug in LAME encoding library LAME %s version %s (%s) LAME version %s (%s) ... INTERNAL ERROR IN VBR NEW CODE (986), please send bug report INTERNAL ERROR IN VBR NEW CODE (1313), please send bug report maxbits=%d usedbits=%d 3.99.1 L3.99r http://lame.sf.net ...
おおお、やはりlameのバージョンである3.99.1という文字列が確認できます。やはりこの/usr/local/lib以下のものよりも優先して/usr/lib以下の低いバージョンの共有ライブラリが参照されているようです。試しに、この低い方のものを削除して、brew install ffmpegしなおしてみると
$ brew install --use-gcc ffmpeg ==> Downloading http://ffmpeg.org/releases/ffmpeg-0.8.6.tar.bz2 File already downloaded in /Users/katsuma/Library/Caches/Homebrew ==> ./configure --prefix=/usr/local/Cellar/ffmpeg/0.8.6 --enable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --cc= ==> make install /usr/local/Cellar/ffmpeg/0.8.6: 97 files, 55M, built in 5.7 minutes
ビンゴ！やはり低いバージョンのものが邪魔をしていたようです。。。！どういう経路でこの古いバージョンのlibmp3lameが入ってきたのか謎ですが、何かのアプリケーションをインストールしたときに一緒に入って、アプリケーションのアンインストール時に削除されないまま残ったのかもしれません(謎)
ライブラリのバージョン依存でインストールに困ったときは、とりあえず
な感じでしょうか。ただ、このstringsで確認するあたりが正当法じゃない感じがする。。のですが、もっといいバージョン確認方法があればぜひ教えていただきたいです。
]]>
これをパスが通った場所に「i」という名前のファイルで置いて実行すると、IPアドレスだけ表示されて、かつクリップボードにも入るのですぐに利用できる状態になる。
手元で開発した内容をディレクターや他のメンバーと共有するときに、自分のIP教えてブラウザで直接見てもらうことがかなり多いんですけど、「i」「Enter」で共有できるようになったことで、めちゃめちゃコスト下がってかなり便利！
]]>「Mac OSXでライブDVDをmp3ファイルに変換」にも書いたのですが、僕はアーティストのライブDVDを買って思う存分鑑賞した後は、mp3/AACに変換してiTunes/iPhoneで聴くという楽しみ方をよくしています。 ところが、この変換の際に肝である0SExというソフトがMac OSX 10.7(Lion)になってから動かなくなりました。理由は明確で、0SExはPPC用にビルドされたバイナリなのでRosetta上では動作していたのですが、LionになってRosettaが取り除かれてしまったことで動作しなくなりました。Rosettaの代用品も存在せず、途方に暮れていたのですが、既存のソフトウェアの組み合わせでなんとかできることがわかったので、自分が使いやすい形にmusicalというgemの形でまとめてみました。
musicalができることが単純で、
だけです。個人的には2.のwavの変換を行ったあとに、iTunesにD&DでAACに変換を行っているので、ここまでの処理を行おうか迷ったのですが、利用する音声フォーマットは個々人に任せたほうがいいと思ったので、wav変換までで止めています。
(2011.11.27 追記) 0.0.2でiTunesの設定に従ってエンコード、ライブラリ追加まで行えるようにしました
musicalはバックエンドでdvdbackup, ffmpegを利用しているので、これらをインストールしておきます。homebrewでインストールできます(後述しますが、ちょっと罠があります)。
brew install dvdbackup brew install ffmpeg
毎度おなじみの
gem install musical
で、OKです。
一番シンプルなのは、DVDドライブにDVDを入れた状態で
musical
だけで、カレントディレクトリにチャプタ毎にwavファイルができあがります。
musical --ignore-convert-sound
で、リッピングだけ行い、wavへの変換は行いません。
musical --output=save/to/path --title=DVD_title
--output, --titleオプションを利用できます。オプションについては--helpでご確認ください。
DVDにプロテクトがかかっているので、Fairmountなどを使って、ディスクイメージとしてマウントすれば大丈夫です。
brew installで簡単にいく。。と思いきや、依存パッケージのlibdvdreadのインストールでコケました。これは単純にURLが変更になっていたので、
brew edit libdvdread
して、
@@ -3,7 +3,7 @@ require 'formula' class Libdvdread < Formula homepage 'http://www.dtek.chalmers.se/groups/dvd/' # Official site is down; use a mirror. - url 'http://www.mplayerhq.hu/MPlayer/releases/dvdnav/libdvdread-4.1.3.tar.bz2' + url 'http://www.mplayerhq.hu/MPlayer/releases/dvdnav-old/libdvdread-4.1.3.tar.bz2' md5 '6dc068d442c85a3cdd5ad3da75f6c6e8' depends_on 'libdvdcss' => :optional
こんなかんじで編集した後、brew install libdvdreadしなおしたら大丈夫です。
ちなみにこの内容は(人生初の)pull requestを送ってみたので、もしかしたら今後は取り込まれるかもしれませんね。
(2011.11.11追記) pull requestは取り込まれたので、brew updateしたらformulaを編集しなくてもインストールできると思います。
これもbrew installで簡単にいく。。と思いきや、最新のXcodeでgccが無くなった + pod2manの実行権限がなぜか無くなっていたことでかなりハマりました。あらかじめgccをインストールしなおした上で、こんなかんじでインストール可能です。
# 関連するものを含めて、一度アンインストール brew uninstall --force `brew deps ffmpeg` # なぜか実行権限無くなっていたので再設定 sudo chmod +x /usr/bin/pod2man # gccの利用を指定 brew install --use-gcc ffmpeg
基本的にこれでいけるはずなんですけど、依存関係上一緒にインストールされるlibxvid, libmp3lameあたりでコケた場合(実際、別のLionのマシンで試したらコケた)は、最悪これらのインストールをスキップしても大丈夫です。brew edit ffmpegで
depends_on 'yasm' => :build
...
#depends_on 'lame' => :optional
...
#depends_on 'xvid' => :optional
...
#args << "--enable-libmp3lame" if Formula.factory('lame').installed?
...
#args << "--enable-libxvid" if Formula.factory('xvid').installed?
こんなかんじでコメントアウトたらビルドも通り、動作が確認できました。
当然ながら、本gemは著作権違反の手助けをするためのものではありません。自身の責任の元、ご利用ください。
]]>
同僚のhmskさんから献本いただいたウェブオペレーション、なかなかまとまった時間が取れていなかったのですが、今週やっと読み終えました。
去年、hmskさんが執筆しているときから内容については大筋把握はしていたのですが、 改めてhmskさんが寄稿された18章から読みなおしました。
こういう形で自分の会社のサービスについて、かなり細かな内部なことを客観的に読むことはほとんどないので、 「あぁインフラモニタあるよね。このウィンドウも入社時と比べて種類が増えたもんだなぁ」なんてしみじみ思ったり、 (hmskさん本人も言及されていますが)「いやいやVarnishいま使ってるよねｗ」なんてにこやかな感じで読んでいたのですが、 フと目にとまったのが「18.7章 抱える課題」。そこにはこうあります。
現在クックパッドのインフラチームが唯一抱えている問題は、インフラチーム外との情報共有の面だ。 アプリケーションの開発チームとインフラチームはグループとしては別の組織として動いているため、 情報の共有がなかなか難しくなっている。(中略) まさに本書の「16章 アジャイルインフラストラクチャ」で述べられているような、 開発と運用の緊張関係に似たようなものがときに垣間見えるのである。
正直、ちょっとドキっとしました。
と、同時に「ムム、そうなのか?そこまででもないんじゃないかな??」と業務を省みることも。 そんなことをもやもや考えながら、まえがきから読み直しました。
話は前後しますが、本書はウェブオペレータ、本書の言葉をそのまま借りると「ITシステム管理の専門分野で、ウェブアプリケーションの開発、運営、保守、調整、修理を含む」業務を担当するエンジニアたち、のさまざまな知識と経験をもとにしたエッセイ集です。アジャイルのプロセス、継続的デプロイ、RDB/NoSQLなどのDB、ストレージ、キャリアについてなど、ウェブオペレータの目線からの内容はかなり多岐にわたりますが、翻訳の角征典さんの文章がとても綺麗で、非常に読みやすい１冊でした。
個人的には「4. 継続的デプロイ」「10. 開発と運用の協力と提携」 「13. 障害を活用する:ふりかえりの技芸と科学」「16 アジャイルインフラストラクチャ」あたりが特に読んでいて面白かったです。 リリースされるサービスをどういう視点でインフラはサービス開発エンジニアと協力していくべきなのか、 品質を保ちながらリスクを少なくリリースを行いつづけるための試行錯誤など、ウェブオペレータとしての生々しい声がグっときました。
このあたりについては、16章の最後にある文章が印象的です。
「アジャイル」は間違って理解、使用されることが多い。「2週間ごとに動くソフトウェアを提供する」開発者の犠牲になっていたら、 本当に申し訳ないと思う。彼らは、自分たちの行動をよく理解していないだけなのだ。悪気があるわけではない。 是非、彼らを助けてあげてほしい。それがあなたの助けにもなる。お互いに助け合いが必要だ。
(中略)
1つの考え方や観点に囚われてはいけない。最善のアイデアは文化が衝突したときに出てくるものだ。 優れたものを見つけたら盗め。理解できたら活用しろ。できるようになったら還元だ。
「アジャイル」になるかどうかなんか気にするな。「すごい」人を目指せ。
技術的な問題を解決するのは人だ。
みんなで幸せになろうよ。
1冊まるまる読み終えてもう一度、最初に気になった18章の箇所を読みなおすと、なんかスっと納得できた気がしました。 あぁ、そうか。僕はインフラチームの取り組みを理解できていなかったし、理解していたつもりになっていただけだった。 普段のSkype上での会話と週１のエンジニアミーティングで情報共有は大筋できていたと思い込んでいたけど、 そんなレベルじゃ全くダメだったんだな、というのが1冊読み終えた後の率直な感想です。
今はプロジェクトによっては、サービス開発のプロジェクトにインフラエンジニアが最低1名Joinして、 一緒にサービスを創り上げることも試行しています。 スケールの問題はまだありそうですが、最初の問題の1つの解としては挙げられそうです。 実際、僕のいるグループにhmskさんがJoinしていた時は、物理的な席もすぐ近くにいたので、 インフラ面での相談もしやすく、圧倒的な安心感がありました。
本書はインフラエンジニア(ウェブオペレータ)の方が読んでも、「そうそう、そうだよなぁ(ニヤニヤ)」と 納得感があるものも多く面白いでしょうが、むしろサービス開発エンジニアこそ読むべき1冊ではないでしょうか。 より高速に価値の高いサービスを産み続けていくためには、 パっと出のアイディアと強引な実装だけで成立しつづけるものではありません。 サービス開発エンジニアとインフラエンジニアがいかにして協調しあうべきなのか。
一度じっくり考えさせられるきっかけになる一冊だと思います。
]]>
jquery(1.5)以上と、当jsをロードしておいた状態で、
$('#foo').flickr({ user_name: 'katsuma'});
こんなかんじで最新画像のサムネイルがロードされます(デフォルトでは6枚)。Topページもこのシンプルな方法でロードさせています。
枚数を変更したいときは
$('#foo').flickr({ user_name: 'katsuma', view_num: 3 });
こんなかんじ。
サイズを変更したいときは
$('#foo').flickr({ user_name: 'katsuma', view_num: 3, size: 'small'});
こんなかんじ。詳しくは実際に試せるデモがあるのでこちらをご覧ください。
で、肝心のdeferredですが、今回は非同期のjsonpを連続して実行しつづけているのですが、普通に書くとcallbackが激しく入れ子構造になってしまうところ、それらの非同期処理を「割と同期処理っぽく綺麗に書ける」のがいいのかな、、という理解です。 たとえば、今回はユーザIDの逆引き→最新画像情報の取得→実画像のパスを取得のフローになりますが、この流れを次のように書くことができます。(実際のコードを簡略化しています)
$.when(methods.findByUsername(setting.user_name)).then(function(){
$.when(methods.getPublicPhotos()).then(function(){
$.when(methods.loadPhoto(setting.photos));
});
});
こんなかんじで、$.when~thenでchain構造でつなげていけるので、非同期処理ながらも「この処理はこの後で実行」を指示できるのがウリです。よくありがちなのはこんな書き方じゃないでしょうか。
var methods = {
findByUsername : function(name){
$.ajax({
...
callback : function(data){
...
methods.getPublicPhotos(); // callback内から次に実行する関数を呼び出し
}
});
},
getPublicPhotos : function(){
...
}
};
// 最初に呼び出す関数
methods.findByUsername(setting.user_name);
こんな感じでも書けますが、呼び出し元がコード内で散らばるので、可読性が著しく落ちることになります。jquery.deferredを利用すれば、when~thenのchainでまとめられるので、「どういう順番でどの関数が呼び出されているか」を追いかけやすくなります。 まだまだ他にもメリットはあるかと思いますが、ざっと書いてみたところとりあえずこの点が一番のメリットかな、と感じました。
最初は結構勘違いしていて、非同期処理を完全に同期処理として書けるものなのかと思ってました。なので、こんなふうに書けちゃうのかな、と。
// findByusernameはjsonpで実行...だけどreturnでidが取れるはず！ var user_id = methods.findByUsername(setting.user_name); // 上記結果を元にして再びjsonpでgetPublicPhotosを呼び出せる！ var photos = methods.getPublicPhotos(user_id);
当然こんなかんじには動きません。非同期処理はあくまでも非同期なので、returnで同期処理っぽく値を取れることはありません。このあたりはやっぱコード書かないとわからないですね。
]]>
#element {
filter: alpha(opacity=0); /* IE */
opacity: 0; /* その他のモダンブラウザ */
}
さて、普段は特に何も考えずにfilter:alpha~と記述していたのですが、 実はIEはある条件下によってまったくfilterが効かない場合があります。
そもそもの話ですが、filterはActiveXを利用したレンダリングを行っています。 そのため、そもそもセキュリティの設定などでActiveXを無効にされていると、filterが効かず想定したようなレンダリングがされません。
たとえば、「インターネットオプション」の「セキュリティ」でセキュリティのレベルを「高」にする、ActiveXの設定を個別でOFFにする、 などの設定を行うなどでfilterを無効にすることができます。
ただし、この場合は当然ながらFlashも見ることはできませんし、セキュリティを気にするユーザはそもそもIE以外のモダンブラウザを利用することの方が多いでしょうし、 標準的なユーザがこの条件下でfilterが効かない、という話はほぼ無いと考えてもいいと思います。実は次の問題が厄介です。
実は今回この事例にずばりハマってたのですが、
な条件下において、filterが適用されないことを確認しています。(参考文献 "filter-alpha-opacity fails if the element is taller than 2048px, IE7 Vista")
上記のActiveX無効の場合はJavaScriptでActiveXが有効/無効を判断できるので、何らかの対応をすることはできるのですが、 この場合はハードウェアの話が絡んでくるので、実質的な回避方法はありません。後で詳しく述べますが、今回は
をやめて、filter対象要素の面積を可能なかぎり小さくすることができたので、回避しました。
そもそも、なんでそんな巨大な要素にfilterをかける必要があるのかという話になるのですが、今回はファイルアップロードのUIをゼロから作ったことに起因します。 ファイルアップロードの際には、<input type="file" name="uploader" />なんかでファイル選択ダイアログを表示し、対象ファイルを選択することになります。 ところが、これはブラウザ標準のUIになるので、「もっと凝ったことしたい!画像など任意に要素クリックでこの選択ダイアログを表示させたい!」などとなると、途端に話は面倒くさくなり、
の選択を迫られることになります。
Flashで実装をとるという方法もあったのですが、カスタマイズ性や毎回publishすることの実装コストを考慮して、JS/CSSでの実装を選択することにしました。 たとえば画像クリックでファイル選択ダイアログを表示させたい場合、次のような構成になります。
img要素の上に大きめのinput要素を重ねあわせ、filterでalpha=0に指定します。これで画像をクリックしようとするとinput要素をクリックすることになり、結果的にダイアログを表示することができます。 そのあとはinput要素のchangeイベントに対してハンドラを設定し、formを送信なりなんなりとしてあげると完了です。
ところが、ここで１つマウスカーソルの問題があります。ただ単純にinput要素を重ねただけだと、画像の上にカーソルを重ねたときに
な形状になり、クリックできそうなことを連想できません。そこで、input要素に対して
cursor: pointer;
な、スタイルを設定する必要があります。これでカーソルの形状が
になり、解決しました。。と、言いたいのですが、実はこれでもまだ完璧ではなく、Firefoxではカーソルは変わりません。
どうもこれはFirefoxの仕様のようで、いくらcursor指定をしても変わることがありませんでした。では、Firefoxだけ残念な形になっちゃうのか。。と思いきやそうでもなく、先ほどの画像とinput要素の重ね方を工夫するともうすこし頑張れます。結果から言うとこう配置します。
分かりづらいですが、最初の例では画像に対してinput要素も{ left:0, top:0 }で配置していたのに比べて、２つ目の例ではinput要素をサイズを巨大なものにして、{ right:0, top:0 }で配置します。(大きさはfont-size:で調整します) このとき、要素のサイズを巨大にして「選択」ボタンを画像に重ねることがポイントです。「選択」ボタンを画像にうまく重ねることで、画像のマウスオーバー時に
と、することができ、最初の状態と比べて「クリックできそう感」が改善されます。ちなみにこのマニアックな手法はいろんなファイルアップロードライブラリを見ても、 Flash実装じゃないものは全部この仕様になってあり、Firefoxのマウスカーソル問題はここが妥協ポイントのようです。（例：file-uploader）
大きく脱線しましたが、ようやく最初のfilterの話に戻します。
ここまできてようやく「Flashで実装しない場合に、ファイルアップロードを実装する場合において、カーソルの形状の最適化のためにfilter対象要素を十分に大きくする必要がある」という話になりました。実際にこれを実装してみるとわかるのですが、画像と選択ボタンを合わせるためにはinput要素を相当巨大なものにする必要があり、 結果的に{数千px × 数百px}の巨大な面積の要素にfilterをかけることになります。
で、HWスペックが十分なマシンだとIEだと問題なくレンダリングされるのですが、冒頭の条件であったりレンダリングスペックが十分でない場合、filterに失敗して 表示が崩れる、という問題が起こります。 この場合、セキュリティ設定やActitiveXなどOS、ブラウザの設定を操作することなくfilterが無効になるので、気づかない間にユーザが不便を被ることになるので非常に厄介です。
さて、ではどう対策をすればいいかというと、話を振り返るとそもそもinput要素を巨大にしたり右寄せにしたり面倒なことをしているのはFirefoxのマウスカーソルを いい感じに見せるためだけであって、IEはそもそもこの対応をしなくともcursor: pointer;だけしておけば表示位置はどこに設定してもOKなので、 IEだけレンダリング要素を最小化しておけば大丈夫という最初で述べた結論に帰着するのです。（長い！）
と、いうわけでここまでまとめるとたとえば130x130なサイズの画象にinput要素をかぶせるときは次のようなスタイルを設定します。サイズは各環境によって微調整をしてください。
right: 0; top: 0; position: absolute; cursor: pointer; opacity: 0; /* IE以外の最新ブラウザはこれでOK */ filter: alpha(opacity=0); /* IE */ font-size: 460px; /* StarHackを使ってIEだけ適用。要素を必要十分なサイズで最小化。 */ *font-size: 32px; *width: 130px; z-index: 1; height: 130px;
CSSコーディングでグラフィックカードの特性を意識しないのは素人！
今回はたまたまレンダリング要素のサイズ変更で回避できましたが、本質的な解決にはなっていません。あと動的なサイズの要素の場合、回避は不可能そうです。どなたかこの問題について詳しい方はいないでしょうかね？？
]]>最近Macアプリケーションが気になっていて、Cocoa周りの話を調べています。その一環でRubyでMacアプリを作る方法についての話です。
Mac上でRubyでアプリケーションを作る場合、最初からインストールされてあるRubyCocoaと、最近盛り上がっているMacRubyの２通りの手段があります。 どちらもCocoaを含むいろんなフレームワークをRubyから直接叩けるのですが、RubyCocoaはプロキシオブジェクトを介してCocoaフレームワークを叩くのに対して、MacRubyはプロキシを必要とせずに直接Objective-Cのメソッドにアクセスできるのが大きな特徴です。 実装方法として、MacRubyはRubyランタイムからObjective-Cのランタイム関数を直接呼び出すことで実現しているようです。 感覚的に考えてもRubyCocoaと比べて、MacRubyの方がパフォーマンスが大きく改善されていることが期待できるので、MacRubyで遊んでみたいと思います。
MacRubyの本家サイトにはインストーラのpackageファイルがあるのですが、もっと手軽に試してみるにはrvmの利用がおすすめです。rvmは複数のRubyを共存させるツールで、いろんなバージョンのRubyを切り替えて使いたいときは必須ツールです。 同僚のmirakuiさんが詳しい記事を書いているので、rvm自身のインストールなど詳細な情報はそちらを参照ください。
ではMacRubyをrvmでインストールしてみます。MacRubyの最新バージョンは2011年1月22日現在で0.8なのですが、rvmのバージョンを最新にしないとバージョン指定でインストールできないようです。
$ rvm update --head $ rvm reload $ rvm install macruby-0.8 $ rvm use macruby-0.8
バージョンを確認してみて、次のような出力が得られるとインストール成功です。
$ ruby -v MacRuby 0.8 (ruby 1.9.2) [universal-darwin10.0, x86_64]
あとGUI系のライブラリを利用するためにHotCocoaのgemもインストールしておきます。
$ gem install hotcocoa
まずは簡単なHello Worldアプリをつくってみます。「ruby hello_world.rb で」ウィンドウ上にボタンを表示し、ボタンクリックでHello Worldをputsさせます。
MacRubyはKernelモジュールにframeworkメソッドを追加しているので、このメソッドでCocoa機能を呼び出します。 あとのコードも大体読めばわかる程度のレベルだとおもいます。Objective-Cだと抵抗あるRubyエンジニアもこれだとMacアプリも怖くないですね！
このままだとただのRubyスクリプトなので、これをネイティブアプリ化します。
(2011/1/23 23:00追記、macrubycはmacrubyに梱包されているので、LLVMからインストールする必要はありません。一応、備忘録のために導入方法だけ残しておきます。)
ネイティブアプリ化を行うためには、LLVMが提供するツールのmacrubycを利用します。macrubycはMacRubyをインストールするだけだと使えないので、LLVMのビルド、インストールが必要です。
LLVMはバージョンに依存するようで、僕の場合はrvmのサイトの内容を参考にして、次の手順で導入できました。
$ svn co -r 106781 https://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk $ cd llvm-trunk $ env UNIVERSAL=1 UNIVERSAL_ARCH="i386 x86_64" CC=/usr/bin/gcc CXX=/usr/bin/g++ ./configure --enable-bindings=none --enable-optimized --with-llvmgccdir=/tmp $ env UNIVERSAL=1 UNIVERSAL_ARCH="i386 x86_64" CC=/usr/bin/gcc CXX=/usr/bin/g++ make -j2 $ sudo env UNIVERSAL=1 UNIVERSAL_ARCH="i386 x86_64" CC=/usr/bin/gcc CXX=/usr/bin/g++ make install
makeのときに追加しているj2オプションの「2」の値はビルドを行うCPUのコア数に合わせて最適化を行ってみてください。なお、このビルドは1時間近くかかるので、時間があるときに試すのをおすすめします。
$ which macrubyc /usr/local/bin/macrubyc
のようにエラーがなく結果が返ってくればインストール成功です。
では、早速先ほどつくったhello_world.rbをコンパイルしてみましょう。コンパイルは簡単で次のコマンドでコンパイルできます。
$ macrubyc hello_world.rb -o hello_world
これでhello_worldという名前の実行可能ファイルができるので、
$ ./hello_world
で、実行できます。無事、ウィンドウが表示されましたね！
rvmでMacRubyは簡単に導入することができるので、Objective-Cを諦めていて人もRubyで手軽にMacアプリの作成を試すことが確認できました。 また、LLVMを導入することでネイティブアプリも作成することができるので、RubyでのMacアプリケーション開発の可能性の大きさも伺えますね！
]]>最近、趣味でopenFrameworksを触りだしたのですが、XCodeの開発環境を触るのも１年ぶりだし、そもそもC++を書くのは数年ぶりすぎて前に書いたのいつだっけ、、というくらいのレベルでした。 そんな感じなので、まずは開発環境を完璧にしようと思った矢先、出鼻をくじかれる問題が。
openFrameworkは2011年1月16日時点でバージョン0.062が最新となっています。 ダウンロードページから最新ファイルを解凍すると、Xcode用のテンプレートディレクトリ「xcode templates」が内包されてあり、このディレクトリをXcodeが起動していないときに下記のいずれかに配置すると、 Xcode側で認識されopenFrameworksのアプリケーション用のプロジェクトを作成できる、とあります。
/Library/Application Support/Developer/3.0/Xcode/Project Templates/openFrameworks /Library/Application Support/Developer/Shared/Xcode/Project Templates/openFrameworks ~/Library/Application Support/Developer/3.0/Xcode/Project Templates/openFrameworks ~/Library/Application Support/Developer/Shared/Xcode/Project Templates/openFrameworks
場所はどこでもよかったのですが、僕は一番下の「~/Library/Application Support/Developer/Shared/Xcode/Project Templates/openFrameworks」に「xcode templates/Project Templates/openFrameworks/Mac OSX Empty Example」ディレクトリを配置し、 「$OF_ROOT/apps/projects」以下で新規プロジェクトを作成しました。ちなみに、openFrameworksのアプリケーションを作成するときは、このapps以下で作成するのがお作法のようです。（ここじゃないとライブラリがロードできなくてそもそもビルドが全く通らない） 配置後にXcodeを起動すると、新規プロジェクトでテンプレートを洗濯するダイアログでUserTemplateで配置したディレクトリ名のテンプレートが追加されていることが確認できると思います。 ところが、ここからMac OSX Empty Exampleを選択し、そのままビルドを行うと以下の２つのエラーが出てビルドできませんでした。
Line Location ツール:0： Command /bin/sh failed with exit code 1 Line Location ツール:0： "_usleep$UNIX2003", referenced from:
さすがにこれだと意味不明すぎて対応ができません。検索してもいまいちピッタリな情報がひっかからないな。。。と思って、そもそもの環境がなんかおかしいのかな、と思いapps/examples/emptyExampleをビルドしてみると、これはビルドが通ります。 と、なると「このemptyExampleをテンプレートに使えないか」の仮説で、emptyExampleを上記のパスに配置して、新規プロジェクト(プロジェクト名test)作成後にビルドしてみたところ、
実行可能なファイルがありません
と、ダイアログが表示され今度はビルドできません。
単体だとビルドが通るのに、テンプレートにしたらダメということは、命名系がなんかおかしいのかな、、と思いよくよくダイアログを見てみると、ビルドの結果test.appを実行すべきはずなのに、emptyExampleDebug.appを実行しようとして、コケてるみたい。 要するに、テンプレートが任意の実行ファイル名を受け付けるべき箇所で、exampleからファイルをコピーしてきただけなので、変数扱いされずに定数扱いされていたことが問題だったよう。そこで、templateディレクトリ配下でemptyExampleをgrepして、全部変数に置換してあげれば解決しそうです。
grepすると、project.pbxprojファイル内で該当文字列が発見されるので、これを「プロジェクト名.app」にしてあげます。プロジェクト名は«PROJECTNAME»を利用すると、プロジェクト作成時の名前に置き換えることができるので、これを利用します。 置換後、またまた新規プロジェクトを作成しなおし、ビルドをしてみると今度こそやっとビルドが通り、実行ファイルを実行することを確認できたとおもいます。
と、いうわけで完成したテンプレートをまとめておきます。このテンプレートを元にプロジェクトを作成すると、空のウィンドウだけを起動するアプリケーションを作成できます。
openFrameworksの勉強をする前に、そもそもXcodeのカスタマイズの仕方に集中しすぎて本質から外れたことに注力しすぎちゃいました。。が、この知識を知っておけば、自分にだけ便利なオレオレスケルトンのテンプレートを作成できるので、 価値は割と大きいかな、と思えます。次回以降は、やっとコードが書ける状態になったので、実際にopenFrameworksネタで何か書きたいと思います。
]]>移行作業にはgit-svnが必要になります。MacOSXでgit-svnを使うには、git-coreをmacportsで入れるときに、+svnのvariantsをつけてインストールしてあげるとOK。ぼくはすでにgit-coreをインストールしていたので、次のようにしてインストールしなおしました。
sudo port deactivate git-core sudo port install git-core +svn
作業用の適当なディレクトリを作ります。
mkdir ~/Desktop/git cd ~/Desktop/git
次のような内容のauthors.txtを作成。(no author)はGoogle Codeの初期設定で、名無しさんがtrunk, branches, tagsを作成しているようなので、この２行が必要になります。左辺はGoogleアカウント名、右辺はgithubに登録した名前とメールアドレスです。
ryo katsuma = ryo katsuma <katsuma@gmail.com> (no author) = ryo katsuma <katsuma@gmail.com>
githubで移行用のレポジトリを作成します。作成はここから。
ここまでくるとあとは簡単。
git svn clone -s -A ./authors.txt http://svn_repo.googlecode.com/svn repo cd repo/ git remote add origin git@github.com:katsuma/new_repo.git git push origin master
Google Codeからgithubの移行は、実作業はauthors.txtを用意するくらいで、全体としてそんなに複雑なものではなかったと思います。 ちなみに今回の作業を通してTokyo-Joggingのコードを全部githubに移しました。 コード管理はもちろん、サイト全体の操作性なんかもGoogle Codeと比べてgithubの方が優れていると思うので、移行して正解だったかなーと感じています。
]]>本書は、EC2, S3を中心とするAWSの導入、運用方がをボリュームよくまとまったかなりの良本です。
一通り読んでみて感じたことは、「僕がAWSを初めてまともに使った１年前にこの本があれば。。。」と、いうこと。導入にあたってのアカウントの作成方法、料金計算方法、Webインターフェースとコマンドツールの細かな説明から運用上の諸注意まで全部一通り掲載されてあって、AWS日本語公式サイトがまだ存在しない今だと、へたに検索して１つ１つ調べるよりよっぽど有益な情報を効率よく収集できます。
個人的に一番よかったのは、６章「AWSにおける運用管理」と７-3「当社でおきた特殊な事件」。AWSの実運用事例はまだまだ国内では少ないので、このあたりの実際に使ってみてはじめて分かる、目の当たりにする困難な点は情報として絶対量もまだまだ多くありません。その点で、これらの章は使った人にとっては「あるある！！」と思える点ばかりで、AWSユーザ視点での生の声が集まったかなり貴重な章と言えると思います。あと、Auto ScalingやElastic Load Balancingなんかは、まだ使ったことがなかったので、そのあたりの情報は普通にかなり参考になりました。
と、いうわけでAWSの導入を検討している人は当然のこと、AWSのサービスを断片的には使っているもののサービス間の連携についての知識が不十分だと思える人にとって、本書は必須な本だと思います。かなりオススメ！
]]>
| user | system | total | real | |
|---|---|---|---|---|
| memcached:set | 0.120000 | 0.030000 | 0.150000 | ( 0.213069) |
| memcached:get | 0.150000 | 0.030000 | 0.180000 | ( 0.238989) |
| TokyoCabinet:set | 0.000000 | 0.000000 | 0.000000 | ( 0.002802) |
| TokyoCabinet:get | 0.000000 | 0.000000 | 0.000000 | ( 0.001759) |
| TokyoTyrant:set | 0.010000 | 0.000000 | 0.010000 | ( 0.005384) |
| TokyoTyrant:get | 0.030000 | 0.000000 | 0.030000 | ( 0.038285) |
| Redis:set | 0.040000 | 0.030000 | 0.070000 | ( 0.147060) |
| Redis:get | 0.040000 | 0.020000 | 0.060000 | ( 0.151168) |
当然のごとくmemcachedが最速だろう。。。と思いきや、そうでもない結果に。むしろ一番遅い結果に。なんだこれーーーと思って調べ続けていたのですが、バインディングのgemのコードを追いかけるかぎり、どうもこれはmemcache-clientの実装が原因のよう。
これは、memcache-clientの実装はpure-rubyで実装されているのに対して、TokyoCabinet/TokyoTyrantのバインディングの実装はnativeコードで実装されてあるのが原因のようです。事実、TokyoTyrantはmemcacheプロトコルを実装しているので、memcache-clientを利用してTokyoTyrantにアクセスすると両者はこんな結果になりました。
| user | system | total | real | |
|---|---|---|---|---|
| memcache:set | 0.120000 | 0.040000 | 0.160000 | ( 0.189803) |
| memcache:get | 0.150000 | 0.030000 | 0.180000 | ( 0.240141) |
| TokyoTyrant:set | 0.130000 | 0.030000 | 0.160000 | ( 0.238009) |
| TokyoTyrant:get | 0.130000 | 0.020000 | 0.150000 | ( 0.271598) |
TokyoTyrantのアクセス速度は一気に遅くなりました。やっぱりRuby実装に引きづられているみたいですね。。
ちなみに、Redisもsetに限るとmemcacheプロトコルと同じプロトコルを利用できるので、そのベンチをとってみると
| user | system | total | real | |
|---|---|---|---|---|
| Redis:set | 0.040000 | 0.010000 | 0.050000 | ( 0.091300) |
と、なってmemcacheクライアントを利用したときのmemcached, TokyoTyrantと比較しても圧倒的に高速だということがわかりました（おもしろい！）
と、いうわけで、memcachedが高速なことを確認するためにベンチマーク取ってみたのですが、実装によってはまったく異なる結果になることが分かって、なかなかおもしろかったです。なお、今回利用したコードはgistに掲載しています。
]]>