辛い #ajiting

#ajiting Advent Calendar 2015 - Adventar 15 日目の記事になります(15 日と 16 日の担当を交代しました)。 tabelog.com

201407300043

f:id:jewel12:20151215000617j:plain

201409102028

f:id:jewel12:20151215000616j:plain

201502190150

社内 Slack #daidai チャンネル AJI 氏より

f:id:jewel12:20151215000623j:plain

201502210152

社内 Slack #daidai チャンネル BRT 氏より

f:id:jewel12:20151215000620j:plain

201507090004

社内 Slack #daidai チャンネル ART 氏より

f:id:jewel12:20151215000621j:plain

201507202025

f:id:jewel12:20151215000613j:plain

201509092204

f:id:jewel12:20151215000611j:plain

201509230119

f:id:jewel12:20151215000610j:plain

201509260029

f:id:jewel12:20151215000609j:plain

201509302205

社内 Slack #daidai チャンネル MMM 氏より

f:id:jewel12:20151215000600j:plain

201510232244

社内 Slack #daidai チャンネル BRT 氏より

f:id:jewel12:20151215000619j:plain

201511111929

f:id:jewel12:20151215000607j:plain

201511202351

f:id:jewel12:20151215000606j:plain

2015112042340

社内 Slack #daidai チャンネル BRT 氏より

f:id:jewel12:20151215000618j:plain

201511242159

f:id:jewel12:20151215000605j:plain

201512012354

f:id:jewel12:20151215000604j:plain

201512142050

f:id:jewel12:20151215000601j:plain

最後に

今年 7 月から減量をはじめて 8kg 減減りました。

f:id:jewel12:20151215123250g:plain

明日の #ajiting Advent Calendar は kuromatsu さんです。

YAPC::Asia TOKYO 2015 に行きました

自分の中では 4 回目の YAPC::Asia TOKYO に行ってきました。初めて行ったのは新潟で学生やってた時に Niigata.pm で知り合った人たちが行くというので気になり、学生枠で参加したものでした(チケット無料!)。その時にいい話が聞けたり LT ソンとかやったりして楽しかったので裏方もやってみたいと思い、上京してからは 2 年連続スタッフで参加していました。

今年は最後の大花火というので、普通に参加しても当たり前のように楽しいやろ通常参加 2 回、スタッフ参加 2 回になってキリもいいやろとてきとうな理由をつけて通常参加。以下は見たトーク一覧。

  • 見た講演
    • HTTP/2時代のウェブサイト設計
    • Perlで学ぼう!文系プログラマのための、知識ゼロからのデータ構造と計算量
    • PietでLISP処理系を書くのは難しい
    • Adventures in Refactoring
    • Perl6 on JVM: It works??
    • Perl で RTB の最前線を闘い抜く
    • Lightning Talks

みんなうまくまとめてるだろうから一覧だけ。両日とも昼から参加してたから見たトーク数は少ないかな。盛り上がってるトークが多くて、可能なら分身して全レーン見たかった。

一番テンションがアガったのは「HTTP/2時代のウェブサイト設計」で、はじめから HTTP/2 に最適化されているサーバーを実装してみんなに使ってもらおうという気持ちが伝わった。

ノベルティについて

今回は VOYAGE GROUP として企業スポンサーのノベルティを手配をする担当の1人でした。企業パンフレットと AJITO と描かれた透明なステッカーです(AJITO は社内にあるバーのこと)。ステッカーは YAPC スタッフの方から言われていた分よりも少なめに出していました。自分のトートバックには入ってなかったから少なかったかーと思ってしまったけど、ノベルティ一覧の写真をあげている方の記事を読むと存在しているようで安心。

AJITO というバーは社内のエンジニア文化をよく表している場で、弊社には自慢しているこんな文化があるんだよと認知していただきたいものです。ノベルティによる周知についてはノベルティについては @fshin2000 さんの記事で

主観だけど、ステッカーは小さいので、イベントの文脈にあわせて頑張ったり、何かひねりがあったほうがいい気がします。もしすげークールなサービスならロゴだけでいいかもしれないです。そうでなくて、これから認知を増やしたい、新参サービスだったら、もう少し違う球を投げたほうが埋もれずに済むかもですね。

f-shin.net

という話があって、ノベルティを作る際、いかに埋もれないかを意識してなかったことに気付きました。確かに、今回の YAPC::Asia TOKYO のイベントではスポンサーが多いのでノベルティも多い。ノベルティ作成に関わったので他の人よりもノベルティに興味がある自分でも、全てのノベルティやパンフレットに目を通していない有り様です。次にノベルティ作ることがあるなら、他のノベルティに埋もれない方法を考えていきたい。

まとめ

スタッフの皆さんやトークをした皆さんはお疲れ様でした!ありがとうございます!YAPC 最高!

InfluxDB の Schema 設計

時系列DBで SQL like なクエリが書ける InfluxDB と、その可視化ツールである Grafana を使おうかなーと思っているのだけれど、InfluxDB はバージョン 0.9 系がもうすぐ出るらしい。気になるのは 0.8 系と 0.9 系間の違いと Grafana の InfluxDB 0.9 系への対応具合になる。0.9 系はまだ出ていないし、Grafana の方もちゃんと対応しきっていない。今 InfluxDB 0.8 系でを使い始めて、Grafana が 0.9 対応した時に移行できない可能性があるという微妙な時期。

Clustering, tags, and enhancements to come in 0.9.0 を読むと 0.9 の機能で気になるのは Tags のサポート。


Tags の話の前にまず 0.8 の時代での Schema 設計の話をする。例えば server01 のコアごとの CPU load を記録したいとする。コアが2つあって、ひとつめを 1 番、ふたつめを 2 番とする。これを表現する方法はいくつかあって、データ点内にコア情報を含めるか、Series(名前の通り時系列なデータ点が入るところ)の名前にコア情報を含める方法がある。

前者は Series 名を server01.cpu 、カラムに core というものを作って以下のようなデータ点を入れる方法。

{"core": 1, "value": 1.2, "time": 1400425947368}
{"core": 2, "value": 1.7, "time": 1400425947368}

後者はシリーズ名を server01.core.1.cpuserver01.core.2.cpu のふたつを用意して、server01.core.1.cpu には {"value": 1.2, "time": 1400425947368} を入れ、server01.core.2.cpu には {"value": 1.7, "time": 1400425947368} を入れるという方法。

InfluxDB Schema Design Guidelines に書いてあるけれど、前者のカラムに core を定義するやり方は index が効かない。コア 1 のデータがほしいだけなのにコア 2 のデータも走査してしまう。

一方、後者の Series 名にコア番号を含めるやり方だとコア 2 のデータを走査するというようなことがない。どっちのコアのデータもほしい場合は select * from /^server01\./ limit 100; というような、Series 名に対する正規表現で複数 Series を対象としたクエリを投げることができる。このやり方は SQL like という割には直感的ではなくて select * from server01 where core = 1 limit 100; と書くほうが SQL を書くのに慣れた人は直感的な気がする。そういう要望が多かったのかどうかは調べてないので知らないけど、0.9 からは index 化される Tags を用意したようだ。

Tags がどういう風に使われているかは v0.9.0 ドキュメントの Schema DesignReading and Writing Data を読めば分かる。

Clustering, tags, and enhancements to come in 0.9.0 の Migration のところを見ると、0.9 系に上げるまでは Series 名にコア番号を含めるやり方と同様に <tagName>.<tagValue>.<tagName>.<tagValue>.<measurement> みたいな Series 名にしておけば Tags を自動的に定義してくれるっぽい。

実際のところどうなのか・本当なのかは 0.9 系を動かして確かめたわけではないので、雑記クオリティということでひとつ。

正則化

暴君ハバネロ シビ盛というのを買ってビール1杯だけ飲もうとしたら、辛い & ウマいの効果で 1缶/5口 という感じになってしまった。最近は山椒が好きで(といっても2年くらいずっとだけど)メニューに山椒と書いてあるだけで頼んでしまう。


今日は PRML (パターン認識と機械学習) 勉強会の日でもあった。上巻 3.1.4 「正則化最小二乗法」のところ。回帰モデルに正則化項を与えて過学習を防ぐ。正則化項には q というパラメータがあり、q = 1 のときを lasso とか L1 ノルムとか呼ぶ。L1 ノルムはある線形回帰モデルがあった時、パラメータのいくつかが 0 になるような解を得やすく、不要なパラメータを削る次元削減に使える。回帰モデルにおけるL1正則化とL2正則化の効果 - old school magic が分かりやすい。

次は 3.2 バイアス-バリアンス分解の担当になっている。正則化のところでもラグランジュ未定乗数法とかを余裕で忘れていて(大学で習ったはずなのにもはや名前だけ知ってるとかいうレベル)、本当についていけるのかと思う。実際、今までやったところも1/10くらいしか理解していないと思う。でも、分からないところは分からないというとメンバーが一緒に考えてくれるので助かるし気楽で良い。


あるバッチが使ってる split コマンドで split: Output file suffixes exhausted というエラーが出ていた。split は指定したサイズでテキストファイルを分割したりするのに使うコマンド。分割後のファイルは yabai_text.aa, yabai_text.ab, yabai_text.ac ... yabai_text.zz とファイル名の suffix に a-z の文字列がつく。split コマンドのデフォルトでは zz (676 個) までしか分割せず、これを超えるとエラーが出る。a オプションで suffix の桁数を増やすことができるので、分割後のファイル数が 676 個を超える場合はこれで解決できる。

なんでデフォルトの最大分割数が決まっているのかが気になった。ディレクトリ内のファイル数の上限とかに配慮してなのかな。

2015-05-26 空腹関数からオブジェクト

連日雑記。2 日も続くなんて明日も地震が起きてしまう。

毎週月曜の TaPL 読みも 20 章「再帰型」に来た。20 章なんて遠いなと思ってたけど、難しい定義とかすっ飛ばしてトピックだけ拾い読みしてるから早い。しかし理解度としてはぬるめ。まあそれでも面白いところはいっぱいある。

今日読んで面白かったところは空腹関数からオブジェクトまでの流れ。空腹関数は f 0 1 2 3 ... というふうに引数を無限に受け付ける関数で、ひとつ引数を受け取るとまたひとつ引数を受け取れる関数を返す。空腹関数は不動点演算子を使って定義できる。パクパク引数を食べまくるパクパク。

こういう構造を見るとストリームになりそうと思うよね。はい、ちゃんと定義されている。ストリームは空腹関数と同じように引数として unit を受け取り、何らかの数とストリームの組を返す関数として定義されている。この組の第一要素を head、第二要素のストリームを tail とみることができる。例では upfrom0 という 0 からの無限な整数列を定義している。

ストリームを一般化したプロセスというものもある。ストリームでは unit を受け取っていたが、ある数を受け取れるようにし、数と新たなプロセスを返すものをプロセスと呼ぶ。例えば今まで入力された数の総和を返すようなプロセスがあるとする。2 を渡すと {今までの総和に2を足した数, 新しい総和を返すプロセス} というような組が返る。この組の第二要素のプロセスに 3 を渡すと、{今までの総和に 2 を足した数に 3 を足した数, 新しい総和を返すプロセス'} という組が返ってくる。TaPL では第二引数の新しいプロセスに数を送る send という関数と、第一引数の値を取り出せる curr (current?)を定義しており、下記のようなことができる。

curr (send 20 (send 3 (send 5 process)));
# => 28 : Nat

第二要素の 新しいプロセス というものについて考えてみるとこれは状態を表しているようにも思える。最近は FRP が話題だったような気もするので(もう古い話題?)、ストリームといったら状態とピンとくる人も多いかも。

はい、ここでオブジェクトが出てくる。プロセスで、第一要素に何らかの数が入っているとしていた部分をレコードにしてあげれば、純粋関数的なオブジェクトを表すことができる。例えばレコードのフィールドとして定義されている関数で、increment のような状態を変える関数は、次の状態のオブジェクトとプロセスを返す。このようにして状態の変わるオブジェクトを表すことができる。かっこいい。

文だけだとよく分からないと思うので TaPL の定義を見たほうが早い(定義を書くとほぼ TaPL の写しになってしまうので文で書いてみた)。状態を変える関数が複数定義されているオブジェクトがあって、その状態の無限の遷移(無限に深い木)を想像すると夜も良く眠れそうな気がする。


ここまで書いてからストリームからオブジェクトの話は SICP にもあったなぁというのを思い出した。すぐ思い出せないといけないな。

http://sicp.iijlab.net/fulltext/x355.html

2015/05/24 減らす技術

気まぐれに雑記。

土曜日は「減らす技術 The Power of LESS」を読んでいた。最近、新卒の人を OJT で受け持つことになった。技術力が云々とかは自分でどうにかできそうな人だし、僕が教えられるのはチームが作ってるプロジェクトのシステムのこととそれっぽい働き方くらいかなーと思う。自分がどんな働き方してるかなと振り返ると、最近はチーム内外で起こっている事柄に対して積極的に興味を持ちつつ、やることを減らしていきたいというのがスタンスになっている。選択と集中という感じ。まあその姿勢を実行するのは難しくて、気持ちは感じられるが行動に見られていない。何も考えなくて済むのは選択をせず、目一杯時間を使ってやる事をこなしていくことなんだけど、たいてい全部できないし余裕がなくて辛ぽよ状態になる。

減らす技術 The Power of LESS にもそういうことが書いてあって、内容を一言でいうと「やりたいことに集中しろ」ということかなと思う。集中するためには気が散るような物事を削っていく必要がある。一時的にはなんか色々やらなきゃと思うことがあって、どれも重要に見えるからなかなか削れない。削る勇気を持つには、やらなきゃということを達成することで将来的にどんなインパクトがあるかを考えること。うまく考えることができれば、削るためのある程度の指針となる。ここらへんのことは前にも書いている(自分が新卒の時だ)。

やるべきことについて - ミントフレーバー緑茶

たまにこういうの読んで意識を高めないとこういう雑記を書いたりしない。

漫画はヴォイニッチホテルの全巻とちおちゃんの通学路というのを読んでいた。ヴォイニッチホテルは元ヤンの主人公の話とスナーク狩りの話の両方に同じくらい比重が置かれたまま話が平行に進んでて、どっちの話がメインなのかよく分からずふわふわしていた。それがいいところだとは思う。

ちおちゃんの通学路は Amazon のお勧め欄にあったから適当に買って読んでみた。読者(自分)を置いてきぼりにするレベルでテンションが高いだけでめちゃくちゃ面白くなかった。Amazon おすすめガチャで最近面白かったのはオニクジョが良かった。

日曜は机を組み立てたりアンダースタンディングコンピューテーション読み会の担当分(3章)を読んだりしていた。3章は正規表現を表すオートマトンを作ったりする。実装しながらなのでわかりやすいけど、Ruby じゃなくて Haskell で書いた方が楽しいはず。

「クラウドを支えるこれからの暗号技術」を読んだ

github.com

developer.cybozu.co.jp

クラウドを支えるこれからの暗号技術」は上の紹介記事にもあるように最近の暗号技術についてのドキュメントで、無料で公開されている。

自分は体系立って暗号技術を学んだことがないので、何かいい本ないかな〜と思っていたところでドキュメントが公開されたので読んでみた。読んだといっても、1部「暗号の基礎」2部「新しい暗号技術」3部「数学的なはなし」と分かれている中で、1部2部で省略された数学的な部分の穴埋めをする3部は読んでいない。

最近の暗号技術を説明するという内容だけど、1部は楕円曲線暗号を含めた基礎をしっかり説明しているし、知らない人は1部だけ読んでみても十分面白いと思う。紹介記事に「入門書と専門書の合間を埋める目的で書かれました」と書かれているように、もうちょっと踏み込んで知りたいという人にとっては、難しすぎもせず少な過ぎもせず満足できる内容でした。このように丁寧に書かれたドキュメントが無料で読めるというのは素晴らしい。

メインとなるであろう2部はクラウドサービスが普及しているなか、全面的にサービスを信用しているわけではないので、暗号化したままデータを扱うにはどうすれば良いのかという、最近だとニーズがありそうな話が多い。クラウドに関連するものだけではなく、放送型暗号や電子投票についての話もある。面白かったトピックを並べると

  • ペアリング
  • IDベース暗号
  • 準同型暗号
  • ゼロ知識証明

がある。

最近、社内で内定者向けに Web アプリケーションセキュリティ周りの勉強会が開かれていて、サポーターとして参加したのだけれど、勉強会で使っているドキュメントがいわゆる徳丸本だった。「体系的に学ぶ 安全な Web アプリケーションの作り方」という徳丸本のタイトル通り、体系的に学べる超良著ではあるが発売が 2011 年ともう 4 年前の本になっていて、それ以降に話題になった話が載っていない(例えばクリックジャッキング)。それで社内のセキュリティ大好きっ子に、いつまで徳丸本だけで勉強しているのかと言われてしまった。

セキュリティ周りの動向は早いので、教えるとき or 学ぶときは体系立ってかつ最近の話も載ってるものを期待するのではなく、既にある良書と他の新しめの情報を組み合わせないといけない。

クラウドを支えるこれからの暗号技術」は扱ってる内容が最近の話だというのもあるけれど、1部の基礎のところでも POODLE や Snowden の告発と前方秘匿性、Bitcoin の話など、比較的最近の話も絡めている。

暗号技術を体系立って学ぶ本には

新版暗号技術入門 秘密の国のアリス

新版暗号技術入門 秘密の国のアリス

があるらしいが(まだ読んでない…)、「クラウドを支える〜」の方の紹介記事に「暗号技術入門」には楕円曲線暗号について触れられていないと書いてあるので、徳丸本と同じように良著でも最近の話が載っていないということが起きているのかもしれない(Amazon 商品ページで目次を確認すると楕円曲線暗号については新板の5章に書かれているっぽい)。「クラウドを支える〜」は GitHub で管理されているので、新しい情報もどんどん追加されそう。