その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

stringsを使ってどのgoのバージョンでコンパイルしたバイナリかをサクッと取得する

How to find out which Go version built your binary | Dave Cheney

stringsを使わないちゃんとしたやり方はこちら．


雑に取るならstringsコマンドを使うとそれっぽいのが取れます．

$ strings main | grep go1[.]
stack=[cgocheckdebugcpugo1.11.1runnableruntime.scavengeunknown( (forced) -> node= blocked= defersc= in use)

なるほど，これはgo1.11.1でコンパイルされたバイナリ．非常にスッキリしています．

$ strings main | grep go1[.]
, not 390625<-chanArabicAugustBrahmiCarianChakmaCommonCopticFridayGOROOTGothicHangulHatranHebrewHyphenKaithiKhojkiLepchaLycianLydianMondayRejangSCHED SundaySyriacTai_LeTangutTeluguThaana[]bytechan<-efenceerrno go1.11objectpopcntselectstringstructsweep uint16uint32uint64 (scan  (scan) MB in  Value> dying= locks= m->g0= nmsys= s=nil
/tmp/test/bin/go1.11
...

これは1.11でコンパイルされている様子．1.11.1と比べてごちゃごちゃ度が増していて，かつパス情報が下にずらずらと列挙されていますね．

$ strings main | grep go1[.]
stack=[cgocheckgo1.10.4runnableruntime.scavengeunknown( (forced) -> node= blocked= defersc= in use)
/tmp/test/bin/go1.10.4
...
Go cmd/compile go1.10.4

1.10.4です．1.11と比較してスッキリとした風味．パス情報が列挙されており，かつその下にはGo cmd/compile go1.10.4という非常にわかりやすい文字列が入っています．親切！

$ strings main | grep go1[.]
value=cs     float32float64fs     gctracego1.9.7gs     invalidpanic: r10    r11    r12    r13    r14    r15    r8     r9     rax    rbp    rbx    rcx    rdi    rdx    rflags rip    rsi    rsp    runningsyscalluintptrunknownwaiting goal
/Users/moznion/tmp/test/bin/go1.9.7/src/fmt/scan.go
...
Go cmd/compile go1.9.7

1.9.7も1.10.4と似ていますね．Go cmd/compileが付いていて良い時代．

$ strings main | grep go1[.]
value=cs     float32float64fs     gctracego1.8.7gs     invalidpanic: r10    r11    r12    r13    r14    r15    r8     r9     rax    rbp    rbx    rcx    rdi    rdx    reflectrflags rip    rsi    rsp    runningruntimesyscalluintptrunknownwaiting goal
/Users/moznion/tmp/test/bin/go1.8.7/src/fmt/doc.go
...

1.8.7のようです．Go cmd/compileが無いですね．つまりこのマーカーは1.9から1.10.xまでの短い命だったのですね……


というわけでサクッと取れて便利でした．

Released lua-benchmarker

I've released lua-benchmarker that is a benchmarker for lua code. This benchmarker is for taking microbenchmark.

github.com

This library is available on luarocks. You can install this by luarocks install benchmarker.

luarocks.org

For example, write a benchmark code like following:

local benchmarker = require 'benchmarker'

benchmarker.new({
    ["insert append"] = function ()
        local arr = {}
        for i=1,1000 do
            table.insert(arr, i)
        end
    end,
    ["index append"] = function ()
        local arr = {}
        for i=1,1000 do
            arr[i] = i
        end
    end,
}):warmup(10):run_within_time(1):timethese():cmpthese()

then execute this code, the result is the following:

starting warming up: 10

Score:

index append:  1 wallclock secs ( 1.05 usr +  0.00 sys =  1.05 CPU) @ 51124.51/s (n=53695)
insert append:  1 wallclock secs ( 1.06 usr +  0.00 sys =  1.06 CPU) @ 9185.70/s (n=9760)

Comparison chart:

                    Rate  index append  insert append
   index append  51125/s            --           457%
  insert append   9186/s          -82%             --

Yes, this output format is taken from Benchmark.pm. This benchmarker is inspired by Benchmark.pm and tokuhirom/nanobench.

NOTE: This utility supports multi-platform (i.e. Windows is also supported!!).

Enjoy.

Elasticsearchに実際に書き込むテストなんかで「indexへの反映に時間がかかって困る〜〜」って時

Elasticsearchに実際に書き込む系のテストをするとき，例えば「fixtureを作ってindexしてクエリ打ってちゃんと結果が取れるかどうか」みたいなことをやると思うんですが，fixtureをindexする際にそのデータがindexに反映されるまでにrefresh_intervalぶんの時間がかかってつらい！！！　というときにどうするかという話です．

Plan A. refresh_interval をめっちゃ短くする

要はrefresh_intervalがめっちゃ短ければ解決する（こともある）話なのでそれをやるという方法．上記のtweetで「1000ms」とか言ってるのはあくまでデフォルト値なので，それをカスタムしてやると良いという話です．

{
  "settings": {
    ...
    "refresh_interval": "1ms"
  }
}

などとしてやればindexへのdataの反映周期が1msecになるのでまあ充分でしょう，という割り切った感じです．テスト用途であればほぼ多くの場合はこれでも動作すると思います．コード自体に手を入れる必要がないのは良さそう．
が，間違えてもproduction環境に入れてはならない設定なのでindex templateを別個に管理する必要が出てくるでしょう．

Plan B. index refresh APIを叩く

www.elastic.co

fixtureを投入してから明示的にindex refresh APIを叩くという方法．叩くとデータが即座に近くindexに反映されるようになるので用途としてはマッチすると思います．これであればproductionのindex templateをそのまま流用できるので便利ですが，まいどまいどrefresh APIを叩くコードを挟まなければならないので，そこは何らかのtest utilityみたいなものでカバーするなどといった工夫が必要そうです．


Plan C. ?refreshをクエリに付ける

www.elastic.co

更新系のクエリを発行する際に?refreshというクエリパラメータをつけると，こちらも即座に近くindexにデータが反映されるようです．お手軽！



他にもあるかもですが，用途と場合に応じたものを使うと良いと思います．

テストが速くなってよかった！

Released lua-cputime

I had released lua-cputime.

github.com

This package also had been shipped to luarocks.

luarocks.org

This library provides functions to measure the CPU time (i.e. user time and system time). The lua runtime doesn't support such functions, so this library bridges to native C's sys/time.h and sys/resource.h and expose getrusage() function as get_process_cputime(), get_children_process_cputime() and get_thread_cputime() *1.

As you can see, this library doesn't support the Windows environment because it associate to sys/time.h and sys/resource.h. I have a will to support the Windows, but I'm not familiar with that. I'm happy if a patch is sent.



[following description is outdated; the implementation has been changed]

This library provides a function to measure the CPU time (i.e. utime, stime, cutime and cstime). The lua runtime doesn't support such function, so this library bridges to native C's sys/times.h and expose times() function as get_cputime().
As you can see, this library doesn't support the Windows environment because it bridges sys/times.h. I have a will to support the Windows, but I'm not familiar with that. I'm happy if a patch is sent.

*1:`get_thread_cputime()` is only supported by Linux

Released lua-url-encode

I had released lua-url-encode.

github.com

And I also had shipped that to luarocks. You can try to install this with luarocks install urlencode.

luarocks.org

This package is a URL encoder/decoder library for lua that is written in C (with lua's native extension mechanism).The library aims (and realized) to be a faster implementation of URL encoding and decoding:

  • encoding is about 64 times faster than pure lua implementation
  • decoding is about 39 times faster than pure lua implementation


Note: This library is a ported implementation from p5-url-encode-xs.

#builderscon 2018 tokyoに参加しました & 話してきました

builderscon.io

builderscon 2018 tokyoで「Java Cardの世界」というタイトルで話してきました．発表資料は以下のとおりです．

喋りたいトピックはJava Card以外にも様々あったのですが，「知らなかった、を聞く」というカンファレンスのテーマを鑑みた結果，あまり一般には知られていなさそうな *1，しかし身の回りを確かに支えている技術についてお伝えしたいと思い至り今回のような発表をした次第です．この発表で少しでも生活が豊かになってもらえれば望外の喜びであります．

さてこの発表はありがたくもベストスピーカー賞第1位を頂戴しまして，感激の極みであります．本当に嬉しい！！！　もちろんこの発表は僕個人の力のみで成し遂げたものではなく，所属しているソラコムの同僚の多大なる協力があって達成したものです．特にJava Cardの偉大な知識を授けてくれたolivier，yaman，kennyには本当に感謝したいと思います．ありがとうございます！！！

副賞としてなんかすげえ量のガジェットがやってくる予定なので向こう1年くらい遊べるんじゃないでしょうか．中でも「マウス自作セット」という文字が僕の心を掴んで離しません！　作ったものについては色々このブログとかに書いていきたいですね．


[追記]

ついにガジェットが来ました！！！！　すごい！！！！！！
スポンサーのGMOペパボの皆様をはじめまして関係者の皆様本当にありがとうございます！！！！！

最高！！！！！！！！！！！！！！

f:id:moznion:20180910112011j:plain

これは同僚のtomoに撮影してもらった目録の写真です！！！

[追記ここまで]


さて，参加したセッションの中でも印象的だった発表について記したいと思います．

産業でガチ利用されるRaspberry Piの話 - @kazuphさん

builderscon.io

本当に身の回りで見かけるようになった，ともすればここ最近では一番身近なコンピュータである可能性があるRaspberry Piを産業利用される話でした．発表中，「BluetoothのIoTゲートウェイなー！！！　本当に難しいんだよな！！！！！」という共感が生まれ，非常に面白い発表でした．
ansibleのようなweb app的な文脈で多く使われてきた技術がIoT分野でも利用されている事例を聞いたときは，いままで隔たりのあった技術間の融合というか，汽水域のようなものができてきているように感じ，非常に興味深かったです．これは素晴らしいことだと思います．

カクヨムでの縦組み表示の実装と、縦書きWebの将来に向けて - @nanto_viさん

builderscon.io

縦書きWebという特別な環境における開発の話が聞けて貴重でした．今まで縦書きWebの開発をやったことがなかったので……
「やっぱりブラウザのバグとか結構踏むんだな〜大変そう，うわっすげえ壊れ方してる！」みたいな感じで拝見していたのですが，しかしそういった問題に対して適切にworkaroundを入れていく，そして適切にブラウザ本体に対してバグレポートを送る，といったことを淡々とこなされており，そうした姿勢が非常に尊く大変良かったです．

実録！ある担当者がみた「謎ガジェット」開発１年史 - @uzullaさん

builderscon.io

これめっちゃ良かった，電子名札ガジェットのプロトタイプ作成から量産するという無茶ストーリーを発表されており，圧巻です．ガジェットを200個作るというのはそれはそれはすごいことなのです．明らかに個人でやることではない！！！！！
これは動画が公開されたら絶対見たほうが良いと思います．最高．

Jepsen 10 - @aphyrさん

builderscon.io

ウオー，俺はこれが見たかったんだよ！！！！！！！！！！　分散システム・DBを調べたり使ったりする時に，ほぼ必ずと言っても良いほど参照することになるJepsen testの著者の方の発表です．このブログは真に最高なので，読んだことがない方はぜひ読むと良いと思います． https://aphyr.com/
本当に最高で，分散システムが勢い良くどんどん壊れていく．ネットワークの物理的分断，タイムアウト，魔のタイミングでのノードの立ち上げ，入力する時刻を揺らすなどなど様々な破壊シナリオが紹介されていてめちゃめちゃに面白い．発表中の「分散ロックできるっていうのはだいたい嘘です」という言葉に説得力があり，大変に良かった．
発表後にRedis Sentinel/Clusterの質問や，InfluxDBの分散エディションについての話をできたのも良かった……

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ - @aerealさん

builderscon.io

いつもお世話になっております (このブログとか)．数万規模のSSL/TLS証明書を管理しなくてはならないというなかなかタフかつ珍しい要件の話を聞けて非常に楽しかったです．各コンポーネントの責務を非常にミニマルかつ明確にされており (つまり責務の境界が明確化されている)，それぞれが正しく協調動作している点に非常に美しさと正しさを感じました．また「AWS Step Functionsよさそう，使ってみたい」とも思いました．

その他雑感

今年はspeakers dinnerという新たな取り組みが行われており，これも非常に面白かったです．懇親会とはまた違った感じで，ゆるーく知らない人 (しかしおそらく距離は近いであろう人) と話したり意見交換したりできる場というのはなかなか新鮮で良かったです．ただ本会の前に開催されるため，そこでうっかり話しすぎてしまい，逆に懇親会で無口になるという珍事が発生しました．ハハハ．

ところで今回はafter partyに参加できなかった，できなかったのです．なぜか？　それは僕がチケットを買い忘れたからなんですけど……これにはへこみました……まいった……
だもんで「とりあえずこれ買っておけば全部OKチケットx万円！！！！！！！！」みたいなチケットが出ると嬉しいですね！

今年は非常に印象的なカンファレンスになりました，スタッフをはじめ皆さん本当にありがとうございました．
また来年お会いしましょう，お元気で！！

*1:事実僕もやるまで知らなかった