読者です 読者をやめる 読者になる 読者になる

下町柚子黄昏記

したまち発・ゆずたそ作・個人開発の瓦礫の記録

ニコニコ学会データ研究会に参加しました&モザイク画生成スクリプトを作りました

参加しました ニコニコ 数学 作りました

ニコニコ学会データ研究会というイベントに招待いただき、セッション3「数学」で発表を行いました。

f:id:yuzutas0:20160330215626j:plain

どんなイベントか

Peatixのイベント紹介ページによると

データ研究会は「データ分析を始めたい人」「データ分析を仕事にしている人」「面白い発表が好きな人」などなど、誰でも参加できる気軽な研究会です。 ...... (中略) ...... データで面白ければ節操のない研究会です。最近は夏コミで薄い本「ニコ知能」も上梓し、データおもしろがり分野のエッジをひた走っています。

とのことです。

他の参加者のブログ・スライド

多種多様な方々が登壇して、普段なかなか接する機会のない魅力的な話を聴けました。

参加のいきさつ

  • 昨夏にはニコニコ学会、昨秋には日曜数学会(=趣味で数学をする人たちの集まり)、それぞれのイベントに参加しました。そこでのご縁からお声掛けいただきました。
  • 100人以上のデータサイエンティストの前で立派な話をする自信はありませんでしたが、せっかくなので恥をかいて勉強しよう!という気概で参加しました。

yuzutas0.hatenablog.com

yuzutas0.hatenablog.com

どんな話をしてきたか

こちらが当日の発表資料になります。

苦労話

当日は時間の都合で省略しましたが、実装上の苦労について、この場で振り返りたいと思います。

画像サイズ

特に1番苦労したのは画像のサイズです。 最終的に完成したモザイク画は160MBにもなってしまいました。

サイズが大きくなった理由

  • 今回使った対象画像(target_image)のサイズは 200 pixel x 200 pixel です。
    • いくつかサイズを試してみて、これが荒すぎないギリギリでした。
    • これより小さいと最終出力がただのモザイクになってしまいます。
  • 同様に、要素画像群(element_images)は 100 pixel x 100 pixel です。
    • モザイク画を拡大したときに1つ1つの画像が潰れないギリギリでした。
    • 個々の画像が判別できないと、プレゼンの魅力が半減します。
  • 上記を組み合わせると 20,000 pixel x 20,000 pixel となります。
    • ラップトップで1人で楽しむなら縮小余地があるのですが、大画面での発表を想定するとこれが最小サイズとなりました。
    • まぁ結局スライドに収まらなくて 1/3 に縮小したんですけどね!!!最初から 1/3 スケールで処理すれば良かったよ!!!

サイズが大きくなったことによる影響

  • ソースコード上にjpgとpngが混在している
    • 最初はjpg拡張子のみを使うつもりでした
    • 160MBになるとjpg拡張子の限界を超えるのですね
    • 結果として割れ窓理論でコードベースの汚さが加速しました
  • モザイク画を自慢したいのにSNSにアップできない
    • 泣く泣く小サイズ版をTwitterにアップしました!が!拡大しても潰れています!
    • png拡張子の画像ファイルはzipにしても圧縮効果がないのですね
  • とにかく処理が大変
    • 目視しながらトリミングしようと思ってもFireworksが落ちます
    • メモリの読み込みや解放を工夫しないとRubyが落ちます

Ruby

スクリプト開発で利用したライブラリについて。

RMagick (Problem)

画像処理に利用した RMagick のリファレンスが分かりにくかったです。

  • 後で Ruby Style Guide(和訳)を読んで知ったのですが、今は RMagick は非推奨で、代わりに MiniMagick を使った方が良いそうです。そういえば、Rails Tutorial(和訳) にも同じことが書いてあったような。
  • どのライブラリがデファクトスタンダードなのか把握しておけば、もっと効率的に開発できるのだと反省しました。
  • ちなみに、 OpenCV であれば Python が公式でサポートされている、とのことでした。機械学習や画像処理は Python に任せた方が良いのかな。

Rubocop (Keep)

コーディング規約を Rubocop で遵守しました。規約違反を指摘するだけでなく、ある程度は自動でフォーマッターを掛けてくれます。最高。

  • 過去に作ったWebサービスを手直しできていない理由の1つに、コードの保守性が低い、というのがありました(エンタープライズな大規模アプリケーションの技術的負債に比べれば可愛いものですが)。
  • ついつい甘えがちな個人開発において、規約を確実に遵守するには、自動化するしかありません。ということで Rubocop を導入して、 .rubocop_todo.yml に反映される指摘事項が常にゼロとなるように心掛けました。
  • チーム開発でも同じで、静的解析で十分なはずの指摘に、わざわざ人間が時間を費やすのは勿体ないように思います。その分を他のことに費やした方が生産性が高まるのではないかと。
  • まぁ、結局汚くなっちゃったんですけどね!!!

質疑応答

長丁場で集中力を欠いていたこともあり、かなり雑な回答ばかりしてしまいました。 非常に申し訳なかったなぁと反省しています。

終了後に感想・質問を書いた付箋を何枚かいただいたので、リベンジも兼ねて回答します。

画像は何枚くらい取得して使用しているのですか?

  • 実際に使った element_images は 1,712枚 となります。
  • 同じ画像を何回か使いまわして 40,000枚 の画像群でモザイク画を構成しています。

最も多く使われた画像はどれですか?

  • 著作権アウトなので掲載できませんが、平均色が白となる画像です。
  • 数式の画像だと全体的に白の出現頻度が多くなりますね。

画像1枚当たりが担う領域を大きくしていくとモザイクが崩れてしまわないですか?

  • 考えなしにやると崩れるので、最初にサイズを計測しました。
  • 詳しくは前述「サイズが大きくなった理由」をご参照ください。

ベクトル比較の仕方を教えていただけますか?

  • 説明を省略した部分なので、理論面は上記スライドを見ていただければ良いかと。
  • 機械学習の分類問題として扱うことができるかと思います。初学者ならCourseraがオススメです。

yuzutas0.hatenablog.com

なお、スクリプトの実際の処理は以下の通りです。閾値を決めて簡単化しています。

  • 明度 0, 1, 2, ..., 253, 254, 255 をちょうど8分割するように閾値を設けて 0 から 7 までのグループを定義する。
  • target_image の各Pixelの色が、どのグループに所属するか判定する。
  • element_images の各画像の平均色が、どのグループに所属するか判定する。
  • 同じグループであれば十分に近いものとして扱い、適当に組み合わせる。

感想

  • 至らない点が多かったですが、学びや気付きも多かったかなと思います。
  • 他の方々の発表は、各分野のプロダクトやコンテンツならではのデータ研究が多く、「これまで知らなかったことを知る」「試行錯誤して知にアクセスする」といったサイエンスの魅力を再確認できました。
  • 今回は数学枠でしたが、機会があれば別トピックでも話してみたいです。

おわりに

改めて、運営者・登壇者・参加者の皆様、素敵な時間をご提供いただき、ありがとうございました。

Courseraの機械学習コースを修了しました

修了しました 機械学習 Octave

概要

Courseraというオンライン学習サイトで公開されているMachineLearningコースを修了しました。

f:id:yuzutas0:20160319161104p:plain

もくじ

  • どんな講座か
  • 講座のアジェンダ
  • なぜ受講したか
  • 受講した感想
  • あると望ましい事前知識
  • はまりどころ
  • 最後に

どんな講座か

  • 機械学習の主要なアルゴリズムを直感的に理解して、実際にプログラミングできるように教えてくれます。また、実装前にどのアルゴリズムを使うべきかの判断、テストとチューニングの方法、大量データの並列処理といった付帯トピックも言及されます。
  • 講師はStanford UniversityのAndrew Ng(呉恩達)氏で、Googleの人工ニューロン研究プロジェクト発起人や百度首席科学者として知られています。実際にこんな風にやっていますよ!という話を交えるので、画一的で教科書的な解説よりも聴きやすいと感じました。
  • ボリュームは結構重いです。「講義および4択試験(2時間)」+「実践課題(3時間)」×「11週間」となります。

講座のアジェンダ

実際の内容は以下となっています。

なぜ受講したか

機械学習の仕組みを正しく理解する必要性を感じたからです。

学生時代に分析手法の1つとして機械学習アルゴリズムを使ったこともありましたが、直接の専門分野ではなかったので、改めて学びたいと考えました。

企画観点

  • 某所にて、機械学習の各手法の特性を無視した施策を打って、ROIを大きく下げた事例を見聞きしました。
  • バズワードに流されて誤った企画判断をしないように、仕組みと特性を把握する必要性を感じました。

開発観点

  • レコメンド機能を開発する機会があり、機械学習ツールやライブラリを使うことで、簡単に機能を導入できました。
  • しかし、さらなる機能改善・性能向上に当たり、本質を理解せずにお手軽ツールを使うことにすぐさま限界を感じました。
  • ほとんどのソフトウェアは作って終わりではないので、パラメータやロジックを継続改善できるように(そもそも継続改善することが妥当なのか判断できるように)仕組みを理解する必要性を感じました。

受講した感想

ビジュアルや動きで直感的に理解しやすい

  • 書籍だと図と文章説明と数式とサンプルコードを1つ1つ見比べながら脳内補完しなければいけないので、初学者には辛いものがあります。動画だと、その過程を講師が順を追ってビジュアルや動きで再現してくれます。
  • オフラインの講義でも直感的な理解を促してくれる優良講師はいるかもしれません。ただ、動画だとスケジュールを気にしなくて良かったり、一時停止ボタンを押すことで、安心して一歩立ち止まって考えることができます。

そのまま実務には使えないかも

内容面

  • Random Forestなど、よく使われるのに講義で解説されないアルゴリズムがあるので、網羅性の高い書籍で概要把握に当たるのが良さそうです。私は書店で何冊か読み比べて『データサイエンティスト養成読本 - 機械学習 入門編』を買いました。
  • せっかく素敵な内容なのですが、いかんせん動画なので見返すには辛いものがあります。途中途中でノートを取るか、チートシートをまとめれば良かったなぁと反省しています。

実装面

  • Octaveで試してうまくいったらPythonなどの言語を使うべし」と解説されるものの、最初から最後までPython一択だと思います。特に分析過程を記録できるIPython Notebookの存在は大きいかなと。
  • 実際にPythonのライブラリ群(Numpy, Scipy, scikit-learn)や、IaaS/PaaSが提供する機械学習サービスを活用するには、各チュートリアルに進むことになるかと思います。もしくはPythonでこの講座の課題を実装するのもいいかもしれません。

分量が多いのでかなり大変

  • 心が折れない方法 / 折れてもすぐに復帰できる方法を自分なりに確立する必要があります。
  • 複数人で勉強会形式で進めると挫折しにくい、という案がCROSS 2016 のセッションで挙がっていました。
  • 辛い分だけ、最終動画の講師の言葉に感動します。

あると望ましい事前知識

前提として以下のスキルがあるとスムーズに進むと思います。

線形代数 / 微分積分

yuzutas0.hatenablog.com

学術的な英文の読解

  • 各レッスンの演習課題は15ページほどの英文PDFで与えられます。読めないと課題に着手できません。
  • 普段から英文でドキュメントを読み書きしているソフトウェアエンジニアなら問題ないかと思います。
  • 自信がない場合は、大学受験英語TOEFL対策を試すのも良さそうです。「TOEFL学習法まとめ」が参考になるかと。

ソフトウェアエンジニアリング / コンピュータサイエンス

  • ソースコードの読み書きができないとOctaveでの演習課題に着手できません。
  • また、分野の特性上、メモリ管理などの比較的低レイヤーな話題も出ます。初歩的なCSの知識は必須かと思われます。
  • 講師の発言を聞く感じだと、そもそも受講対象としてソフトウェアエンジニアを想定しているようです。

yuzutas0.hatenablog.com

はまりどころ

実際にやってみてはまったところや困ったところのメモを公開します。 なお、利用環境は以下の通りです。

  • 利用OS:MacOSX
  • パッケージ管理:Homebrew(およびcask)
  • エディタ:SublimeText
  • ブラウザ:Firefox

Web試験の画面が表示されない

  • Firefoxだと問題・回答の画面が表示されず真っ白になることがあります。
  • Google Chromeでは問題なく進められたので、なるべくブラウザはChromeを使いましょう。

Objective-C の Syntax Highlight になる

MATLAB / Octaveのファイルは拡張子.m なので、デフォルトだとObjective-Cとして認識されてしまいます。

Sublime Text 3 で 拡張子と Syntax Highlight を紐づける方法は以下の通りです。

  1. 関連付けしたいファイルを開く
  2. View=>Syntax=>Open all with current extension as…=>[適用したい Syntax Highlight]を選択

これで .m ファイルが MATLABOctave)のソースコードとしてハイライトされます。

ex1.m の実行時エラー

gnuplot> set terminal aqua enhanced title "Figure 1"  font "*,6" dashlength 1
                      ^
         line 0: unknown or ambiguous terminal type; type just 'set terminal' for a list
  • gnuplotが利用している描画用のターミナル(Aqua/X11)が存在しないために実行時エラーが発生しています。
  • 暫定対応はいくつか考えられますが、Courseraで用意されているDLリンクではなく、HomebrewからきちんとOctaveをインストールしましょう。依存関係が明確になります。
# uninstall
$ brew uninstall gnuplot

# update
$ brew update

# install
$ brew cask install aquaterm
$ brew cask install xquartz
$ brew tap homebrew/science
$ brew install gnuplot --with-aquaterm --with-x11
$ gnuplot # => "terminal set to aqua"
$ brew install octave

# test
$ octave
$ octave:1> w = 10 + sqrt(10)*(randn(1,10000));
$ octave:2> hist(w)

submit.m の実行時エラー

!! Submission failed: unexpected error: urlread: HTTP response code said error
  • HomebrewにてOctaveの最新版(4系)を正規インストールした場合に発生します。
  • 課題スクリプトが想定しているバージョンは 3系 なので、submitコマンドの処理が失敗してエラーとなります。
  • 公式のQ&Aに修正箇所と内容が掲示されているので、その通りに修正します。
    • 対象ファイルは lib/loadjson.mlib/jsonlab/makeValidFieldName.m です。

修正前

str=[str str0(pos0(i)+1:pos(i)-1) sprintf('_0x%X_',str0(pos(i)))];

...(中略)...

str=sprintf('x0x%X_%s',char(str(1)),str(2:end));

修正後

str=[str str0(pos0(i)+1:pos(i)-1) sprintf('_0x%X_',toascii(str0(pos(i))))];

...(中略)...

str=sprintf('x0x%X_%s',toascii(str(1)),str(2:end));

参考 https://learner.coursera.help/hc/en-us/community/posts/204693179-linear-regression-submit-error

Week5 動画の翻訳

講師が話している内容と、翻訳が表示されるタイミングが大幅に乖離しています。 弊害と対応策を整理したのが以下の表です。

弊害 対応策
翻訳「数式のここを見てください」 / 画面「数式はすでに消えている」 巻き戻して内容と画面を照合する
日本語翻訳がまだ途中なのに動画が終わってしまう 諦める or 英語できちんと聞く
読むのに30秒はかかる翻訳が2-3秒で切り替わってしまう 一時停止してじっくり読む

ex6.m の実行時エラー

set: unknown hggroup property Color
  • グラフの可視化を行う際に色の指定に関するエラーが出ました。
  • visualizeBoundary.m を以下のように書き換えます。

修正前

contour(X1, X2, vals, [0 0], 'Color', 'b');

修正後

contour(X1, X2, vals, [0 0], 'linecolor', 'blue');

参考 http://blog.livedoor.jp/kmiwa_project/archives/1034089224.html

演習の内容面でつまづいたとき

以下のようなつまづきケースがあるかと思います。

  • 理解度:課題の要求は分かるが、回答に到達できない
  • 語学力:そもそも課題が何を求めているか要領を得ない
  • 精神力:単純に分量の問題で心が折れる

対処法(理解度のケース)

  • 思考の整理:紙やホワイトボードに書き出す
  • 知識の補充:動画を見返す、公式Wikiを参照する
  • 人に聞く:相談部屋を参照する

対処法(語学力/精神力のケース)

何を聞いたらいいか分からない、うまく質問を整理できない、などなど課題を理解できていない場合。あるいは聞く気概さえ喪失している場合。

あまり褒められた方法ではありませんが、Github上に演習課題を解いた人たちのソースコードが公開されているので、それらを参考にするという手があります。 実際にソースコードを読めば「あぁ、そういうことね」とすんなり理解できることは多いかと思われます。

ただ、これは規約違反のようなので、修了証明を取得するような場合には控えるべきでしょう。 本当に悩んで悩み抜いてきちんと理解できた人だけが修了者として認定されるほうが、サイトの趣旨に照らし合わせると健全と言えます。

とはいえ、あくまでも個人の余暇学習において効率的に学ぶという意味では、上記のような方法も有効です。かなりの分量があり、なかなか体力的にも精神的にも時間的にも苦しい中で、ちょっとズルをしてでも最後までやり抜くのが大事かと。せっかく関心を持ったのに、挫折して気力を削がれてしまうのが1番もったいないです。

最後に

何度も言いますが、ボリュームが大きいので辛かったです。その分だけ達成感と満足感も大きいです。 この講座を足掛かりにして、より高度な内容に踏み出して&実践に活かしていきたいと思います。 何はともあれ、「2015 December 28 – 2016 March 21」で同時期に受講した皆様、お疲れさまでした。

日曜数学会に参加しました&「プログラミングのための線形代数」を読みました

参加しました 読みました 数学

先日、日曜数学会というイベントに招待いただき、LTをしてきました。趣味で数学をやっているひと(=日曜数学者)が集まって、お酒を飲みながら研究を共有する会です。

f:id:yuzutas0:20150831233551p:plain

他の参加者のスライド

どんな話をしてきたか

f:id:yuzutas0:20150831235357p:plain

再学習の経緯

  • WEBサービスを作っているとレコメンドやラベル分類といった機械学習をやりたくなります。
  • ちょっとした実装ならライブラリとサンプルコードに乗っかれば簡単にできます。
  • しかし、がっつりカスタマイズしようとすると、線形代数を復習しておかないと苦しい場面が出てきます。
  • 線形代数とは言っても、計算問題の解法や証明の再現だけではダメで、概念を理解しておかないと応用が利きません。
  • せっかくの発表の場を得られたこともあり、上記を念頭に置いて線形代数を勉強し直しました。

再学習の内容・感想

  • 実際には『プログラミングのための線形代数』という書籍を通読しました。
  • 読んでみて「空間上のある値を別の見方に移す」のが行列であり、「線形空間における代数の作法」が線形代数と呼ばれる分野なのだと、自分なりに理解しました。
  • この理解は間違っているかもしれませんが、単なる数字の羅列・無味乾燥な手続き処理だったものに意味が与えられたということが、自分にとっては大きな一歩でした。
  • 読み進めるうちに「学生時代にやったあの計算や証明はこういう意味だったのか!」という納得感と感動を覚えることが何回かありました。

書籍の内容

目次は次の通り。基礎学習はほぼ網羅していると言っていいのではないでしょうか。

  • 1章:ベクトル・行列・行列式 - 「空間」で発想しよう
  • 2章:ランク・逆行列・一次方程式 - 結果から原因を求める
  • 3章:コンピュータでの計算(1) - LU分解で行こう
  • 4章:固有値・対角化・Jordan標準形 - 暴走の危険があるかを判断
  • 5章:コンピュータでの計算(2) - 固有値計算法

書籍の特徴

f:id:yuzutas0:20150831233716p:plain

図や日本語での説明がしっかりしているのに加えて、数式と照らし合わせながら読み進めることができます。私が学生時代に指定された線形代数のテキストは数式だらけ+略しすぎて何が言いたいのか分からない図しかありませんでした(単に私の学習不足によるところも大きいでしょうが)。一方で、分かりやすさを売りにする書籍は扱う範囲や数式が浅すぎて実用に耐えられなかった印象があります。本書は両者の不満を解決していたので、非常に助かりました。

f:id:yuzutas0:20150831233832p:plain

また、何と言っても素晴らしいのが「この数式や説明が分からなかったら、XXXについての理解がきちんとできていないからだ!XXXページを読み返せ!」という注釈が大量についている点です。ついつい分かったフリをして読み進めがちですが、このように何度でも戻って復習できる工夫がなされているので、着実に土台を固めることができます。

書籍の注意点

  • 「プログラミングのための」と銘打っており、演算処理に関する言及もあるものの、どちらかというと「実務で使えるように概念を説明する」という側面の方が強いです。なので、プログラミングをしない人でも本書の対象になり得ます。
  • 説明用のサンプルコードは書いてあるものの実用に耐えうる内容ではなく、結局は有名ライブラリを使ったり、数学の専門家に依頼するように、という注意書きがされています。なので、書籍に書いてあるアルゴリズムをそのまま使うのではなく、あくまでも概念を理解するためのものだ、という認識で読む必要があります。
  • どうしても理屈の説明がメインなので、線形代数の問題をがっつり計算するという書籍ではありません。実際に手を動かして計算することで理解が進むのだ!という人は問題演習に特化した書籍の併用をお薦めします。

その他

参加者へのメッセージとして「私と同じような初学者がいたら本書を勧めたら良いのではないでしょうか」「数学の輪を広げるには、レコメンドアプリを作って一発儲けられないかな、みたいなことを言っている俗人を引き込むことも有効かもね」という話をしました。

プログラミングのための線形代数

プログラミングのための線形代数

おわりに

ちなみに、私が参加したのは第2回目で、今後は2〜3ヶ月に1回くらいの頻度で開催するとのことです。興味のある方はぜひ参加してみてはいかがでしょうか。

ニコニコ学会サマーキャンプ2015に参加しました

参加しました ニコニコ

注意

このエントリーの内容は私個人による考えであり、所属する組織・団体とは一切関係がありません。また、閲覧する人によっては不愉快に感じる内容、不健全な表現を多分に含んでいるため、気分が悪くなったらすぐにブラウザバックをお願いします。

️ 本題

筑波で開催されたニコニコ学会サマーキャンプ2015というイベントに行ってきました。

f:id:yuzutas0:20150831223359p:plain

当初の目的の1つは、新規事業の種になるアイデアを探すことでした。最初の自己紹介で「何か作ります」と宣言したはいいものの、最終的には、30分でエロサイトを作るというパフォーマンスを披露することに...。

️ 他の参加者のブログ

詳しく書かれているので、興味のある方はぜひご参照ください。

ニコニコ学会βサマーキャンプ2015に参加して - maoring blog

ニコニコ学会βのサマーキャンプに行ってきました! - 株式会社ネクスト エンジニアBlog

参加したセッションの一覧

  • テクノロジーが発達している割にリモートワークが普及しないのはなぜ?
  • テクノロジーを活用して就活をもっと楽しくできないか?
  • 高校は不要ではないか?社会性養成は中学、学問は大学、と考えると役割が中途半端では?
  • 制度としての結婚がなくなれば、重さ・息苦しさがなくなって、事実婚・出産が増えるのではないか?
  • テクノロジーでエロを追求すると、人類はどこに辿り着くのか?
  • セクシュアルマイノリティの生きにくさを和らげるにはどうしたらいいのか?
  • 触感を再現するハプティック・リアライズでどんなことができる?今の課題は何?
  • ペット用ロボットのハードウェアが老朽化するのに、ソフトウェアは永久稼働を想定することにギャップがあるから、寿命という概念を設計してみたらどうなるだろう?

実際にどんな話がなされたのか

せっかくなので議論形式で1つご紹介します。

お題【テクノロジーでエロを追求すると、人類はどこに辿り着くのか?】

  • 「そもそもエロとは何か。肉体的快楽だけでなく精神的充足感も含まれるのではないか。愛するパートナーとの触れ合いとか。これはリアルな人間同士ならではだよね。」

    • 「シナリオのある成人ゲームってその要素を重視しているのではないか。」

      • 「でもゲームって意識した時点でもうリアルじゃないじゃん。」
      • 「ゲームだと認識できなかったら?例えばこの世界が実はゲームだったら?愛するパートナーが実はロボットだったら?将来的にそういう錯覚を起こすことはできるのではないでしょうか?」
    • 「リアルが〜っていうけど、出会い系サイトだってテクノロジーですよね。」

      • 「出会い系の未来ってどうなるんだろう。」
      • 「遺伝子情報から最高のマッチングをさせるとかできないのかな。心がどうこうとか言っているけど、肉体面で最高の相性の人と出会ったら、そんな価値観がひっくり返ったりして。」
      • 「最近ゲノム系ベンチャーが多いようだし、技術要素としては不可能ではなさそう。」
      • 「教師データを集めるのは難しいんじゃないですか。」
    • 「この話って、男性と女性で重視する観点が違うのでは?」

      • 「さっきから男性の意見ばかりですよね。女性は XXX を重視しますよ?」
      • 「いやそれはあなただけじゃないですか。私は違うのですが。むしろ〜」
      • 「これただの性癖暴露大会じゃね?」
      • 「個人によって嗜好が大きく異なるということですね。性差や背景要因によってクラスタリングできる側面も当然あるでしょうけど。」
      • 「でもそうなるとさ、パートナー同士の話だったら、片方の快楽最大化がもう片方にとって苦痛になってはいけないよね。それは人類が追求すべきものではない。『被害者のいないエロ』を目指したいね。」
  • 「ちょっと待って。精神的充足感の正体って化学で言うとそもそも何ですか?」

    • 「脳内でなんらかの物質が分泌されるとか電気信号とかなんじゃないですかね」

      • 「だったら、それを強制的に引き出すことで、充足感を享受できるのではないですか?」
      • 「マウスの実験で脳に電極をぶっ刺して快楽を与えた研究があるらしいですよ。同じことは人間にもできるでしょうね。」
      • 「そうなると、その世界では肉体的快楽と精神的充足感は一致するのでは?」
    • 「この議論の流れは生命倫理としてどうなんですかねー。」

      • 「思考実験のために一度置いておきましょう。行き着くところまで行ってみたい。」
    • 「おっさん研究者に無理やり気持ち良くさせられたくないんですけど(by男性)。」

      • 「同性愛者でなくても、パブロフの犬みたいに学習したら、快楽や恋愛という概念の対象がおっさんになりそうですね。」
      • 「そうなったら今の価値観で美女に気持ち良くしてもらうのと同じことだから、将来的には問題ないでしょう。」
    • 「行き着く先は人類の滅亡ではないか。」

      • 「本来は子孫繁栄のための生殖行為を促すために性的快楽があるのに、その世界では単なる娯楽となっている。恋愛観も歪むのであれば、子供を作ろうとは思わないのではないか。」
      • 「マクロな人口政策と、ミクロな恋愛・結婚・性的欲求の解消は完全に分離されるでしょうね。その場合、人口維持のために試験菅ベイビーを大量生産する『人間工場』を有するディストピアに行き着くかもしれない。」
      • 「いやいや、ディストピアに対する不安感や非難、薬物と同じような脳に作用する快楽装置に対する制限は必ず掛かるはず。だとすると、人類はそこに辿り着かないのではないか。」
  • 「もう少し近未来に普及しそうなテクノロジーから考えてみますか。」

    • 「VRヘッドセットやIoT。いろんな可能性があるように思います。」

    • 「でもハードウェア自体は進化しているけど、コンテンツというか、どういうふうにしたら良いかってソフト面の整備はないような。」

      • 「人類の歴史の中でどれくらい進歩しているんだろう。昔の方がマニアックなワザマエを磨いている印象がある。学術的にそういうの扱っていないのだろうか。」
      • 「現代でもそうだけど性的知識は不浄なものとして表立って示されなかったり、歴史的には口伝や風習となっている地域が多いように思います。まだまだアーカイブされていないのが実情ではないでしょうか。」
      • 「興味深いね。快楽のアーカイブ化は意義があるんじゃないかな。」
    • 「嗜好に個人差がある分野なので、単なるアーカイブ化では参考にならないのではないでしょうか。」

      • 「どういう人にとっておすすめなのか、どんな工夫をすると良いのか、ニコニコ風に言うなら『やってみた』、Cookpadで言うなら『つくれぽ』のようなものがあれば良いのではないでしょうか」
      • 「快楽についてはまだまだWeb2.0に到達できていないってことですね。睡眠や食事に関する記事はSNSでシェアしたり自論を添えるけど、エロってなかなかそうはいかないですよね。」
  • 結論:現実的な到達地点はまだ見えない。なぜならソフト面の情報が未整備だからである。そこで人類にとってまず必要なのは「快楽のアーカイブ化」いわば「夜のCookpad」なのではないだろうか。

「夜のCookpad」作ってみた

f:id:yuzutas0:20150831225247p:plain

f:id:yuzutas0:20150831225306p:plain

  • まぁ、ただのハリボテなんですけどね!笑
  • でも、ホワイトボードで議論したあとに、実際にそれっぽいモックアップが目の前に出てくると、結構それだけで感動しちゃうんですよね。

作り方

  • ブラウザでCookpadのページを開く
  • HTML,CSS,JavaScript,画像を丸ごとダウンロード
  • 文言と画像をそれっぽいのに差し替える
    • ネットで探してコピペ
    • ユーザーの名前とか画像は迷惑を掛けないようにHTMLから消す
    • それっぽいのに差し替えるのが面倒臭そうな部品はHTMLから消す
  • ロゴはFireWorksでささっと作成
  • 完成!所要時間30分!

使い方(脳内設定)

  • 1人稽古や夫婦の勝負事について、新しいレシピを試してみたら投稿
    • 研究者は過去の文献や地方の知恵を投稿
    • 企業は消費者に試してほしいプランを投稿
  • 他の人のレシピを見て、やってみたら「やるレポ」に投稿
    • 感想:こういう点が良かったとか悪かったとか
    • 工夫:道具はこれで代用できるとか
    • 発見:旦那がこういうテンションだと適さないとか

今後について

  • サイトをきちんと作って公開してくれ!という声多数。
  • ただ、仕様が曖昧なのと、コンテンツをどう集めるかという課題があります。
    • カップルで再現可能であることが重要なのか、1人用のオカズコンテンツのキュレーション要素があったほうが良いのか。実は「夜のNaverまとめ」や「夜のwikipedia」の方がコンセプトとしてはあっているのかも。
    • ユーザーに投稿してもらうの大変だから最初はnanapiみたいにライターに書いてもらって広告で賄うのか。でもやっぱり個人の好き嫌いが如実な分野だから、Cookpadのつくれぽのように「自分はこうしたよ」情報は欲しい。しかし、どうやって投稿してもらうのか。実名だとアウトじゃね?くらいしか分析できていない。
    • 要するに雰囲気だけで何も決まっていない。
  • 作るだけ作って放置したらゴミ箱に直行しそうな一方で、きちんと設計・運用したら爆発しそうな感じがなんとも言えませんな。もう1回くらいあのメンバーでディスカッションしたいっす。

感想

  • いろいろすごかった。一応これ個人開発用のブログなので、作ったものとその背景として1トピックの議事だけ拾い上げましたが、他にも色々な議論があって思うところはありました。
  • あと、アンカンファレンスという形式が面白かった。KPTのような場でこういったやり方を試してみるのもアリかもしれないなぁと思いました。

おまけ1

f:id:yuzutas0:20150831225832p:plain

加速器・測定器を初めとした研究施設をいくつか見学してきました。世界線を越えそう。大規模な研究プロジェクトも、ネットワークの配線を1つ1つ繋いだり、巨大な装置をどういう手順で配置するかといった地道な設計・作業の積み重ねの上に成り立っているのだなぁと再認識した次第であります。

おまけ2

f:id:yuzutas0:20150831230057p:plain

今回は初めての筑波ということで「蒼」というらーめん屋に行きました。おいしかったです。こってりしているけど味がしつこくない。食べているうちに具や調味料が混ざり、味が変わっていって飽きない。そんなこんなで味わっていると、いつの間にかお腹が膨れていました。おすすめです。でも駅からちょっと歩くかな。

EnokiLog:更新のお知らせ

Enokilog Rails 改善しました 掲載されました

メディア掲載

掲載いただきました。

Impress 窓の杜(2015-07-02): 知っ得!旬のネットサービス - 資格試験などの学習の進捗をオンラインで記録、管理できる「Enoki Log」

機能改善

改修しました。

2016-04-18

  • SSL証明書を更新しました。長らく期限切れの状態が続き、ご不便・ご迷惑をお掛けしましたことを、お詫び申し上げます。

2015-08-02

f:id:yuzutas0:20150808001222p:plain

  • 記録画面:「Hidden」項目を追加しました。Hiddenにチェックされた行は共有画面で表示されません。

2015-07-04

  • BugFix:コンテンツ表示順の指定方法に誤りがあったため修正しました。

2015-05-28

  • リリースしました。

yuzutas0.hatenablog.com

HileSearch:更新のお知らせ

HileSearch Rails 改善しました 掲載されました

メディア掲載

掲載いただきました。

GIGAZINE(2015-07-17): 自分のノートPCがちょうどすっぽり入るサイズのカバン・バッグ・リュックを約1万の候補から探し出す「HileSearch」

機能改善

改善しました。

2016-04-18

  • SSL証明書を更新しました。長らく期限切れの状態が続き、ご不便・ご迷惑をお掛けしましたことを、お詫び申し上げます。

2015-08-07

f:id:yuzutas0:20150807235802p:plain

  • タグ検索:「OR」だけでなく「AND」でも検索できるようにしました。
  • タグ検索:一括選択・一括解除ボタンを追加しました。

2015-07-20

f:id:yuzutas0:20150720124847p:plain

  • ページング:「次へ」ボタンを、ページ下部だけでなく上部にも表示しました。
  • 検索:表示件数を3件だけでなく「3」「9」「15」「30」から選択できるようにしました。
  • 検索:総件数と何件目〜何件目を閲覧中なのか表示しました。

2015-07-16

  • リリースしました。

yuzutas0.hatenablog.com

PCが入るバッグを検索するWEBサービスを作りました

作りました HileSearch Rails

概要

f:id:yuzutas0:20150708203235p:plain

もくじ

  • どんなサービスか
  • どうやって使うのか
  • なぜ作ったのか
  • どうやって作ったのか
  • 思ったこと

どんなサービスか

  • 持ち運びたいノートPCを選ぶと、そのPCより大きいバッグを一覧表示します。
  • 名前は「PCが入る(ハイル)バッグを検索(サーチ)する」という語感決めです。

注意点

  • PCでのWEBブラウザ閲覧を推奨します。スマートフォンだと閲覧しにくい箇所があります。
  • Amazonの商品画像はアソシエイト用途でのみ利用可能という規約があったので「商品詳細を見るボタン=Amazonへのアフィリエイトリンク」という体裁を取っています。問題があればご指摘いただけると幸いです。

f:id:yuzutas0:20150708203132p:plain

どうやって使うのか

  • HileSearchにアクセス。
    • 持ち歩きたいPCのブランドを選択(例:Mac)。
    • PCの機種を選択(例:MacBookPro Retina 15inch)。
    • バッグが一覧表示されます。
  • さらに条件で絞り込み
    • 種類を選択(例:メンズのショルダーバッグ)。
    • 並び順を選択(例:価格が安い順)。
    • 検索ボタンを押下。
  • バッグを選択
    • 回遊しながら良さそうなバッグを探す。
    • 「詳しい情報を見る」を押してAmazonの商品紹介ページに遷移。
    • 気に入ったらAmazonなり店舗なりで購入。

なぜ作ったのか

  • 技術学習のためです。バッチ処理スクレイピングを練習したかったので、手持ちのアイデアの中から練習に向いているものを選びました。
  • また、事前準備ができていたからです。「鞄を探すサービス」というアイデアは昨年の秋から持っており、紙モックで見込みユーザーに軽くインタビューをしていました。コンセプトが固まっていたので、開発に専念できました。
  • 何よりも、自分自身が使いたかったからです。新しいPCを最近入手したので、持ち運びに適したサイズの鞄を探したいと考えました。

どうやって作ったのか

  • 以下の手順を踏みました。

    1. 企画:ペルソナ、課題、解決策、インタビュー、ピボット
    2. 開発:要件定義、設計、製造、テスト、チューニング
    3. リリース:環境構築、資材配置
  • システム構成は以下の通りです。

  • 基本的にはEnokilogと同じ流れです。

yuzutas0.hatenablog.com

企画

  • 最初は女性向けの想定でしたが、ヒアリング途中で方向転換しました。
  • なお、もともとは私のアイデアではなく、新規事業を考えようという有志の集まりで考えた素案の1つです。

初期想定

  • Customer:サイバーエージェント女子やリクルート女子。ノートPCを頻繁に持ち運ぶが、可愛い鞄を好むので、「見栄えの良さ」と「PCを持ち運べること」を両立したい。
  • Problem:欲しいバッグに自分のPCが入るかどうか調べるのが大変。店舗で聞いても「A4なら入る」程度の情報しか手に入らない。
  • Solution:バッグとPCを入力すると入るかどうか分かるスマートフォンアプリ。

インタビュー

  • 紙のモックアップ(いわゆるペーパープロトタイプ)を作成して、老若男女問わず約20人にヒアリングを実施。
  • IT系イケイケ女子は、PCが入ろうが入るまいが欲しいブランドのバッグは買う。課題感が弱い。
  • 普段からPCを持ち歩くのは外回り営業、就活生、IT系企業勤務やフリーランスのプランナー職/エンジニア職。
  • 特にIT系/フリーランス:人によってはAmazonでサイズを見比べながら良さそうなバッグを買うこともある。

ピボット

  • Customer:対象は比較的自由な風土のIT系企業に勤める人/フリーランス
    • 普段からノートPCを持ち歩いている。
    • 鞄をネット通販で買ったり、ネットの情報を参考にして店舗で買うことに抵抗がない。
  • Problem:PCを持ち運ぶバッグを探そうと思っても大変。
    • 店頭で買おうと思っても、自分のPCが入るかどうか絶妙なサイズのことが多い。
    • ネット通販で買うときに、サイズをいちいち見比べるのが面倒臭い。
    • 初めからPC用バッグを買えば確実だが、見た目のバリエーションが少ないと感じており、できれば広い中から探したい。
  • Solution:自分のPCを入力すると、入るバッグが出力されるWebアプリ。

バッチ開発

  • まずはPC/鞄の情報を取得してDBに入れるためのスクリプトを作りました。

設計

  • DB設計
    • Input:スクレイピングで取得できるデータを確認しました。
    • Output:後述するワイヤーフレームから必要なデータを整理しました。
    • I/Oを元にデータフローとDBを設計しました。
  • クラス設計
    • 事前に見通せない点が多かったので、綿密には設計しませんでした。
    • 小さなコードで試しながら、徐々に設計を修正・確定しました。
    • 徐々にレベルアップできるよう、実装の順番は決めておきました。

製造

  • PCのスクレイピング
    • Appleと価格コムからノートPCの名前とサイズを取得する処理を書きました。
    • どちらもデータ構造が明確なのでライブラリの動作確認に最適でした。
  • 鞄のスクレイピング
    • Amazonからバッグの各種情報を取得するスクリプトを作りました。
    • サイズ(縦*横*高)のフォーマットが統一されていないので、正規表現と分岐処理を組み合わせて、複数パターンの記載場所や表現方法に対応しました。

テスト

  • 小さく作り、小さく試し、エラーが出たらすぐ直す、という検証を繰り返しました。
  • 素早く動作確認するのが苦しくなる度にメソッドやクラスを分割しました。

チューニング

  • 繰り返し繰り返し、設計/実装/試験を行き来することで、少しずつ処理を改善していきました。
  • 例えば、Amazonは頻繁にアクセスエラーを返します。公式のProduct-Advertising-APIでも類似事象があるらしいので、そういうものと割り切ってリトライやスキップの処理を追加・調整しました。
  • また、Amazonからバッグのサイズ(縦*横*高)を取得するにあたって、いきなり完全な処理を作るのは難しいと判断して、チューニングしやすいようエラーログを設計しました。エラーログの確認と正規表現+分岐処理の改善を繰り返して精度を少しずつ上げています。まだまだ完璧ではないので、サイズが違っていたり、アルゴリズムの改善方法を見つけたらぜひ教えていただきたいです。

アプリ開発

  • バッチ作成後に、PCから鞄を検索するWebアプリを作りました。

設計

  • ユースケース設計
    • 必須機能を整理しました。
    • シンプルに「PCを選ぶ/バッグを表示する/絞り込む」といった形です。
  • 画面設計
    • 必須機能を満たすワイヤーフレームを紙に書きました。
    • ただ、実装中の画面をドヤ顔で知人に見せた際、遷移が分かりにくそうな反応があった箇所は修正しました。テンション駆動型ユーザーテストです。
  • CSS設計
    • 苦手意識があったので、確実に保守性とスピードを担保できるよう「共通化を避ける」という工夫をしました。すべての要素に一意となるCSSセレクタを指定して、それぞれ別々にCSSを適用させています。
    • ちょっとレイアウトを変えたくなったときに、CSSのどこを変更させれば良いかすぐに分かります。また、変更したときに他の要素が崩れる心配もありません。
    • 中途半端に共通化して、中途半端に変更しにくくなって、中途半端に嫌なデザインになって、結果として開発のモチベーションが下がってしまうくらいだったら、この方がマシだと判断しました。
/* 共通化しない! */
.bag_items_card .icon_char {
    font-size: 11px;
}
.bag_items_search_tag_form p {
    font-size: 11px;
}
.bag_items_search_price_form p {
    font-size: 11px;
}

製造/テスト

  • 製造
    • PC選択:PCリストの表示、submitで画面遷移。
    • バッグ閲覧:条件に合うバッグの表示、検索絞り込み、ページネーション。
  • APFWの理解不足問題
    • ActiveRecord:PCとバッグのサイズ(縦/横/高の組み合わせ)を計算するクエリが書けず...。SQLなら書けるのに...。結局、スクリプトで事前に「大きい値」「真ん中の値」「小さい値(nullの場合もある)」という3つのカラムに振り分け、その大小でバッグにPCが入るかどうかを判定しています。
    • ERB:Formが思うように書けず...。HTMLなら書けるのに...。というわけで、割り切ってERBで出力されるHTML相当のものを直書きしました。
  • テスト
    • ブラウザで一通りのテストを行いながら、バグやデザインを修正しました。
    • フォームやルーティング、ActiveRecordの負荷あたりは重点的に確認しましたが、まだ改善余地があるかもです。
    • テストコードを書かない悪弊はどうにかしたいですね。

リリース

  • システム構成はEnokilogと同様(CentOS/Apache/Passenger/MySQL/Rails)です。
  • データ移行やコンパイル周りでトラブルシューティングに一手間を費やしました。

環境構築

  • インフラ/ミドルウェアの環境構築は、Enokilogとほとんど一緒です。
  • 唯一違う点として、今回はSSL証明書が不要なので該当作業はスキップしています。

資材配置

  • クローラーの取得データを開発環境用SQLiteからDumpして本番環境にImport。
    • SQLiteで問題がなかったので全く確認していなかったですが、String指定なのに255文字以上のデータがあり、MySQLのvarchar2(255)からはみ出ました。スクレイピング時にバリデーションと整形をすべきでした。
    • また、バッグの高さが大気圏を突破しているデータがあり、MySQLのInt型からはみ出ました。サイズを取得する際の正規表現で変なのが引っかかったようです。
  • Assets:precompile を通すために試行錯誤。
    • 心が折れたのでローカルでコンパイルしてから本番環境に乗せました。
    • 反映後も画像ファイルやfont-awesomeのリクエストでフィンガープリントが反映されない問題など順次対処。

思ったこと

  • 進め方
    • Enokilogでの反省を活かして、小さく検証しながら改善したり、保守しやすい設計を心掛けました。一歩改善です。
    • ただ、チューニングやトラブルシューティングに想定以上の時間が掛かりました。時間が掛かること自体はやむを得ないといえばやむを得ないですが、10分だけ試してみて、それでダメだったら「明らかにベストではないけど一応解決はできる案」で妥協するといった線引きができていませんでした。
  • システム
    • 特にAPFW(Rails)に関する知識不足が足を引っ張りました。きちんと内部設計や事前学習に時間を掛けるべきだったと思っています。
    • とは言え、やってみて失敗して少しずつ理解が深まるという側面もあるのと、学習自体を目的化してしまうとなかなか進まない気もするので、何とも難しいところです。
  • プロダクト
    • 実際に自分で使ってみたところ、改善点が山ほど出てきました。「このサービスで探して本当に買うぞ」という気持ちでサイトを開き、形になったものを直接触ってみて、ようやく気付けたことだらけです。
    • 絞り込み検索でボタンを大量に押さなければいけない、PCだけじゃなくてスマホで見たいけどレイアウトがひどい、候補のバッグを比較しにくい、ページングしすぎて面倒臭くなって結局Amazonを開いてレコメンドから遷移してしまう、全体的にレスポンスが遅い、実際に買おうとすると価格>見た目>購入者レビューの順で情報を見ている(だけどHileSearchだと画像1枚のみ表示/レビューは表示していない)などなど。
    • ちょっとずつ直していきたいなーと思います。

最後に

  • 長くなってしまいましたが最後まで読んでいただき本当にありがとうございます。
  • 改善点やご意見など、何かあればコメント欄やGithubTwitterでご指摘いただけると嬉しいです。
  • 指摘された点や自分で使ってみて気になった点はIsuueに挙げていこうと思います。

その後の改善報告

yuzutas0.hatenablog.com