アニメ顔検出するのおもろい

[twitter:@butchi_y]さんからImager::AnimeFace(Imager::AnimeFaceのページ)っていうのがあって、そいつを入れることができないっていうのが飛んできて、実際に自分も入れてみていろいろ遊んでみた。

結局ぶっちさんが入れようとしていたRackhubには入らなかったんだけれど……。

Imager::AnimeFaceとは

上のリンクにいろいろ書いてあるんですけれど、一言で言えばアニメの中の顔認識をやるみたいです。
複数の顔を認識することも可能で、detect_animefaceっていう関数にImagerオブジェクトを食わせるだけで顔の各パーツの位置だとか構成している色なんかも返ってきてわかりやすいです。
2009年リリースみたいで今はメンテされてないみたいです。リリース直後あたりにいろんな人がレビューしているので使い方はそれを見ればいいと思います。
というかDDPでpしたらそれだけで分かると思います。

難点としては高解像度の画像を食わせると重たいとか。サービスに使うならジョブキューで待たせたりすることになりそうです。

使ってみた

こんな感じのスクリプトを組んでみる。

エラー処理とかはちゃんとやってないのでご勘弁を。

    • cropはパーツごとに切り抜き。
    • frameは枠をつける。

んで、--mosaicはやってみた結果がこちら。

横顔とかは難しい。あと人外目が細い人とか。

しかしイカちゃん、モザイクかけると偽イカ娘に見えてくる。

git status、君をいつまでも忘れない……

実は4月から新卒プログラマとして毎日プログラム書いているマコピーです。
今まではそんなにプログラムプログラムしていていなかったので、どうなることかと思いましたが、なんとかなっています。

で、最近多いミスがあります。

git addし忘れるってやつです。
この前の金曜日にそれやらかして、飲んでいるときにJenkins死んでいるぞという電話がかかってきて、
「git addし忘れるとか論外だよねー」と罵られながら(一部脚色しています)、
その場でgit addしてpushし、なんとかJenkinsさんのお怒りを鎮めることができました。

まあgit statusし忘れてなければ、コミットに含めていないファイルが分かるわけで、
今回はそれを怠ったがゆえの失敗です。

git statusを忘れないためにも対策してみます。

gitに色をつけよう

「git status忘れるんだけれどどうすればいい?」と聞くとみんな決まって
「ハァ? 忘れないでしょ」というように軽蔑の目。

この時点で泣きそうなんですけれど、出会うたびにニヤニヤしながら僕をdisってくる
[twitter:@_ishkawa]くんがこの時ばかりは助け舟。
「え、色つけてないの? マコピー情弱だね」
「あ、はい。。。」
というわけでくれたのがこれ。

e
早速適応してみると、こんな感じ

やべぇ、まるわかり! しかも設定意外と簡単なんですね。これで僕も玉虫色のgit生活が送れる!

いや、まて、これはgit statusをして見逃さないようにするための対策。
僕みたいなあんぽんたんは油断してgit statusすら打たないときがあるので、そのための対策をしなければ。

ぜったいgit statusする

git commitしようとするときに、「addしてないファイルがあるけど本当にcommitする?」
みたいな感じのを出せないかな。同時にgit statusもするみたいな。
commit直前に走るスクリプトは.git/hooks/pre-commitに書くっていうのは知っている。
ここに何か書けばいいのかな。

 #!/bin/sh                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                           
 if git status -s | grep '^??' ; then                                                                                                                                                                                                      
     git status                                                                                                                                                                                                                            
     printf "\e[31mExist of untracked files.\e[m\n"                                                                                                                                                                                        
 fi

とまあこんな感じで、git addしていないファイルがあるときはgit statusするようにしてみた。
commitはされるけれど、「おやっ?」と気づくからまだいいかな。
こんなことしても、addしたファイルがないときはstatusが勝手に走るんだけれど、
addしたファイルが1つでもある場合は、statusが走らない。

あと、上記のように(y/n)とか表示させて本当にコミットするの? とやることも考えたんだけれど、
git - can pre-commit hook accept user input?
よく読んでいないけれどなんかできないらしい。
あくまでもpre-commitはワーキングツリーの状態を見て判断するわけで、
そのときにユーザが介入できるわけではないらしい。

そもそもの話

[twitter:@hisaichi5518]くんからの指摘だとgit commit -am 'hogehoge'ってやってたの、
つまり、-aオプションでTrackedなファイルを全部自動でaddしていたのをやめたほうがいいとのこと。
だからこんなことが起こるのか。。。
あとおすすめは git add -p らしいです。
diffみながらマージするみたいにaddできるらしい。試していないけれど今度やってみよう。

というわけでここまで意識すれば覚えるだろうというライフハックでした。

Kamakura.pm #002 with BEAR!

2012/02/24 Fri
20:00 開始

1. Perlハジメマシタ @massat

以上宣伝

  • Perl歴1ヶ月からの「Perlハジメマシタ」
  • 前会社からJavaの経験はあり。村式からPHP
  • PerlBigeners #1
    • (僕もそっちだったかも。。。。)
  • 村式はPHPを6年メインに
  • PHP dis?
    • 別にいいけれど、Perlは憧れるよね
    • Rubyでもよかった
    • 次のステージへ
  • なぜPerl
    • Ruby VS Perl
    • Perlは古い。敷居が高そう。
    • Perl Mongersの愛は異常
  • Bootstrap
    • はじめてのPerl
    • モダンPerl
    • いそいで書けるようにならないと!
      • AdventCalenderなどで
  • よくなったこと
    • 環境がかっこよくなった
      • MAMPからperlbrewとか
    • エディタがかっこよくなった!
      • eclipseからemacs
      • かすたまいじー。かっこいい、もてる!
  • 配列とリファレンスでハマる
  • bless が好きになる
    • かわいい、かっこいい
    • ふぅーってやってオブジェクト完成
  • 気になること
    • try-catchない
    • public/privateない
    • リストとかハッシュとかの使い分け
    • 環境どうする?
  • Perlを1ヶ月をすると
    • わくわく
    • いけてる感じ
    • でもまだハマる
      • try-catchみたいなことをしようとするとevalやらしないといけない
    • でも書き続ける

2. CPANモジュールを作る人を増やす @songmu

  • Perlと中国語が好き
  • CPANは怖い?
  • PerlCPANの文化
  • 小さいものほど良い
    • 小粒なイノベーションが生まれやすい
    • quick hack文化 サクっと作る
    • Sub::Retry Array::Diff
    • 小粒でピリリとおもしろいモジュールが生まれる
  • 誰もやらないことをやる!
  • @songmuの最近のモジュール
    • HTTP::MobileAgent::Plugin
      • $agent->is_iphone
      • iosのバージョンが取りたかった
    • Encode::JP::Mobile::UnicodeEmoji
    • iOS5からキャリア絵文字からユニコード絵文字へ
      • MySQL5.1とかにはいんない
      • Unicode -> Google -> Encode::JP::Mobile
      • Fallbackちゃんとやっていないのでパッチ歓迎
      • モバイルサービス向け
  • CPAN Authorになる方法
    • PAUSE登録
      • 英語でCPAN Authorになりたい理由を書く
  • shipit!で一発アップ
  • 普段からちゃんとPOD書くようになる……?
  • Test::Spelling
  • 自分をオープンにして要望に対応して最終的にいいものになる!

3. typester的Perlの勉強の仕方 @typester

  • まとめ
    • 本からスタートはしない
    • いきなり何かを書く
    • 他人のコードリーディング
  • 本からスタートしない理由
    • 本で覚えるとつまらない
    • 眠くなる。最後まで読みきれない
    • 一切読まないわけではない
    • 本は情報が古い場合が多い。それに左右されないでスタートできる
    • 本の綺麗な書き方だけでは普通じゃないコードは読めなくなる
  • 作りたいもの駆動
    • 新しい言語でやってみる?
    • 言語の得意分野もある
  • PerlきっかけはBlogブーム。MTをいれる
    • でもMTでかいし、いじるの難しいからblosxomにした
    • blosxomをいじりながらPerlを覚えた
  • blosxom
    • すごく小さい
    • plugin拡張。PerlHackersっぽい思想
    • shibuya.pm.orgはblosxom
    • コードの難易度たかし hackishで楽しい部分を
  • Catalyst DBIx::Class
    • WAFとORM
    • コミットしてた。OSSの開発手法を学ぶ。IRCベース
    • mixinの設計手法
    • 本だと遅くなる部分
  • Plagger
    • miyagawaさんのコード綺麗
    • 美しくシンプルなコードの書き方を学ぶ
  • 他の言語
    • C
      • lighttpd, nginx, picoevのリーディング
      • node.jsのCの部分 ネットワークプログラミングにオススメ Ver0.4推奨
      • XSはData::MessagePackのソースを切り口にperldoc
      • XSはPerlとCの橋渡し 意外と簡単
    • Objective-C
      • CにPerlみたいな皮をかぶせた言語
      • Apple公式ドキュメントで学ぶ
      • Mooseで書いて、Objective-Cに移植
  • コツ
    • わかんないことはほっとかないこと
    • 解釈は厳密
  • 他人のコードリーディング大事!
    • Audryのコードはいみわかんなすぎだけれど天才
  • こんなに読んでいるのに未だに知らないことが出てくるPerlはほんとうに面白いですね!
  • オススメのPerlコード
    • AnyEventはおもしろい
  • Perlを初めて一ヶ月だと?
    • Plaggerを読む
      • 実際に使えて試せるのが面白いよね

4. 某SNSでfluentdとMongoDBを入れた話 @sfujiwara

  • SNSで取っているログ
  • 行動ログ
    • ユーザのアクション
    • ユーザのアクティビティの調査等に利用
  • 問い合わせ対応に重要
    • 管理画面からログが見えると捗る
    • 「コメントが多くて困る」粘着されているんじゃないのかとか
    • textだとssh&grep
  • fluentdとMongoDB
    • 以前: gearman > rsyslog > text
    • 今は: gearman > fluentd > mongo
    • 直接fluentd投げれるが、新しい技術なので、一旦gearmanに投げる
    • お試しなので落ちちゃうと取れない
    • 今は並行で使っている
  • なんで?
    • Fluentd::Loggerを書いたし
    • 実際に使ってみないとわからないよね
    • ある程度の規模で使ってみたかった、でもぶっつけ本番は不安
    • 万が一落ちても大丈夫
    • 運用の知見をためてみる
  • デモ
    • (超便利そう!)
    • Mongo > Ark > JSON
    • 管理ログ追っかけられる ほぼリアルタイムで見れる
  • やってみて
    • プログラマの手間が減る
    • ストーカーするなよ
    • 管理画面のログも取ってあるよ!
    • 使い方によっては危ない
  • job workerログにも導入
    • 問い合わせ番号を投稿後に表示(=job id)
  • 今まで全くログを吐いていなかった
  • warn()で吐き出すようにした
    • なにがなんだかになってしまった
  • 擬似シグナルハンドラ __WARN__
    • warnで吐かれるログをキャッチして投げる
  • MongoDBはJSでクエリ投げれるからいろんなことできるよ!
  • まとめ
    • ログ閲覧を管理画面化してプログラマの負担を下げる
    • fluentdは便利
    • 動作はかなり安定しているが枯れてはいない
    • 設定はわかりやすい。rsyslogは難しい
    • 新しいものなので、平行稼動できるところで
  • fluentdのバージョンアップ
    • rpmでかんたんに
    • アップデート時の取りこぼし
    • PerlのFluent::Loggerでメモリバッファ
  • MongoDBはまだ枯れていない
    • データベース単位でロックされる
    • 普通のデータベースとしてもログ取り用途にも
    • capped collection 容量制限を設定してログをとれる
      • (エンドレスカセットテープみたいなもんですね)
  • fluentdのパフォーマンス
    • 実用十分ぐらい出る
  • 普通に使う分にはRubyなしでもfluentd使える

Kamakura.pmに行って来ました。

Kamakura Perl Mongers

Kamakura Perl Mongers テクニカルトーク#2 : ATND

行って来ました。Perl初めて2週間ですけれど。。。

面白い話も聞けました。藤原組長の話なんかは今、個人的に作っている奴に大いに使わせて頂きます!

さて以下からは講義ノート。無編集アップなのであしからず。まずい部分があれば消します。

このあとのLTのときはお酒が入っていたので諦めて膝を叩いて笑う役に徹していました。

フレームワークのお仕事

僕の友人であるひさいち君がMaltsというフレームワークを作っていて、僕もそれに感化されていろいろフレームワークを考えているのですが、彼がhttp://blog.moe-project.com/2011/12/04/%E3%82%A6%E3%82%A7%E3%83%96%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%9C%E3%82%8B%E4%B8%8A%E3%81%A7%E5%BF%85%E8%A6%81%E3%81%AA%E8%A8%AD%E8%A8%88%E3%81%A8/という興味深い記事を書いていたので、これにもちょっと流されてなんか書こうと思います。

Maltsは確かWebアプリケーションの基底部分とその上に乗っかるMVCなどのプログラミングスタイル?を分離して実装していると聞いているので、その考え方で僕が今作っている信号処理フレームワークGitHub - mackee/utakata: Lightweight framework for singal processingを解説してみたいと思います。

Webアプリケーションと信号処理アプリケーションの違い

Webアプリケーション
  • 設計が画面ドリブンなイメージ。それから必要な機能を導いていく感じ
  • MVCという関心の分離がされ、普及したスタイルがある
  • 今、アプリケーションといえばWeb、というぐらいに主流の世界
信号処理アプリケーション
  • Webアプリケーションから見れば信号処理アプリケーションはModelにあたる。ライブラリぐらいに見てもいいかもしれない
  • 歴史が長いためアルゴリズムがたくさんある。それらを組み合わせるだけで新たな信号処理アプリケーションが作れる
  • 何ドリブンかといえば、出力信号ドリブン、つまり欲しい情報にあわせて処理を組み合わせていく設計

信号処理フレームワークに「スタイル」の考え方を適用する

utakataは今v0.1を実装していますが、このバージョンで用意されているスタイルは「一発入力・一発出力」スタイルとも言うべきもののみです。これは、信号処理にかける数列を全領域にわたってUtakataDispatcherに一気に食わせてどーこーするというものです。かける処理はDispatcherに予め信号ソースと共にリストで列挙したものを渡します。これにより、信号処理にありがちな直列的な処理を簡単に指示することができます。

まだ実装を始めていないutakata v0.2では「ストリームリスナ」という概念を導入します。信号処理は流れてくるストリームをリアルタイムで処理・出力することが一番需要がある使われ方ではないかと僕は思うからです。ストリームリスナはストリームオブジェクトを食わせることで信号処理を行いますが、逐次的に結果が出てくるので、入ってきたものを右から左へ流すというスタイルを上手く記述できるのではないかと考えています。

以上のようにutakataではスタイルというべきものを現時点で2つ実装する予定です。前者の一発スタイルではとにかく全領域にわたっての何らかのデータが欲しいという場合にわかりやすくできるのではないかと思います。スケールなどは下位のライブラリへ投げてこちら側ではそれを抽象的にラップしますので、面倒な事は考えません。デメリットは、先頭データの結果が出てくるまでに時間がかかるということでしょうか。最後のデータが欲しい場合には、同じアルゴリズムで実装した場合、時間差はあまりかからないと思います。スケール機構などのオーバーヘッドを考えたら前者の方が早いこともあると思います。

というわけでMaltsのように生産性があがる方で書いてくださいと言うよりは、欲しいデータの種類によってスタイルを使い分けてくださいという感じです。

フレームワークとライブラリの境目

フレームワークとは何でしょうか?

  • よく使うありがちな処理をセンスよくまとめてくれる
  • 何から書けばいいか分からないときに教えてくれる標識のようなもの。その標識の通りに進んでいけば効率的に開発できるよっと
  • コーディングスタイルの強制による生産性の向上

一方ライブラリとは何でしょうか?

  • 「これが入力されたらこれが出力される」を基準に探して検討するもの
  • 中の人が何やってるのかわからなくても使えるブラックボックス
  • 車輪の再発明をしないことによる生産性の向上

こうしてみると結構近いですよね。そもそもフレームワークにライブラリが内包されているものがありますし、逆も然り。ただ、フレームワークは書き方、ベストプラクティスを執拗に勧めてくることにあると僕は思います。例えばNumPyなんかのライブラリだと手続きで書こうがオブジェクトで書こうがライブラリはなーんにも咎めませんが、MVCフレームワークはモデルやビューの概念をわかっていないと当然使えませんし、その中の便利機能もベストプラクティスに最適化されています。PHPフレームワークで言うとZendFrameworkはフレームワークと名乗っておきながらかなりライブラリに近いです。MVC的な機能も持っていますが、そいつを呼ばない限りライブラリとしてZendFrameworkを使えるという、良く言えば柔軟、悪く言えば優柔不断に陥りやすいやつだと僕は思っています。

utakataはライブラリ? フレームワーク

この問いに答えるのなら、ライブラリを内包したフレームワーク、もしくはライブラリを書くためのフレームワークと言えます。極端な言い方をすれば、プログラマがする仕事の9割は「utakataで使えるライブラリ」を書くこと、が思想です。
utakataで行われる処理のほとんどはライブラリ内部で行いますが、ライブラリ自体は前後に同じ種族?のライブラリが来れば、それらを選ばずに処理するという特性があります。入れ替えても動きます。結果は異なってきますが。
何がやりたいのかといえば、ライブラリを共有することで最終的にプログラマがやるのは既存のライブラリを列挙するだけ、みたいなことにしたいんです。
そうしたらラクでしょ? 虫のいい話かもしれませんが。


ほとんどutakataの脳内構想の宣伝になってしまいましたがこんな感じです。

Jenkinsでexpressoを使う

TDD、宇宙の半分ぐらいヤバいと周りに触れ回ってはいるものの、発信源の自分は

テスト駆動開発入門

テスト駆動開発入門

これを眺めているだけで、こりゃあいかん、実際にやらねばあかんだろうと、今、node.js+expressで作っているやつにexpressoというTDDフレームワークを導入しました。
こいつ、./test以下にテストを書いたファイルを置いて、app.jsがあるところでexpressoとコマンドをうてばテストを実行してくれるんですが、噂で聞く便利なCIツール、Jenkinsでexpressoが使えないかなとか思っていたのです。

ぐだぐだ書きましたが、要は
Jenkinsでexpressoを定期/トリガ実行する
です。

以下の設定をやればJenkinsは次のことをやってくれます。

  1. gitでプロジェクトのリポジトリを取得
  2. 取得したリポジトリの中でexpressoを実行

と、これだけです。そんでもって成功したか否かはおなじみ信号機マークでJenkinsのトップページに載ります。
今は手動実行するか、もしくはJenkinsが定期的にリポジトリを取得して変更が有ればexpressoを実行してくれますが、決まったフォーマットのURLにcURLwgetなんかでアクセスすると、実行してくれるみたいです。これをgitの.git/hooks/post-commitに書いておけば、コミット時にテスト実行なんてことをやってくれますね。
参考: http://unicus.jp/skmk/archives/41

ではでは、手順。Jenkins(日本語化済み/gitプラグインインストール済み)が既にインストールされた状態で行います。
また、環境はMacでnode.jsをbrewで入れて使っているのでnvmなどを使っている方は、後述のPATHの設定を変更してください。

  1. http://localhost:8080/ (ポート等は環境に合わせて)に行って新規ジョブ作成
  2. 「フリースタイル・プロジェクトのビルド」でOK
  3. ソースコード管理システムにgitを選択
  4. 「URL of Repository」にgit initしたローカルリポジトリディレクトリへのパスを入力。file://とかはいらない
  5. ビルドトリガは「SCMを定期的にポーリング」で。ここは好みに合わせて。前述のコミット後にgitからhookするなら選択しなくて良い。
  6. ビルド手順の追加では「シェルスクリプトの実行」を選択。内容は以下な感じ。
PATH=$PATH:/usr/local/bin:/usr/local/share/npm/bin:/usr/local/sbin
NODE_PATH=/usr/local/lib/node_modules ##意味ないかも
expresso -b

expressoの-bオプションはエスケープキャラクタ無しでの表示です。

こんな感じで保存すれば動くと思います。とりあえずこれでテストの自動実行とログは取れるようになりました。
ただ、Jenkinsでのテスト結果の解析や、expressoのカバレッジの結果を使うことが出来ないので、そのあたりはプラグイン書いたり組み合わせたりしないといけないのかなあって思いました。そこまではやらないけれど。

以上、こんな感じです。

Vimでnode.jsの文法チェック(nodelint編)

落ち込んでいるといつも「げんきだして!」とリプライを送ってくれるEmacs使いなid:sugyanさんが、nodelintでflymake - すぎゃーんメモというエントリを書かれて、vimで同じようなことが出来ないかと試行錯誤してみました。
flymakeの挙動を知らないので、それっぽくなったかは分からないのですが、「保存時にシンタックスチェック」する動作は出来るようになったみたいなので報告します。

以下のリンクを見ると、quickfix + errormarker.vimで出来るようです。
errormarker.vim で flymake(Emacsの) る - #生存戦略 、それは - subtech
で、じゃあまず最近Pythonを書く機会が多いから、Pythonで出来ないかなあと思ってたどり着いたのが以下のエントリ。
vimでPythonのコードを書いているときにflymake?っぽい感じをだす | hexacosa.net
これを参考にして、入れてみました。動いたので、それをnodelintに応用します。

errormarker.vimを入れる

そういえば、quickfix使っていなかったので知らなかったのですが、quickfixはデフォルトでvimに組み込まれているんですね。
というわけで、errormarker.vimを入れます。うちのvimはpathogenを導入しているので、これ自体は簡単。pathogenについてはvimプラグインの管理をpathogen.vimにした - WebCrawler2あたりを参照。

$ cd ~/.vim/
$ git submodule add https://github.com/vim-scripts/errormarker.vim.git bundle/errormarker.vim

これだけです。

nodelintを入れる

本題のnodelintです。

$ npm install -g nodelint

とまあこんな感じでnpmで入ります。あ、他の環境ではsudoをつけないといけないかも。うちはMacbrew環境なので。
nodelintはconfig.jsみたいなファイルに設定を書いて実行時に渡すことで出力する形式を指定できます。あとでerrormarker.vimに処理されやすいように、シンプルにしておきましょう。ちなみにデフォルトは$NODE_MODULE/nodelint/config.jsにあります。これを編集して使うのもいいかもです。
こんな感じに書いて、適当なところに置いておきます。我が家は~/node_modules/nodelint/config.jsへ。
追記(11/3): npm updateするとデフォルトに戻りますので、~/develop/node/nodelint/config.jsに置き直しました。

var options = {
    vars: true,
    error_prefix: "",
    error_suffix: ": "
};

nodelint側はこれで終わり。

errormarkerの設定

~/.vim/ftplugin/javascript/内にflyquickfixmake.vimというファイルを作ります。そして以下の内容を記述。

""" $HOME/.vim/ftplugin/javascript/flyquickfixmake.vim                                                                                                                                                      
""" setting for nodelint
setlocal makeprg=/usr/local/bin/nodelint\ --config\ $HOME/node_modules/nodelint/config.js\ %
setlocal errorformat=%A%f\\,\ line\ %l\\,\ character\ %c:%m,%C%.%#,%Z%.%#

if !exists("g:javascript_flyquickfixmake")
    let g:javascript_flyquickfixmake = 1
    au BufWritePost *.js make
endif

makeprgのnodelintのパスは環境に応じて設定してください。
errorformatについてはGoogle サイトを見て試行錯誤しました。たぶんこれでいいはず。。。

これで保存時にシンタックスチェックが行われるようになります。その後:copeなんかを打つと、分割されてエラーリストが表示されて、エラーの行でEnterすると、プログラム本体を開いている方のカーソルが対象の行に飛んだりします。便利ですね。
応用すればいろいろ出来そうですね。