Posts

(この記事は Why you can have millions of Goroutines but only thousands of Java Threads の翻訳です) 経験のあるエンジニアならば JVM 言語で次のようなエラーを見たことがあるでしょう。 [error] (run-main-0) java.lang.OutOfMemoryError: unable to create native thread: [error] java.lang.OutOfMemoryError: unable to create native thread: [error] at java.base/java.lang.Thread.start0(Native Method) [error] at java.base/java.lang.Thread.start(Thread.java:813) ... [error] at java.base/java.lang.Thread.run(Thread.java:844) OutOfMemory …スレッド作成の失敗。Linux が動いている私のノート PC では、だいたい 11,500 スレッドを作成した辺りでこのエラーが発生します。 Go で無限に sleep する Goroutine を作成すると、これとは大きく違う結果になります。私のノート PC では 70,000,000 の Goroutine を作れましたが、飽きたのでそこでやめてしまいました。なぜ Goroutine はスレッドよりもたくさん作れるのでしょう? この答えを探るためには OS を理解する必要があります。また、これは学術的な問題ではなく、実際に使われるソフトウェアをデザインするための問題です。私は本番環境で JVM スレッドの限界にぶつかった経験が何度もあります。問題のあるコードがスレッドを解放させ損ねたこともあるし、単にエンジニアが JVM スレッドの限界について認知していなかったこともあります。 [Read More]

CircleCI に導入された circleci コマンドでローカルでも CircleCI の挙動を確認できるようになった。 …というのは嘘である。 気づいただけで、ふたつ不満がある。たとえば CircleCI の cron は、システムレベルの cron がサポートする */x (x: 整数) のような記法をサポートしていない。つまり、5分おきにジョブを走らせたいときに */5 * * * * と 書けない 。かわりに 5,10,15,20,25,30,35,40,45,50,55 * * * * と書かなければならない。しかし、この問題は circleci コマンドの文法チェックでは検知できない。わたしは、これをリモートに push したあとで「うーん、動かないなぁ」と思いながら色々とぐぐって問題を発見した。つらい。 また、ローカル環境で次のように .circleci/config.yml を書くと Error: error authentication with ECR: AWS Credentials not found と怒られる。 version: 2 jobs: build: docker: - image: 00000000000.dkr.ecr.ap-northeast-1.amazonaws.com/my-image:latest aws_auth: aws_access_key_id: $AWS_ACCESS_KEY_ID aws_secret_access_key: $AWS_SECRET_ACCESS steps: - run: name: Greeting command: echo Hello, world. [Read More]

日本語のブログを広告のないスペースで書いていきたいと思いたち、GitLab にたどり着きました。GitHub はすでに英語の記事を書くために使っていたので。言語が混ざるのはよくないと思っている派です。

なお、「広告のある場所で記事を書くと想いがゆがむ」と考えるにいたった経緯についてはリンク先の記事をご参照ください。

• 東浩紀さんが白票を表明してカウンター運動に失望した流れ - Togetterまとめ

選挙で白票を投じても政治に対する不信感を表明したことには ならない。しかし、自分の世代の投票率を上げたことにはなるので、全く無意味ではないと思う。効率はよくないけどね。

ただし、白票は選挙管理委員の人間に書き換えられるリスクもなくはない (選挙管理委員の人間を疑うと、そもそも選挙が成り立たなくなるけれど)。

勤務先で書いているWebサービスは著しく Twitter と Facebook に依存しているんだけど、個人的にはどちらのサービスにも不満がある。

Twitter はポリシが不明瞭に思える。2007年頃はオープンな Messaging Platform だったように感じるが、3rd Party API の制約を強めた辺りから風向きが変わったように思う。先日 Twitter が発表した Strategy Statement も全く意味不明である。

Reach the largest daily audience in the world by connecting everyone to their world via our information sharing and distribution platform products and be one of the top revenue generating Internet companies in the world.

何が何だか…。サービスとしての Twitter は緩やかに死んでいくのだろう。

Facebook はポリシが明確なものの、全く共感できない。一人の人間が一つのアカウントを持ち、なるべく多くの人たちとつながり、なるべく多くの情報をシェアしてコミュニケーションを盛んにしたいのだと思う。

人間関係はそうそう単調なものではなくて、多くの人とつながればつながるほど、人間は密にコミュニケーションを取ることはできなくなるものだ。Facebook も、やはり衰退が約束されたもののように感じる。

リモートワークの仕事について調べている。

今の職場に不満があるわけではないけど、海外で働いて現地の永住権を手に入れてしまったために現地に縛られるというのは本望ではない。行きたいところにいつでも行ける状態が好ましい。

• Ask HN: The best way to find remote job

Hacker News に Basecamp (旧 37 Signals) が運営している We Work Remotely に関する情報が出ていた。We Work Remotely はリモートワークの求人のみをリストするサイトである。面白い書き込みがあった。

We hired two developers through WeWorkRemotely (gotten about 100 applicants), and couldn’t be happier. Highly recommended.

WeWorkRemotely で二人の開発者を採用したけど、最高だったよ。応募は100通以上あったね。

つまり、この手の口から応募するときは50倍程度の競争率を見込む必要があるということだ。なかなか大変そうだ。

反対に、企業側であれば、この手のサイトに求人を載せると50人程度の候補者から最適な一人を選べるということだ。悪くないのではないか。

リモートワークが全ての職業ないし企業で最適だとは思わないけど、現時点では不当に評価されていると思う。もっとリモートワークが流行ればいいと思う。

Hacker News で次のような書き込みがあった。知らなかったけど、すごく便利だと感じだ。

Slightly related: what many people don’t know is that on OS X and BSDs, commands often react to SIGINFO (Ctrl-t), giving progress information.

試しにOS Xで大きめのファイルを cp し、Ctrl-t で SIGINFO を発行したところ、次のような出力が得られた。

$ cp ubuntu-13.10-desktop-amd64.iso /tmp
# (Ctrl-t)

load: 1.86  cmd: cp 1413 uninterruptible 0.00u 0.19s
ubuntu-13.10-desktop-amd64.iso -> /tmp/ubuntu-13.10-desktop-amd64.iso  39%

ところで、一つ問題があって、私は Ctrl-t を tmux にキーバインドを割り当てているため、tmux を有効にしているときは SIGINFO の発行ができなかった…。

(追記)

友人から ~/.tmux.conf に "bind-key t send-prefix" という行を追加すれば tmux の中から Ctrl-t t で SIGINFO を発行できると教えてもらった。

北米のソフトウェア技術者は三段階でラベル付けされることが多い。Senior Developer (上級開発者), [Intermediate] Developer ([中級]開発者), Junior Developer (初級開発者) という具合だ。実にくだらないと思う。 この件について言及したブログがあった。 What it really means to be a “junior” developer. — I.M.H.O. — Medium 一部分だけ翻訳してみる。 Many junior developers (including me of course) know folks with “Senior” as a prefix or “Architect” as a suffix of their title whom we feel are less knowledgeable (in terms of programming-related skills) than us. One interesting characteristic of many of these folks though is that they have been around for a long time, worked for many companies (not necessarily), made many mistakes, learned from their mistakes, et cetera. [Read More]

ag (The Silver Searcher) は高速なコード検索ツールとして知られている。これを helm と組み合わせる helm-ag という Emacs plugin が公開されている。

これのインストールは MELPA から行えるけれど、インストールしてもうまく動かなかった。ドキュメントによると M-x helm-ag で検索ワードを入れるとカレントディレクトリ以下からソースコードが検索されるとのことだったけれど、これを実行するとミニバッファに helm-ag-init: No output: 'ag --nocolor --nogroup SEARCH_WORD' と出るだけであった。

少しハマったのだけれど、helm-ag のドキュメントには Requirements の項目に

• The Silver Searcher 0.15pre or higher.

と書かれていた。対して僕の環境は

$ ag --version
ag version 0.14

であった。ag をアップデートすることで、めでたく helm-ag を動かすことができた。でも “No output” というエラーメッセージから ag のバージョンアップが必要であるという事実を探し当てるまでに結構な時間をかけてしまった。

Play Framework 2.1.x で “play run” が指定した設定ファイルを読んでくれない現象に遭遇した。具体的に言うと、次のようにしても dev.conf が無視される。 $ play "run -Dconfig.resource=dev.conf" これが “play start” のときに同じ指定をすると有効になるのだから、訳が分からない。Stack Overflow で尋ねてみたところ config.resource ではなく config.file を試してみてはどうかと言われた。これは上手くいった。次のようにするのである。 $ play "run -Dconfig.file=conf/dev.conf" 正直な所、なぜ config.resource が無視されて config.file だと指定通りに動くのかよく分からない。上記の Stack Overflow で回答した方が示してくれた Play Framework のコードスニペットへのリンクも、あまり関係ないように思える。 他にもこの件でハマった人がいるようである。 NOTE: At the time of writing (Play 2.0.2) I can’t get config.resource to work when starting app in dev mode (using play run). Instead one can use config.file which, if using a relative path, points to project root: play -Dconfig. [Read More]