アニメ顔検出するのおもろい
[twitter:@butchi_y]さんからImager::AnimeFace(Imager::AnimeFaceのページ)っていうのがあって、そいつを入れることができないっていうのが飛んできて、実際に自分も入れてみていろいろ遊んでみた。
結局ぶっちさんが入れようとしていたRackhubには入らなかったんだけれど……。
Imager::AnimeFaceとは
上のリンクにいろいろ書いてあるんですけれど、一言で言えばアニメの中の顔認識をやるみたいです。
複数の顔を認識することも可能で、detect_animefaceっていう関数にImagerオブジェクトを食わせるだけで顔の各パーツの位置だとか構成している色なんかも返ってきてわかりやすいです。
2009年リリースみたいで今はメンテされてないみたいです。リリース直後あたりにいろんな人がレビューしているので使い方はそれを見ればいいと思います。
というかDDPでpしたらそれだけで分かると思います。
難点としては高解像度の画像を食わせると重たいとか。サービスに使うならジョブキューで待たせたりすることになりそうです。
git status、君をいつまでも忘れない……
実は4月から新卒プログラマとして毎日プログラム書いているマコピーです。
今まではそんなにプログラムプログラムしていていなかったので、どうなることかと思いましたが、なんとかなっています。
で、最近多いミスがあります。
git addし忘れるってやつです。
この前の金曜日にそれやらかして、飲んでいるときにJenkins死んでいるぞという電話がかかってきて、
「git addし忘れるとか論外だよねー」と罵られながら(一部脚色しています)、
その場でgit addしてpushし、なんとかJenkinsさんのお怒りを鎮めることができました。
まあgit statusし忘れてなければ、コミットに含めていないファイルが分かるわけで、
今回はそれを怠ったがゆえの失敗です。
git statusを忘れないためにも対策してみます。
gitに色をつけよう
「git status忘れるんだけれどどうすればいい?」と聞くとみんな決まって
「ハァ? 忘れないでしょ」というように軽蔑の目。
この時点で泣きそうなんですけれど、出会うたびにニヤニヤしながら僕をdisってくる
[twitter:@_ishkawa]くんがこの時ばかりは助け舟。
「え、色つけてないの? マコピー情弱だね」
「あ、はい。。。」
というわけでくれたのがこれ。
早速適応してみると、こんな感じ
やべぇ、まるわかり! しかも設定意外と簡単なんですね。これで僕も玉虫色の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はワーキングツリーの状態を見て判断するわけで、
そのときにユーザが介入できるわけではないらしい。
Kamakura.pm #002 with BEAR!
2012/02/24 Fri
20:00 開始
1. Perlハジメマシタ @massat
- Perlをはじめるにあたって、ご近所さんがかまってくれるのでは → kamakura.pm
- 村式株式会社
- もっとプログラマ欲しい いいこと期待
- 自社と受託
- iichi(いいち)| ハンドメイド・クラフト・手仕事品の通販
- iichi をPerlに移植したい
- ふくすけ
- 拡散歓迎 写真もOK!
以上宣伝
- Perl歴1ヶ月からの「Perlハジメマシタ」
- 前会社からJavaの経験はあり。村式からPHP
- PerlBigeners #1
- (僕もそっちだったかも。。。。)
- 村式はPHPを6年メインに
- PHP dis?
- なぜPerl?
- Bootstrap
- よくなったこと
- 配列とリファレンスでハマる
- bless が好きになる
- かわいい、かっこいい
- ふぅーってやってオブジェクト完成
- 気になること
- try-catchない
- public/privateない
- リストとかハッシュとかの使い分け
- 環境どうする?
- Perlを1ヶ月をすると
- わくわく
- いけてる感じ
- でもまだハマる
- try-catchみたいなことをしようとするとevalやらしないといけない
- でも書き続ける
2. CPANモジュールを作る人を増やす @songmu
3. typester的Perlの勉強の仕方 @typester
- まとめ
- 本からスタートはしない
- いきなり何かを書く
- 他人のコードリーディング
- 本からスタートしない理由
- 本で覚えるとつまらない
- 眠くなる。最後まで読みきれない
- 一切読まないわけではない
- 本は情報が古い場合が多い。それに左右されないでスタートできる
- 本の綺麗な書き方だけでは普通じゃないコードは読めなくなる
- 作りたいもの駆動
- 新しい言語でやってみる?
- 言語の得意分野もある
- PerlきっかけはBlogブーム。MTをいれる
- blosxom
- すごく小さい
- plugin拡張。PerlHackersっぽい思想
- shibuya.pm.orgはblosxom
- コードの難易度たかし hackishで楽しい部分を
- Catalyst DBIx::Class
- Plagger
- miyagawaさんのコード綺麗
- 美しくシンプルなコードの書き方を学ぶ
- 他の言語
- C
- Objective-C
- CにPerlみたいな皮をかぶせた言語
- Apple公式ドキュメントで学ぶ
- Mooseで書いて、Objective-Cに移植
- コツ
- わかんないことはほっとかないこと
- 解釈は厳密
- 他人のコードリーディング大事!
- Audryのコードはいみわかんなすぎだけれど天才
- こんなに読んでいるのに未だに知らないことが出てくるPerlはほんとうに面白いですね!
- オススメのPerlコード
- AnyEventはおもしろい
- Perlを初めて一ヶ月だと?
- Plaggerを読む
- 実際に使えて試せるのが面白いよね
- Plaggerを読む
4. 某SNSでfluentdとMongoDBを入れた話 @sfujiwara
- 某SNSで取っているログ
- 行動ログ
- ユーザのアクション
- ユーザのアクティビティの調査等に利用
- 問い合わせ対応に重要
- 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のバージョンアップ
- MongoDBはまだ枯れていない
- データベース単位でロックされる
- 普通のデータベースとしてもログ取り用途にも
- capped collection 容量制限を設定してログをとれる
- (エンドレスカセットテープみたいなもんですね)
- fluentdのパフォーマンス
- 実用十分ぐらい出る
- 普通に使う分にはRubyなしでもfluentd使える
Kamakura.pmに行って来ました。
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、宇宙の半分ぐらいヤバいと周りに触れ回ってはいるものの、発信源の自分は
- 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2003/09
- メディア: 単行本
- 購入: 45人 クリック: 1,058回
- この商品を含むブログ (162件) を見る
こいつ、./test以下にテストを書いたファイルを置いて、app.jsがあるところでexpressoとコマンドをうてばテストを実行してくれるんですが、噂で聞く便利なCIツール、Jenkinsでexpressoが使えないかなとか思っていたのです。
ぐだぐだ書きましたが、要は
Jenkinsでexpressoを定期/トリガ実行する
です。
以下の設定をやればJenkinsは次のことをやってくれます。
と、これだけです。そんでもって成功したか否かはおなじみ信号機マークでJenkinsのトップページに載ります。
今は手動実行するか、もしくはJenkinsが定期的にリポジトリを取得して変更が有ればexpressoを実行してくれますが、決まったフォーマットのURLにcURLかwgetなんかでアクセスすると、実行してくれるみたいです。これをgitの.git/hooks/post-commitに書いておけば、コミット時にテスト実行なんてことをやってくれますね。
参考: http://unicus.jp/skmk/archives/41
ではでは、手順。Jenkins(日本語化済み/gitプラグインインストール済み)が既にインストールされた状態で行います。
また、環境はMacでnode.jsをbrewで入れて使っているのでnvmなどを使っている方は、後述のPATHの設定を変更してください。
- http://localhost:8080/ (ポート等は環境に合わせて)に行って新規ジョブ作成
- 「フリースタイル・プロジェクトのビルド」でOK
- ソースコード管理システムにgitを選択
- 「URL of Repository」にgit initしたローカルリポジトリのディレクトリへのパスを入力。file://とかはいらない
- ビルドトリガは「SCMを定期的にポーリング」で。ここは好みに合わせて。前述のコミット後にgitからhookするなら選択しなくて良い。
- ビルド手順の追加では「シェルスクリプトの実行」を選択。内容は以下な感じ。
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をつけないといけないかも。うちはMacのbrew環境なので。
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すると、プログラム本体を開いている方のカーソルが対象の行に飛んだりします。便利ですね。
応用すればいろいろ出来そうですね。