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ということで、こりゃまずい、と。メモリ使用量も気になるけど、コンテキストスイッチのコストの方が気になる。
で、対応方針としては
- タグの数を減らす
- fluentd をマルチプロセス化して、負荷を分散させる(メモリ使用量は変わらないけど)
- 問題を解決してくれるプラグンインを使う
あたりかなと。
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 Code のDigdag 向け拡張機能を作成している。名前はvscode-digdag。
一番初めのバージョンの公開は 2016年7月19日。すでにおよそ2か月が経過しているので、「作成した」というよりは「作成している」の方がしっくりくる。
開発も、当初はシンタックスハイライトのみを考えていたけれど、オートコンプリート機能をつけたバージョンを今日公開した。
作りはじめたきっかけは
ちょうどDigdagのことに興味が湧き、色々と調べていたところ、Atom, Vim, Emacs にはシンタックスハイライトの拡張機能(など?)があるのに、vscode にはなかったので、いっちょやったろうかと思ったのがきっかけ。
作者の古橋さんは、設定ファイルをYAMLにすることのメリットの一つとして、シンタックスハイライトができること、と言われている(参考)。が、それは見なかったことにして作ってしまった。
最初の頃はDigdagの調査よりも、vscode の調査をしていいる時間の方が長かったような。。。
tokyo.ex #5 に参加した
に参加してきた。19:00 に会社を出て 19:20 分に到着。ギリギリ。
細かいことは置いておいて、印象に残った部分を残しておく。
Phoenix について
@ohrdev さんのお話。
Elixir の公開されているライブラリの数は 3000くらい。他の言語 (Go, node など) は 10万 Over。みんな頑張ろう!
Logger
@tuvistavie さんのお話。Logger は Elixir の特徴を活かして作られてるとのこと。その中でも一番面白いと思ったのは、ログレベルでの出力制御の話。
Logger.debug
や Logger.error
は実はマクロ。ログレベルを info にしてコンパイルすると、Logger.debug
はなかったことにされバイトコードに出力されない。コスト 0。
セッショントーク
(トークセッション?)
ユースケースについて
Q. 仕事で使える?
A.
Q. Elixir の不得意なところ
A.
全員一致。
Q. Phoenix の不得意なところ
A.
- ライブラリ
Q. Elang の知識は必要か
A.
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年ほど勉強会には参加できてなかった。久々にこういう場に参加できて楽しかった。
VSCode に Integrated terminal という機能が追加されていた
VSCode 1.2.0 で Integrated terminal という機能が追加されていた。
大雑把にいうと、エディタのウィンドウの一部にターミナルを追加させる機能。
mix コマンドをコマンドパレットから実行できるように拡張機能を書こうとしてたんだけれど、Integrated terminal でいいじゃんって感じ。フォーカスを移動させるショートカットがまだわからないけど、拡張機能を書く意欲は下降気味。というか消失。