書評: はじめての深層学習プログラミング 著者:清水亮
発売前だったのですが、ジュンク堂書店池袋本店にふらっといったところ平積み(しかもラスト2冊だった)ので確保しました。DeepLearningなどの本はいろいろ読んだけど、非常実践的!とおもったのですよ。これは実践で使って、商品開発している清水さんならではないでしょうか。
内容について
深層学習には必要なUbuntuにおけるCUDAの設定から、Chainer / TenserFlowのインストールにあわせて、できるだけ数学用語の少ない形での説明でPythonプログラミングのサンプルコード主体に記述されています。
過去にいろいろな機械学習の本が出ていますが、Chainer / TenserFlowの使い分けについては自分で試してみる以外なく、そゆ意味では非常に実践的な本です。オライリーや、他から出ている本は、何故Sigmoid関数を導入しなきゃいけないのか書いてあるところまで辿りつくだけで決行なページが割かれているのですが、本書では「こうやるとダメでしょ?だからSigmoid関数つかうんですよ!」と書いてあり、その後に「Sigmoid関数でもダメな学習もあるでしょ!」と使い方に徹してします。助かります。
ただ、機械学習の基本的な知識なしでもできるようにした半面、体系的な知識が欲しい人向けには、オライリーなどから出ている本で基礎知識を確認してから読むと「ははーん、なるほど。Chainerではこうやるのか。」と分断された知識が1つになります。
200Pに満たない本にもかかわらず、Chainer/ TenserFlowの使い方、Deep Q Learningさらに蒸留などといったトピックもサンプルコード付でのっているのがこの本の一番のいいところです。
まだDeelや、CSLAIERといったツールも、普通の技術書では「使えない知識」になってしまいがちなのも、「TenserFlowのここが大変なので作った」という明確な理由をもとに書かれているので、肯定的に使うことができます。(偉そうですみません)
個人的な感想
ときおり本文に出てくるnVidiaのCUDAドライバーとUbuntuとの相性の悪さについて頭をかかえている清水さんの顔が頭に浮かびます。私もちょっとはまったけどUbuntuとか、Kernel Driverでコンパイルとか慣れしてたのでむしろ楽しかったようなきがしますよ。
というわけで売れ切れが予想されるので予約でぽちがおすすめですよ。
Rails3.1.0 + rails_adminでassets:precompileをすると失敗する
先日の某クラウドの大崩落があって急遽ECにサーバーをうつしたのですが、assets:precompile中にどうやってもエラーを吐いてとまってしまいます
$ rake assets:precompile (略) rake aborted! stack level too deep (in /Users/xxxxx/.rvm/gems/ruby-1.9.2-p290/bundler/gems/rails_admin-1e2984414293/app/assets/stylesheets/rails_admin/imports.css.scss.erb)
--traceしても-vしてもなにもでないので、原因を追ってたんだけど不明(´Д`;)
Railsを3.1系のstableにすると、今度はhamlとjpmobile周りでエラーをだすという踏んだりけったり状態。
結局saas-railsが3.1.6だとアウトだというところにたどり着くのにまるまる1日かかりました(´Д`;)
Gemfileの該当箇所をバージョン固定にしてとりあえず回避できました。
gem 'sass-rails', "3.1.5"
(´Д`;)
で、興味本位で原因を追ってみると
-------------------- lib/sass/rails/template_handlers.rb --------------------- index 1b3b31e..2350476 100644 @@ -19,7 +19,7 @@ module Sass::Rails nil end - def public_path(path, scope) + def public_path(path, scope = nil) context.asset_paths.compute_public_path(path, ::Rails.application.config.assets.prefix) end @@ -72,14 +72,17 @@ module Sass::Rails options = sass_options_from_rails(scope) load_paths = (options[:load_paths] || []).dup load_paths.unshift(importer) + resolver = Resolver.new(scope) + css_filename = File.join(::Rails.public_path, resolver.public_path(scope.logical_path)) + ".css" options.merge( :filename => eval_file, + :css_filename => css_filename, :line => line, :syntax => syntax, :importer => importer, :load_paths => load_paths, :custom => { - :resolver => Resolver.new(scope) + :resolver => resolver } ) end
これが原因か……
LRAの基準
「LRAの基準」というのが憲法学のお話であります。これは人権規制立法の審査において違憲判断に使われる基準の一つです。
LRAはLess Restrictive Alternative(より制限的でない他の選びうる手段の基準)の略です。端的にいえば「他に取り得る手段がないときにこれは本当は違憲だけど合憲とする」ということです。
別に憲法学の話をしたいわけでもなく、話をしたいのは最近のスタートアップにおけるプロダクトの話です。私が前職にいた2年ぐらい前からエンジニア主導のプロダクトを作らせる風潮が非常に強く、「独立しない/自分のプロダクトをもっていないエンジニアは馬鹿」みたいな空気が流れていました。
で、いろいろiPhoneアプリとか似たようなサービスが出てきては捨てられ、出てきては捨てられということが起きています。これはなんで起きてるのかなということを考えていたときにふと"LRA"の話が頭に出てきました。世の中のサービスは大体において他のサービスに置き換えが可能で、より便利になるつれて他のサービスにユーザーは移動してしまう、ということです。他に選びうる手段があるときに、人は新しく、個々人のスポットにはまるサービスに移動してくのだろう、という感じです。
なので、スタートアップはプロダクトをつくるときにどんどんターゲットは狭小化していき、ついにはごく少数の人間にとって"LRA"なプロダクトになってしまうわけです。するとマスをとれるプロダクトは皆無になり世の中はマイナープロダクトだらけになる……ような世界になっていくのかな……という過激な考えが頭をよぎります。
これを避けるためには、大量の工数を掛けて、マイナーな人々をすべて拾うようにすればいいと思いがちですが、それは現実的には不可能です。ではどうすればいいか。それは自分のプロダクトに個々人にスタイルをあわせてもらい、自分のプロダクトが"LRA"なプロダクトに「感じて」もらうようにすることでしょう。これをするために人々を気持ちよくある意味「調教する」ことが必要です。
調教についてはまた別なときに話すとしても、ターゲットはマイナーではなくてメジャーであるべきということを頭においてプロダクトをつくって欲しいなとおもう今日このごろでした。