Niigata.pm tech talk を開催しました #niigatapm

去る 12/13 、JPAさんの支援により Songmu さんを講師にお迎えして、Niigata.pm tech talk を開催しました。

内容

発表内容は、以下のような感じでした。

hayajoさん 「Dockerを使った Perl アプリケーション開発」

タイトルの通り、Dockerを利用して Perl のアプリケーションを開発するためのノウハウについて発表していただきました。実際にテスト用の環境で業務で Docker を利用されているらしく、さらなる知見を今後も発表していただけそうですね。レンサバを提供するという業務上、FTPの利用をやめることができず、そこがボトルネックとなってDockerをなかなか本番投入できない、という話は「なるほどな〜」という感じでした。資料はこちら Dockerを使ったPerlアプリケーション開発 | ストーリーボード - STORYBOARDS

moznionさん 「空の青とパーザーの気持ち」

最近 Parser ばかり書いているという moznion さん。実際にいくつもパーサを書いたことによって得られた知見を発表してくれました。「みなさんにもいつかパーザ期ってのが来るんですよ」「拳銃は便利、一丁欲しい」「心を強く持て」などの名言がたくさん飛び出す中、机上の空論ではない「自分の体験として得られた知見」をたくさん発表してくれました。資料のアップが待たれる。

neko_gata_s 「Scala と Perl と 関数」

わたしです。Scalaの関数型としての側面を、Perlのコードを用いながら説明するという内容です。解説はほとんど口頭で行ったため、資料にはコードしか書いていないので、資料だけアップしても意味がわからんという感じになっているので、資料をアップする予定はありません。

masaru_b_clさん 「OWINについて」

.NET における PSGI であるところの OWIN についての発表をしていただきました。OWINについての説明の間、twitterのタイムラインが「これPSGIだ」「完全にPSGI」「PSGIじゃん」で埋まったのはおもしろかったです。OWIN によってIISへの依存が断ち切られたことによって、最近なにかと話題の たプラットフォームで .NET のサーバーサイドアプリケーションが実際に動くというのをデモされていて、heroku上で.NETアプリケーションが動いているのはけっこう「おお！」という感じでした。ただ、OWINは .NET5 では消えさり、MSが用意する新しい仕組みに置き換えられるとのこと（しかし概念はまったく変わらない）で、ちょっとした悲しみもありつつ、「はやくこないかな Mac 向け .NET core」という気持ちになる発表でしたね。あと async await めっちゃ便利そうだった。資料はこちらから OWINについて #niigatapm #nds39 で発表してきました #aspnetjp | be free

ritoさん 「JSON Web Tokenについて」

JSON Web Token について。名前は知ってるけど具体的にはよく知らない、くらいの存在であるJSON Web Tokenについて発表してくれました。一言で言うと二者間で署名付きのメッセージをやりとりするための仕様とのことで、シンプルな仕様であるため実装が用意であり、なおかつ構造化されたデータを署名付きで送れるので、悪意あるリクエストと正しいリクエストを比較的前段（アプリケーションサーバーとか）で弾くことができて、バックエンドへの負荷が減らせるという感じでかなり便利に使えるなこれは、という感じでした。eyJ！eyJ！ 資料はこちらから About_JWT_at_NDS_39_Niigata_pm // Speaker Deck

itosouplusさん 「Aircrack-ngによるwifiのハッキング手法とwepのアリゴリズムと脆弱性について」

WEPキーの脆弱性についてWEPの暗号化の仕組みから解説してくれる発表でした。実際にWEPキーの解析が一瞬で終わる様もデモしていました。今回が初発表とのことでだいぶ緊張されていたようですが、「WEPはなんかヤバいらしいよ」くらいの理解であるひとが多いなか、弱いIVが発見されたせいでキーの一部が簡単に割れてしまうことが納得できたし、実際にWEPを利用する怖さを実感できるとても良い発表だったように思います。資料はどこかにあるかな（教えてください）

Songmuさん 「私を育ててくれたN個のCPANモジュールたち」

トリを飾るは Songmu さん。現在第一線で Perl ハッカーとして活躍されている Songmu さんが、自分が関わってきた CPAN モジュールとともに自分がどうやってPerlハッカーになっていったのかを振り返る発表でした。静かながらも熱のこもった発表で、聴いているひとたちが「かっこいいな、自分もこうやってコミュニティに自然に貢献できるハッカーになりたいな」と思えるような感じでした。発表資料はこちら 私を育ててくれたN個のCPANモジュール達

その他の話

正直2次会以降あんまり覚えてない！けど翌日新幹線が止まってしまい東京からわざわざ来てくださった方々が帰宅困難に！という1幕があり、「あっなんかっあっスンマセンあっうっ」ってなりました。

その他レポート

わたしが見つけ次第貼っていきます。「書いたんだけど！」みたいなひとは @neko_gata_s までメンションください！ブログを書くまでがNiigata.pmですよ！

OWINについて #niigatapm #nds39 で発表してきました #aspnetjp | be free

Niigata .pm tech talk に参加してきました #niigatapm #nds39 | civic site

ドラ娘の話

なんか盛り上がってるけど、けっこう前からわたしもよくドラ娘という風潮に twitter とかで言及してたのでこのタイミングでブログで一度書いておく。

• ドラ娘という風潮は個人的には不快であるが、これはどちらかというと私個人の嗜好に基づくものなので、「私は不快である」というのは好悪の問題であり善悪の問題ではないのでそれを理由に「悪いものだ」と言うつもりはない。
• ポリティカリーコレクトかどうかで言ったら完全にアウトだとは思う
• ただ、すべてのカンファレンスが政治的な正しさを持つべきだとも思わない。
• つまり、「うちのカンファレンスはポリティカリーコレクトとかクソくらえなんで」っていうカンファレンスがあってもいいと思うし、それに対しておのおのがおのおのの思うように行動すれば良い。

というのが私の基本的なスタンスです。

追加で言っておきたいことが一点あって、「ドラ娘やってるほうだって楽しんでやってるんだから外野がどうこう言うことじゃねーだろ」みたいな意見は最悪だと思っています。カンファレンスの参加者や発表者から不快感や違和感が表明されているのに対して「外野は黙ってろ」っていうのはどうなんですかね。参加者や発表者がそのカンファレンスのあり方についてする発言を "外野の発言" とするスタンスに対しては「それは違うんじゃねーの」って強く思いますね。「ドラ娘最高！」っていう参加者も「あれはないと思う」っていう参加者もどっちも「外野」ではないよね。

TRADITIONAL MUSIC THEORY FOR CONTEMPORARY MUSICIANS を読んだ

一般に流通してない本なんだけど、下のリンクから買える。

【販売ページ】Traditional Music Theory For Contemporary Musicians | Music Theory Workshop Japan

公開されてる分は全部読んだ。

著者が自分でも言ってるんだけど、「猿でもわかる！！音楽理論」みたいなタイプのやつだと演奏や作曲に活かすことができないくらいレベルが低くて役に立たないし、かといって芸大和声みたいなやつだとそれを役立たせるまでの道のりが遠すぎる & ポピュラーミュージックに応用するまでの道のりが遠すぎるというのがあって、なかなか「演奏や作曲の役に立ちやすい音楽理論の本」ってのは今までなかった印象がある。この本はそのちょうど間を埋めるような立ち位置の本で、バンドマンやDTMerにとってはかなり参考になるのではないかと思った。

ただ、結構ストイックに進んでいくタイプの本だし、たまに「んっこれって説明あったかな」「あーちょっと戻るとたしかに書いてあるね」みたいな感じで、「まだ音楽理論のことをあまり知らない人」にとって、「これ一冊で全部わかる！」となるにはちょっと難易度結構キビシいかもしれないな〜という印象も受けた。

まとめると、もしわたしが「ポピュラーミュージック音楽理論教室」をやるとしたら、教科書にしたいな、という感じの本でした。独学するなら気合いが必要、でもまわりに訊けるひとがいるならめっちゃ良い感じにまとまってるな、というところです。

少なくともわたしのバンドメンバーや音楽仲間にはおすすめできる本なので興味があったら購入すると良いかもしれない。わたしの友人がこれ買って「ここわかんないんだけど」みたいなことがあったらわたしが教えますのでそういうひとはお気軽に相談してください。

あっあと、この本に限らないけど、音楽理論の本やるときはちゃんと音を出しながら耳と頭両方使うのがとても大事だと思う。そうしないと音と理論が結びつかないから。

NDS 38 長岡花火を支える技術 に行ってきた #nds38

新潟県長岡市で定期的に開催されている勉強会「NDS」の38回目に参加してきました。

メインセッションの感想を

長岡花火のインターネット配信がどのように行われているかという話でした。めちゃめちゃ豪華な機材でめちゃめちゃハイクオリティの映像を撮っているにも関わらず、配信の目的が「長岡に人を呼ぶ」である以上インターネットに流す映像の画質はあえて下げている、という話を聞いて、「あーこれが "ミッションステートメント" か」と思いました。プログラマとかって「手段が楽しい」ってなっちゃいがちだから、「せっかくいい画質で撮ったんだからそのまま配信したい！」っていう欲が勝っちゃいがちなんだけど、そこで「何のためにこれをやっているんだ」というところに立ち返ってその欲を捨てられるのはすごいな、と。

めちゃめちゃ手間と暇とお金をかけて配信を行っているのですが、そのすべてがノーギャラという話を聞いたときには、まず素直に長岡花火に対するその情熱と愛情に感動しましたし、その尊さ自体は賞賛されるべきものであると思います。一方で、これだけの負担を、だれかの情熱と愛情に依存したまま続けてもいいのかなぁ、という気持ちも同時に沸き上がりました。地元にとってとても意味のある活動だからこそ、「継続できる仕組み」というのが金銭を含めて構築できたほうがいいよなあというのは感じていて、そのあたりはむしろ市の課題としてあるよなあ、と感じました。

LTもしたよ

「Niigata.pmをやるぞ！！！！」というLTもしてきました。

内容としてはタイトルのまんまです！

上記を見ていただければわかるように、今回の Niigata.pm はメンバーが異常に豪華だぞ！

YAPC::Asia登壇者だらけ！CPAN Author だらけ！！！参加しないと損するぞ！

あなたとNiigata.pm、今すぐダウンロード

ActiveRecord の dup の挙動

ひとことで言うと、 ActiveRecord には dirtry な attribute を追跡するための便利なメソッド群が定義されていますが、dup とともにこれらを扱うときには要注意ですよ、というお話です。

_was とか _changed? は便利

dirty な attribute を追跡するってのはどういうことかっていうと、たとえばこういうことです。

# DBからuserをひとり引いてくる
user = User.first
user.name # => "shinpei"
user.name_was # => "shinpei"
user.name_changed? # => false

# name atribute を書き換える
user.name = "nekogata"
user.name # => "nekogata"
user.name_was # => "shinpei"
user.name_changed? # => true

# DBに保存する
user.save!
user.name # => "nekogata"
user.name_was # => "nekogata"
user.name_changed? # => false

要するに「書き変わってるんだけど、未だにDBに保存されていないattributeはどれですか、書き変わる前の値はなんですか」みたいなことを記録してくれてるんですね。オー、便利。

dup すると面白い挙動する

# DBからuserをひとり引いてくる
user = User.first
duped = user.dup

user.name # => "shinpei"
user.name_was # => "shinpei"
user.name_changed? # => false

duped.name #=>"shinpei"
deped.name_was # => ""
deuped.name_changed? # => true

おおお？という感じの挙動ですね。ちょっとバグっぽい感じもする。しかしこれは意図された挙動です。それは ActiveRecord のテストからも確認できます。

rails/dup_test.rb at master · rails/rails · GitHub

test_dup_not_persisted や test_dup_has_no_id、きわめつけに test_dup_with_changes を見てみましょう。

このあたりを読むと、ActiveRecord の dup は以下のような使われた方をすることを想定したメソッドであることが見て取れます。

# DBからユーザーを引く
user = User.first 

# (pk以外は) 同じ値を持ったユーザーをDBに保存
user.dup.save!

なるほど？ つまり、ActiveRecord の dup は、「オブジェクトのコピー」を作るメソッドではなくて、「レコードのコピー」を作るメソッドとして意図されているわけですね。

オブジェクトのコピーが欲しいなら clone を使おう

よけいなことしないでくれ！俺は単にオブジェクトのコピーが欲しいんや！というときにはどうすればいいかというと、clone メソッドを使ってあげましょう。こうすれば普通の挙動をします。

# DBからuserをひとり引いてくる
user = User.first
cloned = user.clone

user.name # => "shinpei"
user.name_was # => "shinpei"
user.name_changed? # => false

cloned.name #=>"shinpei"
cloned.name_was # => "shinpei"
cloned.name_changed? # => false

API docも読もう

dup (ActiveRecord::Core) - APIdock

clone (ActiveRecord::Core) - APIdock

Niigata.pm をやるぞ！！！！！！

「Niigata.pm って死に体なんじゃないの？」「しんぺいさん Niigata.pm やる気ないでしょ」「新潟にPMなんてあったっけ」「あいつもう Ruby と Scala しか書いてないしダメだな」「猫型さん完全にやる気ない」などの発言がそこかしこで聞かれる Niigata.pm ですが、単に子育てが忙しくて余裕なかっただけだよ！というわけで Niigata.pm やります！

NDS#39 Niigata.pm tech talk - connpass

すごい！2ヶ月先だ！！！

2ヶ月先なので、まだまだ未定なことも多いですが、なんといっても目玉は、東京ははてなから id:Songmu さんをゲストにおよびしていることです！songmuさんにしていただく発表は現在調整中ですが、続報をお待ちください。

また、songmuさん以外にも @hayajo さんと @ritou さん（ふたりともCPAN Authorですね）が発表してくれることが決まっており、なかなか豪華な内容が期待できそうですね！わたしは Scala の話をします！「エッ PerlMongers……」 って話もあるけど、YAPC のベストトーク賞がPHPの話なんだし何の問題もない！心は今でもPerlMongerやで！（実際発表内で Perl についても触れる予定です）

ところで、新潟県には NDS というプログラマのコミュニティがあって、新潟市や長岡市の開発者が中心になって勉強会などを定期的に行っています。ただ、やはり新潟県は首都圏と比べるとプログラマ人口は決して多くありません。NDS は基本的にかなり開かれたコミュニティでして、基本的に誰でもウェルカムな雰囲気なのですが、それでもやはり発表者やコアな参加者は「だいたい知り合い」になっていってしまうんですね。

それはそれで、気心の知れたプログラマ仲間と切磋琢磨していく感じで安心感もあって良いことではあるのですが、たまには「全然まだ気心知れてないよ！！！」みたいな緊張感の中で勉強会を行うのも良いではないですか！

というわけなんで、「へー新潟でそんな勉強会があるんだ、面白そうだなー」と思った新潟県内のみなさん！そして新潟県外のみなさんも！近いひとも！遠いひとも！新潟を去って行った君も！新潟に来たことないあなたも！ぜひ！Niigata.pm tech talk の動向をウォッチして、少しでも興味があれば参加ボタンをぽちっと、押してみてくれはしないでしょうか！絶対楽しいよ！

まだ内容が未定なのでいかんともしがたい……みたいな空気あるかもしれませんが、発表者のトーク内容や、別の発表者が決まったりしたらまた追ってブログや Twitter でお知らせします。check it！

あ、懇親会/忘年会の参加者も募集中です

Niigata.pm 懇親会 / Niigata Developers 忘年会2014 - connpass

こちら人数の都合あるので早めにアレしていただけるとアレです。

値の一意性を保証したいときに気をつけるべきこと

たまに以下のようなロジックで値の一意性を保証しようとしているコードを見かけます。

if ( 既に値が存在するか ) { ...(1)
    print "別の値にしてください"
} else {
    値をどっかに保存する処理 ...(2)
    print "保存しました"
}

一見うまく動きそうなんですけど、これは複数プロセスや複数スレッドが同時に実行されるような環境ではうまく動きません。

例えばwebアプリでDBに値を保存する場合などは、こういうことが考えられます。

1. ユーザーAが nyan という値を送ってきます
2. まだ DB には nyanという値が存在しないので、 (1) で else 節に入ります
3. ここでユーザーBも偶然 nyan という値を送ってきました
4. まだ DB には nyan という値が存在しないので、 (1) で else 節に入ります
5. else 節に入ったユーザーAのリクエストは(2)の行を処理し、正常に終了します。
6. else 節に入ったユーザーBのリクエストは(2)の行を処理しようとします。

このとき、DBにuniq制約が貼ってあればユーザーBには想定していないエラーを返すことになりますし、uniq制約が貼っていない場合、重複してはいけないはずのデータなのに重複を許してしまうという最悪の事態になります。

こうならないように、値の一意性を確保したい場合は、より低く確実な層でチェックするべきでしょう。今回の場合なら、DBにuniq制約を貼った上で以下のようなロジックにするべきです。

try {
    値をどっかに保存する処理
    print "保存しました" 
} catch (ユニーク制約に引っかかったよ例外) {
    print "別の値にしてください"
}

// あるいは

error = 値をどっかに保存する処理
if (error_code == NULL) {
    print "保存しました" 
} elseif (error_code == ユニーク制約に引っかかったよエラー) {
    print "別の値にしてください"
} else {
    print "予期しないエラー"
}

DBへの保存の他にも、例えば「もし存在してないなら、新しくディレクトリを作る」みたいなやつに関しても気をつけなければいけません。これも、「先にチェックして、無かったら作る」みたいにしちゃうと同じようなパターンで予期しないエラーを引き起こす可能性があります。それを防ぐためには、

1. まずmkdir してしまって
2. エラーが出なければ新規作成されたので正常系
3. EEXIST 以外のエラーならば予期していないエラー
4. EEXIST なエラーである場合
   1. path がディレクトリであれば作成済みであったので正常系
   2. path がディレクトリでなければ、「同名のファイルがあるよ」というエラー

といった形にしなければなりません。

要するに、重複が許されないようなものに関しては、自分でアプリケーションのレイヤーでそのチェックを組むと並行性に問題が出てくるので、アプリケーションのレイヤーより下に任せた上で、その結果をアプリケーション側でハンドルしてあげるようにしましょうね、という話でした。

もちろんどこまで真面目にやるべきかは案件によるとしか言えないし、多くの場合、データの整合性が守られてるならそれで問題なしとしていいことのほうが多いとは思う。でもこういうの知っておかないと困ることもあるので一応知っておいたうえで「そこまで真面目にやる必要なし」という判断ができるようになっていたほうがよいだろうという話。

以下余談。

Rails の ActiveRecord の uniqueness validation が、まさに上のような問題を持っている。これはまあいろんなDBに対応しないといけない以上しょうがない部分があるし、どちらにせよDBにuniq制約貼っておけばデータの整合性が破壊されることはないので、そこまで大きな問題ではないんだけど、上記のようなパターンで ActiveRecord::RecordNotUnique 吐かれた場合に真面目にユーザーに「別の値使ってください」って通知しようとするときにはどうするべきなんだろうなぁというのを迷っている。ActiveRecord::RecordNotUnique 例外を catch して record.errors に add するようなやつを ActiveRecord::Validations::UniquenessValidator に prepend しちゃう？それはちょっと暴力的すぎるなぁ、などなど悩みは尽きない。だいたい毎回「レアケースだし、データが守られてればそこまで真面目にやらんでええやろ」に落ち着く気がする。