Gradle で “Failed to load native library ‘libnative-platform.so’ for Linux amd64.” と言われるときの対処

gradle build をして、次のようなエラーに遭遇した:

FAILURE: Build failed with an exception.

* What went wrong:
Failed to load native library 'libnative-platform.so' for Linux amd64.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

いかにも何か依存パッケージが足りていないようなエラーメッセージだ。検索してみると「libstdc++ をインストールすると解決するよ」という記事も実際に存在する。

僕も libstdc++ をインストールしてみたが、問題は解決しなかった。実際には ~/.gradleroot 権限でディレクトリが作られてしまっていたことが問題であった。単に ~/.gradle/* を削除して gradle build を実行しなおすことでビルドを実行できた。

わかってしまえば簡単な問題だけど、エラーメッセージが不親切だと時間を無駄にしてしまう事例だ。

ブログの移行 – 中止

インフラ寄りのソフトウェア技術者として、せめてブログくらいは自身でホストしようと思い、ブログの引越しをしました。とはいえ、作業自体はずいぶんと前に完了しており、すでにいくつか記事も公開しています。

新しいブログでも、どうぞよろしくお願いします 😀

舌の根も乾かぬうちに、新しいブログを閉鎖することにしました…すみません。

疑似科学

(以下、ポエム)

僕は割とインターネット大好きおじさんなんだけど、まだおじさんになる前、青年の頃はインターネットに夢を抱いていたものだ。誰もが自由に情報を摂取できて、誰もが自由に意見を公開できる…それって最高じゃない? 誰かと誰かが意見を戦わせ、しかも第三者がその議論を観測できる。そうであれば、時間が経過すれば「人類の総意」みたいなものができあがるのでは? 不毛な論争もない平和な世界、さいこーだ! やったぜ!

でも、実際はどうなんだろう。「人類の総意」みたいなものはできる気配もないし、むしろ人間の思考はインターネット登場後、さらにバラついたような気がする。

むかし、ディジタルディバイドという言葉が流行した。おじさんは知っている。これは電子機器を使いこなせる人とそうでない人では摂取できる情報の量が劇的に違うから、そこに情報格差がうまれるという意味であった。2017 年になって思うのは、電子機器を使いこなす技術より、情報処理する人間自身に格差があるのでは、ということだ。

たとえば、日本人の 90% がインターネットにアクセスできるこの時代に、なんで水素水なんか流行るんだろう。ホメオパシーなんか信じる人がいるのだろうか。

我ながら「信じる」という言葉はよく出てきたものだと思う。こういうのは、もはや信仰や宗教の世界だよなーと思う。

科学はホメオパシーを否定できない」という記事を読んだ。

「ホメオパシーは科学に基づいた説明もしているのだから、科学的批判を受け入れなければいけない」という主張は、あくまで科学を前提にした批判に過ぎないものです。なぜなら、彼らは「科学は間違っているが、科学でさえ支持していると言っただけ。本来の説明は別だ」言い逃れることができるからです。こうして、科学をいいとこ取りで好き放題に使い、批判されたら切り捨てられるというのは、疑似科学の特徴とも言えるでしょう。

まさに、その通りだ。

NATROM さんの著書は Amazon での 平均の レビューが芳しくないようだ。これは 1 (最低点) をつけている人間が多くいることが原因だ。一方で 5
(最高点) をつけている人間も相当な数いる。これはどう考えればいいのか。信仰を否定された人間は、否定する側の人間に対して冷静でいられないということだろう。やれやれ。

公開情報と公開討論による「人類の総意」は、人の信心のせいで後退してしまった。悲しい。本当に、悲しい。

AWS Certificate Manger へスイッチ

このブログでも何度か Let’s Encrypt について触れてきたけど、ここで AWS Certificate Switch にスイッチすることにした。

Let’s Encrypt の取り組みには強く共感するものの、ふたつ問題があった。

  • サービスの特性上、trial & error を繰り返すとアカウントをロックされる (SSL 証明書の自動更新のためのスクリプトをデバッグ中にロックされるのはちょっと…)
  • ワイルドカード証明書を利用できない

一方の AWS Certificate Manger だが、これは驚くほど簡単に設定できた。単に AWS コンソールでぽちぽちクリックして、ALB に「この証明書を使ってちょうだい」と設定するだけで設定が終わった。

そういうわけで、ようやく僕のブログも HTTPS でホストできるようになった。ワイルドカード証明書さまさまだ。

実は WordPress と縁を切ろうと思っており、ごにょごにょしていたんだけど、前述の通り Let’s Encrypt でアカウントをロックされたあたりで気持ちが萎えていたのであった。AWS にロックインされるのは好ましくはないけど、もはや仕事でも AWS にどっぷり浸かっているし、逃げられないところまで来てしまった気がする。そうであれば、逆にどんどん AWS を使い倒せるように自分を持っていく方がいいかもしれない。

Let’s Encrypt が証明書の更新時に “Could not connect to example.com” とエラーを返す場合の対処

mahata.org は Let’s Encrypt で SSL 証明書を作成/更新している。

Cron に仕込んでいた SSL 証明書の更新スクリプトが “Could not connect to mahata.org” というエラーメッセージで失敗していたので、少し調べてみた。全体のエラーメッセージは次の通りだ:

Failed authorization procedure. www.mahata.org (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to www.mahata.org, mahata.org (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to mahata.org

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: www.mahata.org
   Type:   connection
   Detail: Could not connect to www.mahata.org

   Domain: mahata.org
   Type:   connection
   Detail: Could not connect to mahata.org

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

Let’s Encrypt の更新スクリプトは GitHub に上げてある。これを何もオプションをつけずに実行するだけだ (注意: スクリプト先頭の環境変数は僕の環境固有のもの)。

少し調べてみたところ、Let’s Encrypt の認証サーバが mahata.org ドメインのバリデーションをするとき、80 番と 443 番ポートのどちらでバリデートしてもらうか選択できるようであった。公式のドキュメントには次のように書かれている:

To obtain a cert using a “standalone” webserver, you can use the standalone plugin by including certonly and –standalone on the command line. This plugin needs to bind to port 80 or 443 in order to perform domain validation, so you may need to stop your existing webserver. To control which port the plugin uses, include one of the options shown below on the command line.

  • –preferred-challenges http to use port 80
  • –preferred-challenges tls-sni to use port 443

僕は --preferred-challenges を指定せず、手を抜いて 80 番ポートを公開することで問題を解決した。

「続」ベンチャー企業で英語を公用語にするメリットとデメリット

前回の記事では「英語を公用語にするメリットは大きい」と書いた。この記事を書いてから、半年強が経過した。この考え方は改めたので、新しく記事を書くことにした。

結論から言うと、「英語を公用語にするデメリット 大きい」だ。社内コミュニケーションを慎重にデザインしない限り、日本で英語を公用語にするのは危険だ。

僕の勤務先で起こったことは、大まかに言えばこんな感じだ。

  1. 社内で日本人と非日本人でグループが分かれる
  2. 非日本人が社内で浮いた存在になる (社内の雑談は日本語が多いため)
  3. 週次の全社アナウンスが日本語と英語を交互に話す形式になる
  4. 社内チャットツール (= Slack) で日本語と英語が混ざるようになる
  5. 非日本人がリモートワークがちになる

僕が考えられる改善案は次の通りだ。

  1. 会社の公用語を明示的に英語にする (採用のとき、公用語で十分にコミュニケーションできない人間は落とす)
  2. リモートワークを不許可にする (もしくは制約をつける)

順番に深掘りしていこう。

会社の公用語を 明示的に 英語にする案

僕の勤務先では、なんとなく 英語が公用語だった。単に「日本語が話せない社員が多いから、ミーティングは英語でやりましょう」的なノリであった。

中途採用では、英語が不得意な日本人を採用することもあった。「英語でコミュニケーションが取れること」は募集要項にはなかった。個人としては優秀なのに、コミュニケーションに難があるため全社貢献できない人もいた。ミーティングでは、英語に堪能な人間 (もしくは英語ネイティブ) がワーッと話して、それが「全体の意見」として通ることもあった。

会社の公用語が明示的に英語であったなら、と思う。

僕たちは採用候補者が日本人であれば日本語で面接をしていたし、そうでなければ英語で面接をしていた。会社の公用語が明示的に英語であれば、面接も英語で行うだろう。それならば、採用される側も「英語」という共通言語が使えることが保証される。社内が「話せる言語」で分断されることもない。

反対に、英語を切り捨てて日本語で社内コミュニケーションを統一してもいい。その場合は、多くの「普通の」日本企業がしているように、日本語で募集要項を書いて日本語で面接をするだけだ。

「日本語と英語が混じっている」のがよくない。

リモートワークを不許可にする (もしくは制約をつける) 案

リモートワークは難しい制度だと思う。

適当にリモートワークの運用をはじめると、「リモートワークをする社員」と「リモートワークをしない社員」でグループが分かれてしまう。オフィスに来る社員同士は密にコミュニケーションをとる。よく顔を合わせる間柄だから当然だ。でも、オフィス内で話した内容がリモートの人間には伝えられるとは限らない。そうして、リモートワークをする社員と、そうでない社員の間に情報格差がうまれる。

オフィスの様子を感じられなくなったリモートの社員は、さらにオフィスから足が遠のくようになる。そして分断が深まる。もしリモートワークをする社員と、そうでない社員の間に言語の壁も存在するとしたら…? 壊滅的だ。

この問題を防ぎたければ、単にリモートワークを禁止すればいい。全員がオフィスで働けば、情報格差はうまれない。

もしリモートワークをどうしても導入したいのであれば、「全員がリモートワーク」であれば、どうだろうか? コミュニケーションが全てオンラインで行われれば、情報格差もうまれないし、誰かが疎外感を持つこともない。

とにかく、適当にリモートワークの運用をはじめるのはよくない。Basecamp や GitHub がリモートワークで仕事ができているのは、それなりの仕組みや哲学があるからだ。

まとめ

前回の記事の「英語を公用語にするメリットは大きい」という主張には無理があると感じている。

日本企業が英語を公用語にするのであれば、相応の仕組みを導入するべきだ。少なくとも次のふたつは必須だ。

  1. 「英語が公用語だ」と社内外に表明する。採用面接は英語で行い、英語に難がある場合は他に秀でているものがあっても基本的に採用しない。
  2. リモートワークは慎重に導入する。もし「コミュニケーションに難がある社員」がリモートがちになるなら、それは危険なサインだ。

余談

実はここで書いた「僕の勤務先」は、既に退職した会社だ。

もちろん、辞めた勤務先に砂をかけようとして書いたわけではない。日本でも「英語で仕事をする」ことは普通になりつつある。僕が無駄に踏んだ「英語で仕事をする」ことに関するトラップを、他の人はうまく避けられるように、ここに失敗談 (と、その振り返り) を残しておく次第だ。

`aws ecr get-login` のトラブルシュート

ECR サーバにログインするとき、 aws ecr get-login コマンドでログインに必要なコマンドを取得できる。単にこのコマンドの結果を eval すればログインが完了するので、通常は eval $(aws ecr get-login) とすればよい。

しかし、次のようなエラーに遭遇してしまった。

$ eval $(aws ecr get-login)
Flag --email has been deprecated, will be removed in 1.13.
error getting credentials - err: exit status 1, out: `2017-04-13T08:27:26Z [ERROR] docker-credential-ecr-login can only be used with Amazon EC2 Container Registry.
credentials not found in native keychain`

credentials not found in native keychain の意味がわからず、「キーチェーンなんて動いてないけど…」と時間を無駄に費やしてしまった。

今回のケースでは、~/.docker/config.json に次のような情報が詰まっていたことが問題であった (どのタイミングでこの情報が入ったのか不明だけど…)。

$ cat ~/.docker/config.json
{"credsStore":"ecr-login"}

これを削除して再度 eval $(aws ecr get-login) を実行することで、ECR にログインできた。