Machine Learning その後

2017年3月27日、会社へ向かう電車の中で最後のビデオを見終えた。もちろん途中のクイズ・課題はすべて合格している(満点ではないけれど)。

感想

  • Week5が演習の山場。これを超えるとスルスルと進む。
  • Deep Learning がきっかけで機械学習について勉強し始めた。Deep Learning を使わなくても手書き文字(MNIST)の認識率は 95%くらいだったので、びっくり。そんなに高いんだと。残り数%を埋めてくのが大変なんだなと感じた。
  • 初め方の演習ででた問題と同じような問題が後の方の演習でも出てきた。初めの方の演習では苦労して解いたが、後の方の演習ではすんなり解けて、成長(というほどでもないけれど)を感じた。
  • 機械学習と聞くとよくわからないブラックボックス的なものだったけれど、おおよそどういうもののか把握できたのがよかった。
  • インプットばかりだったので、アウトプットもしたい今日この頃。

Machine Learning

Coursera の Machine Learning コースを 2016/12/27 から始めた。今、Week 4 の途中。とりあえずは、付いていけている。課題を満点でpassしていないのが、心残りだけれど期限があるので期限優先で進めている。順調に進めば、2017/04 には終わっているはず。

2016年の振り返り

Pull Requests

2016年はPRが多い年だった。

GitHubを使い始めてからこれまでに、PRを出した件数を年ごとに数えてみると以下の通りだった。

  • 2010年:0件
  • 2011年:0件
  • 2012年:1件
  • 2013年:0件
  • 2014年:1件
  • 2015年:2件
  • 2016年:11件

2016年が飛び抜けて多い。基本的にPRを出すときというのは、何かのOSSを使っていてバグやドキュメントの不備を見つけたときなので、2016年は前年までに比べてOSSに多く触れてきた年だったのかなと。

まあ、PRを出してるけど大抵がtypoの修正だったりするのであまり自慢できるものでもないけれど。

Deep Learning

ゼロから作るDeep Learning。これが面白かった。これを読むまでは、Deep Learning が盛り上がっているな〜、とは感じていたけど、特にDeep Learningについて調べたりしなかった。これを読んでからは、Deep Learning って面白いと思うようになり自分の中でも盛り上がってきた感じ。何かに応用できればな、と思う。

今 TensorFlow を少し触り始めところだけれど、MacBook Pro だと時間がかかりすぎてツライ。GPU が使えないと気軽に試せない。GPUインスタンスは高いし。。。

fluent-plugin-parameterized-path を作成した

fluent-plugin-parameterized-path という fluentd のプラグインを作成した。

どんなプラグイン

  • ログをファイルに出力するプラグイン
  • 指定したキーの値から、出力するファイルのパスを決定する。
  • out_file とほぼほぼ同じ機能がある。symlink_path は未実装。

例えば以下の設定を書き 

<match dummy>
    @type parameterized_path
    path_prefix /var/log/subs
    path_key path_is_here
</match>

次のレコードが送られてきた場合

{"path_is_here": "/oh/my/log", "message": "hello"}

/var/log/subs/oh/my/log.2016121416.log というファイルが作成され、内容は 2016-12-14T16:18:20[TAB]dummy[TAB]{"message":"hello"} のようになる。

なぜ作ったのか

最初は fluent-plugin-forest を使おうと考えていたのだが、送られてくるタグの数を計算してみると 1000 を超えそうだった。fluent-plugin-forest はタグごとにスレッドを作成するようで、タグが1000ということはスレッドが1000ということで、こりゃまずい、と。メモリ使用量も気になるけど、コンテキストスイッチのコストの方が気になる。

で、対応方針としては

  1. タグの数を減らす
  2. fluentd をマルチプロセス化して、負荷を分散させる(メモリ使用量は変わらないけど)
  3. 問題を解決してくれるプラグンインを使う

あたりかなと。

02 は他の方針と併用できそうなのでキープしておきつつ、根本的な対応としては 01 か 03 のどちらかかなと考えた。 01 だとちょっと利便性が下がりそうだったので、03 かな〜と思ってプラグインを探してみるも、思ったようなプラグインが見つからなかった。

なので作成した、というのが理由。

Digest認証で制御されているElasticsearchにアクセスする

Python Elasticsearch Client を使って, Digest認証のかかったElasticsearch に接続する方法.

from elasticsearch import Elasticsearch, RequestsHttpConnection
from requests.auth import HTTPDigestAuth

es = Elasticsearch(
    ['myelastic.example.com'],
    http_auth=HTTPDigestAuth('user', 'password'),
    connection_class=RequestsHttpConnection
)

vscode-digdag

Visual Studio CodeDigdag 向け拡張機能を作成している。名前はvscode-digdag

一番初めのバージョンの公開は 2016年7月19日。すでにおよそ2か月が経過しているので、「作成した」というよりは「作成している」の方がしっくりくる。

開発も、当初はシンタックスハイライトのみを考えていたけれど、オートコンプリート機能をつけたバージョンを今日公開した。

作りはじめたきっかけは

ちょうどDigdagのことに興味が湧き、色々と調べていたところ、Atom, Vim, Emacs にはシンタックスハイライトの拡張機能(など?)があるのに、vscode にはなかったので、いっちょやったろうかと思ったのがきっかけ。

作者の古橋さんは、設定ファイルをYAMLにすることのメリットの一つとして、シンタックスハイライトができること、と言われている(参考)。が、それは見なかったことにして作ってしまった。

最初の頃はDigdagの調査よりも、vscode の調査をしていいる時間の方が長かったような。。。

tokyo.ex #5 に参加した

beam-lang.connpass.com

に参加してきた。19:00 に会社を出て 19:20 分に到着。ギリギリ。

細かいことは置いておいて、印象に残った部分を残しておく。

Phoenix について

@ohrdev さんのお話。

Elixir の公開されているライブラリの数は 3000くらい。他の言語 (Go, node など) は 10万 Over。みんな頑張ろう!

Logger

@tuvistavie さんのお話。Logger は Elixir の特徴を活かして作られてるとのこと。その中でも一番面白いと思ったのは、ログレベルでの出力制御の話。

Logger.debugLogger.error は実はマクロ。ログレベルを info にしてコンパイルすると、Logger.debug はなかったことにされバイトコードに出力されない。コスト 0。

セッショントーク

(トークセッション?)

ユースケースについて

Q. 仕事で使える?
A.
  • apiサーバで使ってる. 1台あたり 300req/sec.
  • HTTP, JSON を OTP に置き換えてる
  • チャットで
Q. Elixir の不得意なところ
A.

全員一致。

Q. Phoenix の不得意なところ
A.
  • ライブラリ
Q. Elang の知識は必要か
A.
  • Erlang を知らないとプロダクションで扱うのは怖い。Elixirよりも重要だった。
  • トラブル対応などに必要。Erlangというより OTP が重要
Q. エコシステムについて
A.
  • 少ない。足りないものは自分で作る。
  • mix に publish 機能があるので、公開は簡単。
  • 名前が ex_{GEMの名前} は要注意。
Q. 生産性 (Rails と比べて)
A.
  • ライブラリ豊富だから Rails の方が作るのは早いんだけど、その後パフォーマンスチューニングの日々が続く。逆に Phoenix は作るのは遅いが、その後のメンテナンスコスト低いので、長い目で見るといいことがあるかも。
  • (メンテナンス性には)関数型とかはあまり関係ない。
  • Rails はソースを追うのがきついな (長年の積み重ねで)
    • Phoenix もいづれは。。。?
Q. 言語の移行. 関数型
A.
Q. 言語の移行. 並列処理
A.
  • Elixir は安定している。Go は Segmentation fault を出す.
Q. マクロは必要か?
A.
  • アプリを作る分には不要。ライブラリを作る時に。
  • ソース読む場合に必要。でも書かない。
Q. スクリプティングに向いてる?
A.

Yes => 1名, No => 3名.

私も No 派。

感想

  • OTP 重要
  • ライブラリ不足
  • 使いどころを間違えなければ、プロダクションで導入可能。

生活環境の変化より2年ほど勉強会には参加できてなかった。久々にこういう場に参加できて楽しかった。