tokuhirom's blog

commons-math3 の BetaDistribution を利用する場合は rng をキャッシュする

commons-math3 の BetaDistribution を利用する場合、alpha/beta が変わるたびに new BetaDistribution( alpha, beta) とかしてはいけない。 new BetaDistribution(rng, alpha, beta, 1.0) は `new BetaDistribution(new Well19937c(), alpha, beta) ということになるからだ。

new Well19937c() は乱数生成系だが、この初期化処理は重いので、キャッシュしないと非常に処理が重くなる。

Created: 2018-04-10 01:59:37 +0000
Updated: 2018-04-10 01:59:37 +0000

nuxtjs で bootstrap 使いたい

nuxt.js で twitter bootstrap を有効にする方法 を参考にやれば良い。

npm i bootstrap-vue --save

して、nuxt.config.js に以下を追加。

  modules: [
Created: 2018-03-27 02:47:07 +0000
Updated: 2018-03-27 02:47:07 +0000

Host の canonical name を取得するワンライナー

python -c "import socket; import sys; print(socket.getaddrinfo(sys.argv[1], 0, socket.AF_INET, 0, socket.IPPROTO_TCP, socket.AI_CANONNAME)[0][3])" YOUR_HOST_NAME
Created: 2018-03-06 04:19:31 +0000
Updated: 2018-03-06 04:19:31 +0000

spring boot2 で redis 使った session を使う方法

Created: 2018-03-05 04:57:06 +0000
Updated: 2018-03-05 04:57:06 +0000

lombok 1.16.20 以後で @lombok.Value された値を Jackson で deserialize しようとするとエラーになる

@lombok.Value された bean に対して ObjectMapper で deserialize した場合、以下のようなエラーがある。

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `MyGreatResponse` (no Creators, like default construct, exist): cannot deserialize from Object value (no delegate- or property-based Creator) at [Source: (String)"{"FOO":"BAR"}"; line: 1, column: 2]

これは lombok 1.16.20 で以下の変更が入ったためである。

BREAKING CHANGE: lombok config key lombok.anyConstructor.suppressConstructorProperties is now deprecated and defaults to true, that is, by default lombok no longer automatically generates @ConstructorProperties annotations. New config key lombok.anyConstructor.addConstructorProperties now exists; set it to true if you want the old behavior. Oracle more or less broke this annotation with the release of JDK9, necessitating this breaking change.

lombok 1.16.20 で、immutable 厨したいときは lombok.config に以下のように記述すべし。

lombok.anyConstructor.addConstructorProperties= true
Created: 2018-03-01 10:32:41 +0000
Updated: 2018-03-01 10:32:41 +0000

spring boot 2RC2 で prometheus を actuator で export させるやり方


を build.gradle に追加

      enabled: true
        include: info,health,prometheus


Created: 2018-02-25 14:13:43 +0000
Updated: 2018-02-25 14:13:43 +0000

Ruby の deserializer の速度比較

ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-darwin16]

require 'msgpack'
require 'benchmark'
require 'json'

class LTSV
  def self.parse(text)
    r = {}
    text.split("\t").each do |pair|
      key, value = pair.split(":", 2)
      r[key] = value

  def self.generate(data) {|k,v| k+":"+v }.join("\t")

src = Hash[(1..1000).map{|i| i.to_s}.each_slice(2).to_a]

msgpk = src.to_msgpack
json = JSON.generate(src)
ltsv = LTSV.generate(src)

iterations = 100_000

puts "msgpk=#{msgpk.length} bytes"
puts "json=#{json.length} bytes"
puts "ltsv=#{ltsv.length} bytes"
puts "" do |x|'msgpack') do
    iterations.times { MessagePack.unpack(msgpk) }
  end'json') do
    iterations.times { JSON.parse(json) }
  end'ltsv') do
    iterations.times { LTSV.parse(ltsv) }
msgpk=3896 bytes
json=5894 bytes
ltsv=3892 bytes

                 user     system      total        real
msgpack     11.390000   0.050000  11.440000 ( 11.509034)
json        31.690000   0.140000  31.830000 ( 32.131092)
ltsv        36.870000   0.270000  37.140000 ( 37.986320)


Created: 2018-01-31 10:16:43 +0000
Updated: 2018-01-31 10:16:43 +0000

Capturing grafana dashboard and post it to LINE group using LINE Notify

I want to post a screenshot of the Grafana dashboard to LINE Notify.

Grafana distribution includes PhantomJS( Alerting feature uses PhantomJS. ).

Then, you can take a snapshot using curl command.

You need to rewrite Grafana dashboard URL. Insert /render prefix for your dashboard URL. For example, when your dashboard URL is, PhantomJS URL is

If you want to hide a header, add ?kiosk query parameter for the URL.

Grafana supports API keys and Basic Auth. With curl, you can call it like e.g. curl -u 'YOUR_EMAIL:YOUR_PASSWORD' GRAFANA_URL.

It's summarized as follows:

curl  -u 'YOUR_EMAIL:YOUR_PASSWORD' -o img.png

Post to LINE Notify

You can upload dashboard image to LINE Notify using curl command.

curl -X POST 
       -H 'Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN' 
       -F 'message=test' 
       -F 'imageFile=@img.jpg'

See for more details.


Created: 2018-01-05 14:19:48 +0000
Updated: 2018-01-05 14:19:48 +0000

rust のベンチマーク取る時は `cargo build --release` しなくてはならない

name = "hello_world"
version = "0.1.0"
authors = ["Your Name <>"]

futures = "0.1.14"
hyper = "0.11"

extern crate hyper;
extern crate futures;
use futures::future::Future;

use hyper::header::ContentLength;
use hyper::server::{Http, Request, Response, Service};

struct HelloWorld;
const PHRASE: &'static str = "Hello, World!";

impl Service for HelloWorld {
    type Request = Request;
    type Response = Response;
    type Error = hyper::Error;

    type Future = Box<Future<Item=Self::Response, Error=Self::Error>>;

    fn call(&self, _req: Request) -> Self::Future {
                    .with_header(ContentLength(PHRASE.len() as u64))

fn main() {
    let addr = "".parse().unwrap();
    let server = Http::new().bind(&addr, || Ok(HelloWorld)).unwrap();;

のようなシンプルな hyper の本家サイトから取ってきたコードを実行した場合について考える。

普通に cargo build すると依存ライブラリ含めてデバッグビルドされるのでとにかく遅い。


[tokuhirom@dev2 httpd]$ wrk --latency http://localhost:3000
Running 10s test @ http://localhost:3000
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.65ms    1.03ms  21.86ms   89.72%
    Req/Sec     3.16k   718.96     4.04k    61.50%
  Latency Distribution
     50%    1.33ms
     75%    1.61ms
     90%    2.70ms
     99%    5.65ms
  63230 requests in 10.05s, 5.37MB read
Requests/sec:   6293.04
Transfer/sec:    546.95KB

cargo build --release した Release ビルドだと以下のようになり、めちゃくちゃ差が出る。

[tokuhirom@dev2 httpd]$ wrk --latency http://localhost:3000
Running 10s test @ http://localhost:3000
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   353.40us  428.95us  12.69ms   98.36%
    Req/Sec    14.56k     4.55k   20.66k    45.77%
  Latency Distribution
     50%  249.00us
     75%  393.00us
     90%  538.00us
     99%    0.94ms
  291181 requests in 10.10s, 24.71MB read
Requests/sec:  28828.72
Transfer/sec:      2.45MB

C や C++ の場合には、ライブラリコードは yum で入れたものとかを使う事が多く、そこまでアプリケーションコードが debug build かどうかに神経質にならなくてもわりとそれなりにパフォーマンスに差は出にくいが、cargo の場合、依存ライブラリも debug build してるっぽいんでめっちゃ差がでるっぽさ。

ちなみに rust の http server 実装は実質的に hyper 一択かつ、hyper は express-worker 的な機構もないので自前でthread をなんとかしない限り CPU を使い切るのは難しそう。

Created: 2017-12-23 14:17:14 +0000
Updated: 2017-12-23 14:17:14 +0000 するよりも networkaddress.cache.ttl 使おう

jvm はデフォルトで DNS cache が 30sec かかっている。これはやや長過ぎると web service では判断されるケースが多い。 そこで、通常ではこれを短く設定して本番環境のデプロイをしている場合が多い。 手元のあるコードでは が指定されていたが、現在では -Dnetworkaddress.cache.ttl=1 を利用すべき。 このページが挙動について詳しい。 基本的に は歴史的経緯で指定されている名称であり、現代では networkaddress.cache.ttl を利用する方が良い。

Created: 2017-12-01 07:26:03 +0000
Updated: 2017-12-01 07:26:03 +0000

tableau server の "Query View Image" API のデフォルトキャッシュ期間は長い

If you make multiple requests for an image, subsequent calls return a cached version of the image. This means that the returned image might not include the latest changes to the view. To decrease the amount of time that an image is cached, use tabadmin to reduce the value of the vizportal.rest_api.view_image.max_age setting. For more information, see tabadmin set options in the Tableau Server help.

で、これの default value は 720min=12hours なので、とにかくキャッシュが長い。

なんか cache 破棄させるほうほうもありそうなものだが、いまいちよくわからないので、とりあえずデフォルトのキャッシュ時間を短くして運用しましょうかというよう話になった。

Created: 2017-11-30 09:59:41 +0000
Updated: 2017-11-30 09:59:41 +0000

homebrew との付き合い方を見直す 2017

  • 最近の homebrew では、OS に含まれるコマンドも利用可能なので積極的に利用していく
    • なんとかenv 系の管理コマンドは、LL で本格的に開發している場合には便利だが、最近はバージョンを固定して開發するようなことが減ってるのと JVM 言語メインなので気にしないで brew install perl などする。
    • system perl 等にアプデさせると、
  • 古いバージョンのバイナリは brew cleanup で消せる
  • 最近は vim の拡張をゴリゴリ入れたりしてないんで、vim も OS 標準のものでいい
    • たぶん、lua を使うために brew で入れるようにしてたのだが、lua が必要になる理由の根源であった neonantoka シリーズを最近使ってないんで、もはや system vim で良い。
  • brew cask は積極的に利用している。

というわけで現在利用してるのは以下。 * ant(歴史的事情によりデプロイツールが ant に依存しており、動作確認のために手元に入れておく必要がある) * bvi(vi binding で利用できるバイナリエディタ。バイナリの中身をサッと見るときに便利) * cheat(ちょっとしたメモ代わりに使ってて便利) * coreutils(GNU コマンドに慣れすぎてるんで。。) * go * hub(github からの clone とかでたま〜につかう) * jq(json を prettify する用途ぐらいにしか使ってないけど) * maven * ngrep(packet を capture するときにめっちゃ使ってる) * node * peco * perl * protobuf * python3 * redis * rename * ruby * scala * sbt * tcping * tcptraceroute * thesilversearcher * thrift * sqlite * tree * tmux * w3m * wget(ファイルをダウンロードする時は wget のほうが楽な気がしてる) * wrk(最近は ab よりこっちメイン)

その他、brew cask で入れているものが以下。 * alfred(なんとなく継続しているが、真面目に設定してないので quick silver との違いは screen lock をショートカットキーでできることぐらい) * evernote(本来は web ui で十分という気もするが、web ui の出来が微妙なので一応入れてる) * firefox(最近アプデされたこともあり、久々に使ってみている) * filezilla(たまーに使う) * freemind(たまーに考えをまとめるときに使う) * google-chrome * google-japanese-ime * iterm2(選択範囲が iterm2 のほうが好み、という理由だけでなんとなく使い続けている) * java * java8(9 だと lombok が発狂するので。。) * karabiner(英かなちゃんと動くようになってよかったね、という感じ) * kindle * skitch * skype(最近は使ってない) * vagrant(最近は社内IaaS使う事が多くて、使ってない) * virtualbox * visualvm

Created: 2017-11-23 14:05:47 +0000
Updated: 2017-11-23 14:05:47 +0000

spring boot 2 にしたら `springBoot { executable = true }` が通らない

bootJar {


Created: 2017-11-21 02:55:57 +0000
Updated: 2017-11-21 02:55:57 +0000

spring boot 2 にしたら InvalidConfigurationPropertyNameException が発生するとき

spring boot 2 だと @ConfigurationProperties("fooBar") みたいなのを指定することができなくなる。 @ConfigurationProperties("foo-bar") なら通るので、変更必要。

Created: 2017-11-21 02:48:47 +0000
Updated: 2017-11-21 02:48:47 +0000

spring boot2 にしたら `bootRun { systemProperty '', 'local' } }` が動かないよって場合

spring-boot 2 では以下の書き方は許容されなくなった。

bootRun {
  systemProperty '', 'local'


bootRun {
    execSpec {
        systemProperty '', 'bar'
} ref.

Created: 2017-11-21 02:22:37 +0000
Updated: 2017-11-21 02:22:37 +0000

/dev/urandom を fork して読み込んでもいいんかって話

tokuhirom /dev/urandom って開いたまま fork して読み込んだらまずいんですっけ?
親 process で /dev/urandom 開いたまま、fork してそれぞれの子プロセスで読んだら同じの取れる?
kazuho 同じの取れないですね
つまり、open file descriptionは同一なので、readしたらその中にあるfile offsetは進むので (edited)
Created: 2017-11-13 03:32:48 +0000
Updated: 2017-11-13 03:32:48 +0000

spring-boot-actuator 使いたいけど spring-webmvc はいらないよってケース

management.port のほうは開きたいけど server.port のほうは開きたくないってときは

server.port: -1


Created: 2017-11-08 05:39:24 +0000
Updated: 2017-11-08 05:39:24 +0000

Perl Web application に於ける Data::UUID の利用について


本文書では Perl における Data::UUID での UUID 生成について議論する。 特に、Linux 環境に於ける Data::UUID->new->create_str の挙動について考察する。

Data::UUID について

Data::UUID は Alexander Golomshtok 氏が開発したモジュールで、メンテナンスされなくなった結果として、現在は rjbs 氏がパッチの適用などの消極的なメンテナンスを実施している。


This module provides a framework for generating v3 UUIDs

しかし、期待に反して、実際にはほとんどのユーザーは v1 UUID を生成している。 Data::UUID->new->create_str を利用するのが一般的なケースであるためだ。

UUIDv1 の構造について

timestamp 60bit, clock sequence 16bit, node 48bit


  UUID                   = time-low "-" time-mid "-"
                           time-high-and-version "-"
                           clock-seq-low "-" node



/tmp/.UUID_NODEID について

Data::UUID->new で nodeid は生成されます。

/tmp/.UUID_NODEID が存在しない場合、nodeid は md5(gettimeofday(), gethostname()) で生成され、 /tmp/.UUID_NODEID に保存されます。 /tmp/.UUID_NODEID が存在する場合、slurp(/tmp/.UUID_NODEID) + $$ の結果が nodeid となります。

このロジックにより、二回目以後の nodeid 生成は process ごとに独立した nodeid になります。

/tmp/.UUID_STATE について

/tmp/.UUID_STATE に clockseq などが保存されます。これにより、プロセスが再起動した場合などにも動作を続けることができる、という設計に見えます。


  • UUID 生成時に、前回保存時刻より 10秒おきに保存されます。
  • Data::UUID#DESTROY のコール時にも保存されます。


Data::UUID を web application で利用した場合に発生する可能性がある問題について

以下では pre-fork モデルのウェブアプリケーションで Data::UUID を利用した場合に発生し得る問題について議論する。 (Starlet, Starman などの web server が pre-forking モデルです)


UUID v1 の特性上、NTP などにより時刻が巻き戻った場合、重複した uuid が発行される可能性があります。 時刻の巻き戻りが発生した場合に発生する重複が許容出来ない場合、Data::UUID の利用は避けるべきでしょう。

clock sequence を初期化するタイミングで初期値を random にするなどの軽減策は取られているものの、問題が発生する可能性はそこそこあります。

local 攻撃への脆弱性

  • /tmp/.UUID_NODEID
  • /tmp/.UUID_STATE

の2つのファイルが生成されるが、tmp directory に生成されるために、悪意のあるユーザーが設置することが可能。

nodeid の生成ロジックの問題

/tmp/.UUID_NODEID がある場合にだけ pid が nodeid に考慮される。 このため、Data::UUID を一度も利用したことがない新しいサーバーの初回起動時などに nodeid が同一の Data::UUID インスタンスを持つ process が複数発生する可能性がある。

AWS などで頻繁にインスタンスの作り直しを実施している場合、この問題が発生しやすいと考えられる。

Data::UUID->new() を fork 前に呼んではいけない

Data::UUID->new の中で nodeid を初期化しているので、fork 前に呼ぶと同一 nodeid ですべての子プロセスで利用されることになり、相手は死ぬ。

srand の呼び出し

Data::UUID->new の中で、現在時刻をシードに srand() を呼び出し、それ以後は rand() をコールしている。。 現在時刻は srand のソースとして使うにはよろしくないので、これは、他の rand() を利用している XS module に悪影響を与えている可能性がある。 (Perl 本体は drand48() を利用しているので問題ない)


完全に random な UUID 生成方法である UUID v4 を利用しとくか、sfujiwara さんが作ってたみたいなやつ使うのがいいんじゃないすかね。 ただし、UUID v4 の生成系を利用する場合、fork 時の seed 最初期化などについては考慮を忘れずに。

Created: 2017-11-08 04:34:44 +0000
Updated: 2017-11-08 04:34:44 +0000

spring-boot で tomcat の設定するときのやり方

  use-forwarded-headers: true
      directory: /PATH/TO/logs/tomcat/
      pattern: common
      enabled: true
      rotate: true
      # It's required when using remote-ip-header.
      request-attributes-enabled: true
    remote-ip-header: x-forwarded-for
    protocol-header: x-forwarded-proto

なんかこんな感じ? request-attributes-enabled を設定するの忘れると RemoteIpValve で設定した値が AccessLogValve で拾われないので死ぬ。

Created: 2017-11-02 08:11:47 +0000
Updated: 2017-11-02 08:11:47 +0000

spring-boot で ConfigurationProperties に ZonedDateTime を書く場合のやり方

application.yml に日付データを入れて ZonedDateTime にマッピングしたい、みたいな場合。 ↑こちらのブログに掲載されているように以下のようなクラスをおけばよい。

public class ConversionServiceConfiguration {
    public ConversionService conversionService() {
        FormattingConversionServiceFactoryBean factory = new FormattingConversionServiceFactoryBean();
        DateTimeFormatterRegistrar registrar = new DateTimeFormatterRegistrar();
        return factory.getObject();


追記: のようなやり方もあるとのこと。

Created: 2017-11-01 04:19:13 +0000
Updated: 2017-11-01 04:19:13 +0000

apscheduler で add_job するときは misfire_grace_time の指定が必須

python で job の定期実行を実装するには apscheduler が便利だが、misfiregracetime の指定をしないと job が実行されないことがあるので注意が必要。 指定していないと以下のようなエラーに悩まされることになる。

Run time of job "send_menu (trigger: cron[day_of_week='mon-fri', hour='11'], next run at: 2016-05-31 11:00:00 CEST)" was missed by 0:00:01.51075

これは、予定された実行時間よりも scheduler の起動が遅れてしまったから実行しないようにしましたよ、というメッセージである。 デフォルトでは 1 秒以上実行が遅延した場合、ジョブは実行されない。

しかし実際、1.5秒遅れても実行はしてほしいわけなので以下のように misfiregracetime を指定し、delay の許容時間を指定する方が良い。

scheduler.add_job(func, trigger='cron', hour='10,11,12', misfire_grace_time=60*60)
Created: 2017-10-28 08:39:17 +0000
Updated: 2017-10-28 08:39:17 +0000
Next page