バベルの図書館は完成しない

Extended outer memory module
for my poor native memory.

Posts:
2020/09/28 gendoc という YAML からドキュメントを生成するコマンドを作った
2020/09/13 ISUCON10 の予選を 7 位で通過した
2019/12/01 Puma の内部構造やアーキテクチャを追う
2019/05/27 Golang の正規表現ライブラリの処理の流れをざっくり掴む
2019/04/29 InnoDB の B+Tree Index について
2019/04/29 InnoDB における index page のデータ構造
2019/04/28 InnoDB はどうやってファイルにデータを保持するのか
2019/01/06 Designing Data-Intensive Applications を読んでいる
2019/01/03 年末年始に読んだ本について、など
2019/01/01 Ruby から ffi を使って Rust を呼ぶ
2018/11/10 ブラウザにおける状態の持ち方
2018/07/01 Rust で web アプリ、 或いは Rust における並列処理
2018/05/14 なぜテストを書くのか
2018/05/13 Rust で wasm 使って lifegame 書いた時のメモ
2018/03/12 qemu で raspbian のエミュレート(環境構築メモ)
2018/03/12 qemu で xv6 のエミュレート(環境構築メモ)
2018/03/03 Ruby の eval をちゃんと知る
2018/02/11 Web のコンセプト
2018/02/03 Rspec のまとめ
2018/02/03 Ruby を関数型っぽく扱う

コードベースの正規表現検索

GitHub のソースコード検索って Elasticsearch っぽいと思っているんだけど、限定的なリポジトリ群に限っていいので正規表現を投げたいことがある

そこで特定のリポジトリ群に対して正規表現投げられて結果セットを表示できる仕組みを作ってみようかなあ、あわよくば社に展開したい

以下をどうしようか考えている

2020/12/02 11:56


アンチエイリアシング

なんとなくアンチエイリアシングをターミナルで無効にしてみようかなって思ってやっている

5 分くらいやった所感としては日本語がすごく読みづらいけど、これはいつか慣れるのかなあ、わからないね

2020/11/14 16:58


ISUCON10 本選

いやーー楽しかったけど難しかった、気が向いたらちゃんと感想を書きたいですがまずは自分の中できちんと咀嚼できてからかな

結果はおそらく 0 点だったし(またか)、チームとして gRPC/envoy/MySQL8 な技術スタックに対して上手く準備や経験を活かせなかった印象があった

僕個人の問題で言えば、テストのない中で短時間で大きな実装をバグらせずにやりきる、シンプルな実装力が足らないなと大変反省する機会となった

また来年も予選突破して本選で頑張れるといいね

2020/10/04 22:36


eBPF

eBPF っててっきりネットワーク系の挙動を把握するための仕組みだと思っていたんだけどもっと汎用的に使える仕組みっぽいね、面白そう

既存のプロセスにあとからアタッチできるというのがいい、ちゃんと調べてみよう

Ruby でいうところの stackprof + flamegraph なんかもそうだけど、ちゃんとプロセスの振る舞いを把握するというのはその時点でほぼ最適化が終わるケースもありかなり重要だなあと思う今日この頃だったのでした

2020/09/22 21:45


シェルわからぬ

シェルスクリプトって学習する機会が少ない割に意外と利用する機会は多い印象がある

しかも華麗にシェル芸決めると作業時間の短縮にもなるし気持ちいいし…

https://github.com/shirokanezoo/isucon9f を眺めていたんですが、 ~usernameusername ユーザーのホームディレクトリが展開されるとか () || : みたいな exit status を 0 にするテクニックとか知らなかったし : はいろんな使い道があることを調べる中で学んでかなり面白かった(個人的には :> でファイルを空にするイディオムが好き)

Ruby を綺麗に書くというのもシェルを自由に扱うのと似た気持ちよさがありますね

なんて話はさておき、 stackprof の結果を flamegraph にして nginx からレンダリングにする機能を粛々と作ります…

2020/09/18 01:32


この半年での変化

僕はたまーに思ったことを slack の自分宛て DM チャットに貼り付けるということをしている。

コロナによる自粛直後と今とで言ってることが全然変わっていて面白く、またそこに僕という人間の一貫性の無さを感じたのでちゃんと記録しておこうと思う。 (一貫性のある大人になりたいなって思っていたけどまだまだ遠いのだ)

2020/03/04

ここ最近社会が縮退モードになってる雰囲気を感じるし、僕もちょっと疲れてきたからこの流れに乗って全力で休みたいんだが諸々の事情で中々休めないな(このまま続くとたぶんモチベーション下がって体調悪くなるからそれは回避したいが…)

などと書いてから思ったが、じゃあ休んで何をするかと言われると例えば旅行に行きたいわけではない。落ち着いて溜まっている TODO を消化しつつ自分の中で何かが展開するのを待ちたい、というのが正確なところなのではと想像している。(自分でも正確に掴めてない、笑)

とにかく外部の環境に引きづられている感覚を持つのがすごく嫌いで、回避したがる癖があるように思う。更にはその感覚を持つのは大概忙しくて時間のない時期の少しあとなので多くはそのままダラダラと後始末に似た何かを続けてしまう。上手くバランスを取れない。

自分が陥っている状況を鑑みるに、外部環境に引きづられている感覚を持ったときに休んでバランスを取ろうとする思考回路自体が一種のデモチパターンであり僕の反射的思考の欠陥の一つでもある気がしてきた。効果的でなく実現可能性の低い解決策に幻想を抱いてしまっているのかもしれない。

疲れるとロクな打開策も思い付かないまま閉路に追い込まれていくし、閉路に追い込まれたことにも気づかない。その具体的な一つのケースに関して理解を得たような気分になっている。自己の客観視とその分析は偉く、また文章に起こすことは理解を助ける。

2020/03/07

6月(筆者注: 2019/06 を指している)くらいからの苛烈なスケジュールの中、長い期間ずっと長時間労働してなんとかここまで来て無事に仕事を終えたような気がしていた。

しかしこの一週間で自分の中での無事終わったという感覚は幻想にすぎず、実は後ろに大きな穴がいくつも開いていたことを嫌というほど認識させられた。

それらの穴を塞ぐために今週はまたひたすら働いていたけれど、往々にしてこうしたゴールを逃した敗戦処理のような状況ではひたむきにゴールに向かって頑張っている今までと比較して高ストレスな状態で仕事を行うことになる傾向があると思う。既に周囲からの期待値を下回るパフォーマンスになってしまっているのに、ここで部の悪い戦いを投げ出すわけにはいかない。僕が頑張ったところでようやくみんなが当然と思っている状況に帰着するのみ。

おそらく今までの僕の仕事の仕方が悪く、自分がアウトプットを担保できる範囲を越えてタスクを受けて進めてしまったが故にこういうことになったのだと思うので、しばらくはアウトプットの出し方を少し変えてみようかなと思い始めている。具体的には自分のアウトプットの品質を測りその最低ラインを担保するという作業に割り当てる時間を伸ばしてみようかなと思っている。

より詳細に説明するならば、アウトプットの品質の担保を行う上で期待されるアウトプットを詳細に具体的に理解することは必須だと思っているのだけど、求められるものへの理解がいつも劣後されがちで 100 の時間のうち 20 をそこに割き 40 でそのために必要な情報を集め 40 でアウトプットを構築する、というような配分で作業を行ってしまっている気がする。20 の時間で理解した要求に対していくら調査や作業を行ってもアウトプットの品質が早い段階で律速しているので、同じ時間を割り当てるのであれば比率を高めるべきなのかもと思っている。

こうした調整も忙しい時期には行いづらく負のループに入っていることもしばしば存在する。

この一週間自宅にて作業を行っていたが、それ自体は普段と比べるとすこぶる快適で会社に行く意味を見失い始めている。例えば仕事の合間にちょっとした家事ができるし、トイレがいつも埋まっているということもない。イヤホンをすることなく好きな音楽が聞けるし、周囲は静かで美味しいコーヒーも好きなときに淹れられる。仕事と生活の境界が以前よりも曖昧になったという変化はあるが、これは環境の変わると必ず発生する影響であって環境が変わることをなるべくストレスに感じたくないように思っている僕としては払うべきコストだと見做している。税金と同じ。

こうして見えてくるのは、僕にとって仕事に求める本質的な部分とは自己の研鑽と集中をただ繰り返すだけのプロセスなのではということだ。つまりそこに他人は必要なくて、例えば課題発生装置と呼んで差し支えないような代物が部屋の隅に置かれていてそこから定期的に課題が供給されれば満足できるのではないかという空想をしている。課題を自己の内部に求めることが出来るようになれば一層安定的な幸せが手に入るのかもしれない。

これらから導かれる仕事観みたいなものをもう少し追求してみたい。しかし時間はあまりないのであった。

2020/08/19

そういえば僕は出社しないとダメな人間なのだと思い出した

思えば大学受験のときにも塾の自習室に籠もりきってどこから溢れてくるのかわからない不思議な怒りとともにずっと勉強をしていた (受験はナーバスになる人もいて例えば事あるごとに大学生のアルバイトに話を聞いてもらいながらしくしく泣いてる人もいたんだけど、僕のナーバスさはちょっと違った方向に発露したみたい)

昨今の情勢からリモートが推奨されて久しい

しかし僕は自分のいる場によって思考や振る舞いが大きく変わる影響されやすい子なので出社すべき、これを忘れないようにしないといけない

2020/09/04 02:51


在宅勤務

WFH を余儀なくされている。この状況に対して WFH していることに納得感はあるのでそこは問題ないんだけど、まあ仕事のモチベの波が激しい。 とはいえこの先世の中では毎日出社することの必要性が下がってくると思う、特にエンジニアはその傾向が強く出ると思っているから僕も働き方を少し変えて数年試してみたい。

今は神奈川の実家に疎開しているんだけど今の状況が終わり一人暮らしの家に戻って引っ越しも済んだら家の仕事環境にしっかり投資しようと思う。

以下はそのためのメモ。なんとなく上から優先度高そう、 25-30万円くらいで一式揃うと嬉しい。

2020/04/09 21:39


2020 年

まずは去年の振り返り

今年について考えていること

つらつらと書きました、実践できるといいですね、では

2020/01/01 00:43


NeoVim の起動時間

普段エディタは NeoVim というやつを使っているんだけど最近起動がもたつくようになったなと思ってちょっと調べていた。

まず以下のコマンドで起動時の処理を所要時間のプロファイルが取れる。

$ nvim --startuptime <log file name>

僕の場合は VimEnter autocommands という処理が全体の 75% くらいの時間を占めていたのでそこをなんとかしようって思った。

なので autogroup と autocmd を使っていた処理を別の形に切り出してみた(というかもともと autocmd 使う必要なかったね…)

もともと 1500ms くらいかかってたっぽい起動が 500ms くらいにまでなったのでまあいいかな…(気づかないうちに随分遅くなっていた)

https://github.com/furuhama/dotfiles/commit/523705f9e1f4d54938d6f1a0d4c1a0583b9db301 https://github.com/furuhama/dotfiles/commit/ea1e888f5cacf9f7c950d866de1018bdeb0a2b52

ちなみに --noplugin オプションもつけると 160ms くらいで起動するので、普段もなんとか 2, 300ms くらいにまで持っていきたいな。いらない plugin 減らすか…。

2019/07/21 11:08


index のオーダー

index って簡単に逆順で走査できるのかと思ったら特に複合 index の場合とかあんまり自明じゃないっぽい…? とポスグレのドキュメントを読んでいて思った。

https://www.postgresql.jp/document/11/html/indexes-ordering.html

そして MySQL では index の order をメタデータとしては保持するけど実際のストレージの構造は全部昇順に直されるみたいだ。

A key_part specification can end with ASC or DESC. These keywords are permitted for future extensions for specifying ascending or descending index value storage. Currently, they are parsed but ignored; index values are always stored in ascending order.

https://dev.mysql.com/doc/refman/5.7/en/create-index.html

なるほどねえ…

今まで index の逆順のことあんまり考えてこなかったあたり僕はセンスがないなあと思いました。

2019/06/19 13:01


msgpack-ruby を自分でビルドしてみる

native extension を利用している gem をちゃんと読んだことなかったなと思って、 RubyKaigi でセッションを聞いたというのもあるし msgpack-ruby を読んでみている。

だけど JRuby や Rubinius をサポートしていてターゲットによる if 文が多かったので、その辺のコードを全部消した上で自分でビルドしてみた。

https://github.com/furuhama/msgpack-ruby/tree/just_latest_cruby

ビルドも具体的にどんなことをしているのか知らなくて、今回初めて手動でやってみた。

手順としては

$ cd /path/to/msgpack-ruby

$ ruby ext/msgpack/extconf.rb

$ make

$ mv msgpack.bundle ./lib/msgpack

とかでできると思う。

最後の mv がうまくやれば不要なんじゃないかって思っているんだけど、 Makefile とかよくわからないのでとりあえずこれで。

irb なりを開いた上で

> $LOAD_PATH.push File.expand_path('./lib')
> require 'msgpack'

とかすればビルドしたものを使えるかな。

=====

rake-compiler という gem を調べていたらこれが用意してくれる rake task を使えば上で一つ一つ行なった操作を簡単に全部できることに気づいた。

$ rake native gem

とすれば ok 。

(しかし僕の場合なぜか x86_64-darwin18 というターゲットを認識できずに途中でエラーになったので define_cross_platform_tasks 'x86_64-darwin18' を無理やり足すということをして凌いだ…理由はちゃんと調べていないので謎だけど…。)

2019/05/30 17:24


MySQL のパーサ

故あって MySQL ターゲットに生成された SQL をパースして構造化した上である判定に使いたくなっている

外部のライブラリに頼る手もなくはないんだけど、信頼性とか仕様への追従面を考えるとなるべくなら MySQL Server が公式に利用しているパーサをそのままそこだけ流用したい。

このクエリはもともと Rails の ActiveRecord 経由で生成されるので、モデルからのメソッドコールで SQL を作成する際の中間表現みたいなものを見て今回の目的のために判定する方が筋がいいのかもしれないんだけど、どっちが構造変わりにくいかで考えると MySQL の公式のクエリパーサかなあと思っている。

ただシンプルな SELECT 文だけなのでまあ正規表現で頑張れないこともなくて、実際今は正規表現で頑張っている。

MySQL の SQL のトークナイズ & パースは lex と yacc を使って実装されている?のかな。 bison も make しているけど lex とか yacc とか bison とかの役割や関係性が全然わかってないから責務や使い方から調べて流用できるのか調査しないとだな…。

以下のあたりが関係ありそうかな 🤔

2019/05/23 00:09


innodb_ruby

https://github.com/jeremycole/innodb_ruby

これかなりちゃんと作ってあってすごいな

Jeremy Cole の記事はかなり参考になるし、この人が言っている「何かを勉強する時にはまずラフな理解をした上で、それを自分で(できればコピペにならないように別の言語で)書き直す」というアプローチはすごく学習効率が良さそうでいいなって思った。

2019/04/29 02:22


最近の勉強 (RubyKaigi を経て)

RubyKaigi 2019 に行ってきた。以下の点ですごく良かったように思う。

単純に福岡という場所がよかったという側面もある。来年は松本らしい、また行きたいな。

さて、 RubyKaigi を経てちょろっと仕事したらすぐ GW に突入して最高かよって気分になった。

GW はなんとなく以下のことをやりたいなって思っている。

まあ当然全部は無理なのでいくつかをピックアップして進めることになると思うけど。

テーマとしては以下の感じ。

2019/04/29 00:59


Linked-List

https://doc.rust-lang.org/std/collections/struct.LinkedList.html

https://github.com/rust-lang/rust/blob/master/src/liballoc/collections/linked_list.rs

Rust で LinkedList やろうとするとこんな風になるよね。 unsafe は仕方ない。

それはそれとして Rust を The book みたいなコンテンツからざーっとやり直そうかなって思っている。

蟹本は原著を読んだのだけど、昨年末に出たあれの翻訳版買って読むのもいいな。

2019/03/17 18:05


B+ Tree

状態を持つ機構が全般的に好きだなと思っていて、まずは日常的に自分が触れる RDB に対する理解を深めようかなって思っている。(ずっと前から思っているんだけど進捗は芳しいわけではない)

今日は割と時間があったので以下の記事から始まるシリーズを読んだ。

https://postd.cc/how-does-a-rdb-work-1/

Part 3 の後半のトランザクションログとかの話まではなんとか読めて、 B+ Tree への理解がちょっと深まったのでよかった。

一般的なインデックスのデータ構造に対して、すごくざっくりとした理解は生まれたように思う。

けれど一方で MySQL というか InnoDB はクラスターインデックスというデータ構造を取るそうなのだけど、そこに関しては全くわかってないので次はそこのトピックを軸に攻めて行くといいかもしれない。

今いる環境はアプリケーションからデータベースに対して発行する個別の SQL に対する最適化の余地はまだ結構残っていそうで、なおかつデータベースへの負荷を下げるのはそれなりに価値のある仕事っぽい状況なので、こういう領域に力を入れようかなと思っているし、今やってる大きめのタスクが落ち着いたらもっと活発に進めていけるといいなあ。 (今思いついたというわけではなくて 2019 年の目標の一つにしている。)

ただ一方で、そもそもアーキテクチャとかデータの持ち方(データベース、テーブル設計)から考え直す必要もありそうに思っていて、そちらの方が大変かつ難しいものの根本的には正しい道に進めるようにも思うので、どこまで個別の SQL に対して深入りしていくものかと悩んでいるところも…。 🤔

2019/03/03 23:28


Express

たまには js 書くかと思って Express + Sequelize でシンプルな web server & RDBMS の構成のアプリケーションを書いた。

https://github.com/furuhama/express-api-server

js の .catch とかでカスケードしていけるのはいいね。ちゃんと成功/失敗のある処理を扱える感じがすごくいい。(Ruby だと文法レベルでは隠蔽されちゃうので)

今読んでる本に乗っている実装が js で書かれているっぽいので、次はそれを読みながら自分でも書いてみようかな。

2019/02/17 18:29


認証とか認可とか

最近社内向けに認証基盤の改修をしているんだけど、認証や認可という領域はみんな賢いし面白い。

最初この分野はセキュリティに偏ったスキームが生まれ続けているのかと思っていたんだけど、ユーザビリティを損なわないような無理のないスキームを追求しているという点も非常に面白いと思う。

OAuth 徹底入門という本を買ったので読んでいこうと思います。

(というか AuthN/Z っていう表記かっこよくない?!!?)

2019/02/16 22:28


岩手県

国内旅行はあんまり考えてこなかったんだけど、今回スノボで安比高原に行ってそのあと盛岡を散策してみて、国内にも面白いところ色々ありそうだなと思い始めた。

盛岡のよかったところ

2019/02/11 19:27


スノボ

たのしいね

2019/01/26 23:59


コードの表現形式について

コードというのは原則横書きで、行を連ねる形で表現されていると思う。

最近思うのは、行をまたぐような関係性や行の途中のある部分からある部分への関係性を表すのが難しいなということ。

例えば以下のような C の goto 文を利用する際に goto ~~ から ~~: の部分に矢印をコメントとして引けたらだいぶ見やすくなったりするんじゃないかな。

#include <stdio.h>

int main()
{
    int count = 0;

loop:
    printf("I'm in a loop...\n");
    count++;
    if (count >= 10) goto end;
    goto loop;
end:
    printf("Escaped from a loop!!!");
    return 0;
}

そんなに高級な話をしているわけではなくて、算数で図形の問題を解く時に補助線を入れると一気に答えがわかりやすくなるように、コードを読む時に赤ペンとかで上からコードの処理の流れを書き込めると、もっと読みやすくなるかもしれないなって思ったという話でした。

2019/01/06 16:02


dry-rb

dry-rb っていうものがあるらしい、他の Ruby よりも現代的な特徴を備えた言語処理系からいくつかの良い部分を Ruby に持ってこようという試みだと思っている。多分。

公式ページのいくつかのサンプルケースをみていたんだけど、 Dependency management とかは便利そうだなと思った一方で、 Some とか Result 型を Ruby に入れる有用性はどんなもんなんだろ 🤔 と思った。 Ruby って関数の引数や戻り値の型の整合性を静的に解決できないので、結局実行時に評価してみて安全に動くかどうかだし、そういう環境に後付けで Some や Result を入れるのってどれくらい意味があるのか僕には今の所よくわかっていない。

それだったらネイティブでそういった部分がサポートされている言語処理系を使う形に、処理をコンポーネントごとに切り出す、とかも選択肢に入ってこないのかなって。

とはいえどちらかというとある一連の処理をいちいち丁寧に条件分岐作らずに、しかし安全に書いていきたいというモチベーションなのかもしれないね。 JavaScript の Promise みたいなものに近いというか。

2019/01/03 17:16


Thread & Fiber (& Guild)

Thread と Fiber の違いがよくわかってなかったんだけど

Thread: プリエンプティブなマルチタスクを実現するための仕組み

Fiber: ノンプリエンプテイブな協調マルチタスクを実現するための仕組み

ようは制御をどうやって他人に渡すかの差らしい。なるほどね。

ちなみに Fiber の方が Thread よりも軽量に実行できるらしい


あと Guild はなんなのかっていうと、コアを複数使って並列に処理を進める場合に

排他制御を行うための実行単位が Guild らしい。

な関係らしい。ざっくりね。

2019/01/02 13:38


開発環境(物理)

12/25 に職場で使っているディスプレイが壊れてしまった。

Eizo のなかなかいいやつを使っていたのでショックだったけど、壊れてしまったものは仕方ない。(電源系統が逝かれたっぽい)

今までは MacbookPro を机の左側に置いて、正面に外部ディスプレイとしており、目の前に HHKB を持ってきて開発をしていた。(トラックパッドも外付けのものを注文していたのだけれど年内は届かなかった。) しかしディスプレイがお亡くなりになった今、 MacbookPro のディスプレイをみながら HHKB で入力をするのは中々難しく、結局 MacbookPro 単体で開発をしている。これも悪くないんだけど、ずっと手のひらをノート PC の上に置いていると熱くて汗をかいてしまうのと、 HHKB の気持ちいい(周囲からは多分うざい)打鍵感が恋しいので、満足しているかと言われるとそうでもない。

来年の開発スタイルをどうしようか思いあぐねている。もう一個ディスプレイ買ってもらおうかなあ。でも安い買い物ではないのでちょっと申し訳ない気持ちもする…。中々難しいところです。

僕がディスプレイに求める条件としては

書いててそんなに贅沢じゃない気もしてきたね。

2018/12/29 20:55


年の瀬

僕の中でのクリスマスの存在感って数年前と比較して相対的になくなってきている気がするんだけど、一方で 12/25 はアドベントカレンダーが終わる日として認識するようになってきた。

どちらもそこが終わるといよいよ年の瀬へとまっしぐらという部分では同じ。

そういえば VM というのがよくわからないので、 Write your Own Virtual Machine を読んでみている。

LC-3 っていう教育用の CPU アーキテクチャがあるって初めて知った 👀 x86 よか複雑じゃないけど x86 に似た特徴を多く兼ね備えているということでなるほどなと。

2018/12/29 20:38


http リクエストのヘッダの HOST について

(後から書いているので色々説明の順序がおかしくなっているけど…)

発端はこの PR https://github.com/rails/rails/pull/33145

http リクエストのヘッダにある Host と、リクエストの向き先は完全に同じものという制約があるのかと思っていたので、最初は何を言ってるのかわからなかった。で、調べてみると「curl を叩くときにリクエストヘッダの Host の値を好きにいじるには」みたいな記事にたどり着いてははーんとなった。

試しにローカルでサーバを立ててみて

$ curl localhost:3000 -H 'Host:example.com'

とかってする。 pry でサーバ側を止めてみて

[1] pry(#<TestController>)> request.env['HTTP_HOST']
=> "example.com"

なるほどね🤔

これは確かに Web サーバ側としては許容したくないかもね。 (冒頭に貼った PR で言ってる DNS rebinding and other Host header attacks が何を指しているのかわからないけど…)

ちなみに google 様はちゃんとしてた(そりゃそうか)

$ curl www.google.com -H 'Host:example.com'
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That's an error.</ins>
  <p>The requested URL <code>/</code> was not found on this server.  <ins>That's all we know.</ins>
2018/12/26 08:26


musl

Alpine とかで使われてる musl っていう libc の実装はなるべく(?)静的にリンクできるように最適化しているらしい。

すると確かに、コンテナ環境で動く最低限のものだけ欲しいっていう場合はいいのかもしれない。

ちなみに AWS の Fargate とかで動いている Firecracker っていう VM も musl を使っているらしー。

2018/12/22 19:41


neovim

neovim(vim) のプラグイン周りの動作がちょくちょく環境に依存する形で動かなくなるんだけど、なんとかいい方法はないものか

隔離された環境で依存関係を解決して、それでいてオーバーヘッドなしにサクサク動いてほしい…

まあとりあえず直したからまた今度考えよう。

今日は浅草におでんを食べに行ってきます。

2018/12/15 18:27


エンジニアブログ

会社のエンジニアブログに初めて投稿してみた。

ちょっと前まで頑張っていたことをなるべくわかりやすくいろんな人に伝えようと思って結構気合い入れて書いた。

社内での評価は割とよかったように感じているけど、対外的な発信としてはもうちょっと技術的なアウトプット量を増やさないと話にならんなっていう感じもしたので、次回はもうちょっと頑張ろうかな。

2018/12/13 06:59


Mt.Takao

朝散歩をしている友達と、番外変ということで高尾山に登ってきた。

以下感想

という一日でした。高尾山は割とよかったです。

2018/12/08 21:03


VM って

VM ってなにーーー!!!

という思いが強い。完全に概要を理解できてないので、もにょもにょするし、よく思い違いをしている。なかなかつらい。

2018/12/02 18:27


文字コード

文字コードのことを考えるの忘れてた。この前の clr に Shift-JIS 食べさせたら一瞬で落ちてつらい気持ちになった。

いいタイミングなので文字コードについてちゃんと調べて対応してみよう。

2018/11/29 14:00


future

うーん、 Rust の futures 周りを見てたんだけどまだいまいちどういう状況なのか理解できないな…。

代わりに js-primer で js の Promise 周りを読んでいた。 async/await の部分はなんとなく近いアイデアなのかなって思うんだけど、どのタイミングで実際に中身の処理を実行するかが違ってそうな気がする。

https://jsprimer.net/basic/async/

このコンテンツは非常にありがたい…各言語にこういう資料があると世の中がぐっと生きやすくなる気がする。

2018/11/25 21:59


Colorize csv

このところ Rust を全く書いてなかったので何かちっこいものを作りたいなと思った。

そういえばお仕事で csv を扱うことが結構あって、とはいってもそれを利用して何かをするというわけではなく、むしろ利用してもらうために生成する側の処理を書くことが多い。

その中でデバッグとして出来上がった csv を見たいことがあったので、列ごとに別の色付けをして出力するコマンドをサクッと作った。細かいところは全然作り込んでなくて、現状は最低限出力ができるという状態。大したものでもないから craet.io に載っけるみたいな大層なことはしなくていいかなと思ってしていない。(namespace 問題があるのにこんなツールで 3 文字のリソース使うのかってお話もあるし)

https://github.com/furuhama/clr

mysql の explain 文の出力くらいには見やすくしたい気もするから、テーブルっぽいレイアウトを出力するように頑張ろうかなあ。そんなに頻繁に使わないから迷いどころ。

そういえば全然違う話になるけど Rust の非同期をそろそろ勉強していかなくちゃね。

2018/11/24 19:03


プリプロセス

ちょっと前に HackerNews で話題になってた(確か)これを読んでいる。

https://github.com/green7ea/cpp-compilation

__FILE__ とか __LINE__ とかがプリプロセスで展開(置換)されるって聞いてなるほどなってなった。今まであんまり考えてなかったけど、そう言われてみるとこのタイミングでやらないとなっていう。

そして見に言った Wiki の記事がちゃんとしていて英語版はレベル高いなと思った。確か前に日本語で検索してもいい情報にたどり着けなかった記憶がある。覚え間違いかもしれないけど

https://en.wikipedia.org/wiki/C_preprocessor

2018/11/23 17:11


どれ読もう

glibc のライブラリは序章を除くと以下の構成になってるので、今読んでわかりそうなところと興味あるところだけざっと読むので十分だろうな。

ざっと見たけどきになるのはこいつらかなあ。

Error Repoting, Memory, Character Handling, String and Array Utilities, Character Set Handling, Locales, Searching and Sorting, I/O Overview, I/O on Streams, File System Interface, Syslog, Date and Time, Resource Usage And Limitation, Signal Handling, Program Basics, Processes, Inter-Process Communication, Job Control, Name Service Switch, System Management, Cryptographic Functions, Threads

こんなに読めるのかは知らない。

2018/11/23 16:51


引きこもり

C 言語の内部的な話(どうアセンブリに変換されるかという話)も面白いんだけど、C 言語利用者がどうやって C 言語を用いているのかという話も結構面白い。というか言語としてはこちらの方がメインの価値のわけだけど、、、

メモリ確保のインターフェースや戦略などは C 言語ベースの他言語の GC 戦略に関わってくる部分だし、標準ライブラリは意外なところで僕とも接点があるし。コンパイラも楽しいんだけどこれは基本的な概念を理解できれば今の所は問題ないかなという気がしてきている。

僕の目的はどちらかというとリンクのプロセスを理解したいということなので、 libc をみてどういうヘッダにどういうものがあるのか眺めるとか、どういうオブジェクトファイルを引っ張ってきてどんな風に elf バイナリ作るのかを眺めるとか、そういうことの方がいいのかもしれないね。

2018/11/18 23:13


C 言語

C 言語自体を読み書きできることも重要だけど、 Ruby を使っているとリンカとかローダとかの知識が結構必要になるシーンが多いよなあと感じる。 ネイティブな C のライブラリを Ruby でラップして扱ってる gem って結構あるし、そういう gem のためにライブラリをビルドしようとすると、大概リンカがうまく何かのシンボルを見つけられなくてコケる。 コンパイルは基本的にファイル単位で完結するのかなと思ってて、そこがうまくいかないことってあんまりない。(失敗するとしたらプリプロセスでうまく行ってないってことが多そうな感覚)

だからリンカとローダの本を読んだんだけど、まああんまり意味がわからなかった。ということでまずはコンパイラをざっくり知ろうかなという気持ちになっている。そしてその辺りの悪戦苦闘をここに色々書き記すことにした。文章を考えるのが面倒すぎて、なぜか超絶簡易英語でやっているけど…。c_playground

2018/11/17 20:55


おすすめ

人に読み物を勧める時には、まず自分が読むんだぞ原則は意外と破ってしまっている気がする。気をつけよっと

2018/11/15 19:05


view テンプレート

僕はもっぱら仕事で rails を書いているが、一向に rails の view テンプレートが好きになれない。 html を生成したいのに ruby の世界から触ろうとしているから不思議な構造になっているというのが一番大きな理由だと思っている。理解しきれていないヘルパーもまだあるだろうし。しかしこれは ruby 以外の様々な言語においても発生していることだろうし、 DSL によって html を生成するか、文字列として扱って頑張るかのどちらかしかない気がしているので、どうしようもないことかなあ。 Jekyll のマークダウンの書き方とかも気持ち悪いし全然好きじゃないんだよね。逆に生の html は冗長だけど納得はできる作りなのであんまり苦じゃない気もする。つらい。

で、話は view テンプレートに留まらず。一対多の関連のモデル同士があった時に、親リソースから子リソースたちを作りやすくするように view を拡張してくれる cocoon という gem があるが、これも同じくというか、これに関しては view テンプレート自体よりも格段に好きになれない。

こっちの理由は自分の中では明確で、(おそらく)汎用的な API を目指したが故に、やりたいことに対して意図の見えづらい使い方を押し付けられているという点だ。

そもそも親リソースに対して子リソースたちが関連しているデータ構造では、情報の更新の際に子リソースたちの差分管理という概念が必要になる。どれが増えて、どれがそのままで、どれが減ったのか、というのを管理するのは少し難しいと思う。なおかつ、js をないものとした場合、入力に対して要素を動的に変化させることも難しい。

この辺りを解決してくれているという点では評価すべきものだと思っているが、いかんせん API がよくないのではないかという気がしている。とはいえぐちぐち言ってても仕方がないので、自分が作るんだったらどうするか考えて、それでまた評価を決めようと思う。もしかすると数日後には大好きになっているかもしれない、とはいえそういうことはよくあることだし気にしないでいいかな。理解できてないものに嫌悪感を覚えるのは恥ずべきことだけど同時に自然なことのような気もするし。うん、とりあえず現時点では全然好きじゃないってことで。

2018/11/14 23:44


glibc

今朝 linux のタイムゾーンのことを調べる機会があって、特に環境変数 TZ の仕組みについて調べていた。

そしたら最終的に glibc のドキュメントに行き着いて、ほーんここは libc の範囲の話なのか 👀 となった

http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

libc の役割がよくわかっていないな。 Linux kernel とごっちゃになることがあるから、多分何かを理解してないか勘違いしているかなんだと思う。

これ最初から読んでみよう。(pdf とかもあるみたいで良い世界を感じる)

http://www.gnu.org/software/libc/manual/html_node/index.html

2018/11/12 08:52


TypeScript

JavaScript の経験がほとんどなくて、せっかく今からやるなら TypeScript でしょと思って、これまたドキュメントを眺めていたけど、やっぱり型アノテーションは好きだな。一部には冗長とか美しくないとかいう向きもあるみたいだが、僕はいいと思う。

Rust やってみて思ったけど、型アノテーション(と、静的に解決される型システム)がある方が色々と処理を書きつらねていきやすい気がしている。量や時間で行ったら Ruby の方がよく書いているけど、 Ruby でプロダクションコード書くとなると結局テストで関数の引数と戻り値の値の幅を保証してあげることになる。それだったらテストに分断されることなく、アプリケーション側のソースコードの中に、値の取りうる幅(型だったり nullable かどうかだったり)の情報が含まれている方が読みやすいと思っている。

そもそも値の取りうる幅を全て型システムで決定できるというのは、パズルちっくなコードになりがちではあるが、素晴らしい点だよね。型システムの基本概念になれてしまえば他人の書いたコードも 70% くらいの理解度でもなんとなく読めて安全に扱える。 (Ruby は他人の書いたコードを読むのが非常にコストがかかるし、 90% くらい理解しないと怖いなって思ってしまう。。。)

逆に Ruby がいいのは、クラスベースのオブジェクト志向をベースに体系が構成されているから、論理的な世界での話なのに物理的な世界に対してプログラムを行なっているかのような思考の簡単さ・楽しさを持てる点が一つあると思っている。その上で基本的にいろんな方向に制約なく(しかも処理の流れの中で動的に)メッセージパッシングができるから、あんまり悩まなくても、やってほしい子にやってほしいことをやってもらえる部分もいいところかなって思う。(さらにいえば、そんな自由度の中でいかにお行儀よくわかりやすいコードを書いていくか、という部分も割と好き。)

2018/11/11 20:45


webpack

最近よく聞くなと思って公式サイトの concepts のドキュメント読んだ。「はーはーこういうものか基本的なアイデアは理解したわ」と思って、社内の webpack 使ってるリポジトリ覗きにいったらいきなり読むには複雑でつらい気持ちになった。あるある。

2018/11/11 20:04


Pixel3

Google Pixel 3 をこの前ポチったんだけど、さっき届いてセットアップも一通り終わった。

Authy っていう 2FA のためのアプリだけ上手く行かなくて、

こういうアプリで上手くマイグレーションができないのって致命的だなとか思いながらサポートにメール出した。

それ以外は概ね上手くいった感じ。 LINE とかは面倒なので過去のトーク履歴を引き継ぐために頑張るみたいなことやらなかった。

軽く触ってみた感じ

-

そういえば多分 9 月の中頃に前使っていた Huawei nova lite が壊れて、それ以来かれこれ 2 ヶ月くらい SIM 無し iPhone + ポケット wifi みたいな生活をしてきたわけだけど、

周りの人には多大な迷惑をかけたものの、僕としてはほぼ支障なく暮らせてしまった。

頻繁に連絡を取る友達がたくさんいるわけでもないし、平日は特にずっと会社にいるわけだしね。

そもそもポケット wifi とスマホくらいのサイズの端末があれば、だいたいのことは上手くいく。

困るのは

くらいだったかな。

代わりにたくさん本が読めるので、なかなかおすすめです。

2018/11/11 14:53


ブラウザにおける状態

ブラウザが状態が持つ方法っていくつかあると思うんだけど、

僕の聞いたことのある範囲だと

つーのがある。

これの違いってなんなんじゃろ、あとで調べよう。

2018/11/10 17:41


ダークモード

今まであんまり静的なサイトを作ったことがなくて

しかもフロントエンドの経験もほとんどなかったから

ちょっとした練習にいいかなと思って、このブログにダークモードを導入してみた

(色調とかはよくわかったので Docker の公式サイトを参考にした)

スイッチをぽちぽちするだけで色が変わるのはなかなか楽しい。

2018/11/10 17:37


根性

があんまりないので、困ったことがあるとすぐに周りの人に聞いてしまう。

集中モードに入っている時だと逆にそんなことなくて、ずっと考え込んでしまう。

たぶん、困った時に集中モードにパッと入れると色々いいんだろうか

でも asset ファイルのプリコンパイルでコケる、とか個人的に興味もあんまりわかないし、やる気が出ないんだよね、、、、。

もっと面白い問題で悩めるようになるために、こういう問題を秒殺する力が欲しいです。

2018/11/08 20:04


最近早朝からよく活動をしているような気がする。

ただこの時間で何をするかは難しくて、僕の場合は職場周辺を 30 分から 1 時間くらいいろんな方向に歩くとか

あるいは本を読むとか、ちゃんと朝食を作って食べるとか

時には朝っぱらから仕事を始めてしまうこともあるんだが

総合的に見ると、やはり仕事以外のことをしていると物事が上手く回るのかなという気がしている。

2018/11/07 08:57


仕事以外の時間

最近仕事に対して時間を使いすぎているような感覚がある。

そもそもの意識でいうと、僕はまだエンジニアを始めたばかりというのがあり、自分で興味領域を開いていくことも重要だけど

世の中の、web を中心とする技術領域やソフトウェア開発における技術領域が、どんな風に人々に受け入れられているのか

個別の領域の現代における重要性・抽象化され具合みたいなものを、業務を通して理解していきたいみたいな気持ちがあって

あえてがむしゃらに仕事に取り組んでみたっていうのもあった。

で、この目論見はあんまり失敗してはいないと個人的には思っている。

色んな仕事に飛びついたことで、そこそこ多様な方面に知識のとっかかりみたいなものはできたし、

なんとなく集団でソフトウェア開発を行う上での、特にスモールチーム/マイクロサービスを意識した組織での利点・問題点もわかってきたように思う。

===

とはいえ、そろそろエンジニアを始めて 1 年数ヶ月経つし、自立して歩き始めたほうがいい気がしている。

こう思い始めたきっかけはいくつかある。

一つは、上述したようなことをやってきたせいで、自分と他人が納得しきれるような深い知識が、あんまりない状態になっているなと同僚の方々と話していて気づいたこと。

もう一つは、新しい技術を試したり、エンジニアとして対外的なプレゼンスをあげる取り組みをしたり、そういった自分の今所属している組織以外との接点をほとんど追っていないなと気づいたこと。

前者に関しては、日頃空いている時間でネットワークの基礎だったり、言語処理系の基礎だったり、そういった領域の本を読むようにしているので、元々時間がかかる領域ではあれど少しずつ追いつくようにはしている。

後者に関しては、もちろん Twitter, はてブ, HackerNews, Reddit などはざっと興味のあるトピックに関して追うようにしているし、会社や組織や個人のブログも色々と RSS リーダーで追っかけている。そのためおそらく平均的なエンジニアくらいの精度で、話題レベルでは世の中の流れについていけている気がする。一方で、僕が社外のエンジニアに知られているかと言われると決してそんなことはないし、なんというか世間知らずな感じがぷんぷんする。(もっとこう始めてあった人と技術的な話題でワイワイやりたいじゃん)

どちらの問題に関しても、微力ながら今の状態でできることをしている意識はあれど、もっと時間を割くことでこの問題点がどう変化するのか(劇的に改善するのか、はたまたほとんど意味がないのか)を検証したい気持ちが強いので、しばらくはその辺りを試す時間にしようかなと思っています。

===

以上を踏まえて、もうちょっと自分がやりたいことに使う時間を増やしてみようかと思っている。

それにあたっては、やりたいことをしっかりと管理していく & 思ったことは些細なことでも記録するのが重要そうだよなあ

やりたいことを管理するに当たってどういう形式を取ろうかはちょっと悩んでいる。

会社で見てきたのだとタスク管理に Jira, Trello, Asana を使っているパターンがあって、

みたいな感想を持っている。

個人だと昔 Remember the Milk を卒論書くときに使っていた。うむ、あれは無料でも最低限のことをシンプルに管理できるな。ちょうどいいし使ってみよう。

まずはやりたいことを書き出してみるかな

2018/11/04 22:39


はじめてみた

気合いの入ったポストばかりをやっていくのがつらくなったので、

ちょっと頑張って minipost の概念を作り出してみた

日頃色々考えていることはあるものの、それをローカルとか内向き wiki とかに残しておくのも気が進まないので

なるべくインターネットに流してしまおうと思っている。

2018/11/04 20:11


テスト

お試し

ほげほげ

2018/11/04 00:00



This site is maintained by furuhama yusuke.
from 2018.02 -