技術書典4にサークル名「まいにちがきんようび。」で暗号通貨とDNSの本を配布します
直前のお知らせになりますが、 技術書典4 に「まいにちがきんようび。」というサークル名で参加して技術系薄い本を配布します！
以下のような内容になっています！
- 基礎から説明する暗号通貨 @lunatic_star
- 今日から始める IOTA @syu_cream
- エンジニアのための DNS(再)入門(初級者編) @m_bird
- エンジニアのための DNS(再)入門(中級者編) @kdmn
(表紙イラスト @fuga_romantica )
配布部数は 50 程度になる予定です。また販売価格は一冊 500 円を予定しています。 電子書籍での販売も予定しているため、もし売り切れるようなことがあれば（あるのかな...）そちらをご検討頂ければ幸いです。 ぜひ当日、会場にてお会い出来れば嬉しいです！！！
何気ない発言で師匠を傷付けるスマートコントラクトを実装してみた
はじめに
コインチェックの例の騒動を受け、なんだか僕もブロックチェーンネットワーク上で何かワチャワチャしたくなってみました。 ちょうど Ethereum が気になっていたこともあり、ちまたには傑作アニメの発言が流行っていることも助けて、試しに発言ボット的なスマートコントラクトを実装してみることにしました。
ツール群
geth という Go 製 Ethereum CLI が有名っぽいのでこれを利用してみます。
--dev オプションを付与することで開発用の一時ネットワークを構築できるようです。
またスマートコントラクトの実装には Ethereum VM のコードを書くのに一番使われているらしい、 JavaScript っぽい構文にも見える Solidity を使ってみます。
ハマったこと
着手してみたのですが、Solidity 固有の？独特な attribute 指定とかがあってつらい感じでした。また文字列結合が + 演算子でサクッとできたりもしないようでつらみを覚えます。
とりあえず今回は solidity-stringutils でお茶を濁します。
成果物
以下になります。
不用意なメソッドをコールするといろいろな師匠を傷つけてしまいます。
> BBNM.mambo.call() "Your casual \"mambo\" hurt a samba master." > BBNM.ole.call() "Your casual \"ole\" hurt a flamenco master."
ご注意ください。
第1回WSA研究会に参加してみた振り返り
あけましておめでとうございます。年末年始はほぼ寝て過ごしていました。
表題の通り、去年に 第1回WSA研究会 というイベントに参加したのでその振り返りなどをさくっと書いていきます。
第1回WSA研究会全体への雑感
発表内容は以下の通りで、名前の通り Web System Architecture の体系化や選定、流行りの Microservices 、ストレージに関する内容が多かった印象です。
websystemarchitecture.hatenablog.jp
イベント中ははてなさんの会議室の一角を利用して割と近い距離感のなか発表者が事前準備したスライドと共に発表し、聴衆が様々なコメントをしていく形式です。 発表時間15分,質疑応答15分というスケジュールのなか、発表自体も質疑もなかなかの盛り上がりをみせ、充実した時間になったのではないかと感じます。
このイベントで個人的に興味深かった特徴の一つとして、実稼働させた、あるいはさせようとしているシステムで抱える課題の延長線上に発表内容が立っていることが多かった点があります。 （特に matsumotory さんの FastContainer の話などは実稼働しているサービスで評価もしている）
個人的な振り返り
"Reusable TDI infrastructure" と題して、 markdown 付きインフラテストコードを実行する構想について話しました。予稿はこちら （業務と絡めるロジックが思いつかずプライベートで行ってます、ということで内容は個人の意見ですということで）
反省点としてやはり既存技術のサーベイが結構不足していた点があります。 後から知ったことですが、 NII が Literate Computing for Reproducible Infrastructure とうたう構想で Jupyter Notebook ベースの Infrastructure as code 基盤を作っているようだったり、関連するソリューションは探せばもっと出てきそうです。
合わせて他の参加者の方へのコメントも積極的に行ってみたつもりなのですが、果たしてそれらがどれほど良いフィードバックになったかどうか。 余計なことを言っていないかどうかは内省すべきところかな・・・と感じました。
おわりに
普段あまり意識することの無い観点を意識でき、良い刺激になる会でした。 折角こういった議論の場が発足したわけですし、日々の業務の中でも課題の一般化を行いアウトプットをしていくという活動をより多く取り入れ、成果を持ち込めるようにしていきたいところです。
WSA 研 #1 予稿 "再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み"
第1回WSA研究会 という催し物に出る予定でそれ用の予稿を書いたのですが、折角なのでブログにも掲載しておこうと思います。あとで更新するかもです。
再利用性の高い Test Drive Intrastructure 実行環境に関する取り組み
Infrastructure as code や CI/CD の文化の広がりやインフラ構成の複雑化に伴い、 Test Driven Infrastructure といったインフラ構成をテスト可能にすることで安定稼働を目指す取り組みがなされている。
Test Driven Infrastructure の実践方法としては 1) Ansible や Chef などといった構成管理ツールに特化したテストツールを使う 2) Serverspec などといった構成管理ツールとは独立したツールを使う方針が考えられるが、前者はツールに非常に依存しかつ独特の DSL を要求される、後者はツール特有の学習コストが要求されるといった課題がある。
実践方法とは別に、インフラ構成やテストに関する情報を残すことも重要である。これは Google の Site Reliability Engineering の序論に記されている "実装は一時的なものだが文書化された理論は重要" との記述や、 Serverspec が可読性を重要視 して実装されたことからも汲み取れる。
本研究ではこれらの背景を加味しつつ、前述の実践方針の 2) のような構成管理ツールとは独立した形で、かつ低い学習コストで Test Driven Infrastructure を目指す。 その実現方法として現在、 Harmonium というツールを試験的に実装している。このツールは現状、 Markdown に埋め込まれたシェルスクリプトを実行するツールである。 Harmonium によるテストコードの実行は bats と似たアプローチであるが、ドキュメントを Markdown で書けてかつ独自の記法を要求しないという差分がある。 Markdown は GitHub などのサービスの WebUI 上でレンダリング可能で運用上親和性も高く、テストコードに対する情報を付与しやすい。またシェルスクリプトを用いることで運用者はシェルの知識をそのまま利用することが可能で、別途 Ruby や Serverspec などのシンタックスを習得する必要がなくなる。 現在 Harmonium は golang で実装しており、ツールはワンバイナリで実行可能となるため、 Serverspec をローカルで実行する際に発生する Ruby や依存ライブラリを導入する手間などが軽減される。
参考
参考にした文書やソフトウェア。本研究で提案する Harmonium は特に Jupyter Notebook に大きく影響を受けている。 Jupyter Notebook はノートブック形式で実装とは別に Markdown で文書を残し、他者と共有ができる。 Jupyter は Cloud Datalab でベースに用いられるなど、データ分析でよく使われるツールとなっている。
余談だが Harmonium はブラウザ自動テストのためのツール Selenium やアプリ自動テストのためのツール Appium に触発されて命名した。
RocksDB の mruby binding "mruby-rocksdb" を作った
これは mruby Advent Calendar 2017 17 日目の記事です。
本記事は表題の通りの内容になります。 Advent Calendar のネタがどうしても思い浮かばず、ふと去年の自分の記事を振り返ってきたところ KVS の mrbgem を書いてた ので、コードをある程度使いまわして似たようなネタで行くかと考えた次第です。
RocksDB について
Facebook が公開している KVS です。 LMDB とか LevelDB 、 K2HASH と同じような、組み込みの KVS 型 NoSQL って分類できるものかなと思います。
特徴としては、フラッシュストレージに対する書き込みのパフォーマンスに配慮されている点があるかなと思います。 さらなる詳細に関してはおそらく web 上に資料やベンチマーク結果などがシェアされていると思うのでそれらに譲ることにします。
mruby-rocksdb について
概要
RocksDB の mruby binding です。 リポジトリは以下の通り。
RocksDB が C++11 以降を要求することもあり C で書くのも面倒だな・・・と思ってしまったので C++11 以降前提で実装しています。 とは言っても半分くらいのメソッドは Ruby で実装してしまいました。だらしねぇな。
また mruby-k2hash と同様、サポートするメソッドは Ruby の DBM class ライクにしてあります。
使用例
mirb で触ってみるテストです。
$ ./bin/mirb mirb - Embeddable Interactive Ruby Shell # open > db = RocksDB.new("./rocksdb") => #<RocksDB:0x101501570> # store > db['key1'] = 'value1' => "value1" # fetch > db['key1'] => "value1" > db['key2'] = 'value2' => "value2" # each > db.each do |k,v|; puts "key: #{k}, value: #{v}"; end key: key1, value: value1 key: key2, value: value2 => #<RocksDB:0x101501570> # delete > db.delete('key2') => nil # etc ... > db.to_hash => {"key1"=>"value1"} > db.to_a => [["key1", "value1"]] > db.map do |k,v|; k + ' map to ' + v; end => ["key1 map to value1"]
mirb で触ってみるテストでした。
おわりに
次はもっと書いたこと無いタイプの mrbgem 書いてみたいものです。
文フリで配布するSF小説書いた
#bunfree 文ガクサークル大文妄、2017年11月23日の文学フリマ東京に、出ます。【ウ-77, 78】の合体劇場。ジャンルはSF、短編創作小説集、頒布価格は50円(予定)。
— えむばーど@文フリ東京【ウ-77,78】11/23 (@m_bird) 2017年11月15日
未来でもきっと僕らは、アイも変わらず生き続けてるんだって、そんな風に思うのだ。
こちらで配布される SF 小説集に拙作を寄稿しました。 イベント詳細はこちらになります。
モチーフにしたのは認知行動療法とルールベースのフィルタリング処理、そして昨今騒がれている Twitter の凍結騒ぎだったりします。 SF 小説なんて書いたのは人生初で、これらがうまく伝わるか、そもそも読者に伝わるものがあるのかが不安なところですが、もしご興味を持っていただけましたらお手にとってみていただけると幸いです。
なぜ小説を書いたのか
普段得られない体験をしたかったのと、自分が今に至るまでのモチベーションの源泉として何かを作りたいという気持ちが深く根ざしておりそれが(普段ブログに書くような)技術要素以外でも作用するか確認してみたかった次第です。 執筆完了した今の状態では、まぁそれなりに得られるものがあったかも・・・というくらいの温度感。
なにはともあれ
みんな今週 23 日木曜日は東京流通センターへ Go!
uniq を少し早く処理するツール "quniq" を作った
TLDR
重複行を除去する uniq コマンドを早く実行するツール "quniq" を Go で作ってみました。
自分が測った限りでは、他の重複除去を行なうワンライナーと比べて、処理に要する時間が少なくとも 1/3 程度になることが確認できました。
背景
みなさまご存知の通り、 uniq はソート済みの入力を受け付けて重複行を除いた出力を吐き出すツールです。 また -c オプションで重複件数も出力したりすることが可能です。 特に集計の前処理として余分な行を除外したり、アクセスログ中の特定要素のランキング化に利用されることが多いように感じます。
uniq はソート済みの入力を期待するためよく cat /path/to/file | sort | uniq のように sort した結果をパイプで渡すことが多いと思うのですが、入力のサイズが大きくなってくると sort に時間がかかるようになってきます。
そこで今回はより短い所要時間で重複行を除去したり件数カウントができるツール quniq を実装してみることにしました。
設計と実装
高速化のための方針は単純で、 sort を要求せずかつマルチスレッドで処理するようにするというものです。 これをシンプルに実現し、かつツールの利用を簡単にしたかったため、今回は Go で実装することにしました。
実装の概略図を示したものは以下のとおりです。
特徴的な点として、 goroutine を複数立てて各 goroutine で一旦入力を map に格納していることが上げられます。 goroutine ごとに個別の map を操作するためこの点では mutex など同期プリミティブは不要であり、また map の key として各入力行を利用するため重複行除去の効果が期待できます。 その後各 goroutine が処理した map を、最終的な結果を格納する map にマージします。 この map の操作は mutex で排他処理をしておきます。 その他、 入力データを格納する buffer は sync パッケージの Pool で管理し、メモリアロケーションの負荷軽減とコード上における goroutine 間 buffer 所有権の管理を行っております。
使い方
普通に go get してご利用ください
$ go get github.com/syucream/quniq
quniq は入力が sort 済であることを期待しないので、直接重複除去したい入力を渡してみてください。
$ cat /path/to/file | qunic -c
オプションとしては uniq における -c, -u, -d, -i っぽいものを提供する他、パフォーマンスに左右する -inbuf-weight, -max-workers を提供します。
最後に上げた 2 件のオプションは実行環境によって適した値が変わってくると思うので、いろいろお試しください。
評価
今回は筆者の手持ちの環境である MacBook Air Early 2014, Core i7 4650U 1.6GHz, Mem 8GB なマシンで測定を行ってみます。 また適当に重複がありそうな巨大なファイルを以下のようにして作成しています。本記事での測定では総計 4GB ほどの入力データを用意しました。
$ cat /dev/urandom | tr -dc '0-9' | fold -w 4 | head -n 100000000 > randlog_0 $ cp randlog_0 randlog_1 ...
sort | uniq の結果
まずは定番の sort | uniq した時の所要時間を、 bash の time コマンドで測定してみます。
ちなみにこんな記事を目にしたので LANG=C を一応与えてみています。
bash-3.2$ time cat randlog_* | LANG=C gsort | guniq > /dev/null real 15m39.761s user 12m59.955s sys 2m10.857s
sort には --parallel オプションが指定できるのでこれを明示的に与えてみると...少しだけ早くなるように見えます。
bash-3.2$ time cat randlog_* | LANG=C gsort --parallel 4 | guniq > /dev/null real 14m24.231s user 12m32.867s sys 2m7.031s
awk の結果
"uniq large file" とかでぐぐってると awk で処理するワンライナーが見つかったりします。
これは quniq のように map 的な構造で重複除去を行なう & 入力がソートされてなくても良い手法になります。
time の結果を見ると sort | uniq するより早く完了していますね。
bash-3.2$ time cat randlog_* | awk '!_[$0]++' > /dev/null real 11m13.350s user 10m59.538s sys 0m5.868s
sort -u の結果
重複除去だけなら sort コマンドの -u でも行えます。
一応こちらのパフォーマンスも測定してみましょう。
bash-3.2$ time cat randlog_* | LANG=C gsort -u > /dev/null real 6m4.100s user 5m46.810s sys 0m10.659s
--parallel を与えると？
bash-3.2$ time cat randlog_* | LANG=C gsort -u --parallel 4 > /dev/null real 5m56.870s user 5m40.977s sys 0m10.251s
sort -u はかなり早そうです！しかしこの場合は uniq -c のような件数取得が行えなくなるので uniq のユースケースをカバーしきれるわけではないですが・・・。
quniq の結果
最後に拙作ツール quniq の結果を貼ってみますと、、、 sort -u と比較しても約 6m -> 2m と、所要時間が 1/3 ほどになっていることがわかります。
sort | uniq と比べると約14m -> 2m と 1/7 くらいになっていますね！
bash-3.2$ time cat randlog_* | ./quniq --max-workers 4 > /dev/null real 1m45.362s user 4m29.294s sys 0m10.177s
おわりに
というわけで uniq を少し早く処理するツールを作ってみました。 分散処理基盤に突っ込んで力技で重複除去などしてもいいかも知れませんが、手軽に解決したい時の "苦肉"の策として quniq を使える余地はあるんじゃないかと思います。
