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

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 を関数型っぽく扱う

ルックバック

藤本タツキが大好きで今回の読み切りもすごく心を動かされた

https://shonenjumpplus.com/episode/3269754496401369355

2021/07/19 02:43:35


デザインツール

Figma を週末にかけて初めて触ってみた。レイヤリング、グルーピング、コンポーネントの考え方がすっと入ってきてくれたおかげでかなり快適に触れている。デザインツールとカテゴライズしていいのかわかっていないが、こういったツールはよくできているんだなあと感動した。昔少しだけ Sketch を使ったことがあってそのときも感動した記憶がある。

Figma そのものに感動するというか、こういった 2 次元に自由に動き回れる GUI アプリケーションを作れるのはすごい。 Excel 触ってるのに近い感動がある。

コンポーネントは variant という仕組みで状態を持てて表示を切り替えることができるそうなのだが、まだそこまでちゃんと作り込むべきではないと判断して使っていない。しかし気になるので早く試してみたい機能の一つである。

HHKB と Magic Trackpad で作業しようと思ったら Option キーが押しづらくて断念し Magic Keyboard を引っ張り出してきた。デザイナーはキー数の多いキーボードを使うほうが快適に作業できるんだろうね。

2021/06/21 00:05:14


ピュアに課題と向き合いたい欲求

仕事での評価期間があった。今いる会社では半年単位で評価が行われる。振り返りを書いてみるとどうにもこの半年は何もやっていなかった気がする。もう少しちゃんと言語化すると、当初立てていた計画はことごとく負け越したしそのことへの対応もさほど打てなかった、結果的にしょっぱい成果を積み重ねたような感覚だ。

一方でフィードバックでは上司から「確かに十分でない側面もあったが、期待値に対してよくやってくれた」といった趣旨の話があり、僕が今ダウナーな気分になっているだけで実際には評価すべき箇所もあるのは間違いないと思う。

同時にそのフィードバックを聞いてから考えるうちにたどり着いたのは、僕は自身のグレードや評価や給与は実はどうでもよくてピュアに課題と向き合って結果を残すことに興味があるのではという可能性だ。無論評価されたいしたくさんお金もらえたら嬉しいしそういった尺度で周囲と自分を比較して優越感を覚えたり安心を覚えたりすることも正直なくはないのだと思うけど、考えてみるとその先で評価や報酬を何に使いたいのかという明確な目的はあまりない。今のところご飯は毎日食べることができているし。

僕はこういう漠然として短絡的な欲求に判断を狂わされることが多いのだと思う。(評価や給与を求めることが誰にとっても短絡的という話ではなく、おそらく僕にとってそれは短絡的な欲求であるという主張) しかし長い期間での自分の精神的な健全さを考えると、会社から今の自分に期待されている役割は僕にとってはさほど重要ではなくて、自分は自分の見えている範囲で常にベストを尽くしたいしそこに対して結果を出したいのだと思う。(同時に、今は嫌っている評価制度などそのもの自体はいずれ僕は人生でしっかり向き合うことになりそうな予感がある、めっちゃ嫌だけど、自分は自分の嫌っているものに引き寄せられる呪いみたいなものがある。)

ここまで書いて短絡的欲求を取ることで長期的には損していく、というような構造は実は普段の仕事への取り組み方でも見られたことに気づいた。とにかく目の前に飛び出してきた問題を反射的に倒しにいくような動物的欲求が強くて、物事の優先度付けとその短い周期での更新が苦手なのだ。動物的欲求と書いたがこれは本当に動物なら誰でも抱えている性質なのかもしれないな。みんな性質としては抱えているが、優れたアウトプットを出している人の何割かはこの性質との向き合い方が上手いということなのかもしれない。

さらに話は脱線するけど最近 Apex Legends を友達に誘われてはじめた。そこで思うのは敵が近くにいることがわかるとそれしか見えなくなって追いかけて負けるみたいなパターンが多いということだ。上手い人のプレイ動画を見ると接敵して戦闘しつつも常にいろいろなことを考えているし、時に退く選択もそれなりの確率で採っている。こういったことを自覚して自分の行動を直していくのは面白い。始めたての頃よりはマシになってきた自覚がある。ゲームというのは他の人が何を考えてどうやっているのかの情報が多い体験だから学び改善につなげやすくてそこがすごくいいよな。

ゲームでの自己の客観視と自分の性質の修正のための繰り返しの試行は、自分が学習して改善していける存在であることを思い出させてくれる側面もある。そういえば僕は自分のことを「何やっても 2, 3 回は大きく失敗するけどそこから先はちゃんと直していけるはずの人間」だと評価していたのだった。同時に残念ながら能力的には普通なのと運みたいなものはあまり無いので、改善すべき点を改善してベストを尽くしてもダメなときはダメであることも(麻雀で)学んでいる。

そんなわけで自分がダメだったと振り返ると最終的によくわからない前向きさを取り戻して帰ってくるという、自分の根のポジティブさを自覚させられるイベントがあったという話でした。

2021/05/29 11:54:23


テスト

以前 なぜテストを書くのか っていう記事を書いたけど、エンジニアとしてのキャリアを通じて周囲の人たちのテストに対しての様々な考えに触れることがありとてもいい

僕自身もテストを書くべきかどうか自身で意思決定する立場に近づいているし、みんなの意見を興味深く眺めている

テストのめどい話

2021/05/20 15:23:20


懐かしい時代

大学生の頃にずっと音楽聞いてブログ書いたり Twitter で同好の士と交流していたのを唐突に思い出した

ちょっと調べたら当時書いてたブログも出てきて大変懐かしい…(自分でもブログタイトルとかもろもろ完全に忘れていた…)

https://nengara.tumblr.com/

温かい気持ちで自分の過去を受け入れてあげたいね

2021/05/18 11:15:37


terraform で環境ごとの差異をどう表現するか

特定の環境のみ作りたいリソースを表現するときに

terraform variables で environment 的な変数を定義しておきつつ

resource "resource" "name" {
  count = {
    test = 0
    prod = 1
  }[var.environment]
}

みたいなことをしていた

でそうすると付随するリソースで

resource.name[0].id

みたいなことをしないといけないのと、場合によっては

some_reference = {
  test = null
  prod = resource.name[0].id
}

記述が出てくる

この場合に tuple で記述すると variable の設定に関わらず tuple の中身はすべて評価する必要が出てきて test の場合にエラーになってしまう

terraform にはこれと近いことを表現する方法で例えば三項演算子もあり、以下のようにも書けるがこちらは偽になる分岐側の式は評価しない

some_reference = var.environment == "prod" ? resource.name[0].id : null

というわけでほとんど同じようなものだと考えており、見やすい tuple を活用していたけど三項演算子でないと実現できないケースもあるのでメモ

2021/05/02 13:43:28


HEAD 向けてる neovim のビルド

homebrew でパッケージ管理をしていて neovim だけは安定版ではなく HEAD に向けてビルドをしているのでその手順のメモ

# how to install
$ brew install --HEAD neovim

# how to upgrade
$ brew upgrade --fetch-HEAD --build-from-source neovim
2021/03/15 10:18:18


自分を取り巻くコミュニケーションの変化に関して

当たり前の話だけどコミュニケーションってすごく難しいし、特にコロナでリモート/チャットでのやり取りが増えて、 DM みたいな閉じた場所での非同期のコミュニケーションも増えたことでかなり難しくなった感覚がある

もう少し解像度高めてみると、そもそもコミュニケーションって一定の確率で失敗しうるけど、その確率が高まったのと失敗を察知できるまでに要する時間の平均値が上がったのと、失敗の修復の際にきめ細かくコミュニケーション取りづらいケースが出てきた(結果的に修復に時間がかかる)、みたいな感覚

元々他人の感情をあまり重視しないで考えてしまう癖がある(考えてもどうせわからないなら考えなくていいじゃんみたいな思考になりやすいのだけど、わからないからといってその影響まで軽んじるのは誤ったモデル化なんだろうなって思う)のだけど、リモートでのコミュニケーションが増えたのと他人に影響の大きい部分に関わり始めたことで以前よりも問題が起きやすくなってるのがここ最近というところだなあ

書いてみてやはり僕(の価値観)側が変わるべき問題であるという認識なので頑張ります

2021/03/14 15:35:36


Slack の Android アプリ

僕からするとどんどん体験が悪くなっている

UI デザインとパフォーマンスと双方から責め苦を受けておりつらい… Twitter の公式クライアントでも同じようなことを感じたことがあるんだよな…もっとシンプルでいいのに…(老害っぽい思想)

Android で Slack 触るときは凝った UI とか絵文字とか無くてよくて単にメッセージ/画像の読み込みとメッセージ送信ができたらいいんだけど、そういうクライアントはないんじゃろうか

2021/02/20 23:29:01


麻雀

2, 3 ヶ月に 1 度やってるくらいの頻度でしかないんだけど麻雀ってずっと楽しくてすごいゲームだなあと思う

四人零和有限不確定不完全情報ゲームだと思うんだけど、特に不確定と不完全だっていうのがいいよね

自分が最善を尽くし続けても報われるときと報われないときがあって(人生じゃん…!!!)って思うことが多い

未来ある若者には是非勧めたいゲームです(実際には破滅まではいかないとしてもバランス崩す人もいるので勧めない)

2021/01/28 23:09:12


同一デバイス上の複数ブラウザ間での cookie 同期

僕は普段 Firefox で活動しているんですけど社でセキュリティ上の理由から Chrome 使えって言われてモチベーションが 100 くらい下がっている

社の PC の Chrome からしか入れないサービスがいくつか出始めていて結構つらい

そこで例えばあるデバイス(社の PC)上の複数のブラウザ(Chrome, Firefox)で cookie を同期できたらもうちょっと幸せになれるかもしれないなと思ったのが発端

社として Chrome だけに絞っている利用ブラウザを Firefox にも無理やり広げることになるので Attack Surface も拡大するしそれってそもそもの施策の背景と反しているのではって思わないでもないけど、実際に運用するかはともかく試みとして面白そうだなと思ったので試してみる

Firefox も Chrome も sqlite の形式でローカルのデバイスに cookie を保存してる

例えば Chrome -> Firefox への単方向同期を考えると

2021/01/28 01:38:04


factory reset RTA

私用の PC (たしか Macbook Pro 2019 くらい) の Xcode の Command line tools が変で Ruby やら Python やらのビルドができなくなってた

同じタイミングでちょうど最近会社で利用してるサービスへのログインの制約が厳しくなった(社用 PC でないとログインできなくなった)ので、それにあわせて私用 PC から会社関連の一切を取り去ってしまおうと思った

そんなわけで昨日の夜 23 時くらいから本読みながら factory reset をして再度環境構築してた

やったことは以下

たまに覚悟決めて factory reset するのも悪くないね

2021/01/25 11:16:15


コードをどれくらい書くか

あと 1 年くらいは気合入れてメインの仕事ではコードをあまり書かない方向に舵を切ってみようかなあ

積極的にやらないというよりは時間の配分の問題で、副業や趣味でじゅうぶんコードは書ける気もしている

僕から見るとコード書くのもプロジェクトを進めるのもメンバーに何かを依頼するのも全部、理想状態をなんらかの方法で定義し僕が最適だと信じる方法でアウトプットしていくというプロセスで共通化できるんじゃないかって最近思っている

だからこの考えに則って僕のやっていることを抽象化して捉えるとだいたいの仕事はコードを書いているのとさほど変わらないんじゃないかと思うんだよな(本当か?)(そもそも抽象化したら同じ、ということは場合によってはあまり意味がない気もするけど…)

とはいえ今日チームメンバーと話して、僕が全力でコード書いてた時に一緒に開発してみたかったと言われてすごく嬉しかった

そのうち全力でコードを書けるような仕事を自分に用意してあげられるといいなと思う

2021/01/22 20:00:23


カツサンド

さっき気づいたけどカツサンドという料理がかなり好きかもしれない…豚でも鶏でも…

サンドイッチの一種なので食べやすいしカツなので充実感もあるしポピュラーなのでコンビニでも手に入ることが多いし申し訳程度にキャベツが入っていることでジャンキーな雰囲気も緩和されてるし

2021/01/17 18:38:45


他者へのフィードバックについて

普段仕事をしていると関わっている他者に対して何かを感じることがあるし、同じくらいみんなも僕に対して何かを感じていることがあるんじゃないかと思ってる

みたいなやつ

前提として僕たちは組織としてのアウトプットを最大化するために一緒の会社に所属して仕事しているんだと思う(本当?)ので、将来のアウトプットがより増えそうで僕が貢献できそうなことはサボらずなんでもやるべきだと思い始めた

フィードバックのうちプラスのフィードバックは丁寧に良さを言語化して伝えたらいいし、大きくひどいことになる可能性はあまりないのではって思っている

一方でマイナス方向のフィードバックというのはそれがどういう内容であれかなり難しくて、例えば僕は何か言われたら人格を否定されたような気になることもあるしイライラすることもかなり多い

そこでこうした防御反応に自覚的になりつつ、表現や指摘の用途に細心の注意を払いつつ、それでもなんとかして伝えていく方法を模索してみたいなと思った所存

今日よりも明日が良くなるといいけど

2021/01/17 16:53:53


漸進的型付けと NAH 症候群

大きなプロジェクトや組織に何かを導入するとき、どうしてもそのままだと上手くいかない箇所を探してしまいがちという人間の性質があると思う

(人間の性質と書いたけど何事も否定から入るのは単に僕の悪い癖なのかもしれない…)

これは NAH(Not applicable here) 症候群に近い反応なんじゃないかと思っている

対して近年流行っている漸進的型付けのアプローチというのは上手くこの問題に対応する解決策/思想の一つなんじゃないかと感じている

組織に新しい何かを導入するときも漸進的型付けっぽいアプローチで解決していける/精神的に納得していけるといい

ただしこの考え方は「何事もとりあえず経験してみよう」の呪いと似ていて、今度は否定すべき時に否定する理由が探しづらくなってしまうから諸刃の剣ではあるのだけれど

2021/01/15 17:09:51


ラフマニノフ

のピアノ協奏曲第 2 番はやはり結構いい、歌詞がないというのもあり仕事中に聞いてみている

スヴャトスラフ・リヒテルとクリスティアン・ツィメルマンの録音を聞いてみてる、有名曲だからいい録音もたくさんありそうだ

ウラディーミル・アシュケナージ、エレーヌ・グリモーのやつは調べたら名盤って出てきたので聞いてみよう

どうでもいいけど ラフマニノフ ってキーボードで打とうとすると ラフマニノに って打ってしまう手癖があることに気づいた…なにこれ…

2021/01/13 19:37:24


誕生日

に類する、特になにもしてないけど一定の周期で来るお祝い事みたいなものがどうしても苦手だ、ということを急に思い出した

他人の誕生日は祝いたいし心底祝えるんだけど、自分の話になると別でどうにも祝ってもらう必要がない気分になる

一種のインポスター症候群なのか?少し違う気もするけど、自分のことを祝うくらいなら他のもっと有意義なことしてほしいし、僕がもっとすごいことをした暁にちゃんと祝ってほしい気がする(でもそもそもあんまり祝いの席の主役として存在したくない気持ちもある)

ずっと主役を祝う側の立場でいたいし、会を盛り上げるために力を使いたい。祝われる側の何も考えていなくても役割を果たしているみたいな状態が苦手なのかなあ

この話に関連して結構すごい(と思われるであろう)エピソードがある。僕の成人式の時に親が贈り物をくれようとしたのにその時の僕は何を思ったかそれを断ってしまったのだった。今になって考えるとすごく申し訳ないことをしてしまったなと思う。でも親からは十分に良くしてもらったと思っているし親のことは好きなので、僕がそういうめんどくさいやつだってことはちゃんと伝わっていてかつ気にしないでいてくれるといいな

性格もここまでねじ曲がると素直っぽく振る舞うのはかなり大変だ、という話

2021/01/13 00:08:07


手軽な遊び場

考えてみたら GitHub Pages も簡単な JavaScript 実行環境になるなあと思った

そこでちょろっとしたスクリプトを /tools に生やしてみることにした、ハンマーのアイコンのところです

通信や状態の管理が不要な純粋関数っぽいものだけになってしまうけどまあいいかな(と思ったけど別に外部に状態を持ってくれるサービスがあってその API を叩くとかであれば全然いいな)

2021/01/11 22:21:26


情報の流れ

もともと僕は web ページに対してスタイルの良し悪しをあまり求めないというか、情報は情報であり装飾はあくまで副次的なものなので一切スタイルの当たってない簡素な view で十分と考えているような人間だと自己評価していた

つまりその僕に言わせれば web サービスというのはデータストアにそれっぽい皮を被せただけのものであり、どうデータを取り出すかのみが重要であるみたいな話になる(雑で過激な抽象化)

そのため近年色々な web サービスの UI がリッチになるとそれに逆らうように古い UI のままにしていることもあって、例えば gmail は古い UI のままにしている

だが最近気づいたのだけど僕は上に書いたようなことを考えている一方で Instapaper や Kindle のフォントをしょっちゅうあーでもないこーでもないといじっては唸っていることもあり、これは実際には装飾に興味がないのではなくて 文字 というものがすごく好きで 文字文字 としてあまり意識させないような装飾に興味がないだけなのではと思い始めた(この辺の好き嫌いの基準に関しては未だに自分でもちゃんと言語化できてない)

web ページのリーダーアプリみたいなものは作ってみたいと思うことが多いし、いつか自分の接している情報をすべて自分の気に入ったリーダーで読めるような世界を築きたいとしばしば思う

もっと言えば理想は全ての情報が統一された美しい形式で本として本棚に収まってくれて僕はそれをパラパラとめくって楽しむことなんだけど…

…と話がどこに着地するのかわからなくなったのでこの辺で収めたいんだけど、つまり何が言いたかったかというと雑に UI を軽視していたあの日々に UI に携わる人たちに謝りたくなったのだった、大変すみませんでした

2021/01/07 22:33:42


Message Passing

https://messagepassing.github.io/

こういう形式のブログ面白いし好きすぎる…なんで今まで世の中になかったんだと疑問に思いすらある…

文字情報の podcast と言っていいのかな、世の中にもっと増えてほしいね

2021/01/06 13:44:55


長谷川白紙

がすごくいい、ただそれだけ…

でもすごくいい…

2021/01/04 14:02:52


やめどき

嵐の解散ライブ見てた。演出もすごかったけどみんなコンディション良くて歌すごくうまかったしそこが良かった

みんな 40 歳くらいで 21 年やってて相当すごい成果が出ていたものをしっかりと一度終わらせるというのはかなり驚異的な意思決定な気がした。例えば僕が 45 歳でその時のキャリアを一旦終わらせて別の方向に進めるのかと言われたら微妙だと思う。ただ僕はそのときに路頭に迷ってる可能性があるから実はさくっと別のことを始められるかもしれないけど、彼らはその対極なのでそこも加味した上ですごいよね

極める、という感覚があったのかなあ。成長観点で意識の高い人たちはどんな領域でも限界なく学び続けられるし限界を錯覚することは悪だと考えているような風潮をよく感じる(し、僕もそう思っている部分はややある)けど、実際には面白いことは他にもおよそ無限に存在するわけで適当な場所でちゃんとやめるのも評価すべきだよな

よくわかんないけど僕も一番順調で落ち着きを見せ始めたタイミングで次のチャレンジできるといいなあ、次は野良の文章書きみたいな仕事でもやってみたい

雑誌とか小さい団体の会報とか家電の説明書とか小説家になろうとか、とにかく色んなメディアに文章を載せまくってみたいという謎の願望がある

2020/12/31 23:16:48


暗いといわれた

昨晩友だちに Takakazu Honryo’s site - 雑記 の存在を教えてもらい、ふんふんと面白く読んでいた

そういえばここも(個人の脳内の垂れ流しという意味で)近い場所だよなあと思って自分で久しぶりに読み返していたら内容が暗いものばかりでびっくりしてしまった

普段能天気にぼやーっとふらふら色んなものに注意が移ろいながら生きているのでもっといちご牛乳の話とかしているものだと思っていたんだけど、なんだこれは…

健やかに生活しているときは書けそうなアイデアが浮かんでもすぐに忘れてしまうんだよな、そろそろ PC で vim 立ち上げる以外にこのブログを更新する方法を実装せねば…(Web UI か mail か Android app か)

そんなこんなで友だちにもここを見せてみたんだけどやっぱり暗いと言われた。僕も将棋の話をしよう…

ちなみに昨晩はその傍らで別の友だちと

というような話をしてた、やっぱり暗いな…

===

蛇足だけど上にも書いた通り僕は一つのことだけ考え続けるのが苦手で、例えば昨晩こんな話をしている最中に上野駅で買えるお土産を調べたり五等分の花嫁の結末のネタバレを読んだりしていた

2020/12/27 10:46:24


忙しさと興味のバランスについて思うこと

ここのところいよいよ自分の興味があることに対して自分が何もすることができず、極めて強い無力感を心に刻むようになってきていて大変よろしくない

何もすることができないというのは言い換えると、僕の生活ではその生活スタイルや自分の気分などによって決まる「興味あるから触れてみることキャパシティ」みたいな量があり、生活の中で出会う興味や興味の種がそれを明確に越え始めているな、という状態だ

さらに言うと、これを解決するにはキャパを増やすか興味を減らすかがあり、僕は基本的には腕力で今までなるべく前者で解決しようとしてきたかあるいは自然に忘れることによって興味を少しずつ減らすということをしてきた(サラバ、愛しき興味たちよ)

これまでも限界を感じたことはあったが今回がいつもと違う気がするのは、キャパシティが仕事によって強烈に圧迫されている感覚を同時に感じているからなんじゃないかと思う

少し余談になるけど仕事によってキャパが減るというのは忙しいという言葉にすぐに置き換えられがちだけど、僕はこれを雑なラベル付けだと考えていて過剰にチャンスを減らしてしまう可能性があると思ってるからあんまり好きじゃない(自分自身も口癖のように「難しい」って言ってしまうけどこれも悪癖だと思ってやめようとしている)

その前提で話すと、複雑で大きいものがたくさん頭の中を占めていて他のことを考えるスペースが奪われており、その割にそれらは一向に整理されないから大きいままで我が物顔して頭の中に居座っているような気分だ。まるで頭の中に灰色のもやもやしたカビゴンでもいるみたい

計算機でいうとメモリ空間に雑に大きいサイズの領域を allocate していったが故に fragmentation が起きて次の allocate のための領域を確保できていないような状態かもしれない、すると必要なのは garbage collection や compaction か…

一番重要なのは僕はあんまりこういう状況が好きじゃないってことで、興味があることがこぼれ落ちている無力感なんて本当にかなり嫌なことの一つだし、どんどん集中することも難しくなっている、これは最低最悪と言っていいと思う。引き受けたものが多いのでなんとかするとか無理だから他の人に投げるとかしようとは思うけど、今後はそもそもこうした状態にならないような環境に身を置くように努力したいなと思う

一つの反省点としては成長と会社でのポジションが上がることを混同している節がどうやら僕にはあり、雑に近似しても問題ないケースが多いとは思うんだけど、とはいえそれって社内という閉じた組織での相対的な尺土だしなあと囚われすぎないようにせねばというところ。僕はどちらかというと草の根的に活動するのが性に合っているとたまに再確認してあげないとついつい忘れてしまうのでダメだな。

書くことで整理されてマシな気分になってきたけど、とはいえあんまり感触良くない年の瀬の近況でした

2020/12/09 00:43:05


次のチャレンジの気配に際してのメモ

時たま普段とは趣の異なるチャレンジ(変化)の気配が僕に対してやって来ることがあり、先週末はまさにその一つだったように思う。

そうした気配は不確実な前提の上に成り立っているためちょっとしたことですぐに立ち消えになることもあるけど、あまり期待はせずしかしできるだけの準備をすぐに始めるのがいいんじゃないかと思っている。僕は柔軟性とか適応力とかって言われるものが人より無いと自覚しているのでなるべくパフォーマンスを出すために準備多めの方がいいなと社会人になってから特に思い始めた。

そんなわけで 1% も確定したわけではないシュレディンガーのチャレンジ的存在に対する僕なりの見解をメモ。

こんなに抽象的によくわからないことを書いてて何も起きなかったらその時はその時。

でもそろそろチャレンジの質を変えて不得意なところに飛び込んでみたいな、と酒を飲みながら考えることが増えてきた日々の中にいます。

2020/12/07 01:31:11


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

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

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

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

2020/12/02 11:56:42


アンチエイリアシング

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

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

2020/11/14 16:58:38


ISUCON10 本選

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

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

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

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

2020/10/04 22:36:13


eBPF

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

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

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

2020/09/22 21:45:43


シェルわからぬ

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

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

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

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

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

2020/09/18 01:32:10


この半年での変化

僕はたまーに思ったことを 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:12


在宅勤務

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

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

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

2020/04/09 21:39:08


2020 年

まずは去年の振り返り

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

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

2020/01/01 00:43:28


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:27


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:48


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:56


MySQL のパーサ

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

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

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

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

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

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

2019/05/23 00:09:42


innodb_ruby

https://github.com/jeremycole/innodb_ruby

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

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

2019/04/29 02:22:57


最近の勉強 (RubyKaigi を経て)

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

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

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

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

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

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

2019/04/29 00:59:40


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:25


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:04


Express

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

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

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

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

2019/02/17 18:29:48


認証とか認可とか

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

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

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

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

2019/02/16 22:28:57


岩手県

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

盛岡のよかったところ

2019/02/11 19:27:17


スノボ

たのしいね

2019/01/26 23:59:10


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

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

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

例えば以下のような 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:22


dry-rb

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

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

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

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

2019/01/03 17:16:49


Thread & Fiber (& Guild)

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

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

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

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

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


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

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

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

2019/01/02 13:38:05


開発環境(物理)

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

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

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

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

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

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

2018/12/29 20:55:46


年の瀬

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

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

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

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

2018/12/29 20:38:54


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:24


musl

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

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

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

2018/12/22 19:41:13


neovim

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

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

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

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

2018/12/15 18:27:32


エンジニアブログ

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

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

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

2018/12/13 06:59:01


Mt.Takao

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

以下感想

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

2018/12/08 21:03:26


VM って

VM ってなにーーー!!!

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

2018/12/02 18:27:31


文字コード

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

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

2018/11/29 14:00:08


future

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

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

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

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

2018/11/25 21:59:46


Colorize csv

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

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

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

https://github.com/furuhama/clr

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

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

2018/11/24 19:03:04


プリプロセス

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

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

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

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

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

2018/11/23 17:11:04


どれ読もう

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:50


引きこもり

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

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

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

2018/11/18 23:13:27


C 言語

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

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

2018/11/17 20:55:40


おすすめ

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

2018/11/15 19:05:59


view テンプレート

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

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

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

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

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

2018/11/14 23:44:52


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:36


TypeScript

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

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

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

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

2018/11/11 20:45:02


webpack

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

2018/11/11 20:04:21


Pixel3

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

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

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

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

軽く触ってみた感じ

-

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

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

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

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

困るのは

くらいだったかな。

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

2018/11/11 14:53:03


ブラウザにおける状態

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

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

つーのがある。

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

2018/11/10 17:41:49


ダークモード

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

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

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

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

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

2018/11/10 17:37:07


根性

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

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

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

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

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

2018/11/08 20:04:57


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

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

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

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

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

2018/11/07 08:57:10


仕事以外の時間

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

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

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

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

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

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

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

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

===

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

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

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

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

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

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

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

===

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

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

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

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

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

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

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

2018/11/04 22:39:35


はじめてみた

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

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

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

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

2018/11/04 20:11:00


テスト

お試し

ほげほげ

2018/11/04 00:00:00



This site is maintained by furuhama yusuke.
from 2018.02 -