2024-06-25

本棚を自作する。清く正しい本棚の作り方が参考になりそうなので通読する。

通読した。以下の手順かな。今度ホームセンター行こう。

材料の検討をつける
- 21mm以上の厚さでカット可能でそれなりのサイズの板が必要
- パイン集製剤はよさそう
設計する
- 自分の本のサイズとその量を見積もるかな
- 僕の場合は専門書が3サイズ（A5?,A4?,教科書？）あるのと小説と漫画がある。それぞれのサイズを計り量を見積もる
- その上で高さ180cmくらいかなのものを一旦設計して、入手できる材料のサイズを鑑みて調整する
材料を調達する
- 購入・裁断・運び入れが課題
組み立て
- 補助線の書き込みと穴あけ、ねじ止めとボンドでの固定がやること
研磨
- エッジの処理とかはこのタイミングで一度やる
塗装
- 材料によるがニスとかでいいかな
- 蜜蝋とか油は本への影響がありそうでちょっと怖い
乾かす
- 塗料が乾くまで外で乾かす。天気が大切
研磨
- 最後にシュッとやれるとよさそう

認可に入門 wip

https://www.osohq.com/academy これを読んで認可に入門します。頑張るぞ〜！

https://www.osohq.com/academy/authorization-academy

Chapter II: What authorization is: how to organize your authorization code Chapter III: Role-based access control: grouping permissions in your app into roles like User and Admin Chapter IV: Relationship-based control: grouping permissions by relationship, like “the creator of a post may edit that post” Chapter V: Authorization enforcement: once your app has decided to allow or deny access, what do you do with that decision?

こんな感じとのこと。色々あるんだな。どれも気になるが、特にアプリケーションコードにどうやって統合していくかが気になるところかな。もれなく頑張らずに実現したい。

https://www.osohq.com/academy/what-is-authorization

具体例を挙げてWebアプリケーションにはレイヤがあって、それぞれのレイヤではどんな情報を取れて、どんな認可ができるかを議論する。

また、“4. Adding Authorization to an Application>”ではコードでの認可処理の書き方を比較する。

Naiveなアプローチだと以下のつらみがあると言っている。それな〜。

That quickly gets difficult. As the number of places where you need to apply authorization increases, you end up duplicating the same logic. Making any change then requires us to remember every place our logic is duplicated.

どうしたらいいんだ…

Formalizing Our Authorization Model なるほどね（以下を認識する）。

actor
action
resource

UNIXのファイルにつけるパーミッションもこの考えで整理されてそう。どのユーザがどのファイルに対してどんな操作をするかを気にして権限の管理をしてるイメージ。

グループIDみたいなのはactorを発展させたものぽい。 sudoもその辺をいじるのかな。Capabilityはactionsの部分かな。それだけでもなさそうか。

上の三つ組を考えるメリットは二つあるとのこと。

言語を共有できる
設計としてシンプル

設計がシンプルと言ってるのは、以下のように認可のインターフェイスを持てそうということらしい。

isAllowed:: (Actor, Action, Resource) -> Bool

こういうインターフェースを定めることで認可の周りで責務の境界を定められる。呼び出し側の責務にenforcement, 呼ばれる側の責務にdicisionという名前をここではつけている。

認可処理の結果をもとに何をするかを決めること。そもそも認可処理の呼び出しをするのもここの範囲だし、その結果アクセスがなければ403返すとかするのもここ。良いかどうかを気にしつつ、その結果どうするかを決めるのがここ。

基本はyes/noを返すやつ。さっきの関数の実装。警告とかは出したきゃ出せばいい。純粋である必要はなさそう。

5. Putting Everything Together がまとめだった。ここまでのメモが集約されてる感じ。

あとここには書かなかったけど、enforcementとかdicisionとかの話の後にenforcementをどこに実装する？みたいな話があるがマイクロサービスぽいアプリケーションを書いてないとそもそも問題にならなさそうで、一旦そこに僕は興味ないのでスルー。

アーキテクチャの話はなるほどって感じだが、まだ考えられることはたくさんある。

権限が足りないときのエラーメッセージの返し方
- 足りない場合は403だけじゃなくて何を足せば良いか知りたいとか
管理者にアプリユーザがどんな権限を持ってるかを表示するとか
グループとか

https://www.osohq.com/academy/role-based-access-control-rbac

2024-06-08

goconに行ったりscala matsuriで知ってる人が登壇してるのをみて、発信する人になるのが楽しいのだなと心に刻んだ。発信に対するフィードバックをもらえたり、自分を認識してもらった上で質問してコミュニケーションできるのは強い。

2024-06-05

https://www.kikumasamune.shop/c/notseisyu/whisky/nz971 これすごくおいしかったので買い足そうと思ったら売り切れてた。大事に飲もう。

フロムザバレルと似たものを感じる

https://www.kikumasamune.shop/c/seisyu/daiginjyou/nk220?top_pickup これはその逆かな。

半開閉区間

コンピュータで区間処理するときは半開閉区間で持つことが多い気がしている。もはや信仰のレベルで身についているので自分一人で決めて終わりなときはそれで良いのだが、説明が必要なときに困る。そのときのために良さげな参照を集めておく。

“Always use [closed, open) intervals”
- https://fhur.me/posts/always-use-closed-open-intervals
- 半開閉区間の説明と閉区間のつらみ、半開閉区間のよさを語っている
“Google Cloud API設計ガイド”
- https://cloud.google.com/apis/design/design_patterns?hl=ja#representing_ranges
- 半開閉区間を使う必要があるとしている。C++とJavaがそうしてるぞと強調してるが理由は特に触れてない。
“時間の歩き方”
- https://blog.osa.in.net/time-tips/
- 半開閉区間というか、時間（時刻の区間としている）の持ち方の話。日付の区間なら閉区間もありと主張してる。

何というか区間は連続な集合の２端点を指定して定まる部分集合であって、その全体からなる集合族を扱おうと思うと半開閉区間にしておくと綺麗というのも関係する？

区間は全順序集合の部分集合で、それらを体系的に考えようと思うと区間の集合の性質を考えるのが良いはず。つまり区間からなる族を考えると良さそう。

考える全順序集合が連続な集合なら、半開閉区間からなる族を考えると、任意の区間は有限個の区間の非交和として表現できる半開では無い区間の族ではこの性質は成り立たなさそう。漏れとダブりがないように区間を分割する必要は実用的に割とあってそれをきれいにできるのは半開閉区間だけということになる。

ググってみると集合半環という概念があるみたいで、それにこの性質が効いてるぽい。集合半環 (wikipedia)をみると良さそう。

むずい。

https://chatgpt.com/share/4c778bf6-f43a-4230-825d-398ad025a457

結構良い回答をもらえた。

プログラミングで区間を表現する際に半開閉区間（半開区間、片開区間とも言う）を用いると良い理由は、特に次のような点にあります：

直感的なインデックス操作:
- 配列やリストなどのデータ構造において、インデックスは通常0から始まります。半開閉区間 [start, end) を使うと、start から end-1 までのインデックスが含まれるため、範囲を扱う際に計算がシンプルになります。例えば、要素数が10の配列に対して [0, 10) という範囲を指定すると、全ての要素を含むことになります。
区間の連結が容易:
- 半開閉区間は連結する際に便利です。例えば、 [start1, end1) と [start2, end2) という2つの区間を連結する場合、end1 と start2 が同じであれば、それらを連結して [start1, end2) とすることができます。このように、区間の端点が明確に分かれているため、エッジケースが少なくなります。
境界の一貫性:
- 境界条件を処理する際、開区間の端点は含まれないため、範囲外アクセスのリスクが減少します。これにより、特にループ処理や再帰的なアルゴリズムの実装が一貫しやすくなります。
数学的な整合性:
- 半開閉区間の表現は、数学的にも広く使われており、理論的な背景からも自然な表現です。例えば、集合の分割や区間の分割などで、一貫した扱いが可能です。
プログラミング言語のサポート:
- 多くのプログラミング言語やライブラリが、半開閉区間をデフォルトでサポートしています。例えば、Pythonのリストスライスや、C++の標準ライブラリの範囲は、半開閉区間の形式を採用しています。このため、言語やライブラリの機能を活用する上で半開閉区間を使うのが自然です。

以上の理由から、プログラミングにおいて区間を表現する際には半開閉区間を用いることが一般的であり、推奨されます。

数学的な観点から見て、半開閉区間（例えば ([a, b))）を使用することにはいくつかの重要な性質があります。これらの性質により、一貫した扱いや直感的な操作が可能となります。以下にいくつかの重要な性質を挙げます：

区間の連結性:
- 2つの半開閉区間 ([a, b)) と ([b, c)) を連結すると、新しい半開閉区間 ([a, c)) を得ます。これにより、連続する区間を簡単に扱うことができます。
- 例： ([1, 3)) と ([3, 5)) の連結は ([1, 5)) となります。
区間の分割性:
- 半開閉区間 ([a, c)) を点 (b) で分割すると、2つの区間 ([a, b)) と ([b, c)) になります。このように、区間を分割する際の扱いがシンプルです。
- 例： ([2, 7)) を (5) で分割すると ([2, 5)) と ([5, 7)) になります。
一意性と包含関係:
- 各点は1つの半開閉区間に一意的に属します。具体的には、点 (x) が区間 ([a, b)) に属するのは (a \leq x < b) の場合のみです。このため、区間の包含関係を判断するのが容易です。
- 例： (x = 3) は ([1, 5)) に含まれますが、([3, 7)) にも含まれます。
空集合の扱い:
- 半開閉区間において、区間 ([a, a)) は空集合となります。これにより、区間のサイズが負になることを避け、理論的な一貫性を保ちます。
- 例： ([4, 4)) は空集合として扱います。
順序性と計算の簡便性:
- 半開閉区間は順序を持っているため、数直線上の位置関係を直感的に理解できます。これにより、範囲の計算や比較が簡単になります。
- 例： ([2, 5)) と ([5, 8)) の関係は明確に非重複であると分かります。
測度論との整合性:
- 測度論（特にルベーグ測度）においても、半開閉区間は重要です。半開閉区間は測度が容易であり、特に区間の長さが (b - a) で計算できるため、実際の応用において便利です。

これらの性質により、半開閉区間は数学的に一貫した扱いが可能となり、プログラミングにおいても同様の利便性が得られます。このため、アルゴリズムやデータ構造の設計において半開閉区間を使用することが推奨されます。

閉じたとこから開いたと〜こ！

好き好き大好き〜

2024-05-23

https://youtu.be/hCuMWrfXG4E?si=Viiw626EEgkaP7p5 2000年代のアニメかってなった

コロナに罹って出社できず、会社の人たちは福岡オフィスから出張で来てる同僚を囲んで飲みに行ってるのが悔しくて、家でビールを飲みながらソファをデプロイしていました。

床を片付けてルンバに掃除してもらってからハイボールで優勝します。

2024-05-22

チーム開発でコードの品質担保するのむずい。足並みを揃えて品質を上げないといけないのがむずいところで、ふっと自分がやる気を出して勉強すれば済むものではないことがむずいのかな。レビューだときりないし。レビューはするのだけど、次はLinter自由自在になるのが次のステップかな。

プログラミングの酸いも甘いも知ってそうだろ！って人がプログラミングのお作法みたいな本を見て、「これ良い！」とツイッタでいうのは、全人類がこれを理解してくれたら最高だし、なんかあったらこの本読んでって言えそうだと思ったのかなと。

アルコールをとって音楽聴くと最高だという話をどこかで書いたし世間でもよく言われてるみたい（引用はないけど）。それで今気がついたのだけど、音楽がよくなるくらいの酔い方にはコツがあって、ちょっとお腹を空かせて空きっ腹状態でショート缶2本のウォームアップを済ませることが肝だと思う。その後ちょっとアルコールしんどいなと思いながら聴く音楽が最高。

いつだったか忘れたけど多分ここ数ヶ月のどこかの夢の記録をする。僕は最近引越しにハマっていて、今度も一目惚れした土地のある部屋に引っ越した。東京の都心かそのやや東にある部屋で、これまで東京の西を中心に一人暮らししてきた僕にとっては新鮮だった。東京西部はそもそも生活の軸を一つも置いたことがなかったのだ。

その部屋は大きな橋の近くにあって、ロフトがあったかは忘れたがロフトのありそうな天井の高い部屋だったと思う。玄関を入った細い廊下にキッチンが付いていて、そっから扉を隔てて天井の高いワンルームがあるような間取りだ。僕はそういう間取りは毛嫌いしているのだけど、何かの条件（立地と家賃だろうか）がよくてそこに一目惚れしてエイッと引っ越したのだった。

部屋ではなく土地を気に入っているのでそこでの記憶は散歩が中心だった（そう、僕は散歩が好きなんです）。道は雑然として曲がったり登り下りがあったりしてスラムな様相で、そこに生える建物の一つに立体駐車場みたいなやつがあった。それぞれの階に一店舗くらいちょっとした軽食やがあったりなかったりして、所有権の所在が不明な、リゾート地にありそうなプラスチックの円卓と椅子がいくつか置いてあった。その建物の雰囲気が良さげだったので入って中を見たから覚えているのだろう。人と話した記憶はないし、何か買ってもいないはず。時間は過ぎてやがて夜になった。もう少し都心の方へ向けて散歩を進めていた。周りは暗くて道路脇に立っている常夜灯くらいが光っている。テレビ局か工事中の駅の周りにそれらしいモニュメントか1/1ガンダム像があった気がする。それを見て写真に一応撮ったと思う。

他にも何かあったと思うけど、夢なのでこのくらい。

RubyKaigi2024参加メモ

RubyKaigi2024に参加したので、思ったことをメモしておきます。

参加したセッションはこちら: https://rubykaigi.smarthr.co.jp/2024/plans/d2350276-c631-4bdc-ad75-49e446e798a3

今回のセッションをいくつか聞いてShopifyのやり方に憧れるようになった。エンジニアリングをしていく上での姿勢として、課題に対して上流から対処しよう、みたいな箴言があってそれが心に残っている。 ShopifyのRuby周りのチームはまさにそれを地で行っていると今回のセッションを聞いて感じたそういうチームに所属して（作って？）良いエンジニアリングをしていきたいと思っていたのだが、これまでは具体的なイメージいを持っていなかった。

ShopifyのRubyチームによる貢献にはすでに自分が直接的に恩恵を受けているし、彼らがどういう思想で取り組んで具体的に何をしてきたか、これからどういう思想でやっていくかを生で聞くことができた。遠いけれども具体的に目標とする存在に出会えたことが今回の一番の収穫だったと思う。

バージョンとかライブラリのインストールとか大変だしよく分からないのでスッキリする方向に進んでいきそうで楽しみ。セッションも普通に勉強になった。

一方的に知っていた人もお互い初めましてな人もお話しできてよかった。今回存在を新たに認知した人ももちろんいて、いろんな人が色々やっていることとか、意外とコミッタ少ないこととか認知できて良い。 Rubyって人間が作ってるんだなと感じる。

現実味を感じる一週間でした。

2024-05-12

社内外のrubyistの人たちとたくさん喋れた。明日ruby.wasmの話を聞けるのが楽しみ。質問するぞ！！１

2024-05-12

チャットを読み書きするのが大変なのではなく、それらを始めるのが大変という話。ラインが嫌いとかでは全然ないし、会話が嫌いなわけでもない。

僕はラインを手紙くらいの速度でしか見たくないと思うような付き合い方をしてしまっている。議論とかすり合わせをガッとする文脈になれば集中して通知を気にするようにはなれるのだけど、そうではなくて雑談とか、会話ではなく外部の処理に時間のかかるイベントの後処理とかをする文脈だとなかなか通知を見れないというか、そこに意識と返信の気合を割けない。

そもそもラインとか会話に限らず、返信とかリアクションを外部からの割り込み契機で行うのに辛さを感じる気がしている。例えば宿題出されてそれをやるのがしんどいのと同じイメージ。自分からこの辺の分野・技術を学んでみようと思ってやるのは何も辛くないし、むしろ他の辛さを乗り越えてでもやろうと思うが、それが外部から要求されると辛くなる。

おそらく原因は人から指図されることではなく、自分がそれをやる体制に入っていない状態で、やる義務を感じてもやる気にならないことにあると思う。宿題はやり始めて意義を感じたり調子が出たりすることでやるのが辛くなくなる。それが2,3週間かかるものであったとしても、体制に入れると辛くなくなる。

ラインの件も同じだと思っていて、普段僕は会話や事務処理をするモードではない。そのタイミングで人からその依頼が飛んでくると、会話に返事する義務を感じはするものの、処理するやる気は出てこない。

雑談はしてると楽しいし、事務処理も乗ってくると楽しいものではあるのだが、それらを始めるのに時間がかかるし、大変なのだ。これは子供の頃から変わらない（なんなら全人類そういうものなのではないだろうか）ので受け入れて自分の問題として迂回するなり利用するなりしていこう。

ちなみに仕事でSlack使うのは全然苦ではない。仕事するためにSlackでコミュニケーション取るのは有効だと思っているし、始業はすでに始めるインセンティブを持てているので苦なくSlackコミュニケーションは取れる。プログラミング集中してるときとかは通知に気がついてもちょっと返信したくないときがあるにはあるが、それくらい。基本的に仕事するときにはリアクションを優先するモードになっているのだと思う。コードレビューと同じ意識を持っていて、普段のあれとは異なる。そして、仕事する時間は決めていて休日にSlackの通知は切っているがそれが他の人に対しても共通の認識になっているのは良い。

ラインでも時間決めてプロフィールに書くとかするか？（あまり書きたくないけど）。休日の作業しない時間とかになりそうではある。ちなみに今がほとんどそんな感じの運用になっている。

感謝を伝えるのが苦手で、ご飯奢ってもらったりプレゼントをもらったときとかどういう顔をすれば良いかわからなくなる。

ラインでそれをやらないといけない状況ではなかなかヤバい。気がつくとなぜだかわからないが（ライン見ないからなのだが）伝えたい感謝が2,3個溜まり、ついでに謝りたいことも少しできてたりする。早めに、こまめに連絡するのが良いのだろうな。

感謝を伝えるのは単に技術の問題な気がするのでさっさと習得しよう。特に複数溜まった感謝の意を伝える能力が欲しい。

会話やチャットに文脈があるように、僕が日々過ごすことにも文脈というかモードというかがあるみたいだ。仕事、雑務、おしゃべり、勉強、家事、読書（小説）、読書（技術書）、外出、網羅的でも排他的でもないが、それぞれに飽きて数ヶ月やらなくなることはないが、数週間くらいならおろそかになるものが出てくる。

排他的ではない例として、仕事な雰囲気になっているときに雑務、おしゃべり、プログラミングは全然する。ただし、雑務やおしゃべりはプログラミングに集中しているときはできないし器用に行き来も無理。

このセクションは、だからどうというわけではないのだけど走っているときにそんなことを思ったのでメモ。

2024年4月での振り返り

4月が終わるので（？）最近のことを振り返る。

1月に配属されて、2月開発にプロジェクトが始まってからずっとLOLIPOP! for gamersを作り続けている。今まで本で読んだようないろんな苦しみを体感できて楽しい。プログラミングに関することや、設計とか技術選定、開発体制や組織、チームとか締切とか工数みたいな大変さを一通り味わったと思う。

自分がうまくできなかった・できた経験や周りの人が自分より上手くやったりあるいは自分が彼らにアドバイスする経験を積めた。修行を積んでいる感じがする。

修行が必要なのはそれはそうと思うのだが、戦略的に仕事したいなとも思う。たとえば１ヶ月後は今の倍のスピードで開発できるようにしたいがどうすれば良いだろう、とか考えて立案して実行するとか。

学生の頃に感じていたプログラミングの課題が感覚としてわからない気持ちはだいぶ薄くなってきた。そろそろ腰を据えて課題を整理して解決を図る余裕が欲しくなってくる（自分で作るぞ）。

Webアプリケーションを作っている。知らない人が変更をするであろうプログラムを作ることが仕事。実行環境は不安定で、このプログラムは複数のプロセスで同時に走るし、どのタイミングでプロセスが落ちるかわからない。

DBとかの外部サービスは自分たちが実装しているプログラムよりも余程信頼できるもので、一貫性とかを担保しようと思うと外部サービスに頼ることになる。もちろん我々が実装するサービスを雑に作っている訳ではないが、外部サービスを選ぶときには厳しめな基準を持っているので信頼性が違うのは当然に思う。 Webアプリケーションはたくさんの人が作っているので、そのための外部サービスが成熟しているのは当然なのかな。一方で、プログラミング言語を設計するときに使えるツールってそんなになくて、自分で実装するものが理解できて使うの楽なイメージがある（僕はにわかなので見当違いなことを言ってると思った方が良いかもだが）。

そう思うと、Webアプリケーションを作る仕事はインターネットから情報を探し出して信頼できるツールにうまく責任をなすりつつ、本当にやりたいことを見失わないようにハンドリングすることなのかと思う。そのためにモデリングとか設計とかするのかな。インターネットから欲しい情報を探し出したりそれらを組み合わせて実装するのもまあ大変。

この解釈はなんだか悲しいな。プログラムを作ることが目的になっている視点な気がする。これを悲しいと思ったのは、ぼくが思う正しい仕事が事業で利益を上げることではなく、誰も知らなかったこと・できなかったことを明らかにして誰でもできるようにすることだと捉えているからだろう。やるのが大変で、それをやったのであれば誰もできなかったことをできたのは間違い無いのだろうが、後から来る人がそれをやりたいと思うかや、やりたいと思ったとして自分の影響で簡単にできるようになったかは別の問題。事業でやる分には競合が同じ苦労を味わったりするような状況で放置することも多いはず（この辺はペパボはいい感じだと思う）。

数年前よりも良いものを早く作れるようになることがWebのエンジニアリングでは求められていて、そのためには知見を集めつつそれでも叶わない課題を見つけてそれを解決する手法を提案・実装・共有することが必要なのだろう。その中でそれまでの仮説を否定するものがあると、パラダイムシフトが起きて自分も含めてみんなで楽しくなれるのだろう。仮説を否定するためには流れに乗るのではなくて既存の目的や仮説を理解した上で、自分が先端の課題に向き合って試行錯誤して課題解決することが必要なはず。そうやって狙ってやった提案がハマると気持ち良いだろうから、それをふんわりとしたエンジニアリングの目標にするのは一つの手だと思う。

2024-04-21

ボトムアップの学習と、トップダウンの学習の使い分けがずっとわからない。ボトムアップな学習は技術に対する好奇心からくると思っていて、トップダウンな学習は課題が動機になっていそう。

トップダウンな学習をすることで、課題解決のための技術を手に入れらる。ボトムアップな学習では既存の手法を理解して、それをベースにした課題解決方法の探索ができるようになる（キャッシュできる）。

課題解決の方法を模索するときには、問題を分割してそれぞれを解決する。筋の良い分割をして、それぞれの問題を解決できるようにしておく必要があって、逆に解決できる課題の組み合わせだと元のでかい課題を捉えられるか否かがその人の課題解決能力を左右する。

もちろん分割結果を元から想像できるわけがない（そういうものもあるけどそれはそもそもその人にとって課題って感じではなさそう）ので、問題のある分割による簡単さの増分を感じ取れると良いのかな。その増分を計るために経験を積むとかベストプラクティスを学ぶとかするのだろう。でもこれだと高々局所最適な感じがする。それが常に悪いわけではないだろうけど。なので人はいろんな方法を検討するのかね。単純にそんな綺麗に微分するみたいに問題を認識できないからか。

2024-04-20

あれ実装したいなと思って手を動かそうとしちゃうの良くないな。とはいえその直感を無視するのは悲しいので意義を議論して見るのはありかな。

最近だと複数プロセスのログが一個のログファイルに書き込まれるときに、プロセスごとにIDを振っていい感じにわかるようにしたい。プロセスもそうだしセッションでもそうしたい。おそらくotel?がその辺をやるやつなのだろうと想像していて、それを勉強して導入するのも良いしそれが合わなさそうなら自分の欲しいところだけ実装してしまっても良いかなと思っている。

なんだけどそれを実装したところで誰がどんな状況でどういうふうに幸せになるかをちゃんと説明できない。

ログ見やすくなって嬉しいのはそうだと思うが、じゃあいつログをどんなふうな目的で見るのか、そのときプロセスとかセッションで引けるとどう嬉しいかの説明は僕ができるものは弱そう。

こういうときに人格をふたつ用意してさっと議論に移れると良いだろうと思う。昔から何度もやってることではあるが、その作業に移るタイミングがランダムなのが課題だと思う。何が困るかというと、議論をしないで手を動かし始めてしうとか、重要性に気がつかなくてやりたいと思いつつ忘れしまうことがありそうなこと。あと課題を深掘りできてなくて、確かにその手段は良いものではあるけど、芯を喰った課題解決にはならないこともある。

hugoで多言語対応始めた

https://github.com/naoyafurudono/naoyafurudono.github.io/commit/b4966a3e96c2a8131da6d623cef85df5c97439ba このコミットみたいな感じで設定したりファイル名を変えたりすると、いい感じにパスを掘ってくれる。

パスを掘ってくれる以外のメリットは知らない。

ElmアーキテクチャをReactで実現する話

リアクティブプログラミングの勉強をしていた頃にElm言語を知って好きになった（全然コード書いてないけど）。特徴はElmアーキテクチャにあると思っている。 Webアプリケーションの大体のフロントエンドアプリケーションはこう言うアーキテクチャで表現できるはず、みたいなことを言っていて、そのアーキテクチャが簡単なので気に入ったのだろう。

ユーザやAPIとやりとりをするアプリケーションなので、外界からの入力は当然ある。

また、それによって（のみ）アプリケーションの状態は変化する。アプリケーションが取りうる状態はアプリケーションに固有だし、どんなことがアプリケーションで起こって（入力としておきえて）、その結果どのような状態遷移をするかもアプリケーションに固有。なのでそれらはアプリケーションの実装者が決める。入力というかイベントがあって、それによってある状態から他の状態に遷移する、状態遷移系を定義するのはシンプルに思える。

状態が決まればそれの描画結果も決まるはず。もちろんDOMとかスタイルを当てたりとかして状態を描画結果に対応づける方法はそのアプリを作る人が定義する。描画というのは状態から描画結果への写像なのだ、と思うのがシンプルなポイント。

最初にあげた、外界からの入力は曲者。クリックとかレンダリングとかAPIの呼び出しとかは、知ったことではない感じがする。少なくともフロントエンドアプリケーションの範囲で意味を定義して実装するものではない。なのでその辺はElmのランタイムがいい感じに実装してインターフェイスを提供してくれる。そのインターフェイスを使いつつ、イベントを定義することになる。

Elmアーキテクチャは最高なんだけど、仕事のプロジェクトで使うとなると言語の選択はもっと資本主義ぽい判断が必要になって、TypeScriptとReact使うかという気持ちになる。

幸いなことにこれら二つでElmっぽいことはできるので、今の仕事では黙々とそれを進めている。 Reactで違うところは、Elmランタイムがなくてもうちょっと小さな部品がたくさんあって、それをいい感じに組み合わせて使うところだと思う。useEffect で頑張るとか。

そのあたりを頑張っているうちとかに、だんだんElmアーキテクチャっぽくするのが辛くなったりして辛い。みんなで強い気持ちでその方針に向かうのが良さそう。

https://guide.elm-lang.org/ がElmのガイドでElmアーキテクチャを推してくれる。なのでみんな読んでほしい。

エフェクトハンドラで実現したい世界と、Elmアーキテクチャみたいな世界は重なる部分が多そうだと感じている。 Reactの開発者もuseContextはalgebraic effectなんだ！みたいなことを何処かで言っていた気もするし、誰しも思うことなんだろう。

2024-04-13

最近お仕事楽しいのだけど、ちょっと忙しすぎるかもしれない。

引越してから全然運動してないので、そろそろなんとかしたい。暖かくなってきたし会社にもだいぶ慣れてきたのでソリューションを編み出せる時期なはず。

2024-03-26

イベントソーシング？と言うのかわからないけど、イベントを全部持っておけば現時点での状態はイベントを全部みて計算できるので永続化しなくて良くない？みたいな考え方がある（はず）。

イベントを解釈する遷移規則が変わらなければそうだけど、実際のソフトウェアではプログラムは継続的に変わっていくもので、イベントの解釈が変わらないこと（もっと言えば解釈できること）を保つのは大変そう。検証するためにリグレッションテストみたいにスナップショットを取っておいて、遷移規則が変わるたびに新しい解釈結果と比較すれば良いかもしれないw。

世間ではその辺どうしているんだろう。遷移規則が変わらない範囲でこのアーキテクチャを採用することでクリアしてるのか、そんなことは気にしないのか（あるいは気にならないのか）、他に上手いやり方があるのか。

このアーキテクチャを採用する目的にもよるか。

Nextjsのプロジェクトにstorybookを導入してみた

https://github.com/naoyafurudono/timer/pull/1

このプルリクエストで頑張った。コミットメッセージにやったことは書いてある。

公式ドキュメントがしっかりしてそう。storybookが内部で使っているwebpackが@ インポートを読めないみたいで、プラグインを入れる必要があった。

storyの書き方: https://storybook.js.org/docs/writing-stories
Next.jsへのインストール: https://storybook.js.org/docs/get-started/nextjs
- コマンド一発だった。便利。
@ インポートが効かない問題の対処: https://qiita.com/sinnlosses/items/51e614570180c5f12e86

2024-03-22

2年間くらい不在だったフライパンのふたの取手をさっきリニューアルした。取手の穴に割り箸を差し込む運用からついに解放される。

ふたを掃除するときに取手を外したら、乾かしている間にネジがどこかに行ってしまったのだった。それから2年間ネジを探し続けてきている（まだ諦めてないぞ）のだけど、イオンで取手だけ売ってたので衝動買いしてしまった。多分今年のベストバイ。

2024-03-20

Webアプリケーションのテストをどう実施したものかと最近考えることが多い。 Webアプリは雰囲気で変更したいはずで（ソフトウェアって大体そう？）、またテストは長持ちしてほしいと思う。

テストではなんらかの仮定のもとで実装がある条件を満たすことを検証する。その仮定を上手に置くことがテスト戦略を決める人の腕の見せどころだろう。

例えば関数の単体テストをする場合は、そこに渡す実引数を仮定して、その関数の出力が意図した通りになることを検証するし、モックを使うならそのモック対象の振る舞いを仮定することになる。 e2eではユーザの操作を仮定するのだろう。

いろんな仮定の置き方とその結果実現できる検証内容がある気がしていて、安定した仮定（覆るとテストを直さないといけない）を選びつつ、そこがクリアできれば安心と思える検証内容を取ることがテスト戦略の設計で目指すことなのだと朝の東横線で思ったのだった。

で、そういうお得さを出せるように実装するのも大事なんだろうなと思っています。

2024-03-17

今日はランニングして、いい坂を見つけた。暖かくなってきたしランニングを再開していこうと思う。

この辺りは道が入り組んでいて、良いルートがなかなかわからないのが困りどころだった。逆手にとって地図を読みながら走ればナビゲーションができて楽しいはずだと気がつき地図を用意することに。

何年か前にopen orienteering map を使ったことを思い出して生成したら意外といい感じになった。家のプリンタはモノクロなのでコンビニで印刷してこようと思う。ロゲインを見据えて名所探しをしてもいいかも。

2024-03-14

数列とか、関係とかを日常会話で使える環境にいたいと思うことがある。あと高山ラーメン食べたい。荻窪ラーメンでもいい。今週末荻窪行くか。

ラーメン
ランニング
銭湯
図書館
前住んでたところ

2024-03-09

フロントエンドのモデルとRPCについて考えてみたい。

Webアプリケーションのフロントエンドがリッチなときに、テストをどんな感じで書こうかとか、そもそもアプリケーションをどんな感じで書こうかと悩む。僕は悩んでいる。

ユーザとページがあって、必要に応じてAPIを呼ぶ、その結果画面遷移が起きるくらいのものだったのが、しっちゃかめっちゃかしてきてそれを理解できるのはコードを書いた時空にいる人のみになる。

フロントエンド、副作用が多すぎるんだよな。レンダリング、人間、apiが絶対にいるのでそれは大変に決まっている。ログを気軽に残せないとか、エラーの出し方に気を使うのも辛い。Webアプリのバックエンドなら、しょうがないからログたくさん出して500返しとくかができるけど、フロントエンドで想定外が起きたときに、すまん壊れただけでは完結しない。

そもそも完結しないようなレイヤ分けが間違ってるのか？ネットワークの隔たりとレイヤ分割が一致してしまっているが、フロントエンドアプリケーションも気軽に壊れさせてあげてほしい。その内容をログに取ったりユーザに幸せになってもらうためのあれこれは他のレイヤでやるべきなんじゃないかと思ったりしました。

今お酒を飲んでいるし、今日会社で上司というか先輩というかがウイスキー好きだとしって酒モチベが高い。最悪だな。

お酒を楽しく飲める会をしたいね。酒の好きなところを語ると良さそうに感じたのでやります。

まずいやつはまずいけど、美味しいやつは本当に美味しい。他の食べ物と同じで体調とか好みによるのだけど、摂取するもので酒が一番美味しいことはままある。ウイスキーとビールは特にそう感じる。日本酒とかワインはそんなに美味しくないと思います。

アルコールを摂取するといわゆる常識を司る理性が外れて、あらゆる人と小学校の友達のように接することができるようになって楽しい。それっぽい言い方をした（？）けど、僕が小学生みたいな動きをしてるだけかも。

あと音楽聴くときにはアルコール入ってるともっと楽しめて好き。

インカレの1,2週間前くらいな感じがして楽しい。フルタイムで専門目な領域なのが痺れる。

2024-03-07

昔はIPAが好きだったのだけど今はハイネケンが好き。理由は今も昔もなんか甘い気がするからで、味を認知してからそれを好みと判定するところは変わってないけど味覚を認知するところが変わったのだろうと思う。

そういえば麒麟のIPAが好きだったんだけど最近見ない。https://drinx.kirin.co.jp/beer/grandkirin/ipa/ と思ったら終売していた。https://drinxfaq.kirin.co.jp/faq_detail.html?id=12066。悲しいね。

学部生の頃に研究室のゼミ前の小ネタで喋ったスライドにグランドキリンのことを書いていた。slide (pdf)

（合掌）

今見返すとグランドキリンへのコメントがよなよなエールに似てるとしか書いてないな。本当に好きだったのか？

2024-03-02

op inject が欲しいやつだった。テンプレートに1passのURLぽいやつを書いてコマンドに渡すと、そこを埋めたファイルを出力してくれる。埋め込むときに環境変数を読んで、URL内での参照を置換した上で1passのレコードを参照することもできる。

https://developer.1password.com/docs/cli/secrets-config-files/

2024-02-27

職場が遠い
ネット回線の契約が不自由
間取りがそんな良くない
浴槽がちょっとせまい
ゴミ出しの曜日
- いまだに覚えられない
- 資源ごみが土曜日だとgood
- いつでもだせるとbetter
ベランダでタバコ吸う輩がいる
- 洗濯物ほしてるとにおっていや
外からたまに塩素臭がする
和室を洋風に改装しているのでところどころ微妙
- 収納が押入れであることとか
洗濯機が室外に置く間取りなのでドラム式を買いにくい
食洗機がない
段差があるのでルンバしにくい
電車で横にいる人がにおいがち
- これは不思議。座る頻度や時間が増えたことも関係するかも

2024-02-26

人間失格の主人公はそんな失格っていうほどやばい人には思えないというのはあるあるだと思っていて、そういう感想を抱いたことで自分を許せるようになったと思う。そういう人も結構いるんだろうと思う。

太宰修がまともじゃない人間について描写したおかげで、それを読んだぼくみたいな他人がもっと救いのある解釈を手に入れられたのだ。当の太宰修は自殺してしまった（理由をぼくは知らないけど）が、彼の残した解釈のおかげでぼくはそれなりに幸せに生きているのでなかなか感謝している。昔は太宰修は愚かだと思ったけど、たたきを作った人は偉いし、その恩恵を自分は受けているのだった。

久しぶりにUbuntuでブログを書いのだけど、入力がキビキビしていて気持ちがいい。最近は会社や私物のmacを使っていた。何が違うんだろう。

2024-02-18

今の家に初めて人を呼んだ。酒を飲んでタバコを吸い、餃子と焼きそばを作って食べた。どれもうまかったけど寝起きにタバコとコーヒーを一緒に摂取したことでキャパオーバーしてしまった。

The Pieceという良さげなタバコを3本もくれたのは感謝だしおいしかったのだけど、適量を超えてしまった感じがする。がっつりタバコにやられた感じがあるので、今後はもう少し避けるようにしよう。

2024-02-17

glangにgeneraterを入れようというプロポーザルがあって、試験的に実装されているみたい。いくつかのパターンがあるけど、だいたいこんな感じで使える (The Go Playground)。

ジェネレータとして使われる関数は定義の段階では普通の関数と区別がつかないような構文定義をされている。コンパイラやランタイムの実装が気になるし、静的解析ツールが大変なことにならないかが心配。

気が向いたらプロポーザルを読もう。ジェネレータが引数にとる関数がブールを返すけど、どちらを返すかを誰が決めているかも気になる。

第一印象ではgolangには入らないで欲しいなと感じた。

2024-02-13

今日1on1で教えてもらった。ロールモデルとして追っていく。https://scrapbox.io/kawasima/%E3%82%A4%E3%83%9F%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%96%E3%83%AB%E3%83%87%E3%83%BC%E3%82%BF%E3%83%A2%E3%83%87%E3%83%AB

2024-02-12

管理画面の設計について考えてみる。 Webアプリケーションでもろもろを設定する際のUI設計を考えている。

設定の初期化時や更新時でフローが異なるはずだ。

初期化のタイミングでは、氏名やメールアドレスの設定・認証や、オプショナルな事項（決済情報とか追加の契約事項とか）の設定が挟まり、最後に確認してよければコミット、ダメなら修正する。

更新では最初の設定で気に食わなかったところを修正したり、追加の設定項目をいじったりするだろう。

それぞれのタイミングで何を設定させるかや、どれだけサクサク入力できるかによってユーザの体験が左右されそう。例えば初期では認証情報だけをコミットして、その他の情報は更新で登録する手もあれば、ファストバスを登録時に持ってきてしまって、8割のユーザが最短で使用を開始できるようにするパターンもあるだろう。

ユーザが行うそれぞれのフローはアプリケーションというかシステムにどのような影響を与えるだろうか。というよりも、ユーザがそれぞれのフローの結果及ぼせる作用をどのようにデザインすると良いだろうか。

この作用をデザインするにあたって、アプリケーションで表現するモデルがどんなであるかを明らかにしておくと良いはずで、そのモデルに対する作用の一つの実現方法としてユーザが操作するフローがある、と思えそう。

ユーザによる操作じゃない作用としては、決済が行われたとか権限が時間経過で失効したみたいな作用がありそう。

データにもいろいろありそう。モデルを表現するためのデータと、作用を実現するために一時的に保持するデータは異なる。

例えばユーザが登録されているか登録されていないかしかないモデルでは、メール認証中にはユーザが登録されていないけど、メール認証のためのトークンとかはサーバにデータとして持っていないといけない。

もちろん、そういう一時的な状態もモデルに含めるてもあるはず。RDBで実装する場合delete操作が激しくなりそうだけど。セッションキーもそうかな。セッションキーはモデルを表すデータに持つことは少なさそう。モデルの表現には含まれないログイン状態として扱われるイメージがある。揮発性のあるデータストアで保持しそう。

全部モデル化してしまうのが教科書的なんだろうな。汚いとわかるならあえて汚いことをやる必要はないだろう。

モデルではないけど、DBMSの都合について説明する記事があったので貼っとくセッションの保存などにRDBMSよりもRedisやmemcachedのような、NoSQLが向いているのは何故ですか？他にNoSQLの用途として向いている(いない)処理にはどのようなものがありますか？ (Quora)

TTLが欲しいよね、という感じか。確かにそもそもセッションキーにはTTLが欲しい気がするし、モデルを考える上でTTLはあまり意識したくない気もする（頭弾けそう）。

反面、TTLもうまく表現したら面白そうな気もするし、割と欠かせないんじゃないかという気もする。そのときに普段のモデルを表現するのに使うDBとTTLを複雑さを吸い取らせるために導入したDBが異なると不必要な複雑さが生じたりするかもなと思った。

今日たくさん寝て軽くランニングしたらなかなか幸せな時間を過ごせた。ただいまはそのクオリティが持続していない。夕食の目処が立っていないこととか部屋がちょっと寒いこと、姿勢が微妙なことが原因だろう。軽く座って作業する空間はやはり欲しい。机にがっつり向かうか後傾でノートパソコンを叩くか、床で作業するかの三択でQOLっぽい作業時間を過ごす空間がない。コメダで作業する姿勢を家でも取れるようにしたいイメージ。やはりベンチソファだと思うんだよな。僕のユースケースだとソファだけでなく机も欲しいことに気がついたのが今週末の成果。

あとは壁が寂しいことにも気がついた。なんか怖くないすっきりとした絵とか飾ればいいんだろうな。めんどいので誰かに決めてほしい。ああいうのってどこで売ってるんでしょうね。

2024-02-10

このブログを読んだと感想をいただいた。初めて読んだ人を認識したのでなかなか恥ずかしかった。読まないで欲しいわけではないのだけど、これは人に読まれると恥ずかしいやつだよなと日々思って書いている。

人間性が出ているみたいなことを伝えてもらった。確かに隠し事をしないように（というか内面を晒すように）書いているつもりなので、その意図が叶っていたようで嬉しい。

ファインディング・ニモという映画が好きだった。ニモは僕が言葉を音でしか認識せずに見て記憶している映画だ。なので「ニモ」という表記がなんだか変な感じがする。あと、昔はfindingではなくfightingだと思っていた。その間違いは以前から認知していたのだが、主人公がニモではなくてお父さんであることに（タイトルから察した場合はだが）今気がついた。ニモが主人公だと思い込んでいたのと、お父さんとニモのビジュアルが似すぎているので英語の間違いは腑に落ちていたなかった。僕の父親からドヤ顔でファインディングだぞ言われたときにはうるさいぞと思った。今考えてもどっちでもいいんじゃないかと思っている。

プラットフォーマの良心

プラットフォーマとして、つまり場を提供してその場を幸せな環境として維持するものとしてリーダーシップを発揮することは綺麗なことだと思う。

gmailやyahoo mailがメール送信者のガイドラインを発表して、それを元に受信者・送信者双方にとっての利益を追求したことは記憶に新しい（少なくとも僕にとっては）。風当たりのあることだし、プラットフォーマにとって利益のあるものではない（よね多分）が、それを主導したメールのプラットフォーマたちは綺麗なことをやったと思う。

僕はビジネスとか損得勘定のことはわからないのだけど、あれは間違いなく正しいことだと思う。例えば、あの声明を立案して推進して実行したのが僕だとして（そんなことはまず無理だけど、その責任を僕が負ったとして）、仮にそれが原因で責任を追及され非難を浴びたら、その非難を挙げた人々を憐れむ自信がある。憧れてしまう。ああいうことができる力やセンス・良心をもったプラットフォーマになりたいと思う。自分の良心に従って人の幸せを実現した彼らを尊敬するし、そうなりたいと思う。

ぼくの母校である大和小学校の校歌は「強く、正しく、美しく」を掲げていた。今回掲げた、憧れるプラットフォーマは強さと正しさを持っていた。では美しさはどこにあるだろうか。

RFC8058には美しさを感じた。実際的かつシンプルで、僕の尊敬するエンジニアが美しいと言ってくれそうな哲学を持っているように感じた。ああいう美しさをお前も表現しろよな！というのを校歌は僕に要求しているのだろうか。

あと僕がGAFAに目指すなら絶対Googleに行きます。Googleは美しさと正しさを持っていると思う。ブランディングが大きいのだろうけど。

話が二転三転したけど、正しさや美しさを体現できるだけの強さを手に入れたいと思っています。また、その強さを手に入れる過程で追い求めていた正しさと美しさを忘れずに、むしろよりしっかりしたものにしたいと思う。

2024-02-07

家の環境を良くしたい。家でやることの幅を広げていく。今までは衣食住に加えてパソコン触るかコーヒー飲むかくらいしか快適にできなかった。読書とかゲームとかを快適にできるように – 生活を快適にできるように – したい。

たぶん家具が足りないことが問題。居心地の良い場所がベッド・机・風呂・台所・トイレだけで、リビングみたいな概念が僕の家には7年間存在しなかった。リビングを作る。2月の目標にしよう。

あと福岡ってごぼう料理が得意だな？なべのごぼうっうまいんだなと、旅行で気がついたのだった。多分しばらくはすべての煮物に薄切りのごぼうを入れると思う。

https://www.youtube.com/watch?v=xTRx39EtPZ4

2024-01-22

今日は仕事で最近やってたやつをガッと片付けて褒めてもらった。やったね。近所の八百屋が復活していたので豪遊してきた。飽きたのでこれくらいで。

関数型言語の会に今度参加する。楽しみ。どんな人が集まるんだろうか。仕事でどんなふうに関数型言語を使っているかを知りたいし、語りたい。どんな論点がありうるだろうか。

2024-01-18

どっかで見たのでやってみたhttps://16test.uranaino.net/share/fjv4MRBoFqNv7yYuaOwO ぼくはうさぎ型らしい。ぴょんぴょん

2024-01-14

引越しの片付けがひと段落した。片付けてみると意外と片付くものでそれなりに快適。これから細々としたところを詰めていく。シンクのスポンジ置き場とか延長コードの配置とか。

狂言の附子はなぜか黒いイメージがある。水飴みたいなやつだったはずなので透明とか茶色がかった色が妥当なのだとは思うのだけど初めて演目を聞いたときからずっと附子は黒いイメージ。サトウキビを精製するときに黒いタイミングがありそうなイメージもある。多分石油に引っ張られている。

ぼくが小説を読むときは物語ではなく文章を読んでいるのだと気がついた。ちなみにこの気づきは過去に何回かやっている気もする。なので小説や純文学、エッセイやブログはぼくの中で割と近いポジションにある。

砂糖を入れておくための瓶を買った。欲しかったのは蓋が薄い金属でできた、ジャムとかハチミツとかご飯ですよとかが入っていそうなタイプのいい感じのサイズ感なやつ。見つけるのに難儀したが結局ダイソーで見つけられた。凝ったギミックとかいらなくて、「こういうのでいいんだよ」と言いたくなる。実家であのタイプの瓶に砂糖を入れているのを帰省したときに観測してよかったので模倣。お手軽で気密性がそれなりで、可用性もあるのが良い。母は偉大である。ちなみに附子の話は砂糖を瓶に入れようとして気がついた。さっき瓶を洗って乾かしているので明日砂糖を入れる。楽しみ。

生活水準ってなんなのだろうなと思った。引越しで生活水準を上げた実感を得たがじゃあ生活水準とは何かと問うてみたら上手い答えが見つからなかった。なんなんでしょうね。

クックパッドに登録したお汁粉のレシピが誰かにブックマークしてもらえた。嬉しい。写真の全くないレシピなのによく保存したなと思う。お汁粉レシピマニアとかだろうか。ちなみにぼくはこのブログにメモってしまったので参照していない。ログインしなくてもアクセスできるのは偉大。オープンなインターネットの良さ。でもブログページを仮にブックマークしてもらってもぼくはその事実をしれないので喜べないから悲しくもある。上手いプロトコルがあるといいのだけど（ありそう）。

2023-12-31

質量ベース。

あずき: 1
砂糖: 0.5
水: 4

渋抜き: 茹でてタンニンとかを抜く
1. 水から茹でる。沸騰してから20min蓋をして火を止める。
2. 煮汁を捨てる
煮込み: 柔らかくしたり味をつけたりする
1. 45-75min煮る: 豆の4-5倍の水を用いる。指で潰せるようになったらok
2. 30min蒸らす。加熱むらをなくす
3. 汁を捨てたり水を加えたりしてバランスを整える
4. 火をかけつつ砂糖を加える。沸騰後5minで火を止める

修論を提出して卒業した
入社した。7月までずっと研修をしていた。
7月末からOJTを始める。12月末までずっと。
- かっこいい先輩たちのかっこよさをたくさん見れたのが良かった
インカレの運営で演出のパートチーフをやる
- 多方面に迷惑をかけつつ、仕事を人に丸投げすることを覚えた
- しっかり進めるのは僕より得意な人がたくさんいるので基本人に任せる方がコミュニケーションコストを込みにしても早い
- 自分がやった方が早いことは特に思いつかないのが寂しいところ。仕事を説明したのが偉かったのだと思うことにすると幸せになれる？
同期が人生を進めているのも印象的
お金の自由が効くようになった
- 引越ししちゃった
- 行動範囲が劇的に広がったかというとそんなことはない。店入る頻度が増えたとかそういう程度。生活水準が微増した感じ。
出社の影響で運動が減った。8時間も働くと疲れちゃうので。翌日のことを考えて0時に走り出すのを恐れるのも要因だと思う。
学習時間はどうだろう。仕事で学習するからなんともか。自分の意思で選んだコンテンツを学ぶことは減った。

人生をやるぞ
- お金の自由が増えた分はここで生かす
走る。サブ3を達成する。マラソン大会を探そう。
- これとかで力量を試して11月とかの大会で達成する？ https://www.sportsentry.ne.jp/event/t/93823
自炊を増やす
- 夕飯の少なくとも一品は自分で作ったものにしよう
技術の話はまた別途

2023-12-26

ついったで同僚が panicIndex と言っていて、なんだそれと思ったので調べた。golangの文脈だったので想像はある程度ついて、golangのランタイムの一部として？実装されている関数でインデックスに関するパニックを投げる関数だった。

https://go.dev/src/runtime/panic.go

来年はついに配属される。小Rまでもそうだったけど求められることが変わるので楽しみ。今度は長くなるので、そこで効きそうな技術を特に強くしておきたい気持ちと、自分の主張を通しやすそうな環境なので好き勝手とがりたい気持ちがある。

どっちもやればいいかな。

2023-12-21

ターミナルのプロンプトを ❯ に一瞬変えたのだけど、心が荒みそうになったのですぐに 🐧 に戻した。

推し言語機能 Racket編

この記事はGMOペパボエンジニア Advent Calendar 2023 🎅会場の19日の記事です！

昨日はyagijinさんのReactやってる人向けのSwiftUI入門でした。 Swiftに興味があるReact信者の僕のために書いてくれたのかと錯覚しました。これを期にSwift UI入門しようと思います。 Swift UIは双方向バインディングを採用しているとのことなので、Vueとの類似もありそうですね。

Reactを書いている時間は癒しの時間です。ところでReactは関数型言語からインスパイアされた機能が多いですよね。今日の記事はそんな関数型言語の中でも僕の好きなRacket言語の記事です。僕が一推しするRacketの言語機能を紹介します。

好きなRacket言語の言語機能を紹介します。ざっくりとした紹介なので、ここでの知識を人に話したりプログラミングで活用する前に、節々で参照する公式ドキュメントを参照してもらえると嬉しいです。

契約
named let
動的束縛

ここでいう契約とは、関数の入出力の性質を関数定義の際に宣言しておくことで、関数を呼び出しを実行する際に入出力の値を検証し、違反していた場合にエラーを投げる言語機能のことです。余談ですが、契約と型は対応する概念です。契約の検証は実行時に行いますが、型検査はコンパイル時に行います。静的に型をつける言語では関数定義の際にその型を宣言することで、関数呼び出しのあるコードの入出力の方を検証し、違反する呼び出しを特定します。 ContractのRacket Guideを貼っておきます。https://docs.racket-lang.org/guide/contracts.html

ここでは https://docs.racket-lang.org/reference/function-contracts.html の例をお借りして説明します。

> (define/contract (maybe-invert i b)
    (-> integer? boolean? integer?)
    (if b ( -i) i))
> (maybe-invert 1 #t)
-1
> (maybe-invert #f 1)
maybe-invert: contract violation
  expected: integer?
  given: #f
  in: the 1st argument of
      (-> integer? boolean? integer?)
  contract from: (function maybe-invert)
  blaming: top-level
   (assuming the contract is correct)
  at: eval:2:0

冒頭の define/contract で始まるS式では、関数定義をしつつ、その関数の契約を宣言します。二つの引数 i, b をとる関数 maybe-invert を定義していて、bがtruthyなら-iを返しbがfalthyならiを返す関数として実装しています。この関数の契約は(-> integer? boolean? integer?) と宣言されています。これはinteger?を満たす値とboolean?を満たす値を引数に取り、integer?を満たす値を返す関数である、と読みます。

(maybe-invert 1 #t) という関数呼び出し式では第一引数に 1, 第二引数に #t を渡しているので入力に関する契約を満たしていて、返り値は-1になるので出力に関する契約も満たしています。そのためエラーが出ずに何事もなく計算結果の　-1が表示されます。

一方で、 (maybe-invert #f 1) という関数呼び出しでは引数の順序を間違えて渡しているようです。第一引数にfalseを表す #f を渡しています。#f は integer? を満たさない（そういうふうに integer?が定義されている）のでRacket処理系は契約に違反している旨をエラーとして表示しています。

こういうのが契約です。ちゃんと確認していませんが、PHPで型注釈を書いた際にも実行時の検査が行われるそうなのでPHPは契約を言語機能としてサポートしているといえそうです。他にはD言語も契約をサポートします。

入力値のバリデーションはコードを書くときに当たり前に行う作業ですが、それをシステマチックに行うためのフレームワークを言語が提供してくれるのは魅力的だと思っています。また、契約は型システムや漸進的型つけとも密接に関わりがある楽しい概念です。

次はnamed-letです。これについても公式ドキュメントを貼っておきます。https://docs.racket-lang.org/reference/let.html#%28form._%28%28lib._racket%2Fprivate%2Fletstx-scheme..rkt%29._let%29%29

RacketやSchemeなどのLisp系言語で勉強しているとwhileやforは習いませんが、再帰を習います。例えば整数のリストを受け取って、その和を返す関数sumを定義するにはこんな感じで書きます。

> (define (sum lst)
          (if (nil? lst)
              0
              (+ (car lst) (sum (cdr lst)))))
> (sum '(1 2 3 4 5 6 7 8 9 10))
55

nil?はリストが空を判定し、carはリストの先頭要素をとる関数で、cdrはリストの先頭を除いた部分をとる関数です。先頭の値とそれ以降の和をたすことで、リスト全体の和を得ています。

このように再帰があればループはかけるのですが、関数を定義してその直後にその関数を呼び出す、そしてその後その関数は使わない、みたいなケースがしばしばあります。そういうときに役立つのがnamed-letです。以下のように再帰関数の定義と関数呼び出しを同時に行うことができます。

> (let sum ((lst '(1 2 3 4 5 6 7 8 9 10))
       (if (nil? lst)
           0
           (+ (car lst) (sum (cdr lst))))))
55

再帰関数を使ってループを書くことでループの中での再代入を避けることができます。そのためループ不変条件を把握するのが楽になります。そしてnamed-letを使うことで、不要な関数定義を省くことができます。スコープにある変数は少ないほど嬉しいです。ここだけで使う再帰関数なんだということが一目でわかります。あと書いてみるとわかるのですが、named-letを書くととても気分がいいです。

最後は動的束縛です。emacs lispの変数束縛は動的だということで有名ですし、最近だとReactのContextが動的束縛っぽいかなと思います。やはり公式ドキュメントのリンクを貼っておきます。https://docs.racket-lang.org/guide/parameterize.html

誤解を恐れながらいうと、環境変数みたいなやつをコードの中で設定できる機能です。公式ドキュメントの例をそのまま貼り付けます。

> (parameterize ([error-print-width 5])
    (car (expt 10 1024)))
car: contract violation
  expected: pair?
  given: 10...
> (parameterize ([error-print-width 10])
    (car (expt 10 1024)))
car: contract violation
  expected: pair?
  given: 1000000...

REPLで2回プログラムを実行しています。(expt x y) は x の y 乗です。それのcarを取ろうとしています（carはリストの先頭要素を返す関数でした）が、(expt x y)の計算結果は数値であってリストでないのでcarの契約に違反します。そのためエラーメッセージが表示されています。今回フォーカスしたいのは動的束縛です。parameterize で error-print-widthの値をそれぞれの実行で 5 や10に指定しています。その結果表示されるエラーメッセージの幅が5になったり10になったりしています(10... と 1000000...)。おそらくエラーメッセージを表示する関数の中で error-print-widthが参照されているのでしょう。

このように関数を呼び出すタイミング側でその振る舞いを変えられるのが動的束縛の旨みです。関数の引数で渡す必要がないので、動的変数を参照する関数と設定する関数の間の関数たちが余分な引数を取らなくても良いわけです。

グローバル変数を使ってもこのような引数を介さない設定はできますが、動的束縛を使う方が衛生的です。例えば一つのプログラムの中でグローバル変数の値を変えたい場合、グローバル変数の値を書き換えることになります。これは悪名高い可変なグローバル変数を使うことを意味します。可変なグローバル変数は無関係に見えるプログラムの実行順序がクリティカルにプログラムの振る舞いを左右するのでよくないです。

一方で動的束縛では関数呼び出しごとに値を設定するため実行順序のことは気にしなくて良いです。値を設定した呼び出しの範囲下ではそれが反映されるし、その範囲外ではその設定は無効化されます。このように衛生的に、かつ疲れない形で広い範囲で参照する値を設定できることがグローバル変数と比較した際のメリットだと思います。

動的束縛される変数を参照する場合、呼び出し側の不慮の事故によって変数の定義もれでプログラムが正常に動作しないかもしれません。環境変数を設定し忘れるとアプリケーションが動かないのと同じです。こういう事故は実行する前、例えばコンパイルしたり型検査のタイミングで気がつけると嬉しいですよね。

Racketでこの課題を解決できるかは知らないのですが、エフェクトハンドラとエフェクトシステムを使えば型検査の中で解決できます！その説明をしたい気持ちが溢れているのですが、そろそろ日を跨ぎそうなので興味がある方は僕に声をかけてくれると嬉しいです。

プログラミング言語の言語機能、いいですよね。言語設計者が思う表現のベストプラクティスが詰まっていて触れるたびに嬉しくなります。

明日のアドベントカレンダーは冷静沈着なTepiさんがTextのJetpack Composeで画像表示した話を書く予定とのことです。 Jetpack Composeは名前しか聞いたことがないので、新しい概念を見られそうで楽しみです！

それでは良いクリスマスを！

2023-11-25

依存性逆転の原則の何が嬉しいか思い出せなくなったので考えてみる。

ぼくが今思い出せる依存性逆転の原則は、抽象度の高いロジックを表現するのにそれを実現するために必要な部分問題の解決があるとき、抽象度の高いロジックが部分問題の解決方法に依存しなくなることが嬉しい。

Dependency injectionでは抽象度の高いロジックは部分問題に依存するけどその解法には依存しないことで依存性の逆転を実現する。関数呼び出しみたいな感じで、ロジックの使い手が解法をロジックに適用する。

最初の文で終了していた。気が向いたら答え合わせしよう。

ティッシュ箱の製造が寡占されているか知らないけど、なんだか寡占されてそうだなと思った。構造はだいたい同じだし。口にあるビニールの素材は材料も分厚さも違いを感じたことがない。箱の紙も違うことがあるんだろうか。ペットボトルも寡占されてそう。なんというか要件はどの消費者に対しても均一な商品は寡占しやすいのかなと思う。ペットボトルは自由度が高くて消費者の要求も色々ありそうだが、ティッシュ箱はだいぶ均一そう。局所的なシェアを確保しにくいことが寡占の要因なのかな。

感性で評価するものは寡占しにくい。反対に評価関数が定まるものは寡占しやすそう。プログラミング言語は寡占しにくいがコンパイラは寡占しやすい。食品は寡占しにくいが、精密機械は寡占しやすい。アイドルは恋人に比べて寡占しやすい。

2023-11-22

高校生の頃、進路を考えるにあたって自分は何を求めているかを真剣に考えて幸せになることだと行き着いた。幸せにも色々あるはずで、僕の幸せはなんだろうかと思った結果、いろんなことに理解を深めることかなと思い至って進路を決めた（理学部に進学した）。大学で少し考えを変えて色々うまくできるようになることに重きを置くようになった。その中で理解することに重きをおいてはいるけど。

今日本屋さんでニコライ倫理学に出会って幸福が大事だよね、みたいな考え方に出会ったし、昨日同僚と理解とか認識・意思の話をした。昨日今日で自分探しの旅の振り返りタイムが訪れたような感じ。記念にメモしておく。

TypeScriptを最近書いているのだけど、型をどこで定義してどのように依存関係を表現するかで迷い続けている。構造的部分型を許すとこういう悩みが生じるのかという感じ。むずい。自由なのは難しい。

割といいノイキャンヘッドホンを買ったのだけど、おかげで音楽を聴く時間が増えたし好き嫌いがはっきりした。感動する時間が増えた。道具がいいとそれを使った営みが幸せになる。パソコンや家とかも大事な道具だろう。やはり道具は大事だし、それを揃えたり試すためのお金も大事。

道具を作る能力も大事だ。 Unixっぽい環境やオープンソースなツールは自分の意思であれこれできて道具を作りやすい点が良い。幸せになれそう。

何回読んでもいい。こういうのをツイートすべきなんだろうな。

吹き出しの外でぼそっと発言するやつできるとうになりたくなる。

グラスに注いだビールの上の方に泡があるのはそれっぽく見えるけど、実際に飲むときには泡はおいしくなくて全部液のままであって欲しいと思う。

ぼくが日常会話で使える絵文字は :tada: くらい。あとは絵文字の名前を覚えていられない。おかげでなんでも祝えるようになりそう :tada:

国産のりという表記を見つけた。イタリア産なら勝てそうだけど、他には無理だろうなと思った。

2023-11-16

家ごとにホコリに傾向があるんじゃないだろうか。家人の髪やシーツ、カーテンなどホコリを左右するファクタは多そうで、ホコリは家の特徴を切り取っていそう。猫の味は分かるか知らないが、猫のいる家はホコリを見ればわかる。味覚ではなし得ないテイスティングをホコリで実現できるのだ。

掃除機はそんなホコリを集める機械で特に集塵ボックスとでも呼ぶのかわからないけど、ホコリが溜まるパーツは家の特徴を凝縮した場所だと言えるはず。

ぼくの家では顆粒だしをこぼしてルンバに食わせた。ルンバの集塵ボックスでテイスティングしたらどんな判定になるだろうか。

2023-11-14

このブログのデプロイに使っているgithub action workflowを読んでいたら、外部リポジトリにデプロイするのも簡単なことに気がついた。https://github.com/peaceiris/actions-gh-pages/tree/v3/#%EF%B8%8F-deploy-to-external-repository-external_repository

たとえばプライベートリポジトリでマークダウンを管理して、公開したいアセットだけを今のリポジトリに置く運用を実現できる。公開したくない文言はどこにも書かない運用にしているのだけど、限界はたまに感じるので移行しても良いかも。とはいえ情報はできるだけオープンにしたい信仰があるのも確かなので悩ましい。

2023-11-07

ドキュメントを読むときに参考文献が適切に使われていないと辛い。ドキュメントには2種類あると思っている。

水先案内
主張をするドキュメント

主張をするタイプのドキュメントで参照先を読まないと主張を理解できない場合は辛い、というのが今回の主張。

水先案内のドキュメントとしては、wikipediaの水先案内ページやgoogle検索の結果ページが該当する。水先案内のドキュメント自体は主張をしておらず、その水先案内ページに辿り着いた読者が適切なドキュメントにたどり着くためのサポートをする役割を持つ。

主張をするドキュメントとしては、この記事やAPIの仕様を説明するページなどが該当する。参考文献とか例を上げる目的で引用とか他のドキュメントへの参照を持つことはあるけれでも、そのドキュメントを全く読まないでも主張を理解できることが期待される。もしも読まないと理解できないのであれば、その文章は主張をできていないんじゃないかと思う。サーベイ論文は主張をするドキュメントだと思う。参照を探す目的で使うこともできるけど、対象をサーベイしてこういう歴史があるとか界隈はこういう感じになっているよねといった主張をすることが目的なはずなので。論文のアーカイブページは水先案内。

ドキュメントはそれ自体で完結していて欲しいので、参照先に主張の内容が書かれているはドキュメントとして不十分で読むのが辛い。内容ではなく根拠を委譲するのは良いし、よくある引用のスタイルだと思う。

2023-10-29

新書で勉強しようとしても失敗する。話がまどろっこしく感じてしまって途中で投げてしまう。推敲していらないところを削ってくれ、読者はたくさんいるはずだから全体の利益を考えればそれがプラスになると思うんだ！みたいなことを思いだして読む気が失せてしまう。教科書とか読めばいいんだろうな。心理学の概論っぽい教科書は割と読めた記憶がある。暇で時間を持て余していた時期だったというのもありそうだが。あとおすすめされて読んだ社会学の新書は面白かった。民主主義とか共栄圏？だったかみたいな話が書いてあって今も多少影響されている。

民主主義の話っていろんな話があってかなんでかわからないけどこんがらがる。今僕がイメージしているのは、社会があって、その中の個人はそれぞれ独立していて互いに適宜頼ったりしながら、だけど依存とか支配とか隷属みたいなことはしないで、あるいは全く関係を持たないで営む社会のことを想像している。そういう社会では個人は日本国憲法を遵守しているようなイメージ。

独立の概念が難しいよなと思う。どういう考え方をするのがみんな幸せになれるんだろう。完璧超人がたくさんいる社会ではなくて、いい感じにみんなが仲良くできるような社会を構成するための個人の振る舞いのことを、独立した振る舞いというんだろうな。頼ったり失敗したり負担をかけるのは（程度の問題はあると思うが）okだと思う。この辺はきっと公共の福祉を害さない範囲ってことなんだろう。

飽きたのでこの辺で。

今日は大学の友達と走ってご飯を食べて、そのあと風呂に入って帰ってきた。バーミヤンでしゃぶしゃぶ食べ放題をやっていそうだったのでチャレンジしたのだが、残念ながら今はやってないとのことだった。結局普通のメニューから注文して満足している。もっとエンジョイする余地があったと思っている。みんなの近況をもっと聞けばよかったな。次の週末に会うのでそのときにしよう。

ご飯を食べたあとお風呂行く手前で御嶽山のイオンでウイスキーを買った。今はそれを炭酸で割って飲んでいる。山桜というウイスキーでなんかうまい。日本で作っているみたいだけどニッカみたいに甘くはなくて焼酎とかジンにあるようなアルコールの味がする。ドライな感じ？たしかに桜ではなく山桜がしっくりくる。以前飲んだときにフロムザバレルを持っていったことで友達を一人ウイスキー好きにできたようなので嬉しい。人を引き込むには好きにさせてモチベーションを持ってもらうのが良いんだろう。

昨日は家に引きこもっていたし、今日も夕方まではずっと家にいた。まったりした週末だった。こういうのもたまにはいいと思いつつ、もっと気合い入れてまったりしたい気持ちもある。この辺りは一人暮らしの弊害なんだろう。人と一緒に暮らしていたらまったりしようと話を合わせて、じゃあ何をアクセントにしようかと計画しそう。いい酒を買っておくから昼から飲もうとか、アニメやドラマを3クール一気に見るぞみたいな。

次の土日は千葉に行くが金曜日は暇なので何か計画しようと思う。会社の同期を誘ってもいいか。三連休なので向こうも何か予定が入っているかもだが。

2023-10-28

ジャンププラスの表示がどなっているか気になって開発者ツールでみたらなんかすごかった。アプリケーションのストレージにページをバラバラにしてパッチワークみたいにしたデータがあって、恐らくそれをいい感じに繋ぎ合わせて表示する感じでcanvas要素を使っているみたい。スクレイピングとかで漫画を引っこ抜かれないための仕組みなんだろうし、パッとわかるものではないだろうけど気になる。はてなのGigaViewrが使われているとのこと。ヒントとか開発話みたいなものが聞けないかなと思ってポッドキャストを聞いている。

2023-10-27

https とかで通信をするときはローカルにインストールされているCA証明書を参照する。 ubuntuの場合 /etc/ssl/certs/ca-certificates.crt がそれで、適当に名前を変えるとhttpsでcurlできなくなる。

🐧 curl https://pepabo.com -vvv
*   Trying 13.225.183.31:443...
* Connected to pepabo.com (13.225.183.31) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* error setting certificate file: /etc/ssl/certs/ca-certificates.crt
* Closing connection 0
curl: (77) error setting certificate file: /etc/ssl/certs/ca-certificates.crt

2023-10-24

hugoでCJKの文章で改行を無視できるようになった。 platexとかでは当たり前のように単独の改行は日本語文中で無視されていたが、巷のmarkdownエンジンはそうとは限らない。 hugoがデフォルトで使うgoldmarkではオプションで指定できていたようだが、 hugoではそのオプションを活用しないでいたみたい。

v0.118.0に更新される際に、hugoの設定でサポートされるようになった（リリースノート）。とてもめでたい。

昔は改行しない人間だったのだけど、論文を書くときに教えてくれていた先生が綺麗に改行しているのを見てそれに倣うようになった。テキスト処理は人間の仕事ではなくて、ソースコードは読み書きしやすい形であることだけを気にするべきだと信じているので改行は自由に行いたい気持ちがある。

先月PRを書いたやつがシュッとマージされていた。本当にそれでいいんか？という感じがするが、何はともあれコントリビュータになれたのは嬉しい。好きなツールに貢献できる喜び。

世の中にはいろんなソフトウェアやシステムがあって日常的にそれらを使っているわけだが、いざ何かを作りたいとなったときに何をするのが楽しそうかは悩んでしまう。何が面白そうかわからないのだ。普段使っているあれこれが100倍早くなったらどうなるかを想像して幸せになれそうならそれを実現するために頑張るのは便利な考え方かもしれないと思った。

2023-10-09

テキストを扱うツールをたくさん知れたことが情報系に進んで一番お得なことだったなと感じている。エディタ、git、その他CLIツールを日常的に使う環境に身をおけたことは幸運だったと思う。というか、これが幸運ではなく当たり前な世の中になって然るべきな気がしてきた。

2023-10-05

風邪を引いた。最初は喉が痛くて、次にはなが出るようになり何だか体がだるくなった。体がだるくなった時点で体温計で熱を測ったら37度あってなるほどなって感じ。これは無理だと色々諦めて会社を休みやるべきことを放棄した。

朝イチで病院の予約をしたのに予約がすでに7人も入っていてなんだそれってなった。世の人は暇なのかと実感した。病院にかかってから処方箋を手に薬局に行ったら１時間かかるとのことで一旦家に帰ってできたときに電話してもらうことに。電話を受けてからも気力が湧かず、30分ほど行かなきゃと思ってから薬局に伺った。結局薬を受け取れたのは午後だった。お昼を食べてから薬を飲んでたくさん寝た。

そろそろ飽きたので話を省くが、二日目の夜と三日目は頭の痛さとの戦いだった。ずっと寝ていたからかわからないけど頭がとにかく痛くて寝るのがつらかった。とはいえ寝るのが仕事だと思っていたので頑張って寝ることに徹した。起きている今はそれなりに楽。キーボード打っていると調子が出ないことはわかるのだけど。

2023-09振り返り

今月はインカレの運営準備と仕事を頑張った。またカレーとボルダリングを始めた。

インカレでは人に仕事を回す仕事でしっかりキャパオーバーした経験をできた。おかげで価値観を少し変えることができて、瞬殺できるタスクはすぐに瞬殺するのが楽だと思えるようになったし、瞬殺できない仕事もなんとか小さくしようともがけるようになった。この辺りは仕事でも意識しているところで、二つのサンプルがうまいこと僕の中で補い合って学びを得る機械になってくれた形だと思う。どちらもちゃんとした人たちが一緒に仕事をしてくれてフィードバックもくれる環境だから実現しているのだと思う。感謝だし、この環境に身をおけた運と自分を褒めてあげたい。

カレーもオリエンテーリングと職場の人たちが相補的に絡み合って好きになり始めた。ボルダリングもそうか。今の僕は職場とオリエン界隈の二つのコミュニティに支えられて生活を営んでいるみたいだ。充実している。いいこと。

ここまではいわゆるソフトスキルみたいな仕事をする上での能力とか趣味の話だったけど、純粋な技術の話でいうとWebアプリケーション開発のレイヤが低めのところが（どのくらいかわからないけど）強くなった。Rackみたいな構成とかDNSの話（間接参照は偉大だ）、アーキテクチャの成長のさせ方とかを新たに腹落ちさせた。

10月は趣味を深めつつ、ソフトスキルっぽい面ではきっちり仕上げるところを重視する。ガッとやる。技術はネットワークとかを深められると嬉しい。趣味は今のを深めていく。ボルダリングは週2回いけるといいなと思う。

GASでスライド生成

Google Slidesで作成したテンプレートファイルに文字列を置換する形でスライドを生成するスクリプトをChat GPTに書いてもらったのでメモ。

+--------------------------------+
|                                |
|  {{氏名}}                      |
|                                |
|                                |
|     {{住所}}                   |
+--------------------------------+

みたいなスライドを作って、

氏名,住所
佐藤太郎,日本のどこか
田中一郎,東京のどこか

みたいなスプレッドシートでスクリプトを実行すると以下のようなスライドをテンプレのあるスライドに追記する。

+--------------------------------+
|                                |
|  佐藤太郎                      |
|                                |
|                                |
|     日本のどこか               |
+--------------------------------+

+--------------------------------+
|                                |
|  田中一郎                      |
|                                |
|                                |
|     東京のどこか               |
+--------------------------------+

スクリプトは以下。

function createSlidesFromSheet() {
  var slideId = 'ここにスライドのIDを入れる'
  var sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
  var data = sheet.getDataRange().getValues();
  
  var slide = SlidesApp.openById(slideId);
  var templateSlide = slide.getSlides()[0]; // テンプレートとして使う最初のスライドを取得
  
  var headers = data[0]; // ヘッダー行を取得

  // データ行をループ
  for (var i = 1; i < data.length; i++) {
    var row = data[i];
    var newSlide = slide.appendSlide(templateSlide); // テンプレートスライドをコピー
    
    var shapes = newSlide.getShapes();
    for (var j = 0; j < shapes.length; j++) {
      var shape = shapes[j];
      var text = shape.getText().asString();
      
      // スプレッドシートのヘッダーを参照して、対応するデータでプレースホルダーを置き換える
      for (var k = 0; k < headers.length; k++) {
        var placeholder = '{{' + headers[k] + '}}';
        text = text.replace(placeholder, row[k]);
      }
      
      shape.getText().setText(text);
    }
  }
}

2023-09-25

昔スプレッドシートを頑張ってこねこねしてこなしていたような作業をsqlでしゅっとこなせるようになったことに気がついて。こういう成長なんだよなと思っている。

2023-09-22

仕事とか技術っぽい話をするときに背景が揃っていて欲しいと思う。議論や質問、ミーティングでは背景を合わせることを大事にしていく。背景がわからないとモヤモヤしてときにはイラっとするし、見当違いな方向に話が進んだりするので。

逆にそもそも背景が共有できている人との議論は楽で気持ちいい。そこから考えると以下をいかにさっとできるかで、話の通じる人になれるかが左右されそう。

常識みたいな考え方を（輪郭だけでも）把握しておくこと
自分が足りなさそうなときは（申し訳ないけど）質問すること
常識から外れたことが背景にあるなら共有すること
反対の状況では質問すること

2023-09-21

gh コマンドを使うとPRの番号とタイトルを取得できる。

gh pr list --search "<SHA>" --state merged`

https://cli.github.com/manual/gh_pr_list

"<SHA>" の部分は一般にクエリを指定できるそう。多分 pr:open みたいなやつ。逆にコミットハッシュを指定できることが驚き。

2023-09-19

ドキュメントを読むときにパッと見で読んだ気になってしまったので反省。とはいえドキュメントを使うときに理解しきるまで常に頑張るのもどうかと思うので難しい。

ちょっと二つのcsvをinner joinしたくなってtextqlを見つけて使ってみた。わりかしいい感じ。ファイルからsqlのソースを読めればなおよい。気が向いたらPR作ろうと思ったけど、最近コミットがないな…。

https://github.com/naoyafurudono/textql/tree/read-sql-from-file に実装した。go build textql/main.go でビルドできる。PR送りたいところだけど、テストも書いてない上に試してすらおらず流石に無責任すぎるので自重した。

使ってまあ大丈夫だろという気になったのでPR投げてみた。実はこれが通りがかりのOSSへの初めてのPRかもしれない。メンテナが気づいて気に入ってくれるといいな。

PR通らなくてもgolangなのでビルドが簡単でローカルに自分で書いたやつを置きやすいのが救い？

日記に書いた

ベストバイ

酔っていて興が乗ったので「しばらくの間で買って良かったもの」N選をやります！！

本棚を買いました！横に長いタイプの本棚で、高さは太ももくらいです。二段だけで、本棚の上にも物を置けるような感じ。幅は120cmくらい（ところでセンチって微妙ですよね）で、横に長めの本棚です。 2cmくらいの厚さのベニヤ？でできていて、それなりに丈夫そうな雰囲気があります。 minneで買いました。一階にプログラミング言語のほんを置いて、2階にそのほかの本を置いています。本棚にある本の中でのおすすめは、『数学の基礎集合・数・位相』です。これを読むと実数の作り方がわかって感動できます。また、眠れない夜にぴったりで、楽しめるときには存分に興奮できるし、そうでもないときには眠くなります。ホテルに聖書の代わりにこれを置いたらいいのにと思ってます。

M2 macbook airを買いました！これはいい物です。ノートパソコンのいいところは椅子に座らないでも使えるところです。仕事で疲れた体でも、ノートパソコンならさわれます。退勤後もキーボードを触る幸せを感じられるのはノートパソコンのおかげです。ところで酔った状態でキーボードを叩いていると、タイプミスが頻発します。タイピングに頭のリソースを使っているようです。 m2 macbook airはキーボードがいい感じだし、性能もいいのがいいところです。メモリは16GBにしています。細かいことはよくわからないので、考えないことにします。

キリがない気がするので個数制限を設けましょう。 N=5にします。あと3個。

ルンバを買いました。ルンバのいいところは、掃除でstuckしている光景がちょっとかわいそうなところです。彼は頑張って掃除してくれるのですが、たまに段差に座礁して身動きが取れなくなります。その姿は少し傷ましくて、それを避けるための掃除をしないとなという気持ちにさせてくれます。一人暮らしの家に優しさを発揮する機会を与えてくれるのがルンバのいいところなんじゃないかと思います。こういうふうに書くと彼はポンコツみたいな表現になってしまいますが、彼は僕より掃除が上手いです。頼りにしてるよ。

会社に入るよりかは前に、echo dotを買いました。 echo dot自体がもたらす利益よりも、そのインターフェイスがあることを前提とした環境構築への影響がノミネートの理由です。 echo dotのおかげでルンバやswitch botを導入できました。音楽も流せるしアラームも設定できる。

5月の頭にリュックサックを買いました。新宿の駅の近くの百貨店で見つけて、ゴールデンウィークいっぱい悩んでから購入に至りました。出勤も旅行もオリエンテーリングの遠征も全てこのリュックと一緒です。ちょっと小さいけど必要十分な機能提供してくれている感じが好き。

いかがだったでしょうか？この記事ではベスタバイ5選を紹介しました！この記事が皆さんの参考になれば幸いです。よかったらチャンネル登録と高評価、よろしくお願いします。

<!-- エンディングテーマが流れる -->

2023-09-13

今家のトイレで気がついてんですが、冷蔵庫と自分の体にはどんな落書きしても人に迷惑かけないので落書きし放題です！！何書こうかな…。

人生楽しくなってきた。今度人生つらそうな人を見たらこれを教えてあげつつ、鏡のある場所を教えつつ、マッキーをプレゼントしよう。

ちょっと前に買ったbowmoreが美味しい。味の表現はさておき美味しいからそれでいいんです。テイスティンググラスでストレートで飲んでいます。 aged 12 yearsと書いてあります。

350ml瓶を買ったんですが、このサイズの便が一番かっこいいです。他のサイズでかっこいいのはフロムザバレルくらい？

350のbowmoreはリュックの横に挿してもいいかなというくらいかっこいい。

会社ではあだ名で呼ぶ文化がある。それはなかなか楽しくて好きなんだけど、人生のほとんどを苗字呼びの文化で過ごしてきて、会社の飲み会で苗字よびをしてもらって、「ああ、こんな感じだったな」と昔の感覚を思い出した。新しく上の人から苗字呼びされる経験は僕にとって深いところに刻まれた体験なのかもしれない。

ホッピー師匠とも知り合えたことだし、今日の飲み会は僕にとっていいものだった。明日は走って帰るか。判断は夜にするとして、ランニングシューズを履いて、ジャージを持って出勤する。

まふまふの夢花火を久しぶりに聴いている。中学生に頃に友達にまふまふのCDを貸してもらって夢花火をしり、高校までめざましは夢花火だった。懐かしい思い出。

去年の暮れに会社の同僚がまふまふファンだと聞きちょっとテンションが上がったことを思い出した。今はまふまふの他にもdazbeeやado、co shu nieとかのアーティストが好き。オタクって感じがする。

オタクっぽくない歌手っているかと思うと、どのアーティストもそのアーティストが好きというと途端にオタクぽくなる気がするので気にすることではなさそう。 AKBもSMAPもheysayjumpも何もかも、アーティストが好きって言ったらおタックぽい気がする。

オタクっぽさを排除して「この曲が好き」みたいなことを表明しようと思うと、自身の音楽性に芯があるか流行りに乗っていくミーハーみたいになりそう。

そろそろ世間体について考えるのに疲れてきた。このくらいにしよう。僕がコモンセンスとして取れている自信を持っているのは、新劇場版のエヴァの最後のやつで「よかったねぇ」と思えたことです。ATフィールドは全ての人の間にあると思っているタイプの人間です。よろしくお願いします。

オフィスカジュアルっていうのやめません？曖昧で、インターフェースで要求しているような感じがしつつ、実装する側にはその要件が伝わらない。コミュニケーションのための符号としてあまり良く機能していないように見える。

ジャケット
シャツ
靴
パンツ

以上の四つについての要求を書いて欲しい気持ちが芽生えた。これらが指定されない限りは、どれだけフォーマルに寄っても、喪服まで行かない限りは文句言えないと思うし、喪服まで行かなくても服を着てくる側に対して不親切だろう。

2023-09-12

以下のあたりを完全に理解したらだいぶ楽になる気がする。

エラー処理
イテレータ
借用とcopy

エラー処理やイテレータの周りはrustに限らずどの言語でも乗り越える一つの壁な気がする。例えばpythonに入門したときは、フランクにExceptionを継承したクラスを定義して、それを投げたりキャッチしたりすることを覚えたり、ジェネレータやリスト内包表記を覚えたりしたときに楽になった。そのほかはモジュールとかパッケージ周りの仕組みが新しく言語を学ぶときの障壁だと思っている。

借用とcopyは割とrust特有な気がする。似たところで、rubyの構文はその言語特有の難しさだと思う。 rubyの構文は慣れないとパースが難しいと思っている。実際に書いてみると、そう書きたくなる気持ちはわかるし書いていて気持ちいのだけど。

エアダスターを買ってノートパソコンのキーボードを掃除したら幸せになれた。ちょっと前にUキーの裏にゴミが入って、たまにかちゃかちゃ言って鬱陶しかった。そして週末にオリエンの都合で外でパソコンしたときに、たくさんゴミが入った気がする。

Amazonで400円くらいのエアダスターを買って使ってみたら、なんとなくよくなった気がする。昔の自分だったら圧縮した気体を吹き出すために400円かけるなんて、とか思っていただろうから成長した。手段ではなくそれがもたらす価値に対してお金を払えるようになったので偉い。

この価値観は、賢く生きるためには逆手に取ったり取られないようにしたりしないといけないんだろうなと思う。例えば自分が提供する価値を売るときには、この価値観を持つ人に対して安価な手段で高い見返りを得られると良いし、自分が目的を達成するために人のリソースを買うときは、リソースの売り手が想像もつかないような価値を見出すと有利だろう。

読んでいる。https://dl.acm.org/doi/10.1145/2660193.2660223

threaded codeの何がいいかを理解しないまま今に至っていたけど、ループ構造を変えることで分岐予測の精度を高めるみたいなことが書かれていて、そうなんだとなった。バイトコードハンドラのディスパッチをループの末尾で行うようにするらしい。ループの末尾でディスパッチするってどういうことだ？それぞれのハンドラが相互再帰な関数として定義されていて、全てのハンドラの末尾で次のバイトコードを読み込み次のハンドラを末尾位置で呼び出す、みたいな感じかな。分岐予測の仕組みは僕の中でブラックボックスになってしまっているのだが、めっちゃすごいやつだと思うことにすると、コードパスと次に実行されやすいハンドラの間に確かに相関が生まれそうなので、分岐予測の精度は上がる道理があるかもしれない、という気持ちになる。逆にループの頭でディスパッチすることにすると、ハンドラの末尾でループ先頭への無条件ジャンプを経由してからディスパッチすることになる。この一回挟まる無条件ジャンプが邪魔なのかな。この論文に飽きたら答え合わせしよう。

2023-09-10

昨日は大会運営の準備で一日外にいた。楽しいので後悔はないのだけど、だいぶ疲れて今日の夕方になったのにまだ疲れてぐたっとしている。

僕は疲れに気が付きにくいようで、周りが疲れたと言っていたり、翌日ダメージが残るよう場合でも、そのときは特に気が付かない。パフォーマンスには影響していると思うのだけど、気持ちは疲れていないので実際どれくらい疲れているかはわからない。酔っているとか深夜テンションとかみたいな感じに普段からなってしまうのだろう。

疲れや体調不良に鈍感なのは、子供の頃からずっと変わらない気がする。やる気が出ないのと体調が悪いのの区別はずっとつかない。一度インフルエンザにかかったとき、病院にかかったりする前に塾に行きたくなさすぎて、だるいと言って仮病を使ったら仮病じゃなかったことがある。その他にもなんか調子が出ないと思ったら花粉がすごい飛んでいた、みたいなことはよくある。

こういうことを書くと、やる気が出ないときは体調不良を疑おう、みたいな学びを得たくなるのだけど、単にめんどくさくてやる気が出ないことの方が僕は多いので、そんな甘えた学びを得てしまうと色々立ち行かなくなる（経験済み）。

今のところの付き合い方は以下の通り。

原因が明らかにわかっているだるさがあるときは、自分を甘やかすことにして、
よくわからんけどだるいときは、寝る、走る、食べる、手を動かすを試してみる。
大抵は手を動かすと動き出すのだが、それでもダメなら人と喋ったり病院いくのが良いだろう

今日は疲れているのにVSCodeで使うフォントをノートパソコンにインストールした。とても偉い。これでターミナルの一部でレイアウトが壊れていたのが直った。やったーー。

5月くらいに秋吉台に行ってロゲインしたときに買ったちんぐを飲んでいる。ちんぐは麦焼酎で、黒麹を使っているのが特徴。

ちんぐは親友という意味らしいのだが、あのとき一緒に行った友達とはしばらく会っていない。元気だろうか。

SlackとかDiscordみたいなチャットで議論の最中に、議論に参加していない人に質問とかしたくなる。そのときどこでメンションを飛ばすか選択肢があるけど、議論の場でメンション飛ばす形で召喚するのがいいよなと思った話をする。

選択肢としてはいかがありそう。

議論の場
DM
その人がよく出没するチャンネル
LINE、電話、メールなどの違う媒体

相手に文脈を理解する余地を残すためにも、議論の場に呼ぶのが誠意なんじゃないかと思っている。

今日久しぶりに静的型付けな言語（Rust）を書いて、 match式は書くブランチの型が一致しないといけないことを思い出して、じゃあreturnする場合はどんな型をつけるんだ、と思ったので型規則を定義するならこんなふうになるんだろうなと想像してみる。

returnがあるってことは、関数があるということだ。その関数の返り値の型とreturnの部分式の型が一致しないといけないはずだ。これをトラックするために、型は3項関係ではなく、今の関数の返り値型を表す項が必要なはず。

型規則では、次のような関係を定義すれば良さそう。 $\Gamma \vdash e : \tau | r$ ここで $r$ は今の関数定義の返り値の型。

関数定義では、次のような感じになるだろう。

G, x: t1 |- e: t2 | t2
-------------------------------- (fun)
G |- lam x: t1. e: t1 -> t2 | r

そしてreturn式はこんな感じだ。

G |- e: r | r
--------------------- (return)
G |- return e: t | r

こうすることで、returnに任意の型をつけられるので、フランクにブランチの末尾でreturnできる。任意の型ではなくてユニット型とかを不用意につけるとearly returnをしにくくなったりしそう。

書いてみると意外と単純だった。本当にこれでうまくいくかは知らないけれど。

2023-09-09

tomlもyamlも難しいので、みんなjsonを書けばいいのにと思う。 Goとか静的型付け言語とかが流行って、読みやすさの意義が重要視されている時代なはずなのに、設定ファイルは書きやすさとか、見栄えの良さが重視されていそうなフォーマットが人気なのが解せない。 jsonがナウいんじゃないかと思うし、好みとしてもjsonがいいなと思う。

jsonは誤解することが一番少なそうだし、みんな何が嫌なんだろう。編集がちょっとたいへんとか？そんなに設定ファイルを編集している時点で大変なことになっているのだから、それは妥当な大変さ何じゃないかと思うのだけど。

ブログを分割したい

このブログは日記も開発っぽいことも両方書いてある。これらを別のサイトに分けようと考えている。

開発の記事が日記に埋もれるのが嫌だから
今の環境だと開発の記事を書きにくい・表現しにくいから
- コードや数式を書きにくい・表示が微妙など
- madoko使いたい

そのための準備としてnetlifyを試しに使ってみた。このブログのリポジトリを登録したら、特に細かい設定をしないでもシュッとデプロイできてしまった。すごい。DNSとかSSLとかの設定を試していく。

ところでデプロイの設定は何もわからないのでチュートリアルが必要。madoko使うなら設定ちゃんとしないとだろうし。

2023-09-06

今日から有給明けて仕事に復帰した。リモートワークで少し緩めに働けた。気温が低いからか今までとちょっと違う気分だった。同期のノリも少し変わっていて、前よりもっとはっちゃけた感じになったと思う。どんどん楽しくなる。

昔、コンパイラとインタープリタの違いがわからなかった。コンパイラはプログラムを機械語とかの低級な言語に落とすやつのことで、インタープリタは落とすかどうかは知らないけど、実行するやつのこと。コンパイルしてもどうせ動かすのだから、cpuとセットで考えたらどっちも同じようなものだろと思っていた。

そういうわけで、コンパイラとインタープリタの分かれ目がどこにあるんだろうか（、いやない）みたいな気持ちを抱いていた。ちょうどjitコンパイラを知ったタイミングだったのもあり、この辺りの知識がこんがらがっていた節がある。あの頃の僕のために今の理解を書いておく。

コンパイラ: プログラムを低級な言語（主に機械語やアセンブリ、バイトコード）に変換するやつ
インタープリタ: （主に高級な言語で書かれた）プログラムを実行するやつ
- パソコンは機械語のインタープリタだというのは、まあそうかなと感じる。物理的なインタープリタ。
トランスパイラ: プログラムを別の言語に変換するやつ。コンパイラと大体同じ意味だけど、トランスパイラはターゲットがコンパイラよりも高級な雰囲気がある
JITコンパイラ: 最近のインタープリタに組み込まれているコンパイラ。最適化のために、普通にプログラムを実行する代わりに（多くの場合入力に制約をつけた）プログラムの一部をコンパイルして実行するときに使われる。

2023-09-05

9/1-4で北海道旅行に行っていた。オリエンテーリングをするのがメインの目的で、向こうで働いている同期に会ったり美味しいもの食べたり観光したりした。

やはり美味しいご飯は印象に残っている。特にスープカレーが忘れられなくて、これから好きな食べ物を聞かれたときにはアイスではなくスープカレーが好きだと答えることになりそう。 15時頃に成田を出て、宿に着いたのが夕ご飯どきだった。気になるお店も他にあったが、時間の兼ね合いで近所のスープカレー屋さんに入ったらとてもおいしかった。狙ったところに入っていたらどうなってしまったかわからない。それ以降毎日スープカレーを食べたいと言い続けている。

札幌の回転寿司やさんもおいしかった。こちらは会社の人に教えてもらったお店に入った。なごやか亭だったかな。会社の関連でごく稀にいただける美味しい寿司をが回っていて、幅広い選択肢から好きなものをチョイスできる、みたいな感覚だった。鯵とかが特においしかった気がする。友達曰く、この旅行で一番おいしかったのはここの寿司だったそう。僕はスープカレーとどっちがおいしかったかいまだに悩んでいる。

その他にもジンギスカンやラーメンを食べた。そういえばラーメンは2回食べたな。

夜の札幌を散歩したり、スプリントのテレインであるゆにガーデンで遊んだりした。小樽や余市、千歳のあたりやesconにもいった。それぞれに異なる印象がある。

最初の観光は9/2に訪れたゆにガーデンでのスプリント。オリエンテーリングのテレインがゆにガーデンで、お花畑のあたりでのスプリントが楽しかった。競技後にアイヌの衣装を着させてもらった。僕は長老の子供にいそうな見た目だと友達に言われた。素材は綿っぽいんだけど、風を通さない感じがする硬めの布だった。刺繍が凝っていてすごい。

その後esconで日本ハムとオリックスの試合を見た。普段は野球を見ないのだけど、結構楽しかった。友達の解説と会場での演出、試合運びが良かったんだろうと思う。両チームともピッチャーが強いらしくて（日本代表だとか）、試合がテンポよく進んだ。友達の解説では、例えば2アウト2ストライクの状況でバッターが球を打ったら、それがどうなろうが走り得だから塁にでているランナーはみんなめっちゃ走る、みたいなことを教えてもらった。おかげで試合で起きたイベントを解釈できるようになって楽しかった。選手がどういう局面に立たされていて、それが次のアクションへの意思決定にどう結びつくかがわかると、イベントを解釈できるようになる。

その日は札幌に帰って、先述した回転寿司にいき同じ宿でもう一泊した。回転寿司で食べ過ぎたので、寝る前に札幌の中心街のほうへ散歩しにいった。終電まで散歩を続けてすすきのの、繁華街を詰め込んだ雰囲気を味わってきた。

9/3はロングを走った。久しぶりの森でのオリエンテーリングはなかなか厳しく、プランを立ててから走るんだったなと途中で思い出した。そこで何人かのオリエンティアとおしゃべりして、味噌つけ麺を食べて小樽の宿へ移動した。テレインは札幌の南東の方だったので割と長めの移動で、途中で豊平峡温泉に寄った。鉄っぽいお湯が特徴で1時間くらいお湯に浸かった。小樽ではジンギスカンを食べて、毛無山展望台から夜景を長め、宅飲みした後やはり散歩した。

9/4はなぜか早起きしたので手宮公園まで走った。海沿いに泊まるとランニングしたくなるのは不思議。最初は天橋立に1人で行ったときかもしれない。

その後余市に向かって観光をしつつ、小樽北部のお店で焼き魚を食べた。海でちょっとはしゃいでから、余市でウイスキーとリキュールを買って、スイーツを食べてから札幌、新千歳の方に帰った。

スープカレーをやはり食べたくて自炊してみた。ある程度美味しいものはできたけど、北海道で食べたのとはやはり違うものになってしまう。甘味やスパイスの風味が足りない気がする。

ナスやオクラは美味しくできた。玉ねぎも炒めるだけじゃなくて素揚げも作れば良かったな。スープをフライパンで作るようになってから保存方法に迷う。

フライパンを使うようになったのは、引越しでコンロが一つになったから。並列作業できないので鍋やフライパンを同時に使うメリットが薄いし、むしろフライパンだけを使うことで洗い物が減るので今の運用に落ち着いている。

近頃タスク管理に追われていて、心のモヤモヤと闘っている。思えば小学生の頃から長いことこのモヤモヤと付き合っている。タスクを追うのではなく追われるようになるとこういう気分になるようだ。

小学生の頃は宿題がタスクだった。今は職場とかでの仕事関連や日々の事務タスクが追ってくる。小学生の頃とは違って今の環境は99%くらい自分で選んで身を置いている環境なので、バランスをちゃんと取ればタスクに追われることはないはず。そういうわけでtodoリストをいい感じに運用することでバランスを取ろうとしている。

モヤモヤする原因は何をやるべきかわかっていないことや、やるべき（だと感じている）ことをやらずに放置していることが原因な気がする。しっかり整理して正面から向き合うとタスクは消化されていなくてもモヤモヤは消えるし、タスク進行も捗る。

todoリストの運用が難しいのが今の課題で、何に記録して管理するかや、確認と更新のタイミングがうまく行っていない。

今の感じだと確認の頻度を上げるのが良さそう。毎朝確認するか。カレンダーに入れたい気持ちもあるけど連携がうまくいかない。それぞれのタスクをオブジェクトとして表現して、それらにurlを割り当てて、任意のドキュメントから参照したり、内容の表現や状態管理できるようにしたい。カレンダーともいい感じに統合されていて、期限や気にするべき期間をうまいこと設定して、通知や表示をしてほしい。 google todoリストは個人利用の範囲では良さげ。共有機能がないので人とタスクの共有はできない。悩ましい。

契約と型検査

プログラミングの型検査・契約・テストについて書きます。お酒を飲みながら書きました。注意は払ったつもりですが、変なところがあるかもしれません。

契約とは何か
- 例を含める
どんな嬉しさがあるか
型検査との兼ね合い

契約 (contract) とはプラグラムの関数の入出力に関する規約のことです。例えば整数の割り算をする div 関数は、二つの整数を受け取って商を返す関数だとしましょう。このとき、入力の二つの値は

どちらも整数
二つ目の整数は0ではない

ことが求められます。また、整数の割り算を行なっているので、div(a,b) の値は例えば

a の絶対値以下であること

が求められます（もっと細かい要求をしても良いでしょうが）。箇条書きで示したような div 関数について求められる性質のことを契約とよぶことが多いです。

ここまでで例を示しました。例のことは忘れて一旦抽象的な定義を試みましょう。契約は関数を呼び出す側と呼ばれる定義の間の約束事です。関数を正しく呼べば正しい結果を返すことを規定します。どんな呼び出しが正しくて、正しい呼び出しをされたと仮定とした上でどんな結果が正しいかを規定するのが契約です。

先ほどの例を考えると、 div 関数の第二引数に0を渡すのは呼び出し側の契約違反で、div(168,4) の結果が42にならないのは関数定義の契約違反です。契約は、関数呼び出しにおける呼び出し側と定義側との間の規約を表明し、検査します。

多くの言語でコードを書く際は、関数の冒頭で引数のチェックをして、呼び出し側の責任を追及するスタイルでコードを書くことになりがちです。言語によっては組み込みの機能でいい感じに契約を書いて、実行時に検査できます。 D言語とかRacketがいい例です。

例えばRacketだと、モジュールでエクスポートする関数を表明する箇所で、関数の契約を書きます。完全に雰囲気ですが、おそらくこんな感じで書くんじゃないかったかと思います。正確にはRacket GuideかRacket Referenceをご覧ください。

#lang racket

(export
  (div (-> (and int (lambda (x) (< 0 x) )) int  int)))

...

(define (div a b)
  (/ a b))

契約を書いておくと何が嬉しいでしょうか。問題の切り分けが楽になることが嬉しいですね。Blame shiftingができます。みなさん人生で一回は Segmentation fault とか Null pointer exception とか car: cannot apply for nil みたなエラーに遭遇したことがあるかと思います。これらのエラーは契約をちゃんと関数に書いていないから起きるはずで、まともなライブラリを使っていればあまりみないはずです。これらのエラーが出たときには割と深く絶望して、どの関数が悪さをしているか探す旅が始まります。

もし真面目に契約を書いていれば関数が許さないnilを受け取った時点で呼び出し側に責任があることを即座にエラーを起こしたり、変な結果を返しそうになったら返す直前に同様にエラーを起こします。

これが契約の嬉しさです。反対に、関数を動かして契約違反で怒られない限り、その契約を実装が遵守していることが保証されます。これもまた契約の嬉しさの一つです。契約はプロダクション環境で生きているドキュメントとして機能します。

テストとの違いは、契約は実行時に検査をすることが大きいでしょう。テストはテストを走らせるときにしか検証を行いませんが、契約は実行時にも検査を行います。プロダクション環境で関数を呼び出すときにも契約は検査されるのです。

契約はいいものであることがわかったと思います。関数定義の性質を保証して、何かあればすぐに検出し、何もなければ、すべてのそれまでの実行で違反したケースがないことを保証します。

この観点で見たときに、型検査はテストよりも契約に近しい存在だと言えるでしょう。型検査は、コンパイルのたびに型制約が満たされていることを検証します。健全な（まともな）型システムでは、型検査をパスしたプログラムは実行時に型エラーを起こさないことが保証されます（この保証がある型システムのことを健全だというので順番は逆ですが）。型検査では、関数の入力として渡される値が、関数が期待する条件を満たすことを検査しますし、関数が返す値が宣言にあっていることも検査します。契約と対比させると、契約は実行時に検査を行う一方で、型検査はコンパイル時に行うという感じです。

逆にいうと、契約は型検査で静的にやろうとする検査を実行時まで遅延したものです。実行時には任意の計算をできるので表現力は契約の方が高いです。例えば引数の値が10と20の間である、みたいなことを検査するのは型検査では大変ですが、契約ならちょちょいのちょいです。

じゃあ契約だけでいいじゃないか、型検査なんてやめてしまえ！という話になるかというと、そういうわけにもいきません。型検査には契約にないよさがあります。

型検査の良さは静的に検証が済むことにあります。つまり、以下の二つを型検査は満たします

全ての実行について、検証結果が成立する
プログラムを実行しないでも検証を行える

まず一つ目について。契約やテストでは、実行した場合については動作を検証してくれますが、それとは違う値については特に保証をしてくれません。だから境界テストみたいな、人間が上手に動かす技法が使われるのでしょう。型検査では、ある程度検証内容を抽象的にしたり保守的にすることで、全ての実行に対する性質を保証します。 intが返る関数は決してfloatを返さないことを型検査では保証できます。

抽象化や保守的な検査を行う二つ目の恩恵として、実行しないでも検証できることが挙げられます。本番環境で動かさないとわからなかったり、テスト環境をせっせと用意する必要は、型検査では生じません。

型検査や契約の有用性を主張してきましたが、それでもテストは必要です。実際に色々な具体的なケースで動かすことでわかることは多いでしょう。型検査は動かさないでもわかることを検証して、契約は動かしたらわかることを検証します。テストはプログラムを動かしてみて検証します。型や契約だけではプログラムを動かすことはありません。そこが大きな違いなはずです。

それでも全ての異常の検知をテストでまかなう必要もないはずです。契約や型検査は保証をする仕組みとして優秀です。基本的な保証は契約や型検査で済ませて、本当に際どいところをテストでカバーする、みたいな役割分担をすると幸せになれるんじゃないでしょうか。

タスク分解と見積もり

見積もりとかについて真面目に考えてみる。

仕事をするときに、頑張ります！と意気込んで、目標を分解しひとつひとつこなしていくことはある程度できるし、途中で分解したタスクが違った方を向いていることに気がついて、自分がやることを軌道修正することもできる。

全部ではないけれど、ある程度のことは十分に時間があれば達成できるんじゃないかと思う。特に目標を具体的に描けていればできることは多い（できないことをなかなか目標として想像できないとか、そもそもできないことがある、みたいな話はそれはそうだけど一旦置いておく）。

仕事とかチームで動くときとかでは、歩みを揃えられることが大事なわけで、自分の好みで十分な時間を消費して良いわけではない。仕事では、目標に、達成する事項だけでなく期限がついてくる。目標を達成できそうかを判断するには、期限と見積もりを照らし合わせれば良い。

目標は期限と達成する事項のペアだと思うことにして、達成する事項のことはタスクと呼ぶことにしよう。つまり、目標はタスクと期限のペア。今まではタスクを分解して一個ずつクリアしていけば良かったが、仕事では目標を分割して、タスクをクリアする中で期限も一緒に守らないといけない。次元が増えるのだから難しくなるのは当たり前だ。

タスクの分解は、タスクをよく観察して論理的に推論すれば割と上手くいく。それに対して期限を含めてうまく目標を細分化するには、つまり見積もりをするには、自分の能力や環境要因、タスクの達成の確実性などを含めて考慮しないと考え切ることはできない。

見積もりは曖昧さを伴ったものになるはず。そこが難しいのかな。また、タスクを分解して軌道修正をするとタスクはそれで洗練される一方で、期限の方は純粋に遅れが生じるのも難しい。時間は巻き戻らないのだ。

見積もりを安定させるには、このように生じる遅れの量を最小化すれば良い。そのためには目標の分解を小さくして、細かい粒度で軌道修正すれば安定するはず。あまり細かく分解しないでガッと取り組みうまくいけば最速だし、細かく分解して検討を繰り返して良さそう良さそうと確認をたくさんするのは時間がかかる。それでも確認することを込みで見積もることはできるので、安定性の面ではやはり有利に働くだろう。この辺りは最急降下法とかで、一回のイテレーションでどのくらい進むのが良いか、みたいな話と似ている。

なんにせよ、今の僕は安定した見積もりをできていないので学習の意味を込めて、細かすぎるくらいのタスクの分解をするのが良いのだろうなと思った。

自分の性格と合うだろうか。

先ほどの段落で、一発でガッと仕事して上手くいけばそれが最速、みたいなことを言った。これが実際にありうるのは個人で仕事をしているときであって、チームで仕事をするときには普通以心伝心というわけにはいかず、解釈違いやすり合わせ、議論に会話が必要だろうし、それができるのがチームの強みのはず。

これをこまめに行うことは、多くのチームにとって課題だろうし、僕がチームに参加するときに度々足りていないなと思うところでもある。

タスクの分解を細かくすることでコミュニケーションの機会を増やせるだろうから、チームでの仕事には細かいタスク分解がプラスに働きやすそう。

2023-08-31

今月はOJTが始まって、大変だなあという感想と自分成長できているなという喜びがあった。毎月力不足を感じて反省をし、できることが増えて次でそれを活かしつつ、次の力不足を感じる、というのをやっている。いい流れ。ポケモンみたい。

残念ながら自分のキャパはそんなにないことを痛感している。悲観するほどキャパがないわけでも将来に期待できないわけでもないが、気合いがあればなんでもできるというわけではなくて、気合いの入れどころを工夫しないとできないことはあるよね、という気づきが今月のホットトピック。

まだ短期的な実感しかないけど、人生を通して自分ができること、人に頼りたいこととかをみえるようになると一歩真人間ぽく幸せに近づけるのかなと思ってる。

大学を卒業して会社に入ったことで、自分とは異なるバックグラウンドの人ばかりいる環境に身を置くことになった。それをうまいこと使って、良い影響を僕から広げるためにできることを考えている。

契約と型
- 契約って概念があって、言葉を知っているかは知らんけど、内容自体はみんな日頃から思うところがあると思う。
- 型は多かれ少なかれ思うところがあると思うけど、こういう使い道があるんやで、という話
- 特に契約の延長線上にある型は結構便利で、単にプログラムがデータ型の違いでぶっ壊れるというよりか、最初の設計通りにプログラムをかけていそうなことを安心してコードを信頼するための便利な仕組みなんだよ、という話
- 特に代数的データ型はいいぞ
  - 帰納法と場合わけ
  - それのコンパイラによる支援

2023-08-30

dotfileを整備して、シェルの設定を複数のマシンで共有していると、あるコマンドがインストールされている場合にのみ、有効にしたい設定が出てくる。僕が今回遭遇したのは、k8sのcontextをプロンプトに表示する設定をなんとかしたいという欲求。いい感じに表示するコマンドが入っていれば、プロンプトに反映したいけど、入っていなければ別に表示しないのもありで、無理して全てのマシンにコマンドをインストールしたくはない。

コマンドの存在をチェックして、設定を条件分岐するのがナイーブな解決方法で僕もそうした。そこで気になるのが、コマンドの存在チェックのベストプラクティス。

command -v が良さそうだった。https://qiita.com/kawaz/items/1b61ee2dd4d1acc7cc94 fishでもbashでも使える。

コーヒーとハンバーガーを食べたらいつもより夜に動けている。不健康は一時的な動作を促進するのかもしれない（本当か？）。

昼健康な食事を摂ったのでバランス。

2023-08-19

能力はすごいと思っているのだけど、使うと部屋にいるだけで体調が悪くなるので苦手。換気とか空間の隔離をうまくやれれば良いのだが、僕のやる気と部屋の構造の問題でうまくいっていない。今日は頭がクラクラする。シャワーを浴びて少しマシになった。

dotfilesのセットアップスクリプトを書いた

dotfilesをGitHubで管理しているのだが、今までは設定ファイルの管理だけで、インストールは手動で行なっていた。設定ファイルを使いまわせるだけでだいぶ便利なんだけど、コンテナ環境の中で作業したくなると、手動インストールに耐えられなくなる。そこで重い腰を上げてセットアップを自動化した。

git のインストールと以下の実行でok。 nvimとかfishとかcargoとかが入る。

git clone https://github.com/naoyafurudono/dotfiles.git
bash dotfiles/setup.sh

test

arm環境かつubuntuだけでしか動かしていないが、dockerコンテナでセットアップスクリプトを動かして、正常に終了するかを確認するテストを書いた。

この手のセットアップスクリプトのテストって、世の中ではどのようにテストしているんだろう。以下の難しさがテストを大変にしている気がする。

環境依存な部分をうまく吸収する必要があること
インストール失敗の判定が難しいこと

2023-08-16

夕飯に味噌ラーメンを作って食べた。自作したスープがうまくて今晩は天才。味噌と本だしは正義。スープを自作したのはインスタント麺が高くて安い生麺を買ったから。 3食分残ってるので頑張って食べないといけない。

falseとlambdaは手癖で打つ。街頭インタビューでfalseのスペルを聞かれたら、キーボードがないと答えられない気がする。 faulseとか言いそう。 lambdaはギリいけそう。

2023-08-13

この前の水曜日から帰省していた。今回の帰省では地方都市の幸せな家族みたいな過ごし方をした。イオンにいったり外食に家族でいくと雰囲気が出る。高校の同期にあったりゲームをしたのもポイントが高い。

初任給で親に贈り物をするイベントをやっと終了できたので安心している。イオンでめがねを買ったのだが、直接会ったのだから夕飯をおごるとかでもよかったかもしれない。

新幹線の改札内で8個入りの赤福を買った。賞味期限が明日までで人に会う予定がないのでたくさんたべないといけない。

帰省をするとエネルギーを使う配分をミスって睡眠リズムが毎度崩壊する。今回は途中までいい線いっていたのだけど、漫画を読んだ日と星を見に行った日が連続してやはりリズムが崩れてしまった。今日はとても眠い。新幹線のホームできしめんをたべてお腹いっぱいになったのも効いていそう。次回からは運動を計画的にしよう。ちなみに星は見えなくて、岐阜タンメンをたべて帰ってきた。

帰ったらスマホの通知設定を調整して、がんばるモードになる。

2023-08-10

ルンバを買った。少し前にレンタルして、返却してから生活が崩壊したので買うことにした。この書き方だとレンタルして甘やかされたから掃除能力が落ちたみたいに見えるが、そうではなくて、もともと生活が崩壊していたことがルンバのおかげで判明したという感じ。今度家に届く予定で楽しみ。

2023-08-04

今日は会社の飲み会で夏祭りしてきた。その前にインターンの人たちとご一緒させてもらって楽しかった。僕も頑張らねば、という感じ。

夏祭りでお酒を入れると終わりが寂しくないことに気がついた。悲しいライフハックを覚えてしまった。浴衣を頂いて、おそらく人生で初めてきた。結構テンション上がって楽しめたのでこれからも積極的に着ようと思う。おかげさまで就職してから新しい経験をたくさんできてる気がする。

昨日から違国物語を読んでいる。結構面白い。今リンクを貼るために検索したら映画化すると知った。だから推薦されたのかな。

ここ最近は24時間楽しい。

too long to tweetというタイトルのブログを昨日か今日に読んだのを思い出して、今いいなと感じたのでブログのタイトルを変えてみた。今度こそしっくりくるといいな。

ガスバーナを買ったのだけど、お酒が進んでよくない。明太子を炙るとうまいしレンチンしたものを炙ってもうまい。お酒が進む。今度実家に持って帰ろう。

ここまでjamesonを飲んできたが、今からラフロイグかフロムザバレルに移る。どうなってしまうのか！

選ばれたのはフロムザバレルでした。やっぱりスモーキーさがあるのは良い。

なんかTwitterでやってろって感じがする。明太子って可算名詞なんだろうか。this is a mentaikoといって、英語のせんせいは満点をくれるだろうか。

5年くらい前にバイトでまふまふさんのライブの設営に行ったことを思い出している。まふまふさんは中学のとき（もう10年以上前！）から好き。友達にCDを貸してもらって、目覚ましや定期試験のお供だった。それから大学受験や諸々のタイミングでお世話になった。まふまふさんの歌がなかったら人生が違っていたかもしれない。そう思うと友達やまふまふさんに感謝してもしきれない？もっといい人生があったのかもしれないけど。今の人生は割と頑張ってきたなりの結果で頑張りのためにはまふまふさんの歌が必要だったことは間違いない。頑張りの良し悪しはわからないけど、頑張れたこと自体は良かったと思っているので感謝していることは見当違いではないはず。歌ってみたとかボカロ、高音ボーカルにハマったのはまふまふさんが始まりな気がする。話を戻してなんでまふまふさんのライブのバイトを思い出したかというと、co shu nieのライブに申し込んだから。人生始めてのライブ。前から気になってはいたけど、ついに人生初のライブに申し込んでしまった。ライブの設営は何回かやったのに、観客として参加するのは初めて。来月末が楽しみ。

今気がついたのだけど、音楽ってでかい音で鳴らすと楽しいな？んにゃって言える仲は割と仲良いと思う。

2023-07-29

ARM64でいろんなサイズの整数の足し算をする方法を整理する。サイズごとに演算が用意されているわけではなく、レジスタの指定方法（x,wの使い分け）や、レジスタのコンテンツをいい感じにすることで、 byte, half, word, double wordの足し算を実現する（と思ってよさそう）。

レジスタどうしの足し算では、destinationとその他の二つのsourceレジスタのサイズが同じじゃないといけない。結果のサイズがdouble wordならXnを使えばいいし、word以下ならWnを使う。
レジスタのコンテンツをいい感じにする方法は二つありそう
- 適当なマスクとandを取る
- 専用の命令を使う。二種類観測した。
  - Armv8-A Instruction Set Architectureが優しい。7.4節Extension and saturationに説明がある
  - 一つ目は拡張命令を使う方法。符号{あり,なし}と拡張前のサイズについて、それぞれ定義された拡張命令を使うと、destinationレジスタにsourceレジスタを拡張したビット列がセットされる。
  - 二つ目は足し算で追加の引数として拡張方法を指定する方法。拡張命令と似たような感じのenumが定義されていて、それをadd命令のsourceレジスタの後にしていすると第二sourceレジスタを指定した方法で拡張した上で足し算する。

朝はお茶漬けを久しぶりに食べた。朝にお米を食べようと思うと、やっぱりお茶漬けがいい。子供の頃に抱いた感覚が長持ちしている。一時期パンに手を出したこともあったけど、なかなか難しい。食パンは口の中の水分を持っていくので惣菜とかが一緒にないとちょっと難しい。小倉トーストとかは好きなので、全くダメというわけではないと思うのだけど。

2023-07-22

コンパイラの実装で、次はポインタ算術をやる。演算子がオーバーローディングされているので型検査が必要。今は環境とかのデータ構造を設計する気力がなくて、パソコンを前にふにゃっとしている。お昼ご飯食べたら考える。

興味本位でコンパイルしたプログラムの実行速度を測ってみた。時間計算量が試数時間なfibの実装（あのみんな大好きなナイーブなやつ）で、 fib(40)を計算してみた。自作コンパイラだとuser時間が1.3secくらいなのに対して、 gccのO3でuser時間が0.3secくらいだった。 O3を指定しないと（多分O2）0.5secくらい。 Inliningとかは効かないだろうし、ループ周りでの最適化もできないはず。スタックマシンではなくレジスタマシンとして動かすことで（無駄なpush/popを排除することで） O2くらいの速さになってる感じかな。 O3では何が早くなってるんだろう。気が向いたら調べるか、実装するかしたい。

お昼を食べて買い物に行ったあと、型検査器を実装した。がんばった。 strcmpがboolを返すと思い込むやつをやって時間を溶かした。ランニングをしてオーバーロードに取り組む。今はintもポインタも64bitにしているけど、abiをみたらintは32bitっぽいので合わせる。オーバーロードは楽しそうだけどintを32bitにするのが面倒。 ASTに型を行き渡らせたので難しくはないはず。

買い物ではズボンを買いに行った。涼しい長ズボンが欲しかったので。初めて買う感じのやつを変えて満足している。サンダルも欲しかったけど、僕の期待が矛盾していることに気がついたので断念。来年は期待を変えられることを願って今年はスニーカを履き続ける。

Cとかその辺の関数型言語を使っていると欲しくなる言語機能第1位は動的束縛だという説を提唱したい。代数的エフェクトほどのことを普段使いに人類は求めているとは僕には思えなくて（普段使いと言ったのは、凝った仕組みを作る場合はのぞきたい気持ちの表れ）動的束縛が欲しいんじゃないだろうか。オブジェクト指向でインスタンス変数を使うのもこの用途が多いんじゃないかと勝手に思っているんだけどどうだろう。

とにかく、動的束縛が欲しい。動的束縛はいいぞの会を結成するまである。

Uを叩くとメチって音がする。髪の毛でも入り込んでしまったかもしれない。割とストレス。

2023-07-21

https://github.com/naoyafurudono/comp

早いもので作り始めてから2週間たったみたい。もっとサクサク進むと思っていたのだけど、しばらく楽しめそう。

自作CコンパイラでCのプログラムの一部をコンパイルできるようになった。これまでは変数宣言をできなかったので型宣言のあるmain関数を読めなかったが、 intだけ許容するようになったので、初めてCのプログラムをコンパイラが受け付けたことになる。

こんなコードをコンパイルすると、

int main()
{ 
  int a; int b; int i;
  a=0; b=1; i=0;
  while(i < 10)
  { 
    int t; 
    t=a+b; a=b; b=t; 
    i=i+1; 
  }
  return a;
}

こんなアセンブリを吐く。 SSAみたいな中間表現を挟んでレジスタ割り付けを真面目にやるのはいつがいいんだろうか。

.globl _main
.text
.balign 4
_main:
    stp x29, x30, [SP, #-16]!
    mov x29, SP
    sub SP, SP, #32
    mov x0, #-16
    str x0, [SP, #-16]!
    mov x0, #0
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-24
    str x0, [SP, #-16]!
    mov x0, #1
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-32
    str x0, [SP, #-16]!
    mov x0, #0
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
.L0:
    mov x1, -32
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #10
    str x0, [SP, #-16]!
    ldr x1, [SP], #16
    ldr x0, [SP], #16
    cmp x0, x1
    cset x0, lt
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    cbz x0, .L1
    mov x0, #-40
    str x0, [SP, #-16]!
    mov x1, -16
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x1, -24
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    ldr x1, [SP], #16
    ldr x0, [SP], #16
    add x0, x0, x1
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-16
    str x0, [SP, #-16]!
    mov x1, -24
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-24
    str x0, [SP, #-16]!
    mov x1, -40
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #-32
    str x0, [SP, #-16]!
    mov x1, -32
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    mov x0, #1
    str x0, [SP, #-16]!
    ldr x1, [SP], #16
    ldr x0, [SP], #16
    add x0, x0, x1
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    ldr x1, [SP], #16
    str x0, [x29, x1]
    str x0, [SP, #-16]!
    b .L0
.L1:
    mov x1, -16
    ldr x0, [x29, x1]
    str x0, [SP, #-16]!
    ldr x0, [SP], #16
    mov SP, x29
    ldp x29, x30, [SP], #16
    ret
    mov SP, x29
    ldp x29, x30, [SP], #16
    ret

2023-07-19

実装しているCコンパイラで関数定義をできるようになった🎉。今までも既存のコンパイラで作ったオブジェクトファイルとリンクすれば呼び出すことはできていたが、自分で定義した関数がある程度ちゃんと呼べるようになった。

まだ型がlongしかないので道は長い。

https://github.com/atweiden/fzf-extras ここが良さげ。

2023-07-17

Cコンパイラをarm macで実装しているのだけど、a=b=0; return b;"みたいなコードがセグメント違反で落ちる。 lldbで調べてみると、main関数は正しい値をw0にセットしてretできていそうなんだけどその後の動的リンクされたコードでエラーが発生しているみたい。設定する値を変えるとエラーにならずに実行が終了する。謎である。

ABIを守っていないのが悪さをしているかも。

土曜日はパソコンしてた。お昼頃に連絡が来ていたことに気がついて、翌日の約束をした。

勢いで日曜日は丹沢に行くことになって、卒業ぶりに会った友達と2時間くらいの登山をしてきた。コースタイムが4時間だったのでいいペースだった。最近登山をしておらずペースタイム通りの時間でいく想定をしてしまっており、思ったよりもあっさりと終わってしまった。友達の靴が下山した後の道で壊れてしまったのでサンダルを貸して歩くことに。風呂に入ってからはま寿司で3時間くらいお茶を飲んで帰宅した。

日曜日は海の日なので海を目指して部活の後輩と走った。天王洲アイルが海の近くだったのでそこまで行ったのだが、思ったよりも海っぽくなかったのが残念。久しぶりに走ったので走り始めがだいぶ辛かった。

久しぶりの人と会うと時間の流れを感じる。

arm64のメモ

Cコンパイラを実装するためにarm64のことを調べている。この記事はそのメモ。

よくあるソフトウェアのライブラリについているドキュメントとは毛色が違う。

Armv8-A Instruction Set Architectureが優しい
- PDF版もある。空白多めのシングルカラム39ページなのでサクッと読める。最初に読んでおくと幸せになれたかも。
Procedure Call Standard for the Arm® 64-bit Architecture (AArch64) (pdf)がCコンパイラを実装するときに気になる細かいことをコンパクトにまとめてそうな印象。
上のドキュメントを含む公式のリンク集がある

Arm macを使っている人の話です。

既存コンパイラがはくアセンブリを覗く方法
- アセンブリをはく: gcc -O0 -S
- ディスアセンブル: otool -vVt
デバッガで調査する
- lldbが使える
- エラー箇所の特定に便利
- ドキュメント
  - 入門記事（東大の講義ページ）何もわからんくなったら{ここに立ち返る|ここから始める}のが良さそう
  - 公式チュートリアル: ちょっと読んだ。真面目に勉強するなら導入に良さそう

アセンブリ命令って割と体系的になってなくてやばいイメージがあったけど、 arm64は秩序がある程度あるように感じている。まだ深淵を覗けていないだけかもしれないが。汎用レジスタの名前が簡単なことが大きいかもしれない。

2023-07-08

椅子に座るほどの元気がなくてもパソコン座れるので楽しい。気軽にコーディングできる。

cコンパイラ実装するやつは、今からローカル変数の定義に入るところ。ここまでで、四則演算と比較をコンパイルできるようになった。 armでやっているのだが今のところそんなにx86と違わない。 push/popでスタックポインタがarmだと16byte境界にしか設定できないとか、割り算がシンプルだとかくらいの違いしか観測していない。

そういえばenumは値だった。変数名みたいにコンパイラがよしなにするやつというイメージが強くて戸惑ってしまった。今回初めてcファイルを頭を使って分割した。定義と宣言の違いを認識して活用する日強がある。

パーサ前はサクッとできて、コード生成も一応形にはしたのだが、生成したアセンブリをアセンブルして実行するとセグフォで落ちる。 x29にSPをmovするだめみたい。x29以外にしたらどうだろうと思い、x9を使ってみたらセグフォのタイミングが変わった。ちゃんと追ってないので明日起きたら追ってみよう。

とりあえず、armのマニュアルを落とした。めちゃ長いけど良さげ。ソフトウェアと違って、ライブラリが無い分こういうふうに一つのでかいドキュメントが提供されるのはなんかそうなんだろうな、という感じがする。Web版よりも検索しやすいのはいいこと。今日はこれくらいにしよう。

ちなみに今はラフロイグ10年を飲んでいる。いいでしょ。

動画を見たり手を動かすことが増えた。あとは仕事でドキュメントを読む時間が増えて、活字が安定供給されているのが影響しているかも。

とはいえ仕事で読むドキュメントは、読み物としてはそんなに面白く無いことが多い。その分手を動かしてものを作るのが楽しいからいいのだけど、小説を読む楽しみとか、心に響く論文を読む感覚が足りない。小説とか論文とかに飽きてきたのはあるのかもしれない。残念ながら深掘りできる人間ではなかったのか。広く学ぶ好奇心とかがあるわけでもないのだけど。

話題になっていたのは当時から認識していたが、ずっとみていなかったユーフォを見た。特に第一シーズンが好きで、上手くなりたい、のあたりが響いている。僕がある程度まじめに考えて方向性を決めるときには、上手くなりたいが奥底に合ったなと再認識させられた。

頑張っているときはわからないけど、少し環境が変わると上手くなっていたことがわかる。加えて、そのときになって周りから、それが上手い人というラベルを貼られることに気がつくし、振り返ると上手くなったなと気がつく。上手くなりたいと憧れた、あの頃の自分からすると今の自分は割といい線行ってるんじゃないかと思う側面がある。全部が全部上手くなってるわけじゃないけど。

この頃は、上手くなった先に何があるのかということをちらほら考える。幸せがあると思っていたのだが、実際のところはどうなんだろうか。今は体力と好奇心と自尊心がボトルネックになって、ボトルネックになってることがそれらを削っていくんじゃないかと思う。また、自分が上手くなるのにかかる時間が実感を通して認識できたことで、自分の限界を認識するようになるのだろう（僕はまだ認識してない。アカデミアのスターにも総理大臣にも、経済界のドンにも縁があればなれると思ってる。巡り合わせに依ると思ってる時点で擦れているのかもしれないけど）。

僕はアニメを見て、アニメの感想ではなく内省をアウトプットしたくなってしまうので自分から進んでアニメの話をしたくならない。聞かせるのは悪いなという気持ちとなんか恥ずかしい気持ちがある。日付が変わってしまいそうなのでこのくらいで。ところでフロムザバレルは甘い。干し芋っぽい風味がする。

明日はランニングしよう。午前中に走ってみる。

2023-07-06

そういえば 社会人 になったわけで、そろそろ子供の頃に思い描いていた大人（僕はまだ自分のことを子供だと思っているのだがここでは5歳くらいの意味で）になったはず。あの頃大人に抱いていた感覚は、なんでもできる自分とはどこか遠い人だった。今の自分は子供の頃の自分からしたらどう映るんだろう。

大人は子供の前では大人ぶるものなので、子供の頃の僕の前で今の僕が大人っぽく見せようとしないとは思えないけど。

そっけなかったのでChatGPTに相談して新しくした。解釈は以下の通りとのこと。

「星影のメモランダム：キラキラ上弦の月が見守る心の手記」というタイトルは、幾つかの意味やイメージを含んでいます。以下に説明いたします。
「星影のメモランダム」: 「星影」は夜空に広がる星の光を指し、その美しさや神秘的な雰囲気を表現しています。また、「メモランダム」は手記や書き留めたメモの意味であり、心の中に浮かんだ思考や感情を記録するという意味を持ちます。このフレーズは、夜の静けさの中で思索や独り言が交錯し、心に残るメモとして綴られる様子を表現しています。
「キラキラ上弦の月が見守る」: 「キラキラ上弦の月」は、満ち始めた月の美しさや輝きを表現しています。上弦の月は成長と新たな始まりを象徴し、それが心の手記や冒険を見守る存在として描かれています。上弦の月がキラキラと輝き、心の手記や冒険を照らし、導いてくれるイメージが込められています。
「心の手記」: タイトルの中で「心の手記」というフレーズは、内面の思考や感情を綴る日記や手記を指しています。主人公や著者の心の中にある思いや経験が、その手記として表現されていく様子をイメージさせています。
これらの要素が組み合わさり、「星影のメモランダム：キラキラ上弦の月が見守る心の手記」は、静かな夜の中で心に浮かぶ思考や感情を記録し、上弦の月の導きと輝きによって心の手記が見守られる様子を表現したタイトルとなっています。

かっこいいので採用。

2023-07-05

プロトタイプベースのオブジェクト指向言語について、哲学の方面から議論したエッセイを読んだ。クラスベースなのは古典的なアリストテレス的な分類の考え方に基づくもので、プロトタイプベースなものはヴィトゲンシュタインっぽい考え方に基づくとのこと。

アリストテレス的な考え方では、物事は分類できて、しかもいろんな分類があったとしても最高の分類みたいなものがある、みたいに捉えるそう。分類の中でその類を象徴する代表みたいなものも取れてしかるべきみたいな。一方でヴィトゲンシュタインっぽい考え方ではアリストテレス的なのには割と無理があって、そんな考え方が通用するのは数学の概念くらいとしていて、分類は観察する主体に依るし、文化とかの影響を受けるもので「科学」みたいに自然に導かれるようなものではない、みたいな考え方をするらしい。

リアルワールドを表現、分類しようと思うと確かにヴィトゲンシュタインの方がしっくりくるというか、矛盾が少なさそうな雰囲気がする。だけど、独自の世界を作ろうと思うとヴィトゲンシュタインの考え方に基づくのは骨が折れそう。

では、関数型言語とか意味論の人たちの視点だとどうなるだろうか。オブジェクト指向は哲学の話に基づいて議論しているみたいだが、型システムとか意味論は論理学をベースにしがち。型は命題でプログラムは証明。

ところで

型は命題でプログラムは証明。

この標語はしっくりきていない。型に入る_項_を僕は証明だとは思えない。依存型は項に依存する型だとは思えるけど、証明に依存する型と言われるとなんだかなと思う。まあ、その項にも型をつけるので、その型の証明にはなっているのだけど。Numみたいな型を命題というのがしっくりこないのと同じか。

依存型でも依存する項の型が関数型とかの命題っぽい型だったら証明に依存している雰囲気を味わえるかもしれない。帰着を考えればいいのかな。この命題が成り立つなら、これこれが成り立つ。これは依存型じゃないな。帰着は型をとって型を返すだけなので、type operatorだ。

ところでラフロイグの10年おいしい。

nが2より大きい、みたいな命題は依存型がないと表現できないか。簡単だ。

\Pi n: Nut. (n > 2 -> \Pi x,y,z: Nut. x^n + y^n != z^n)

ここで _ > _ は依存型。普通だね。

話を戻す（ラノベだったらここで閑話休題って言ってた）。オブジェクトと抽象化の話をしていたのだった。オブジェクト指向では、分類を動的な性質としてみるきらいがありそう。それに対して関数型っぽい世界では、分類は静的にできる型判断でしかないイメージ。型によって動的な振る舞いは変わったり変わらなかったりするけど、とりあえず型は静的につけるものだと思う。その情報を実行時まで持ち越すかは好きにすればいい、くらい。

動的メソッドディスパッチはいまだにしっくりこないし、メタプログラミングに関しては勝手にやってくれって思ってしまう。

ディレクトリの構造で投稿の分類を決めるのはよくないと思う。分類なんて書いているうちに変わるのだし、その方が便利そうなので全てはフロントマターにお任せしてしまえばいいと思った次第。そんなこという子はhugoユーザには要らないのだろうから、そのうち独立するのがいいんだろうな。

明後日が七夕だ。花金なので会社の人と七夕のみをできるかもしれない。

七夕は織姫と彦星が一年に一回逢瀬を重ねられる日。天の川に橋がかかるんだったか川の水が引くんだったかで会える。ここでは皮の水が引く説を採用する。

旧暦では時期的に川の水が引いたかもしれないが、現代では7月の頭はまだまだ梅雨みたいなもので川は元気だ。このままでは織姫と彦星は約束の日に会えない。かわいそう。なのでいつも夏の大三角に心を癒してもらっている僕たちは、せめてもの恩返しに川を飲み干して、逢瀬を支援することにした。これが七夕のみ。幸いなことに梅雨の雨で薄まった川はアルコール度数が比較的低く、ほろ酔いくらいのイメージ。だからこの日は梅雨がもたらす潤沢な量のほろ酔いを飲む。

エンジニアリングは手段でしかないと今は本心で思っている。とはいえ、プログラミングやエンジニアリングをしていて幸せを感じるタイミングもある。このギャップはエンジニアリングの成果を確かめることにあると思う。

例えば家に電気が通っていることは感動的なことだと頭ではわかるが、その恩恵を享受することは特に幸せだとは思わない。それに対して、新しくプログラミング言語を学んで、これまではできなかった表現でこれまではできなかった解決策を実現するのはとんでもなく楽しい。さらにはこれまでは明らかではなかった解決の方法を明らかにするのは結構な幸せだ。

このギャップは成果を確かめること、差分を観測することにあると思う。微分係数が大きいときが一番やりがいを感じる、みたいな話に通じる気がする。

会社の人の親切に触れたこと
- 一人だけじゃなくて4,5人くらい
会社じゃない知り合いとちょっと仲良くなれたこと
ラフロイグがおいしいこと
オブジェクト指向の話が面白かったこと
権八に行けたこと

こんなしょうもないことを書いていたせいで、今日の元気が終わってしまった。ラフロイグに完敗。またこんなことをインターネットで公開するおかげで恥の概念がなくなってきた。これは良し悪しありそう。

2023-07-02

末尾位置での関数呼び出しは、継続渡し形式ではcaleeに渡す継続をcallerが大きくしないで、 callerのcallerから渡されたものをそのまま渡す点で特徴的だ。レジスタマシンではcallerのスタック領域をcalleeが上書きして使うことに対応するのだろう。こういうcall命令はどのくらい実用されているのだろうか。

https://www.sigbus.info/compilerbook これを読んでいる。

高校の化学の授業でナトリウムをどうやって保存するべきかと先生が問いを投げて、追い討ちをかけるようにそのまま先生が水筒ですか、と言ったのをたまに思い出す。確か灯油とかに放り込んでおくのが定石だった気がする。

今日は水筒を買った。会社で水をもっと飲みやすくなる。水筒にはお茶もコーヒーも入れないつもり。レジで「ご自宅用ですか？」と聞かれたのが印象的。プレゼントか否かを暗に問われたのだと思ってそうですと言ったのだが正しく意図を汲み取れていたのだろうか。家で水筒使うことなかなかなさそうなので明には嘘をついてしまった。

意図が自明ではない発言にはその背景を添えて欲しいし、自分も添えるように気をつけよう。

報酬主義を超えてを読み始めた。思ったよりも面白い。ある程度、当たり前の主張をさも常識を疑って得られた結論みたいな書き方をするけど、それでも僕の立脚する価値観を疑うようなことも書いてありそうなので期待している。

2023-07-01

envsubstを使うと標準入力の環境変数の参照っぽいところに環境変数の値を埋め込んだテキストを吐ける。 readmeにコマンドのヘルプメッセージを載せたいときに便利。例: https://github.com/naoyafurudono/tools/tree/main/cl

gitで管理しているファイルのパスが得られる。 git grepみたいに管理対象だけに興味があるときに便利そう。 fzfとの相性が良さげ。

2023-06-30

すでにgit管理されているファイルをgitignoreでマッチするようにしても、管理から外れない。外すためには以下のようにすると良い。

git rm -r --cached .
git add .
git commit -m 'update with .gitignore'

2023-06-29

crate.ioに初めてコードを登録した。cargo install で入るから便利。ちょっとしたCLIツール書く体験がなかなか良い。 copilotが面倒なことやってくれる。

Railsとか書いてると深いところに元からあるファイルをコピーしたいことがちょいちょいある。そのときに長いパスを2回打ちたくないので作った。

2023-06-25

今日は親戚のお家にお邪魔してきた。だんだん親戚のことがわかるようになってきた。たくさん構っていただけてありがたい。ここ1,2年くらい、人の人生を聞く機会が増えたように感じる。

その後に荻窪に住んでいた頃に通っていた銭湯に行った。あそこは熱めのお湯と水風呂があって良い。安定感がある。そういう安定感に対してシャンプーが置かれるようになったりタオルが有料化したりして、変えていく部分もあるみたいだ。

今週末はlinuxの鈍器な本を割と読めたし、sedとawkの理解も深めた。いい週末だったと思う。今週も頑張ろう。

VoltaはJSツールチェーンのマネージャ。 Copilotをnvimで使うためにnodeが必要だったのでnvmを入れようと思ったら、 fishではうまく動かないとのことだったので他をあたることにして出会った。ちょっと触ってドキュメントを覗いた感じ、シンプルそうで好感を抱いた。“The Hassle-Free JavaScript Tool Manager"を謳っているので狙い通りな感想を抱けたのだろう。

Pixel6aを使っているのだけど、この度初めて壁紙とロック画面を設定した。デフォルトだと時刻が大きく表示されていて見やすいのだけどあまりかっこ良くはない。また、壁紙もボヤッとしててそれっぽいのだが、ピンとはこない。時刻の表示はコンパクトにできたし、壁紙はビビットな感じのものに設定した。満足している。

2023-06-24

macのタイムゾーンの設定が狂っていて、今日の投稿がこれと前回の二つに分かれてしまった。

今日はmacの設定と、以降に伴って壊れたちょっとしたCLIツールの修正した。昔Rustで雑に書いたもので、エラー処理が辛そうだったので少し勉強して改善した。 anyhowを使ってみたい気持ちが湧いたけど、まずは基本的なところからということでトレイトオブジェクトを使うことにした。type Result<T> = std::Result<T, dyn Error>みたいな感じにすることで、いろんなエラーを孕んだresultに?を使うことができて幸せ。

一箇所ムムッとなったのが、クロージャの中で?を使う箇所。dyn Errorの気持ちで書いていたら、推論器はもっと具体的な型を推論していたみたいで、二つ目のエラー型の式に対して?したら型エラーになってしまった。こういうときはアノテーションをつければ良い。 Rustの型推論の割り切り方に慣れていない。

2023-06-23

macを買って環境構築をしているのでメモしていく。

capslock -> eisu toggle
- システム環境設定 > キーボード > テキスト入力 > 入力ソース > Caps LockキーでABC入力モードに切り替える
- 最近のmacは組み込みの設定で変更できるようになった
1Password
- 最新のドキュメントを参考にしてsecret keyを探し出す
CLIツール: 以下の順で入れると良い。気が向いたらインストールスクリプトを書こう
- brew
- fish
- nvim
- .config
- その他
gitでsshを使うための設定: この投稿のおまけを参考に
- 鍵を生成
- githubに公開鍵を登録
- .ssh/configを書く

個人メモ：dotiflilesに書いてあるのでコピペは不要。

# for fish
function _ssh-keygen
  set name $argv[1]
  mkdir -p "$HOME/.ssh/$name"
  ssh-keygen -t ed25519 -f "$HOME/.ssh/$name/id_ed25519"
  chmod 600 "$HOME/.ssh/$name/id_ed25519"
end

#!/bin/bash

name=$1
mkdir -p "$HOME/.ssh/$name"
ssh-keygen -t ed25519 -f "$HOME/.ssh/$name/id_ed25519"
chmod 600 "$HOME/.ssh/$name/id_ed25519"

Host github.com
  User git
  IdentityFile /Users/naoyafurudono/.ssh/github/id_ed25519

Terraformでローカル環境の管理とかできないだろうか？

2023-06-17

ルンバをレンタルして今日から使い始めた。結構細かく動いてくれて僕より掃除がうまい気がする。 7時/19時で掃除するようにしたので、目覚まし代わりになるはずだし、寝る前と出勤前に床を片付ける習慣がつきそうで期待してる。

日中に運動するとその日の体力とやる気を使い果たして何もできなくなる。やはり夜に運動するのが性に合っていそうだ。

2023-06-16

話題だったので読んでみている。手塚治虫っぽい印象を受けてる。

ある程度目を通したけど、村上春樹の小説のような例え話が実用書で延々と続いて途中で読むのをやめてしまった。たまに話題にでてきていた模倣理論とかは気になるので、そっちを調べてみようかしら。

2023-06-11

舌の奥の方や、先端よりも少し奥、中央くらいで味わううまみやとろっとした感じが好き。苦味とか酸味にはなれてしまってあまり感じなくなったみたい。

美味しいコーヒー屋さんででてくるやつは大概美味しいと感じるけど、自分で淹れたりそのへんのお店で飲むならアメリカンが美味しいと感じやすい。

最近家でパソコンに向き合っていると腰が痛くなる。今に始まった頃ではないけど、職場ではそんなことにはならないので対策しだいではよくなるはずだ。職場と全く同じ環境を整えるのも手ではあるけど、それだとつまらないし、切り替えもしたいので却下。スタンディングデスクを使うようなやり方を最近は考えている。

本屋さんとかで技術書を立ち読みするときが、図書館にこもるときの次くらいに集中できる気がする。図書館的な集中の仕方を会社でやってると思うことにして、家では試しに本屋さん的な集中をできないか挑戦してみたい。椅子が邪魔だと思っているので、座らなくて良いならそんなに嬉しいことはない。また、PCに向き合ってだらだら動画とかをみるのはあまり気持ちのいい過ごし方ではなくて、それを予防できるのならなお良い。

昨日本棚を注文して一週間ほどで届くとのことなので、それと合わせて家をいい感じにしたい。

2023-06-10

共感できるところが多かったし、なるほどなと思うところもあった。なにより読んでて楽しかったので読んでよかった。

野崎まどの本を読むのは、野崎まど劇場を友達に借りたのが最初だった気がする。かれこれ10年くらい前の話かも知れない。

天気予報を確認したいのだけど、テレビを見たり朝スマホを確認する習慣がないし作る気もないので、なにか方法が必要。ちょうどラズパイが手に入ったので、毎朝どこかから引っ張ってきた天気予報を喋ってもらおうかと考えている。

読み上げは、voicevoxがいろいろいい感じなので試してみるつもり。ドキュメントがあまり充実してなさそうなのがたまにきず。やってみた系のブログ記事が有ったのでメモ https://ponkichi.blog/raspberry-voicevox/ 。

天気予報はどこから取ってくるのがいいんだろう。とりあえず、傘が必要かどうかを知りたい。

CAMPHER-が主催した植山類さんの講演でyoutube配信があったので視聴した (youtube)。リンカの話はよく知らなかったので楽しかった。「『CSの大体の問題は間接参照で解決する』という言葉がある」という発言がなかなか面白かった。使いたくなるときに我慢して使わずに乗り越えられたら幸せになったりするだろうか。

2023-06-06

昨日は退勤後にランニングをして銭湯に行ったあと、お酒を飲んで今にいたる。ランニングをしてアパートに帰ると、階段の近くで猫が鳴いていた。一旦スルーしたのだけど、気なって戻ってからじっと見ていると近づいてきてくれた。僕は昔猫カフェに行ったときに一匹にも懐かれずに悲しい思いをしたことがあったので、近づいてきてくれた時点で感動した。猫はめちゃかわいかった。

首輪がついていたので、きっと飼い猫で人懐っこいのだろう。よふかしのうたで野良猫と遊んだあと手がすごく臭いみたいな描写があったので試しに匂いを嗅いだら虫が嫌いそうな葉っぱの匂いがした。シャンプーのにおいだったのかも。猫欲が増したイベントだった。また会えるといいなと思う。

近所にいい銭湯を見つけた。水風呂がないところは残念だけど、シンプルなお風呂と熱めお湯を提供してくれるお風呂やさんに巡り会えた、毎日通ってしまうかもしれない。明日回数券を買おう

見た感じ、今日は満月だった。

今日はいい日。

2023-05振り返り

月末なので気まぐれに今月を振り返る。

エンジニア研修が始まった。ビジネスっぽい話も面白かったけど、エンジニアっぽい話とは違う面白さだった。プログラムに関して議論するのはやはり楽しい。

蓼科と山口にいったし、日本ダービーにも行った。だいぶ遊んだ気がする。静かな週末は一回くらいだったかも知れない。読みたい本が溜まっている。

走る機会を減らして筋トレを増やしている。体重計に乗っていないので成果の程は定かでないが、体感筋肉が増えた気がする。たまに13km走るとしんどい。

親に初任給で何買うか決めてない
- 個人的に気になっている家電を送りつけて、レビューをもらう案が今のところ最有力
  - いいトースター
  - ルンバ
- その他の案
  - 置き時計・壁時計
  - ケーキ（一緒に会えれば）
いらないものを処分したい
本棚がほしい
- これは6月の課題にしよう
- いい感じの本棚を選んで、それに見合った量の本だけ残してあとは処分する
オリエン大会の運営２つに参加することになった。どちらもまだ、そんなに動いていないけど放置はできない感じ。楽しみ。

すべて6/30 9:00が締め切り。来月は振り返りと次の目標策定をする。それは6/30 23:00締め切り。

親に初任給でなにか贈る
- 喜んでもらえるもの
- ついでに僕も楽しいもの
- 兄に酒でも贈るか
部屋をいい感じにする: 読書と衣類を最適化する
- 本棚を一つ買う
- 本と服を処分する
- 夏っぽい服を買う

クラウド・インフラの理解を深める
- ラズパイ買ったのでそれで遊ぼう
- ネットワークとOSをいじる
仕事の議論についていけるようになる

月間120km走る
- 2日あたり8km
自炊写真をインスタする
- 食器がネック
運営で友達を増やす
- 試走で運営に関係ない話をするひとが増えるとよい
PC環境をなにかしら改善する
- 開発環境系がいいな。キーボードショートカットとかウィンドウマネージャもあり

初めて家の近所にあるコンパスコーヒーに行った。

日替わりの浅煎りをダブルで頂いた。今日はコロンビアらしい。あまり酸っぱくなくて後味がうまい。コーヒー豆も買ってしまうかもしれない。後味がうまいコーヒー好きで、苦くても酸っぱくても多少ならどちらもおいしいと思う。

今日はコンパスコーヒーで浅煎りのコロンビアをいただいた。とてもおいしかった。酸味が少しあるのだが控えめできつい感じはしない。それよりもあとを引くうまみが印象に残っている。
野崎まどの新作がでていることに1年くらい気づいていなかったので今日読む。
今日はペペロンチーノを昼に作った
- 明日からはインスタに写真を上げる

2023-05-26

クラフトビールを飲むと走りたくなるのをなんとかしたほうがいい気がする。心臓に悪そうだし、生活リズムが崩れる。

今日は宇宙ビールのなにかとBrasserie KnotのMOONを飲んだ。残念ながらそんなに好きな感じではなかったが、単に飲み方を間違えた感じがする。有識者から学ばないといけない。ただ、お酒を飲むと記憶が失われてしまうので知見をどうやって残すかが問題。

今夜（25日よる）は退勤後に筋トレ、本屋さんへGO、ミーティング参加、資料の読み込み、ランニングをして気分がいい。明日もがんばるぞ〜。

これまで存在を知らなかったのだが、actionsにはwate timerという設定項目があって、デプロイを許すまでの時間を設定できる。デフォルトでは5minとなっているようだ。 actionの初回トリガーについてのみ有効っぽい。

2023-05-22

週末に山口旅行に行ったのでメモしておく。秋吉台ロゲが目的な旅行で、せっかくなので前日入りした。 1日目が観光で、2日目がロゲイン。

1日目
- 移動（新幹線）
- 焼肉
- 秋芳洞
- 秋吉台
- 泉
- 酒蔵
- 宿
- 中原中也記念館
- 風呂
- 飲み会
- 散歩とほたる
2日目
- ロゲイン
- 風呂
- ご飯
- 移動
- 日焼けとの戦い

観光の日。Google mapででてきた一番早い行程で移動して時間を作った。いままでは学割だったので初めて新幹線のきっぷを普通の値段で買った。それにともなって、きっぷをネットで買ったり、モバイルPasumoと紐付けることができて楽しかった。スマホで新幹線に乗るのはすこしどきどきする。

僕と同じような思惑の人が多いのか、自由席は混み合っていた。座れない人がいて僕も危なかったが、荷物を座席においている人に声をかけて座ることに成功した。すこしコミュニケーション取れると得する。名古屋から一人と合流した。たまたま横の人たちが名古屋で降りたので、合流したもう一人は入れ替わりで座ることができてよかった。ついている。名古屋が行程のちょうど真ん中くらいで、合計で4時間ほど新幹線に乗り新山口に辿り着いた。新山口で熊本から車を運転してきてくれたもう一人と合流して、あらかじめ目星をつけておいた牧場併設のステーキハウスで早めの昼食を頂いた。

あのあたりにも地場の牛がいるみたいで少し推しているような雰囲気だった。頂いたお肉は（僕は焼肉をいただいた）やはりおいしかった。食べ放題で舞い上がる年齢は過ぎ去ったようで、いい肉をいい感じの食べ方でいただくのが最近は幸せだと感じる。食べ放題はおいしいというより楽しい感じ。そういう幸せもあるけど。

お昼を頂いてからは、すこし離れたところにある秋芳洞にいった。行くまで記憶から抜けていたが、中学三年生のころの修学旅行で秋芳洞には行ったことがあった。当時お土産に買った湯呑みが今も売られていて記憶が蘇った。二回目とはいっても違う面子で訪れているし、感性も変わっているおかげで純粋に楽しめた。あそこは今行ってもまた楽しめると思う。次行くときはもう少し地学の勉強をしてから行きたい。秋芳洞は往復することも可能だが、片道で抜けてしまうこともできて、今回は片道で地上にでることにした。地上は特に面白い感じではなかったので、特に目的がないなら往復したほうが良いだろう。

秋芳洞の入口まで帰ってから、そのあたりで売っているアイス（炭のはいった、鮮やかなアスファルトの色をしていた）を食べて、口や手を汚してから翌日訪れる秋吉台を見に行った。秋吉台の展望台の看板で知ったのだが、秋吉台は割と下の方にある鍾乳洞で、もっと上にも２つほど名前のついた、観光で入れる鍾乳洞があるらしい。そこからは車でカルストロードを抜けつつ（景色がとてもよかった）なんとか弁財天という、青くてきれいな泉を見に行った。泉では軟水を汲めて、そこそこのおいしさだった。水を汲むためのペットボトルを開けるのに1L一気飲みしたからそう感じただけかもしれない。

併設されている地域のものをうっているお店で唐辛子を買って（ペペロンチーノを作りたい、ちょうど今日の昼にペペロンチーノをいただいて、ハーブを入れるとおいしいことを知った）、宿のある湯田温泉へと移動した。

その途中で思いがけず酒蔵を見つけて覗いてみるとたまたまイベントをやっていた。おしゃれ系の酒蔵として売っているみたいで、雑誌かなにかと手を組んでいるみたいだった。酒蔵の設備を友達に解説してもらいながらおしゃれ甘酒を飲み、日本酒と関係ないところで作られたビールを買って道に戻った。

宿は青年のなんとか、みたいな行政が一枚噛んでそうなところで特にこれといった魅力はないが欠点もなく、部屋が異様に広いことが印象的だった。冷蔵庫にお酒をいれたものの電源を入れ忘れたまま街に繰り出した。だいたい16時すぎくらいだったか。

街には意外と見どころがたくさんあって、ザビエルのゆかりのところとか、芸術関係の施設、温泉、酒蔵や酒屋など、時間は足りなかった。熱意と多数決によって中原中也記念館に行くことをぬるっと決めて、詩人の石碑とかを見つつ向かった。

中原中也は「よごれちまったかなしみに」くらいしか知らなかったが金曜の夜に少しだけ予習していたので楽しみだった。行ってみると特別展として「山羊の詩」の出版にまつわることが取り上げられていて集中した。集中しても僕は早くは文章を理解できないし、閉館まで1時間もなかったので消化不良である。もう一回くらい行きたい。作品は韻がとても良かったし、原稿とか解説を通じて作品をつくるプロセスとかを知れた。あんなにすごい、自然な詩を書く人も試行錯誤をするのだと知ると勇気が湧く。作品を読むだけでは沸かない感情をいだけたので、行って良かったのだろう。

18時に閉館してしまったので、それから風呂にはいった。あのあたりは温泉がたくさんあって、そのうちの一つに入った。このときは行った温泉は、そんなに温泉っぽくなくて、次の日にロゲインの帰りに入ったほうがぬるぬるしててそれっぽかった。ロゲインの温泉は源泉かけ流しなんだとか。夕飯は目星をつけていたところはおろか、他のところにもなかなか入れず、3人で電話をかけまくってようやくカウンター席が空いているお店に巡り会えた。日本酒を中心としたお魚系のおいしい料理を頂いた。

いったん宿にもどって、荷物をおいてから（夕飯の前に中原中也記念館の隣の酒屋で買い物した）翌日のための買い物をしつつホタル見るために3kmくらい散歩した。出かけるときに冷蔵庫の電源が入っていないことに気がついたが、背に腹は変えられないので室温のビールを3人で2つ回し飲みながらの散歩になってしまった。途中のコンビニで焼きそばを補給して（一応翌日の朝ごはんとかも買って）川までたどり着くと想定外にホタルを見ることができた。町中の川にホタルが本当にいるとは思っていなかったが、しっかり光っていた。

帰りは途中まで歩いたのだが、疲れ（と酔い？）が回っていて歩きたくない雰囲気になりタクシーに少しだけのった。そのあとはすぐに就寝。

夜はよっていたわけではなく疲れていただけだったようで、みんなしっかり起きた。いつもどおり支度を済ませてロゲイン会場の秋吉台へ。秋吉台のロゲインも書くことがそれなりにあるけど、疲れたのでとりあえず省略。

走り終わってからはアイスを食べ、大会がもう開催されないことやその経緯に少しの悲しみを覚えつつ風呂に向かう。閉会式は時間かかる予感がしたのででなかった。お風呂は湯田温泉まで戻り、いい感じのところでいただいた。風呂ではゆっくりしたが、時間がないのでご飯を食べるところを急いで決めて、新山口駅へと移動。道中にある店を選んだのでそこで瓦そばと天丼をいただいた。

新山口には目標の範囲内でたどり着けて、お土産を見る時間もとれた。熊本の友達とはここで解散。途中までは完璧だったのだが、途中で乗りたい新幹線が車両点検をして30分ほど待った。不幸中の幸いで、路線の端の方からのったので、席には座れたが社内は混み合っていた。

名古屋でもう一人の友達と別れたあとは、新幹線のすごく硬いアイスのキャラメル味を食べた。多分初めてあの硬いアイスを食べたと思う（もしかしたら小さい頃に親にかってもらったかもしれない）。新横浜線に乗って家へ帰った。

秋吉台で派手に日焼けしたのを家で冷ましてから就寝。長い週末だった。

2023-05-19

明日は秋吉台に行く。楽しみ。新幹線を初めてスマホで買った。どうやらモバイルパスモで乗れるみたいなのでワクワクしてる。更に今日、仕事が終わってからJINS MEMEを買ったのでそのあたりでも楽しみが止まらない。

明日は早いのでさっさと準備して寝ないといけない。

2023-05-17

今日同僚と話していて気がついたのだが、僕は呼び方を腹に落としたい人みたいだ。新しく学んだ概念をなんて呼べば良いかがはっきりすることが大切で、単に記号として確立しているだけでは不十分みたい。たぶん、英単語を覚えるときに日本語訳より発音記号を大事にしたことが元凶だろう。

呼び方は僕の中でそれなりに重きをおいている概念な気がする。人をなんて呼ぶかは気を遣うし、呼び方が人間関係をある程度定めるとも思っている。たとえば「おまえ」と呼べる人は信頼できる人で、それが昔ながらの意味で失礼に当たらない人である、とか。

こういうふうに、名前とか呼び方を真剣に考えるのは研究室に入ってからのことだと思う。なんで考えるようになったかというと、社会学の講義で役割や役割期待について知ったことが影響していそう。もっとさかのぼると、中学で習った縁の概念も関係しているし、僕の縁の解釈には物理とか数学も絡んでいる（お酒を飲んでいるとどんどん話が発散していく）。

回線速度が良いと自己肯定感が高まってとても良い。git push が終わるまでのレイテンシでその日の幸福度の半分くらいが規定されているんじゃないだろうか。

2023-05-16

日曜はトレランして昨日は筋トレ、今日は走った。えらい。明日は夜に髪を切ってもらうのでおやすみ。今日は丸子橋で引き返した。退勤後はこれくらいがちょうどいい。

週末のロゲが楽しみ。今日、靴が届いてそれで走ってきた。フィット感はバッチリで、アウトソールが合うかの問題。というか遊歩道しかはしらなさそうなのでランニングシューズが正解かもしれん。そうなるとあの靴は普段づかいしたりたくさんトレラン・オリエンしないとかわいそうだ。

2023-05-14

高尾山で走ってきた(strava)。雨が降ったりやんだりしていて、濡れながら走った。僕ともう一人しか集まらなかったので二人でいったが、楽しかった。向こうにペースをだいぶ合わせてもらった。今回は高尾山の山頂を迂回して、小仏峠、景信山まで行った。陣馬山までいくことも考えはしていたけど、帰れるか不安だったので引き返すことにした。

景信山で持参したたべっ子水族館を食べて帰ってきた。会社の先輩が猛プッシュしていて気になったので持っていったのだった。おいしかったけど、シルエットが崩壊していて、どれが何なのかは全然わからなかった。水族館の生き物を山の上に連れて行ったのがまずかったかもしれない。

二人トレランはなかなか楽しかった。お風呂に入ってご飯を食べて帰宅。今日はからっぽになってしまった。ガッツリ運動したあとはなにもできないことを思い出した。近場のトレランだと明るいうちに帰ってこれるのでなんでもできる気になるがそんなことはない。ほわほわしてても楽しめることをあらかじめ用意しておかないともどかしい気持ちになってしまう。

2023-05-13

もともとbashで書いていたスクリプトを拡張したくなって、普段ならPythonで書くところを今日は新しいことをしてみようということでRustをつかってみることにした。

Rustはまったく初めてと言うわけではなくて、ちらちらドキュメントを読んだり、ノリで学校の課題をRustで書いてみたり（痛い目にあった）したことがある。所有権のあたりで苦労はあまりしなかった（というかPythonっぽくヒープを贅沢に使うコードを書いた）のだが、Result / Optionの変換で発狂しかけた（メソッドが定義されていることに思いをはせられずに自作してしまった）。

あまり苦労しなかったと言いつつ、所有権のあたりで困りはしている。参照を受け取るコンストラクタに、その場で作ったオブジェクトを渡したいときに、一旦変数に束縛しないと、渡すオブジェクトが即死してしまっていけない問題が面倒。名前をつけるまでもない、式が体をを表しているような値にまで名前をつかないといけないのはしんどい。コンストラクタが所有権を奪うようにすればよいのだろうか。いらないから参照にしたのだよな…。

今ではそこそこなれてきて、代数的データ型とまともな型検査器がついたPythonくらいの書き方はできるようになった。 Rustのライブラリがイケイケに作られていて（エラー処理周りは辛いと感じるけど）、プログラムを書いていて楽しい。すごく汚く書いてしまった。当面の目標はまともにかけるようになることかな？ちょっとしたCLIでは大差ないのかもしれないけど。

ブログのGitHubのプログラミング言語構成比がカオスなことになってきた。

ここ何日か胃腸炎でつらい。今日はだいぶ回復して、Rustを勉強できるくらいになったけど、まだつらみを感じる。とはいえ三食たべても大丈夫な体に戻りはしたので問題なし。何日か会社に行けなかったのがなかなか悲しい。

今日は以前もらい忘れた診断書を書いていただいた。前回の診療に対して診断書を出してもらうことはなんだか難しそうで、もう一度診察していただくことになってしまった。自分の中では治ったと思っていたけど、見ていただいたらまだ治っていないとのことだったし、今はそう感じる（流されやすい性格なのか？）ので、忠告していただけてよかったと思うことにしている。

病院の帰り道で食器のフリマ的なことを日本料理屋さんがやっていた。普段使っている食器を入れ替えるのかなにかで、安く売り出してくださっていたようだ。胃腸炎になるまえに、会社のランチで「おいしそうな自炊の写真はくろっぽい器が大切」とのアドバイスを頂いていたことを覚えていたので、これは運命だと思い食器を購入した。黒っぽい器はどんぶりしか出会えなかったけど、それがなかなかいい感じだし、白っぽい器もいい感じのにいくつか巡り会えたのでほくほくしている。

あとはおいしそうなご飯をつくればよい。

夕飯につかってみた。いい感じ。味噌汁のお椀（蓋付き）が小さいやつで、フリーズドライの味噌汁一杯分しか入らないやつ（褒めてる）。感動している。

（アマプラ）。グレンラガンの監督？が制作しているらしい。ノリが楽しい。

2023-05-09

コロナの時期に入ってから使っていたロケットモバイルを解約して、ahamoに乗り換えることにした。ロケットモバイルでは神プランという、通信制限が常にかかっているようなプランがある。通信の最初のうちだけ少しまともな速度が出るようになっているので、お財布の代わりにするくらいの用途なら困らない。電話回線込みで月に1000円程度しかかからないので、コロナ時代で引きこもっている身にはちょうど良いものだった。

外に出る機会が増えたて、会話で聞いた情報をその場で調べたり、google mapを使ったりする場面が増えて、QOLへの影響が大きくなってきたので回線を乗り換えることにした。お給料もいただけるし（明日は給料日！）。たくさん調べ物するぞ！

ahamoに乗り換えようとしていたのだが、しかしMNPがもつ契約者名義のあれこれの縛りを回避できそうになくて諦めることにした。電話番号はロケットモバイルに任せて、デュアルSIMで強く生きる。 IIJmioで10GB/monthのプランを契約した。割とすぐに使えるようになったし、1100yen/monthなのでそれなりに安く済んでいるんじゃないかと思う。試しにgoogle mapを使ってみたがいい感じ。

2023-05-07

5/4-5/6で親戚と会ってきた。少し遠目の親戚が多くて、はじめて会う人も少なくなかった。たくさんお世話になって、楽しませて頂いた。小中学生と一緒にたくさん遊んだのだのと、大人たちと夜中まで飲んでお話したのが印象的。こどもたちとはシーツをネットにしたバトミントン（相手の動きが見えない！）とかバスケやバレーっぽいことをした。時間を追うごとにルールが洗練され、楽しみを見出す場所が移ろっていた。おとなとは、持ち寄ったり、その辺においてあったりしたお酒（おいしいのばかりだった、ナポレオンの容器に入ったウイスキーと、名前を忘れたスコッチが特においしかった）を飲んだ。子育てとかキャリアの話題が中心だった。

2023-05-04

昨日スクワットしてからランニングしたら、今日トレランに行った翌日みたいな感覚になっている。手軽に足の疲労感を感じられておとく。
この間オンライン飲み会をしたときに秋吉台ロゲに参加することを決めてしまった。 5/21に5時間走る予定。競技エリアが「秋吉台山焼きの実施範囲」とされていて絶対楽しい。 5時間走って新幹線に飛び乗り、翌日仕事できる体力をつけないといけない。まずはたくさん走ることに慣れよう。5/6の午前中にたくさん走ることにする。ロゲイン的な走り方をしたい。平野ではないけど山でもないところをのっぺり走り続けるようなスタイルをイメージ。

2023-05-02

DDD周りを最近漁っている。原著はオブジェクト指向で説明されているけど、関数型で説明している本を直近で読んでいる。僕はプログラミングを関数型から始めた人間だし、集合論や関数解析が好きだったからかオブジェクト指向があまりしっくり来ない。インターフェースとかクラスでモデルする気持ちはなんとなく分かる気がするし、拡張性とか再利用性を考えたときに既存のコードをできるだけ壊さずに機能追加できるのは強いと思う。なんだけど、そういう変更ありきで書かれたコードが素直に対象を表現しているとは思えなくて辛さを感じてしまう。それに対して型とか関数型のあれこれを考えるときは、まだ分かる感じがして救いがある。モナドとかが普通のプログラミングに入ってくるとやはりこんがらがってくるのだけど。きっとパラダイムの問題ではなくて、抽象化になれてないとか親しんでないみたいなところが問題なのだろう。

話をDDDを漁っている件に戻そう。オブジェクト指向と関数型のそれぞれで同じようなことを表現しようと思ったときに使う言語機能を比べられて楽しい、ということを言いたかっただけなのだった。こういう見方をしていると、代数的エフェクトやエフェクトシステムのもたらす幸せがもっと浮かんできて本当に欲しくなるし、どんな側面が役立ちそうで、どんなところは妥協して良さそうかが感じ取れるようになってくるような気がする。

Ulauncherを使い始めた。とりあえずはただのランチャーとして使うけど、拡張機能をpythonでかけるのでターミナルの代わりのCLIとしても良いかもしれない。

2023-04-29

Money Forwardの連携を頑張った。あれだけ連携できるのはすごい。 APIを提供しているように見えない機関はどうやって対応しているのだろうか。 RPA的なものを使うのがうまかったり、営業を頑張ったりしている感じな気はする。なかなか便利。

もう少し分析をしやすいと嬉しいのだが…。 BQとかにエクスポートする機能があったらそのために課金してもいい。

CSVを落とせるので、SQLとかで分析することは可能か。 IDまでつけてくれているので、更新時に差分をとるのも簡単そうだ。

今まではChromeの機能を利用していた。便利になる。

2023-04-28

今日は意味論の直感が少し生えたので機嫌がいい。寝て起きたらもう少しまじめに考えよう。

完全に忘れていた。一回捨てた継続渡しスタイルで考えるのがやはり良いだろうという直感のもとでの考えだった。細かいことは忘れてしまったが、少し考えれば再現できる程度だったと思う。継続フレームを生むときと、式を評価するタイミングを明示的にわけるとか、反対にそういうくくりで共通化することでこれまで見えていなかったアスペクトが表面化していい感じになりそう、みたいな直感だった気がする。

alcoholタグの運用

ブログの"alcohol"タグをいつからか使い始めた。当初はお酒に関する記事につけるタグのつもりで使い始めたのだが、この度アルコールが入った状態で書いた記事にもつけることにした。

この記事の"alcohol"タグはどういう意味なのかはクイズにしたらおもしろいだろうか（こういう書き方をすると、お酒が入っているとばれるのだろう）。

2023-04-27

人と語るわけでもなければ、熱狂的に推すわけでもないのに、僕はなにのためにアニメを見たり、小説を読んだり、音楽を聞いたりするのだろうか。アニメはほぼ毎日みるし、小説は人並み以上に読むと思う。漫画もそれなりに読むし、音楽もなんやかんや毎日聞いている。これまでそういう作品の良さをまともに語ったことはないし、積極的に人と共有したりもしない。物語のキャラクターを推したいと思ったこともない。アーティストを好きになることはあっても、エッセイを読みたいとはあまり思わなくて、あくまでその人の作品が好きだからアーティストを好きになっているように思う。

アニメや漫画は単に面白いからだろうか。少なくとも日常的に触れる作品はそういう毛色が強い気がする。たとえば、鬼滅の刃やかぐや様のアニメはおもしろいから見ている。その一方で、ゾクゾクする経験があって、それが好きだという側面もある。たとえば91daysは面白かったがそれ以上にゾクゾクしたから記憶に残っている気がする。 Fate heaven’s feelやヴァイオレット・エヴェーガーデンも僕にとってゾクゾク系。

音楽はゾクゾクするのを求める気持ちがより強い。Co shu nie には特にゾクゾクを求めている。その他アニソンやボカロ、ピアノ、その他jpopも、そのときの気分にあったゾクゾクを求めて聞いている気がする。横道だけど、900STを買ってから飛躍的に音楽を聞くのが楽しくなった。幸いなことにヘッドホンはまだこれしか買っていない。初手でいいものを買う戦略が功を奏した。昨日くらいから電車通勤で音楽を聞くことに良さを見出してしまい、ワイヤレスでノイキャンのついたいいヘッドホンが欲しくなってしまった。

話を戻そう。ふんわり楽しい時間を求めるのと、ゾクゾクするのを求めるのの、２つの欲求があってそれらを満たすためにアニメとか音楽とかを浴びているようだ。それらの限らず、僕の幸せはそのどちらかにあるような気がする。ゾクゾクするほうが刺激的で楽しいので、今後はそっち方面の体験を増やすために意思決定を進めようと思う。

散歩をしてきて、本当に音楽とかに限らない話だと思った。プログラミング言語や数学のことを考えたり、プログラミングをしたり、オリエンテーリングをするときに、僕が一番好きな瞬間でモチベーションになっている体験はやはりゾクゾクしたときのことだと思う。今挙げた分野でのゾクゾクは、ハイになって、理解のぎりぎりのところで間に合ってというか、手が届いて自分のものにできた感覚だ。それに対して音楽とかアニメとかでのゾクゾクは、与えられた気持ち良さですごく心地良い体験だったり、強く共感したり、よくそこまでいった！すごい！みたいな感動から来る気がする。どちらのゾクゾクも僕を幸せにしてくれるけど、なんとなくプログラミング言語と戯れているときみたいなゾクゾクのほうが欲しい気がする。

2023-04-26

おいしいご飯を食べたら感想を残すことにする。お昼に会社近くのご飯屋さんに行く機会が多くなりそうなので、その話が多くなりそう。 Instagramに写真をあげていく。気が向いたらうまく連携する仕組みを考えよう。

月曜日は同期の紹介で焼肉屋さんに行った。お昼から焼肉を食べるのは初めてかも知れない。わさびカルビ定食をいただいた。聞いたことはあったが、わさびと油っぽいお肉は合う。塩とわさびで味付けした肉を焼いて、必要に応じて後からわさびをつけて頂く方式だった。

火曜日は先輩の紹介で中華料理屋さんに行った。パンダレストランというところで、何かが創業100年とのこと。青椒肉絲をいただいた。期待を裏切らない青椒肉絲で美味しかった。定食についてきた卵スープがコーンスープの風味もして不思議だったことが印象的。

今日も先輩の紹介でイタリアンに行った。会社近くのビルの一階にあって、雨の中でも快適でありがたかった。スパゲティをいただいたのがが、細かい名前を見忘れてしまった。そもそも書いてなかったかも知れない。きのことかナッツとかがトマトと合わさったソース（というほど液状ではなかったけど）とがパスタと絡んでおいしかった。自分で料理するときにナッツを使ったことがないので挑戦したい。

毎日おいしいものを教えていただけて幸せ。来年後輩に教えられるように、やはりメモしておくのが良いだろう。

2023-04-16

午前中はChatGPTとかであそんでいた。ブログを書いていたおかげで、AIに食わせる自分の書いた文書に困らないのが嬉しい。

文書から自分の人柄を表現してもらって、それをもとにSNSで使えるアイコンを生成しようとしたのだけどうまくいかない。人柄の表現はそれっぽいのができるのだけど、表現が抽象的になってしまうので、そのままアイコン画像を生成につかうと小学生のときによんだ漫画にでてきそうな怪しくて怖い宗教っぽい画像がでてきてしまう。

インターネット上でのキャラクタに合わせたアイコンを提案してもらえたら楽しくないだろうか？

ちなみに生成できた画像はこんな感じ。改善のしようはいくらでもありそう。

DALL-Eで生成したもので、権利の問題はなさそう (2023年4月16日閲覧):

Starting today, users get full usage rights to commercialize the images they create with DALL·E, including the right to reprint, sell, and merchandise. This includes images they generated during the research preview.

本腰を入れて文書を読むときは印刷して読みたい。なので長いWebドキュメントを読むときは少し辛いし、論文を読むときは（本腰を入れて読むなら）印刷する。本はたいてい物理の書籍を買っていた。印刷するのが面倒だし、書き込みを残しやすいので。

ただ就職して出社するようになって、移動中に文書を読みたい機会が増えた。そんななかで本を持ち運ぶのは大変で、その日に読みうる範囲だけを持ち運びたくなった。そういう経緯でPDFみたいな印刷しやすい形式で購入できる場合は積極的に電子書籍を買うようになってきた。本のサイズが小さければこれまでと変わらず物理で買ってしまうのだが、面積が大きかったり鈍器の形をしているものは電子書籍を買う。

書き込みが残らなくなる問題は解決できていないが、書き込みたくなるほどまじめの読むことは少ないし、そこまで腰を吸えられるのは結局家の中のはずだ。今の生活ではそんなに困らないだろう。余談だが、EoPLを物理でもっていないのは数少ない書き込みが大切な機会を逸しているように思える。

SNSで情報発信するのがあまり得意ではない。もともと会話があまり得意ではなくて、インスタントに情報を発するのが苦手なのだと思う。なにか考えてから言葉にするのにある程度時間がかかるし、言葉にしてから吟味したくなってしまいもする。

お酒が入ると吟味したい気持ちがどこかにいってしまうからしゃべる量が増えるのだろう。

話を戻そう。SNSは思ったことをパッと書いてそのまま発信することを重視したようなUIをしているように思う。たぶんそういうところで苦手意識を持っている。とはいえ情報発信の場としてSNSがメジャーなのは間違いないだろうし、ここみたいなブログはほとんどの人にみられないだろう。ブログを更新したときにSNSにリンクを投稿すると良い気もするが、それはそれでSNSの苦手な部分がブログ投稿に侵食してきそうで嫌な感じもする。悩ましい。

2023-04-10

この頃「詳解システム・パフォーマンス」を読んでいる。チューニングをする機会はないのでツールの説明は読み飛ばしているが、それに入る前の基礎的な概念を勉強している。学部の授業でやった理論的な基礎から復習して、もう少し具体的な実装とか最近のアーキテクチャのこととかまで勉強できている気がする。

今からファイルシステムの章を読み始める。

2023-04-06

今まではレイテンシを減らすために改札をくぐった際の処理をローカルで行い、その後まったり同期する、みたいな方式をとっているという記事をみた記憶がある。

これからそのように凝ったことはしないで、改札機はクライアント、処理は中央のサーバで行うそうだ。時代が変わったのでそれでもいけるとか。なかなか驚きだ。どんなパフォーマンスチューニングやUXまわりの工夫がされているのだろうか。 Suicaの話は何回聞いてもロマンがあると感じる。運用開始が楽しみだ。

昔Fitbitを使っていたのだけど、日々の記録が安定していておもしろくなかったから一年ほどでやめてしまった。最近通知を腕で受け取りたいとか、ランニングのときにつける時計を変えたいみたいな欲求がでてきて探してみると、 Fitbitが良さげだったので再開することにした。Charge5を使っている。必要十分プラスアルファくらいの機能でいい感じ。ただSlack返信機能を誤作動させてしまったので対策したい。ぱっといじった感じでは無効化する設定を見つけられなかった。あとは腕時計をつけなれてなくてうっとうしく感じるのが欠点。

それ以外はばっちり。ランニングの記録もとれるし、通知もしっかり気がつける。ディスプレイの常時点灯を時間をしていして有効にできるので時計としても完璧につかえる。

2023-04-03

オリエンテーリングの人たちと飲み会をした。社会人としての心構え（）を教えて頂いた。今日の入社式から頑張って行こうと思う。

こういう書き方をするとふざけているようにしか見えないだろうけど、内心ではそれなりに不安に思っているし、しっかりとしたフィードバックも受け取れたと思う。

今日、明日で良い出会いをできるといいな。

2023-04-02

CPythonの開発者向けドキュメントがとてもよい。今はコンパイラの構成に関する部分を読んでいる。抽象構文木の扱いやメモリ管理の方針など、コンパイラ開発の方針を説明している。ドラゴンブックとかからは得られない、開発手法の知識を得られて幸せ。

好きな言語にドキュメントがたくさんあることは本当に嬉しい。

学生生活の振り返り（技術）

昨日学籍を失って、こんど入社式に出る。学校に入ったり研究室に所属したり、就職したりするときには自分が抱える課題と向き合い、自分の幸せについて考えて進路を決めてきた。これから先はそういう機会が来たことに気が付きにくくなるだろう。

高校生のころ、大学にはいることは周りの雰囲気からして僕の意思が入る余地はなく決まっていた。そのなかで進路を悩んだ。理学と工学のどちらかにしようとは早く決めたのだが、そこからの踏ん切りがなかなかつかず、出願するときにエイヤと決めた。学問自体の面白さは理学に惹かれていたけど、就職とかキャリア的なことを考えると工学がよいのではないだろうかみたいな悩みかただったと思う。結局目先の面白さを優先して理学を選んだのだった。就職はなんとかなるだろうと踏んでいたし、学問の選択でなんとかならないのなら、自分は他の要因でなんとかならない人間であるはずなので、学問の選択でキャリアが狂うことを心配するのは無駄だと結論づけた。

高校生のころは化学が好きで、特に化学反応に惹かれていた。水素と酸素を一緒にしてエネルギーをかけると十中八九水に落ちるのが不思議だと感じた。統計的にそうなるのは受け入れらたのだが、反応の過程でなにが起きているのかがとても気になったし、この好奇心は普遍的なもので、すでに賢いひとが調べているはずなので大学で勉強したいと思っていた。大学で蓋をあけると、学部でやった化学や研究室で行われている研究は思ったよりもぼくにとって腑に落ちない考え方をしていて、そのなかで勉強してもぼくはあまり幸せになれないだろうと感じた。

では腑に落ちるのはどういうときだろうか、みたいなことが気になりだした。これは学部一年の後期くらいのこと。論理学とか心理学とか数学とかに答えがあるかもしれないと思いはじめて、論理学と数学を扱う数理計算科学系に所属することにした。所属のためにはある程度の成績が必要だったのだが、勉強が楽しかったのと、なにより友達に恵まれたおかげで、無事に所属できた。

数理計算の学部の講義（2018年4月から2020年3月）はどれも大体おもしろかった。集合論とか解析の話をしっかり数学者に教えていただけたのは幸せだったと思う。議論を正面からできる相手も複数人いてだいぶ恵まれていた。

学部では、数学の基礎や応用数学の入門や基礎（ORや確率・統計など）、計算機科学を学んだ。どれも専門的な議論はできるほどにはならないが、その手の書籍が怖くない程度には身につけることができた。数理論理学の講義も取り、不完全性定理の証明を追うなどした。これらの学問は現象を表現する数理的な手段を追求するものとしての側面をもち、当初の想定以上にぼくがかかえていた「腑に落ちること」の解釈（？）に影響を与えてくれた。

心理学とか小説とか、数理的とは限らない本を読むこともしていた。そういう本を本で、自分の中で巡らせていた理解を答え合わせしていたのだと思う。なんやかんやあって理解することとか腑に落ちること自体にはある程度の安定した解釈を持てて、実用上困らなくなった。

ここまでが学部3年のこと。学部3年の後期に研究室に体験所属みたいなことをして、輪講みたいなことをする機会が会った。そこで型理論に入門した。それまではプログラミングが好きじゃなかったのだが、プログラミング言語はおもしろいと思うようになった。研究室の先生方がとくに魅力的なことを決め手にして、所属を決めた。

プログラミング言語の理論の勉強、研究はおもしろかった（2020年10月から、研プロを含む）。論文や教科書はいままでで一番熱心に読んだし、人と議論して楽しいと感じた。研究でも小さなものではあるが世の中の知見を広げた感覚は得られた。この感覚は個人として、とても大切なものだと思っている。数学のゾクゾクする定理の証明を理解したときの感覚を、だれから教えられるわけでもなくて、自分で考えて得られたことが嬉しかったし、それを人に共有できる喜びもあった。

プログラミング言語についていると、嫌でもプログラミングのことを考える。この型システムを持つ言語は使いやすいだろうか、どういうふうにプログラミングがかわるだろうか、など。残念ながら僕にはプログラミングの経験があまりなく、その思考の幅が広がらなかった。このままではだいぶ人生損すると思ってプログラミングをがんがんやりたいと思うようになった。修士1年のころにはこの思いはそれなりに持っていた。

はじめの頃はどこから手を出していいかわからずだいぶ迷走した。コンパイラ最適化の実装やインターンへの参加もして、ある程度開発をしたが世の中で行われているプログラミングとの乖離を感じていた。

転機になったのが、mepayでtentenさんが主催して開催されたGo関連の短期インターン（2022年3月）だった。そこでGo言語に触れたことも大きかったし、なによりエンジニアやそれを志向する学生とコミュニケーションを取れたことでいわゆるソフトウェアエンジニアがどんなことをしていて、彼らがするプログラミングを垣間見た。その後友達の紹介でキャディでのアルバイトをはじめて、プログラミングの幅がさらに広がった。

今のぼくの関心事は上手に楽しくプログラミングをすることにある。きれいに書くとか、メンテナンスできるとか、思ったことを自然に表現できるとか、どういう考え方がいい、みたいなことに興味がある。これからはプログラミングの幅をもって広げつつ、上手に表現することを直近では追求したい。さらにそのためのプログラミング言語や環境などについても考えて、形にできたら楽しそうだと思う。

腑に落ちて、自由自在に扱えるようになると楽しいと僕は感じるのだろう。そのための過程にも楽しさを感じるように思う。

2023-04-01

久しぶりにロードバイクに乗った。名古屋に帰ったとき以来かもしれない。3年くらいぶり？腕が疲れてしまった。姿勢が良くない。町中を走って信号にたくさん捕まったことで、ブレーキをたくさんかけたり、停止からの加速をたくさんしたことが原因かもしれない。荻窪から今の家までの16kmの道のり。

2023-03-31

東大の田浦先生が公開されている大規模ソフトウェアを探るがとてもよかった。 GDBを使って大きなソフトウェアの振る舞いを理解する方法を学べる。 2年ほど前に、こういう資料が喉から手が出るほどほしいと感じていた記憶がある。

今日はこのあと研究のことを少し考え、後輩とお酒を飲む。どちらも楽しみだ。

午前中には入社や書類を仕事をした。 Macのターミナルが重い。今まで使っていた研究室のでも重かったし、新しく使い始めたものでも重い。原因を調査中。アプリを起動するのも重いし、コマンド実行が終了してプロンプトが返るまでのレイテンシもある。

GitHub Actionsの実行結果をDiscordに通知

このブログはGitHub Actionsでデプロイしているのだが、ここしばらくデプロイに失敗したことに気が付かずに放置してしまっていた。

Actions Status Discordというアクションをデプロイの最後に叩くことで、いい感じの通知をDiscordにWebhook経由で送れる。

こんな感じに実行条件を指定しないと、デプロイが失敗したときに通知が実行されないことに注意。デフォルトでは if ${{ success() }} が指定されたものとみなされるとのこと。

Hugoのマークダウン処理をカスタム

HTML文書のheading要素の周りにはidがついていてほしいし、それへのリンクは手軽にコピーできて欲しい。その点Googleのドキュメントはとても好き。人に文書コンテンツを渡すときにこちらの意図がURLで表現できるし、そのリンクを踏んだ側も見るべき箇所にスムーズにたどり着ける。このブログを書くのに使っているHugoでも同じことをした。

このコミットのように、headingのHTMLへの変換を定義する。

示したコミットではaタグで囲むだけでなく、heading levelを増やしている。 Hugoではタイトルをh1にするにもかかわらず、マークダウンの#もh1にする。そのせいで、本文を書くときは##から始める必要があって気持ち悪い。この気持ち悪さを解消するために、マークダウンのheading level+1をhtmlのheading levelとしている。

2023-03-29

今日はアルバイト先のキャディの方々に送別会を開いていただいた。一年弱お世話になった。あのころはいろんなプログラミングの経験を積みたくて入社し、結果としてキャディのあの部署（秘密なわけじゃないけど、名前がよく変わるので明言しない）じゃないと積まなかっただろう経験を積ませて頂いたと思っている。僕はだいぶ一緒に働いた方々に恵まれていて、こんなにぼくに都合の良い環境でいいのだろうかとなんど思ったかわからない。機会があれば（つくれれば）また一緒にぜひとも働きたいと思っている。それまではいわゆる大学で教わる「お行儀のよいプログラミング」しかしらなかったのだが、仕事を通じてどのように僕の仕事に価値をつけるかを意識するようになった。

例えば研究でできないことがわかったと共有することはひとつの貢献だと教わって言葉ではわかっていたことを、キャディでの仕事を通じて、実際にアウトプットとして共有できたし、他人ができないといっていたことをぼくにとっての利益として活用する経験を得られた。僕のキャリアを考える糸口にさせていただいたし、何人かの方々には相談にのっていただいた。そもそも相談する機会をいただけたこともありがたい。一重に感謝している。すこしでも皆さんに僕が貢献できたのなら光栄だと思っている。

送別会では、スポーツ羊羹とキャラメルを頂いた。エネルギーが凄そうなので、日本のどこにいても駆けつけられるだろうと思う。みなさんお世話になりました。ありがとうございました。

2020年から（学部は2017年から）通っていた東京工業大学を卒業した。晴れてぼくはmaster of scienceとして認めていただけた。心残りは多々あるし、これからもやることは山積みだが、一つの節目は迎えられたのだろう。これからは積み残しと社会でのよしなしごとに精進する（心持ちは変わらないだろうけど。ぼくは自分と他人の、幸せと自由を追求し理解することをライフワークとするのだろう）。大学でもぼくは人間関係に恵まれていた。友達にも恵まれたし、先生や先輩、後輩にも恵まれた。みなさんの優しさのおかげでいままで楽しく生きてこれたと思うし、今の僕の人格があると思う。もちろん僕の至らぬ点は僕の責任である。それでも僕が人に感謝できるのは周囲の人に優しくしてもらったからだと思う。これからも人の優しさを享受しつつ、それ以上に人に優しくしていくことを目指す。そして、優しさの価値観を洗練させていきたいと思う（たとえば厳しいことを受け入れられるように伝えるとか）。

僕の大学での生活は研究に限らず他者との交流に強く幸せが依存していた。学部のころはオリエンテーリング部での活動や、学科の友達、一年生の頃からの友達との交流でいろいろなことを構成してきた。それとは独立して本を読んだり一人で考え事をする機会もあったが、それは人との交流と必ずしも独立していなかったと思う。僕の中で際立っている人間関係はあるが、ここでは明言しないでおこう。研究で3人、一年生からはひとり、部活はいろいろ、その他はインターンやアルバイトという感じ（今の僕にはわかるように表現したつもり）。僕が他者にどんな影響を与えたかはわからないが、たまには思い出してもらえたら嬉しいと思っている。

卒業に際して旅行と飲み会をした。いつものメンツや久しぶりの人たちと互いの卒業とこれからの人生を祝福した。楽しいし、彼らとずっと一緒にいたいと思う。

僕が所属した（所属している）増原研では、この時期に先輩が新入生に対して自身の研究内容を紹介する。僕も自分がやってきた研究を紹介した。僕自身も学びがあるし、新入生は無知の知を得られるのだろう。今日のミーティングが少しでも彼らの糧になれば幸いだ。次にいつ彼らと交流できるかわからないが、話したりアウトプットを観測するのが楽しみだ。

4月から入社する会社（秘密というわけではないが、まだ入社していないので明言しない）で最初のころはオフスカジュアルとお達しを受けた。オフィオスカジュアルを一ミリも理解していなかったので、研究室の先生方や後輩、お店の店員さんに質問しまくり、ある程度落ちつけた。感想としては、スーツを指定されたほうが楽だなと思っている。それでも僕はいろいろな有識者の「オフィスカジュアル」を研究した上で出社する。最高のオフィスカジュアルで望むのご期待ください。

2023-03-21

今日は久しぶりに自転車をいじった。しばらく乗っていなかったのでタイヤとチューブを交換して、移動のために外していたリアディレーラを取り付けた。チェーンオイルを注せばある程度の遠乗りはできるだろう。

ライトとヘルメット、夏用のグローブを買わないといけない。アイウェア（なんていうんだったか）も必要か。自転車はお金がかかって良くない。でも深夜に自転車で走るのが一番どきどきするし、ランニングとかでは使わない筋肉を使う楽しさがある。それなりに遠くにいけるのも良いが、関東は広すぎる。遠くまで来た気になるにはだいぶ頑張らないといけない。箱根を越えるとだいぶ来た気になるが、それ以上に大変。

2023-03-19

最近AIが流行っていて、精度がすごいと話題で、生活が多かれ少なかれ変わっていくのだろうなという感じがする。ああいう機械学習ベースのAIは学習で直感を鍛えて、それに基づく出力をするものだと僕は解釈している。人間が頭を使うときには直感を論理とか議論で検証して、主張の穴を見つけて改善するサイクルを回すはずだ。今の機械学習っぽいAIは直感で得た主張を論理で解釈しないだろう（NECがそういうことを考えていそう。それができればAIはもっとつよくなるはずだし、そういうAIを見てみたい。

実現するためにはAIの入出力に使う「言語」に解釈を入れることと、それをもとにして論証を行うことが必要だろう。今のAIは抽象構文木を操作の対象にしていて、それを意味を解釈するようにしたらいいんじゃないかという想像だ。

今ある論理が世の中の事象を扱うのに十分かはわからないし、多分結構不足しているはずだ。機械学習AIのための論理体系の研究とかあったら楽しいだろう。NIIとかでやってないだろうか？

おととい届いたBig Peatがとてもおいしい。明日の研究室飲み会にもっていこう。ちょうど二年くらい前に部活の先輩に勧めていただいたのだが、懐具合の問題で飲めずにいた。少し無理してでも飲んでおいたほうが良かったかと思うくらいには好き。ストレートで飲んでもおいしいし、ハイボールにしてもおいしい。天才か？ぼくはスコッチウイスキー？が好きなのかもしれない。

学部2年のころ、確率論基礎の試験の前日にウイスキーを飲む会に誘っていただいたとき、ラフロイグ・ロアを味見させていただいて半分感動したのを覚えている。あのころは二十歳になりたてでお酒のおいしさは今よりも分かっていなかったのだが、それでもいいかんじなことは分かった。それからラフロイグ・ロアには縁がなかったのだが今気になっている。数量限定なようで、毎年11月ころに発売されそうな雰囲気がある。今もアマゾンで売ってるが、転売価格に見えるので時期がくるまで我慢しよう。

ちなみにBig Peatと一緒に勧めていただいたジョニーウォーカーのグリーンラベルはすでに飲んでいて、やはり好きな感じだった。

2023-03-17

ホットクックで鶏大根を作った。大根に火がうまく通っていて本領発揮を感じた。

注文していたBig Peatが届いたので、走ってから飲もうと思う。楽しみ。

クラス指向のOOPがわからない。クラスを作ってそのインスタンスを量産するようなプログラムを書いた経験がないからだろう。

そもそもクラスインスタンスを作った経験が乏しい？文字列みたいな基本的なオブジェクトや、 REST APIのクライアント、イテレータとかくらいのデータ構造くらいは確かにクラスが必要でお世話になっている。

インスタンス変数を定義するのが苦手なのかも？コンパイラみたいなデータ構造に対して一回処理をしておしまいなプログラムでは、そういう一回の処理をメソッドとして定義するのが不自然？そういうコードを書いているときに、クラスに押し込もうとするとインスタンス変数がモジュール変数に見えてくる。これは別に問題ないか。

なにがつらいのかわからなくなってきた。

使い勝手の良いデスクトップ向けウィンドウマネージャが欲しい

使い勝手のよいウィンドウマネージャがWindowsとかMacに搭載されることはないだろう。使うアプリケーションやブラウザ、入力デバイスやその使い方によって使い勝手が大きく変わるだろうから。 OSが決め打ちで提供できるものでは無いんじゃないかと思う。なので自分でまじめに使い勝手の良いものを考える必要がある。

先日オリエンテーリングのインカレの配信のお手伝いをしたのだが、そこで使っていたスイッチャがなかなかデスクトップでのウィンドウマネージャの機能として魅力的に感じた。

スイッチャにはいろんなウィンドウ（カメラからの入力や、図、合成用のテロップなど）が接続されていて、すべてが画面の下部に控えめに表示される。それらを見ながらスイッチャのオペレータが放送するためのウィンドウを選択、合成する。放送されるウィンドウは画面上部に大きく表示される。放送されるウィンドウの右に同じサイズでプレビューウィンドウも表示される。これらの違いは放送されるか否かだけで、合成のテストとかに使える。

これを実現するためには操作用のデバイス（このデバイスをスイッチャというようだ）と、大きなモニタが必要だ。

デスクトップのウィンドウマネージャでもスイッチャのように

すべてのウィンドウを表示しておいて
本番+alphaくらいのウィンドウをメインエリアに表示する

と便利な気がする。単純にはいかないだろうけど、いい線行きそうだ。

懸念事項は以下の通り:

ウィンドウの個数が多くなりそう
ウィンドウサイズが固定ではない（アスペクト比）
ウィンドウの動的な生成とその配置方法が非自明

エフェクトハンドラの良さと実用性について

エフェクトハンドラで継続や代数的エフェクトを扱う必要性は一ミリもなくて、実用的にそれらが欲しくなることはないか、あるいは限られていてそこまで一般的な機能を提供する必要はないんじゃないかと感じている。

このあたりを議論するために

エフェクトハンドラの嬉しさ
意味論の歴史的経緯
改善ポイント

を考える。

なお、この記事はとくに裏付けもなく書いている。気が向いたら裏付けをしようと思っているが、この記事の目的は僕の考えの整理であって、世に主張をしたいわけではない。

記事の内容は不正確なことを留意されたい。

エフェクトハンドラが実際的 (practical) なプログラミング言語でエンドユーザに使わせたくなるのは

エフェクトシステムと相性のよい意味論
動的束縛

を提供したいからではないだろうか。エフェクトハンドラを言語に入れれば、それで表現できる操作は自動的にエフェクトシステムで追跡できるし、ハンドラを用いることでエフェクトをローカルに使えるのは特筆するべきだろう。汎用性とlocal reasoningのしやすさはエフェクトハンドラのもつ良い性質だと思う。

エフェクトハンドラで実現できる動的束縛はとても使い勝手が良い上に、エフェクトシステムで追跡することで使い勝手が上がりそうだ。動的束縛のためだけのエフェクトシステムではなく、もう少し凝ったことができるエフェクトシステムがつくとなお幸せだろうから、エフェクトハンドラみたいな抽象度の比較的高いフレームワークで実現するのは幸せなんじゃないかと感じる。

エフェクトハンドラと呼ばずに “algebraic effects” とか “algebraic effects and handlers” とか呼ぶ流派、時代がある。歴史的には

algebraic effects
algebraic effects and handlers
effect handlers

みたいな流れで登場したはずだ。最初はハンドラはなくて、モナドとかの話をするような人たちが副作用にモナドではない別の表現を与えようとしたんだったか。ここでいうモナドはモナド則とかを真面目に考えるような数学のモナド。代数的エフェクトもその流れの中に（このころは）あったはず。そもそも代数的エフェクトの代数とは、操作が（0だか1こ以上）あって、それらに等式制約を課す。それを満たすようなモデルを持つのが代数 (algebra) である、みたいな世界だっと思う。群とか環は代数だけど、体は代数じゃないみたいな話を聞いたことがある。そういうのりの代数として、エフェクトを表現したらモナドの合成みたいなことを考えるときに幸せだ、という主張がことの発端だった気がする。

ここまでは数学とかモデル理論？とかの話によっていて、あまりプログラミング言語っぽい雰囲気がしない。ハンドラとか継続が入ってきた経緯はしらないが、多分、プログラミング言語に代数的エフェクトを入れるにあたって、モナドのbindやreturnみたいなものを定義するように、エフェクトに意味を与える仕組みとしてハンドラが考えられたんじゃないかと思う。このあたりは論文をまじめに読めば分かるはず。これが確か2014年くらいのこと。

2000年くらいだったかから考えられていたエフェクトシステムとの相性に目をつけたからか知らないが、「代数的エフェクトとハンドラ」を取り入れた言語が2014年ころに登場し始める。2017年くらいにでてくる印象がある。 EffやKokaはこのへんな気がする。このあたりで、エフェクトが代数的であることはとくに気にされなくなっていき、エフェクトシステムと例外ハンドラがうまいこと組み合わさる限定継続演算子くらいの気持ちで代数的エフェクトとそのハンドラが捉えられて、やがて代数的ではないことが気になる人々がエフェクトハンドラと呼ぶようになったのではないかと思っている。

限定継続は本当に必要だろうか。もっとやさしい概念を提供するのにとどめるのはいかがだろうか。ワンショット継続とかに限定する言語もあるが、それは正しい方向性だろうか。

僕たちがほしかったものは、local reasoningしやすいエフェクトシステムとそれで健全に管理できる意味論なんじゃないかと思う。エフェクトハンドラはその条件を満たすけど、もっと使い心地のよい意味論があるはずだと思う。

最後の文をメモしたくてこの記事を書いた。それ以外は文脈である。

Google Cloudの認証を必要とするアプリケーション開発について

Google Cloudの認証・認可はきめ細かくちゃんとしている感じがして、扱うのが難しいと感じていた。少し調べたらApplication Default Credentials with client librariesの説明を見つけて腹に落ちた。これを抑えた上で、それぞれの実行環境でどのようにcredentialをセットアップするかを見ると、プロセスの権限が半分くらいわかる。ここまでで、サービスアカウントがどのようにプロセスに付与されるかを理解できるはずだ。

次に、それぞれのサービスアカウントがどのようなリソースへのアクセスをもつか、それをどうやって設定するかを確認すれば認証・認可を自由に管理できるんじゃないかと思う。How Application Default Credentials worksが良い水先案内に見える。

このあたりは知識がないと本当に挙動がわけわからないので分かりやすいところにドキュメントを置いといたり、積極的にエラーメッセージで教えてほしい。 Google Cloudを使う上での義務教育だと感じた。

2023-03-14

TODO: 割と眠いときに書いたのでまとまっていない。気が向いたら書き直す。

日常のおしゃべりではなくて、仕事や練習、議論の場でどれくらい「優しく」するべきかは悩ましい。真剣に、最短でコミュニケーションするといわゆる優しさが欠けがちなのだが、いわゆる優しさを優先してコミュニケーションしていると本来の目的が疎かになる。

例えばコードレビューでイカれた名前をつけ、グローバル変数を好き放題使っているコードを出されたときにはそれらを指摘して改善に導くのが本来の目的だ。コードのまずい点を明確に指摘して、それが及ぼす悪影響なんかも添えると親切だろう。さらに改善案を示して、その変更を採用した場合の影響を示すのも有効だと思う。ただ、こういうことを最小限のコミュニケーションで提示すると、レビュイーは自分がバカであると感じたり、最初からレビュワーがやればいいではないかと感じることが多そうだ。それを避けて、正面から改善のために向き合えるように「優しさ」を発揮して、生じるのが今回議論したい優しさ優先のコミュニケーションだ。

ぼくは優しさ優先のコミュニケーションはいらなければそれに越したことはないけど、一般的には必要なものだと思っている。不要な情報は発せられないことは当然望ましいけど、モチベーションみたいなものは大切で大事に扱わないといけないだろうから。

優しさのない、そっけない態度で議論とかを振られると、そのときむっとすることはあるが、あとから信頼みたいなものを感じて嬉しくなるのはぼくだけだろうか。ある程度信頼している相手にそういうそっけないやり方で議論を振ったときに、向こうに分かってもらえず少し嫌われたことがあってちょっとしたトラウマになっている。

これを読むと、僕は冗談とかが嫌いな人間に思えるかもしれないが、そんなことはない。議論に冗談が挟まるのは割と好き。でもその余裕がないときとか白熱したときとかにダイレクトに主張を交換できる関係は幸せだという認識がまずある。その上で、まだそこまで至っていない関係では、コミュニケーションを工夫して補うのがいいんじゃないか、という考え方をしている。

これを書こうと思ったのは、優しさを脇においたコミュニケーションに反感を買う様子を目の当たりにしたからだ。そこで気づきを得て、内容をぼかして抽象的なことを書いてみた。だれも悪くないし、みんないい人なのであの環境のもやもやを解決できるといいなと思っている。

2023-03-09

昨日PPLから帰ってきた。初めて対面で学会に参加した。対面だと変な疲れ方しないし、コミュニケーションを取りやすいのがいい。ポスター発表が特に楽しかった。

研究室の人とバーに行った。初めてのバーだった。初めて飲むたぐいのお酒を飲んだし、初めての飲み方をした。僕はやはりウイスキーが好きなことがわかった。

ふんわり想像していたことを2つ実際に経験できたわけで、それぞれ期待を上回る部分や下回る部分があったのでメモ。学会は思ったより楽しいし、普段合わない人に話が意外と通じる。とはいえ常に話が盛り上がるわけではなくて、お互いにある程度深い話ができないとそんなに盛り上がらない。話がわからないと全然盛り上がらないのは結構強く感じた。研究分野に流行り廃りができるのはこのあたりが大きな要因なのではないだろうか。そして友達はそうそう簡単にはできない。アウトプットがベースにある交流の積み重ねが必要なのだろう。

Linux (gnome) でよくやる設定

GNOMEというかLinuxというかでよくやる設定を列挙する。キーボード系が多いと思う。

以下を実行

gsettings set org.gnome.Terminal.Legacy.Keybindings:/org/gnome/terminal/legacy/keybindings/ next-tab '<Primary>Tab'
gsettings set org.gnome.Terminal.Legacy.Keybindings:/org/gnome/terminal/legacy/keybindings/ prev-tab '<Primary><Shift>Tab'

参考: https://askubuntu.com/questions/133384/keyboard-shortcut-gnome-terminal-ctrl-tab-and-ctrl-shift-tab-in-12-04

xremapやxkeysnailを使うどちらもそんなに使い心地は変わらないと思う。今はxkeysnailを使っている。

課題が2つある:

xkeysnailがuinputを必要とすること
- sudoが必要とreadmeに書かれているのはこれが理由
xkeysnailをsystemdに登録すること
- sudoつけられない/等価なことはできない？

以下のように解決する

必要な権限を自分に与える
1. sudoなしでxkesynailを実行できるようになる
systemdに登録して、ログインくらいのタイミングで有効にする

これの通りにやればよい: https://github.com/mooz/xkeysnail/issues/64#issuecomment-600380800

設定ファイルを書く https://github.com/naoyafurudono/configs/blob/main/systemd/user/xkeysnail.service
~/.config/systemd/user/におく
1. バイナリをおく: 上の例では~/.local/binにおいてあることを想定している
systemdに登録する: systemctl --user enable --now xkeynail
1. enableで登録、--nowで今実行

もしうごかなかったらjounalctl -rでsystemdのログをみる。

https://github.com/naoyafurudono/configs/blob/main/mozc/ibus_config.textprotoを~/.config/mozc/におく。

参考: https://blog.nfurudono.com/posts/mozc-default-engine/

2023-02-27

Gentooが入った。基本的に待っているだけではあるのだけど、それがなかなか大変。パッケージを一瞬でインストールできる幸せに気がついた。割とすぐにUbuntuに戻るかもしれない。今はnodejsとtexliveをコンパイルしている。未だかつてなくCPUが仕事をしている。かわいそうに。とはいえportageに触れるのはなかなか楽しい。

mozcの設定はこのブログのメモに助けられた。過去の自分に感謝。

(追伸) Gentooを入れるためにssdを付け替えたのだけど、そのときにじゃまで外したCPUクーラーがうまくはまっていなかった。このPCはまともな冷却なしでもろもろをビルドしていたのだ。本当にかわいそうなことをしてしまった。ずっとうるさかったのでさっさと気がつくべきだった。今はこれまでがうそのように静か。

2023-02-26

Golangをすごく久しぶりに書いた結果、構造体の要素がコピーされることを忘れておりデバッグに時間を溶かした（コピーした構造体のフィールドを書き換えて、コピー元に変化が起きると思い込んでいた）。最近はPythonやTSか、関数型言語ばかり書いていて、Cっぽい構造体の扱いをしていなかったので忘れてしまっていたのだろう。忘れていたけど、CやGoのように構造体の要素をコピーする意味論は好き。直感的というか、明示的にポインタを表現することが好きなのだろうか。

軽いドキュメントを印刷するためのツールが欲しい

さくっと書いた文書を印刷したいことがある。ビジネスライクな手紙とか、その日のTODOリストなんかがそうだ。 LaTeXやMadokoを使うのは大げさな感じがして、諦めて手書きするか、Google Docsで済ませることが多い。とはいえ手紙の書き方を毎回調べたり、フォーマットを調整したり、PCで打ち込んだデータを手書きするのはつらい。

テンプレートと変数の宣言、UIの調整と文書のまともな処理をして印刷（A4）できるものが欲しい。A4のPDFに変換できればよい。それぞれの文書のソースはマークダウンのちょっとした拡張くらいの文法で書きたい。エディタで編集したいのでGoogle Docsとかはなしで。テンプレートの作成方法はテキストにこだわらない。いじりやすいと嬉しい。

問題が以下のように分割できるはず。

テンプレート作成
ソースの文法
- Markdown拡張
テンプレートへのソースの埋め込み
PDFへの変換

HTML/CSSやlatexを勉強してMadokoでくっつければなんとかできる気はするが、大変そうだしあまり楽しくない。文書作成ツールを自作するか？とりあえず、HTML/CSSで手紙を表現できるようになるところから始めるのが良さそうか。自作マークダウン拡張（というより処理系）はまれに欲しくなるのでやっても良いだろう。Hugoもそんなに快適じゃないし、Madokoはいじりにくいので。

自分でコードをいじりやすいこと
メタな文書処理がしやすいこと
- 識別子や文書の変数への束縛、正規表現やCFGベースのテキスト置換など
- この辺はMadokoが強い
そういえばMadokoはPDFの生成でHTMLを使わずにlatexを使っていたな…

ここまで来て、Paper CSSという良さげなリポジトリを見つけた。 Qitaでこのライブラリを使って帳票を作る例が解説されている。

まだそれぞれをあまり読んでいないのであとで確認する。このあたりの技術に合うように出力することにして、それを生成するマークダウンエンジンを用意すればok?

やはりしんどい気がする。GUIでなんとかする方法を探すのが楽だろうか。あらためて考えよう。

Google Docs APIを利用するのはどうだろうか。 APIはあまりリッチではなくて、create, update, pullができるのみ。文書構造の編集はJSONをごりごりいじることで実現する。JSONスキーマが定義されているので、これを見ながら必要な変換を定義すればよい。

テンプレートをGoogle DocsのGUIで作成して、それをAPIでpullした上で、コンテンツを注入したドキュメントをcreateすれば、やりたかったことを実現できそうだ。テンプレートの置き換え箇所の指定方法はどうするのが良いだろうか。

(開始記号)名前(引数リスト)(終了記号)を文書に埋め込む。これがひとかたまりの文書オブジェクトとして認識されることが必要。また、これにスタイリングを適用した場合、埋め込み後もそのスタイリングが保たれるようにする。引数に他の名前が出現しうることに注意する

テンプレに埋め込むテキストを定義する側では、埋め込み内容の定義リストを作成する:

def name(args: list[str]) -> str:
  return f"""\
ここに置換後の文字列を書く。
ここにも埋め込みの出現を許す。
"""

埋め込み処理では、JSON形式のテンプレのすべてのテキストについてマクロ展開をすればよい。

リブロワークスからCSSで組版するノウハウをまとめた本が5/12に出るらしい。途中までをオフィシャルが公開している。 Vivliostyleというソフトを使って、MarkdownとCSSで書籍を作るらしい。その手のソフトは他にもあるようで、比較サイトを先の書籍で紹介されていた。

こう思うとmadokoはだいぶ良いものだなと感じる。適用範囲を限定した置換とlatexはなかなか強い。 latexとcssを完全に理解すればmadokoが最高かもしれない。

2023-02-24

最近は時間とベーシックな元気が足りない。この時期にやりたいこと/やるべきことがたくさん押し寄せてくるのはどうしてだろう。変わり目だからか。これまでぼちぼちやっていたものを、みんなが足並みをそろえて一段落つけようとするから忙しいのだろう。意識的に間引く必要があるかな。

PCの構成メモ

PCを自作して使っているのだけど、どんなパーツを使ったか忘れて後でなにか買い足すときに互換性があるかわからなくてこまる。今回調査してメモしておく。

CPU: Core i5 12400
マザーボード: GIGABYTE B660M DS3H AX DDR4 [Rev.1.x]
RAM: DDR4-3200 (2933・2666対応) (PC4-25600) W4U3200CM-8GR
SSD: WDS500G3X0E
- M.2 NVMe 内蔵SSD / 500GB / PCIe Gen4x4 / WD BLACK SN770 NVMe SSDシリーズ
ケース: Thermaltake Versa H17 ミニタワー型PCケース CS7096 CA-1J1-00S1NN-00
電源: XPG PYLON パイロン 450W PC電源ユニット [ 80PLUS Bronze認証取得 ] PYLON450B-BKCJP

Ubuntuを入れて使っているけど特に不満はない。不満はないのだが、この間Gentooのことを教えてもらって面白そうなので使ってみようと思っている。

余談だが、このPCは親に就活で必要だろうからといって渡してもらったお金で組んだのだった。自由に使えと言ってもらったが、きっとスーツとかを想定していたのだろう。幸いなことにスーツは買わずに済んでいるので（兄のお下がりがまだ着れる）、ずっと気になっていた自作PCに手を出すのに使ったのだった。少し後ろめたい気持ちがないでもなかったが、Linuxとか触るの楽しいことが分かって仕事でもこの手のものを触りたいと思えたし、面接の話のネタにもなったので結果オーライだろう。学校とか本で学ぶOS周りの技術をそのまま試せるのが僕には嬉しかったのだろう。Windowsでは厳しいし、Macもどこか違っているので。

2023-02-21

昨日まで4日連続で人とご飯を食べた。いろんな人と話せて楽しかった。今日は研究室に行くし、昨日はオンラインでのコミュニケーションで別のコミュニティの人と話したので、社会性週間だ。てんやわんやしている。（追記）研究室ではお土産を持ってきてくれた人がいて、お茶した。だいぶ話し込んでしまった。

ご飯がおいしかったのは、昨日のカレー屋さんで、カレーコース？を食べさせてもらった。行く前のイメージはカレーを何種類も食べるカレーバイキングみたいなものを想像して楽しみかつ戦々恐々という感じだったのだが、蓋を開けるとカレーは一つだけでそこにたどり着くまでに野菜や肉を出してくれた。その後にアイスとチャイを出していただいた。ビールやラッシーが飲み放題で、ラッシーを浴びるように飲んだ。あんなにラッシーをたくさん飲んだのは初めて。こういう料理は食べて美味しいけど家で作る感じではないな。お店の味と言う感じがした。

昨日はご飯がおいしいのも嬉しいポイントだが、初めての人たち（それも楽しいひと）と話せたのが嬉しかった。社会は大変だということを教えていただいた。宿題でバーキン（バーガーキングではない、パーマンの音程）をググったのでメモしておく。値段の桁に驚いてしまった。「一生ものとして日常使いにこそ活躍できるバッグです」と紹介されている。煽りとか皮肉とかではまったくなく、どういう日常をおくるのか気になる。ちなみに、バーガーキングは Burger King でバーキンは Birkin なので、英語表記では少しずれる。惜しい。

昨日以外は学科同期や部活同期とご飯を食べたのだった。餃子のタレをジントニックに入れるとおいしくない。日本酒にわさびをいれるのは美味しいらしい。

Linuxシステムプログラミング（アフェリエイトリンク）を読み始めた。 Linuxでのファイルとプロセスについて説明されている。これまでIO周りのバッファとかよくわかっていなかったけど、ここまでの読書でスッキリした。こういうことはただの知識な感じがして、学校で教えられても忘れそうではあるのだけど、必要になったときに勉強する戦略が通じるとは思えない。必要なときに必要だと気がつくのは難しそう。こういうのを教養というのだろうか。だとしたら学校で教わって覚えておくべきなのかも知れない。

OSとプログラミング言語の間のところを勉強している感じがして楽しい。このあたりが分かれば、手を出せる幅がだいぶ広がるんじゃないかと思っている。システムプログラミングをゴリゴリやるのも楽しいかも知れない。ゴリゴリやらないにしても、ソフトウェアを作るときの一つの課題の解決策としてシステムプログラミングを常に選択できるようにしたい気持ちがある。

仕事に絡めたいかは別にして、パソコンの操作性を上げたい。キーボードの設定・設計やIME、アプリケーションの（ショートカット）キー設定とかで、飛躍的にパソコン操作が快適になるはずだ。難関はブラウザやSlackなどのGUIアプリだろう。

Fluent Pythonと言う本が面白そう。最近英語で第二版がでたようだ。

HugoでタグをつけるためのTips

車輪の再発明ではあるだろうけどメモしておく。archetypes/にhugo newで生成する.mdファイルのテンプレを置くことができる。そこにありうるすべてのタグを書いておけば、記事を書くときに関係ないタグを消すことで、関連するタグを忘れずにつけることができる。

僕は以下のようにフロントマターを設定している。

---
title: "TODO"
date: {{ .Date }}
author: "Naoya Furudono"
draft: true
tags: [
    "daily"
    ,"PL"
    ,"tech"
    ,"ubuntu"
    ,"alexa"
    ,"book"
    ,"idea"
    ,"python"
    ,"tool"
]
---

2023-02-16

Jane Streatのテックブログで単体テストの書き方が紹介されていた。記事ではその手法をexpect testと呼んでいて、プログラムを書いてその結果を確認してokだったら受け入れる、というものだ。受け入れた結果はソースファイルに保存されて、その後は単体テストとして機能する。

IPythonとかで書いて、試して書き直すループを繰り返し、良さげな結果が得られたら良しとするスタイルの開発の改良版だと思える。 TDDの人が見たら気になる？のかもしれないが、記事ではTDDについても言及していた。

僕はIPythonを最近使う機会が多くて気に入ってしまっているので、expect testも良さげに思えた。昔学校の授業で単体テストを書かされて飽き飽きしていたのを思い出した。

Jane StreetはなんでもOCamlで作っていてすごい
動作のGIF画像がSpacemacsで動いていた
- 昔Macで動かしていて、もっさりしていたのといろんな言語に手を出す時期で拡張が面倒でVSCodeに移行してしまったのだった。今はPCのスペックが上がったので戻ってもよいかもしれない。言語はまだfixできていないが（一生fixしない？）。
この記事以外のブログポストもなかなか面白い(link)。

好きなPL本

プログラミング言語を勉強するとイディオムとかその言語界隈でのベストプラクティスが学べて良い、みたいなことが巷でよく言われる。確かにそれはそのとおりだとぼくも感じるのだが、雑にチュートリアルをこなしたりするだけでは言語をよく学べないだろうと思うし、良い情報源を見つけることはそんなに簡単ではないと感じている。

僕がこれまで呼んだPL系の本でこれはと思ったものがいくつかあるので紹介する。 (注意: 好奇心でアフィリエイトを試しています。アマゾンへのリンクはアフィリエイトを有効にしています。)

C言語: The C Programming Language
- 低レイヤを知りたい人のためのCコンパイラ作成入門も面白い
Go言語: プログラミング言語Go
OCaml: Real World OCaml: Functional Programming for the Masses
- ここで公式が無料でHTML版を公開している。
Python: Google Python Style Guide
- Python以外の言語についてもスタイルガイドがある

どれも勉強になる。文化の共通部分と異なる部分があって楽しい。共通部分はプログラミング全般で大切なのだろうと思うし、異なる部分は言語の活かし方なのだろうと思う。

そういえばこういう本を読んだときと、良いPLの論文を読んだときでは感想が異なる。 PLの論文はすごいアイデアを中心として、周辺の概念がうまく回っていく様を見せつけられると感動するのだが、この手の本はもっといろんな機能や習慣がうまく組み合わさる様を見せつけてくれる。甲乙つくものではないだろう。

ちなみに、いま述べた類の感動を与えてくれたのはこれら2つがぱっと思いついた:

1つ目は背景知識がたくさんいる気がするので人にはおすすめしない。 2つめは必要な背景知識が少なめなはず。

このように整理すると、local reasoningがPL意味論で大切にしたい中心的な概念に思える。本当だろうか。

2023-02-15

Real World OCaml FUNCTIONAL PROGRAMMING FOR THE MASSESを読み始めた。 Practicalで面白いと伺って、目次を見たら実際そのようだったので読んでいる。 3年前にプログラミング in OCamlで入門したのが懐かしい。 Real World OCamlはOCamlらしいOCamlの書き方を教えてくれている感じがする。まだ最初の方なのでレビュはできないが。

最近出版された本ということもあり、サポートページやそれぞれのツールのREADMEに従えばすんなり環境構築できた。プラスアルファでduneを使うことにしたのだけど、その使い方が公式ドキュメントを読んでも不思議な感じで苦労したからメモしておく。

dune init project <name>でプロジェクトを作成
dune buildでmainをコンパイル
依存を加えたいときは、該当するduneファイルのlibraliesフォームと、dune-projectのdependsフォームに依存ライブラリ名を追加する。そのうえでdune buildすると処理してopamファイルを上書きしてくれる。dune-projectに追記しなくてもコンパイルはできるが、opamファイルが更新されない。IDEはopamファイルを見ているようなので、linterのお世話になるためにdune-projectにも書き込む必要がある。

2023-02-12

ドメインを取得して、サーバを借りた。もちろんムームードメインとロリポップを使っている。

ブログのドメインを独自ドメインに変更したらhttpsが無効になってしまった。読むときに怒るブラウザいるかも知れないのが怖いけど、お金がかかるし面倒なのでこのままにしておく。 httpsを有効にした。お金はかからなかった。ロリポップが無料で引き受けてくれた。感謝。 Hugoのbase URLの設定をし忘れて、CORSとかで怒られたのでメモしておく。

サーバへのデプロイを初めて行った。クラウドサービスをずっと使っていて、サーバにファイルを上げるとかその前にビルドするみたいな作業は初めてだった。今日は独自ドメイン記念日であり、デプロイ記念日でもある。デプロイ記念日は微妙か。サーバで動くプログラムを走らせたりしてないし。

そういうわけで今日は独自ドメイン記念日ということにしよう。

2023-02-10

髪を切ってもらった。２ヶ月くらい切っていなかった気がする。今回は引っ越してから初めて近所で切ってもらった。なかなかいいかんじのお店、店員さんに巡り会えた。嬉しい。

修論発表お疲れ会を学科同期とした。九絵でいいご飯（九絵定食なめろうつき）をたべてカラオケ、ビリヤード、ダーツをして解散。卒業すると会う頻度が今よりぐっと減るのだろう。

2023-02-08

昨日、修論発表をした。発表する部屋が想像より大きかった。発表の内容はなかなか未熟だったけど、あれよりいいものを作る時間があったら研究をもっと進められると思うので、発表の準備作業に改善点はあまりないと思う。

これからも研究を改善していくのだが、方針を変えるのが良いだろう。これまでの方法では一つのステップがいろんな概念と絡まりすぎていて理論的に難しい。ラムダ抽象はラムダ計算ではきれいなだけで、僕たちが扱うシステムでは素直な言語機能ではないはずだ。ラムダ抽象にはやりたいことが詰まっていて魅力的な目標だけど、今はぐっとこらえて問題を分割するのがやるべきことだと思う。

値としてのデータ構造の表現が問題になるだろう。一口にデータ構造といっても、ヒープ領域とポインタで表現するか、TaPLのレコードのような値を扱うかでだいぶ雰囲気が変わってくる。どちらをモデルしたいかで決めるのが良いのだろうと思う。

ここまで書いたが、僕と一緒に研究している人以外はなんのことだかわからない内容になってしまった。目を通してくれた人には申し訳ないが、他に適切な放流場所もないのでこのままブログに流してしまおう。

ウイスキーの甲州韮崎を買った。スッキリしてる。おいしい。ウイスキーを飲みまくる飲み会をしたいわね。おいしいものからそうでもないものまでいろいろ飲み比べたい。

2023-02-03

自分のご機嫌をとるのは難しい。睡眠やエネルギーが足りていないだけのこともあれば、体を動かしていなくてつらいこともある。気持ちが足りないこともあれば、気温が低いことが原因で機嫌が良くないというか、パフォーマンスがでないこともある。他にもモニタの見すぎとか眼精疲労みたいなものが原因なこともある。

それぞれを回復する手段はある程度もっているのだが、座って作業をするなかではどれが原因なのかをなかなか判断できない。すべてうまく回すような、余裕を持った生活をできれば良いのだが、そうも言ってられない時期はどうしてもある（今がそう）。

特効薬はおそらくなくて、余裕をできるだけ長くもてるように日頃から負荷分散に務めることが肝要なのだろう。

2023-01-24

この前みそしるを作ったのだけど火にかけたことを忘れて2,3時間放置してしまった。水分は完全に失われ、具のもやしとは白菜が完全に炭になっていた。幸い火事とかにはならなかったが、炭の匂いがなかなかとれない。

そこで人生初の消臭力を買って置いてみた。またたく間に匂いは和らぎせっけんの香りが心を安らかにしてくれたのだが、次第に残った炭の匂いと調和してタバコくさい、芳香剤の効いた車の匂いになってしまった。なかなかうまくいかないものだ。

2023-01-15

カタログギフトで頂いたお茶が届いた。煎茶の詰め合わせで、いい感じの缶に入っている。 300gもあるのでうまい運用を考えたいところだ。研究室で飲むか。

メーカが紹介しているお茶の入れ方をメモしておく。

2023-01-13

鼻セレブを使い切ってしまった。

熱も引いてるし喉の痛みも大体おさまったのだが、鼻だけがおさまらない。いいティッシュ買い足さないと、週明けには擦り切れてなくなっているかも知れない。

家に引きこもっているので、一人で議論している。なかなか楽しいし、進捗も生まれやすいように感じる。

議論は仮想的に二人で行っていて、チャット形式でおこなう。先に喋りだしたほうがaで、もう片方がbだ。 aがアイデアを提案して、それにbがツッコミを入れることが多い。 aはツッコミから防衛したり、主張を取り下げたりする。防衛したら、bは確かにそうだねとなるか、さらなるツッコミをいれるのが定番の流れだ。

とはいえ、aが防御でbが攻め、みたいなふうに固定するわけではなく、bが自説を振りかざすこともあるし、 aの主張を補助することもある。逆もまたしかりだ。

チャット形式にすると、途中で疲れて中断しても復帰できるのがいい。議事録もとれているのでしばらくたってから見返すこともできるかもしれない。とりあえず議論の結論がでたので、一息ついてから作業に取り組もうと思う。

2023-01-12

36.8

風邪は大体治ったように感じるのだが、鼻水だけが止まらない。おかげで鼻セレブを手放せない体になってしまった。パッケージがうさぎなので縁起物である。

2023-01-10

Value independeceという言葉をVIMPL 2023のcall for papers経由で知ったのだが、それがどういう概念かを説明するドキュメントは見つからなかった。頑張って検索すると、VIMPLの組織委員であるDave Abrahams (twitter) (GitHub)のCPPCon2022での公演を見つけた: Value Semantics: Safety, Independence, Projection, & Future of Programming - Dave Abrahams CppCon 22。 Valueが指すのはC++のvalue semanticsのvalueらしい。一年くらい前にちらっとvalue semanticsを覗き見ていいなと思った気がする。ここで再会できて嬉しい。公演はすごくよくて、value independenceが表現したい概念がなんとなくつかめた気がする。僕の理解が追いついていないのでそのうち復習しよう。 value independenceを説明するだけの公演ではなくて、示唆に富んだ内容に思えた。彼が今度日本に来るなんて最高だ。3月13-17は空けておこう。

最近研究で値と参照のことを考えていたのでちょっと親近感を覚えたというか、勇気やモチベーションみたいなものが湧いた。

2023-01-09

念願かなって時計を壁にかけた。今までは机の上に置いていたのだけど、なにかの拍子に落としたり、モニタを見るときの邪魔になったりしていた。

壁にかけると邪魔じゃないし、位置が固定されるのが良い。それに時計が見える範囲が広がったのも嬉しい。これまではベッドからは時計が見えなくて、朝起きたときは何時かわからなかった。これからはすぐに時刻がわかる。だから何というわけではないけど。よかったね。

体温は37.1度だった。あんまり下がりませんな。

2023-01-08

体温: 37.1

かぜが治らない。なんなら体温が少し上がっている。熱は感じないけど、体がだるい感じがする。背中や腰が痛いというかしんどい。部屋が少し埃っぽいので今日は掃除をする。来月の頭までもつくらいに、がっつりきれいにしたい。

夜になった。体温はあまり変わらず36.9度だった。だけど体は結構楽になった。部屋をきれいに掃除してご飯をしっかり食べた。作業も少しできたので幸せ。

2023-01-07

体温: 36.7

かぜが悪化している。今日の昼に病院に行った。引っ越してから初めて病院に行ったのでどこに行こうか迷ったけど、見てもらった病院や薬局の方が良い方ばかりだったので良かった。コロナとか肺炎とかではなさそう。たくさんもらった薬を飲んでさっさと調子を取り戻したい。

体温計を持っていなかったので買ってきたのだが、最初検温に10分かかるモデルを買おうとしており、レジで店員さんが指摘してくれた。違うモデルを案内してもらって、少し高いけど15秒で測れるモデルを買うことができた。混んでいたのに優しくしていただいて、二重でありがたい。

このあたりは物価が高いのは悪いところだが、民度も高いように感じる。献身的というか、振る舞いの端々に人の幸せを願っている節を感じる。

Pythonのジェネレータをyieldで書く例

Pythonのジェネレータ（というよりyield）の挙動を示す例を書いた。二分木を作るgenと、ノードを探索してその内容を表す文字列を返すジェネレータを返すconvを定義した。convがこういう風に定義できることを例で確認したかった。

from dataclasses import dataclass
import itertools
import random
from typing import Generator


@dataclass
class Tree:
    value: str


@dataclass
class Node(Tree):
    children: list[Tree]


@dataclass
class Leaf(Tree):
    pass


def gen(n):
    msg = f"{random.randbytes(1)}"
    if n <= 0:
        return Leaf(msg)
    else:
        return Node(msg, [gen(n - 1), gen(n - 2)])


def conv(t: Tree) -> Generator[str, None, None]:
    if isinstance(t, Leaf):
        yield f"Leaf: {t.value}"
    elif isinstance(t, Node):
        for i in itertools.chain(*map(conv, t.children)):
            yield i
        yield f"Node: {t.value}"


if __name__ == "__main__":
    import pprint as pp

    t = gen(3)
    pp.pprint(t)
    for i in conv(t):
        print(i)

2023-01-06

昨日の朝からのどが痛い。それ以外の症状はないので単に乾燥とかにやられただけだと思う。とはいえ確証がないので学校にはとりあえず行かないようにしている。おしゃべりと作業を学校でしたい〜。週明けにたくさんたのしい議論ができるように（それをモチベーションにして）研究とかの作業を進めておこう。

2023-01-05

年末にPython向けのGoogleのスタイルガイドを読んでからPythonを書くのがとても楽しい。知らなかった言語機能やその有効な使い方とその理由をコンパクトに説明してくれる。言語機能の使い方は補足程度で、機能そのものは知っていたりググって理解することを読者に期待していそう。言語に入門したあと、息を吸うようにかけるようになるまでの間を埋めるのに役立ちそう。

その他の言語についてもGoogleはスタイルガイドを公開しているので折をみて目を通したい。

UbuntuでPDFを印刷するときに拡大縮小ができなくて困っていた。たまたま巡り合ったこの記事のおかげで解決した。

2023-01-02

名古屋の地下鉄に久しぶりに乗った。桜通り線は電車がホーム来る前後の音楽や音がいい。特に構内放送が始まる前の音楽がかっこいい。ギターっぽい少し高めの音を出す弦楽器で奏でられた5秒くらいの曲が流れる。

今日は栄まで行ってきた。正月の栄という感じだったが、そもそも正月に行くところではないような気がする。来年は熱田神宮や伊勢、東京のお社に行くと楽しいだろう。思いきりまったしたい。

帰りは散歩をしたい気分だったので、少し遠いけど歩いて帰った。僕は走るのが好きなのだが、体を動かすというよりぶらぶらするのが好きなのかもしれない。歩くよりも走るスピード感が好きだし、自転車とかでは交通ルールに縛られるから何にしても走るのが好きではある。

明日から学校には歩いて行こうと思う。走って登下校は大変なので一回でやめたのだが歩いて登下校なら特に無理もないし楽しいと思う。

今日はいとこ3世代が実家に来るので楽しみ。

P.S. 一緒に遊んだ。20こくらい離れているが昔僕が楽しいと思ったことを割と同様に楽しんでいたようだ。子供（男の子？）はそんなものなのか、親戚だからなのか、それともたまたまだったり僕の思い過ごしだろうか。何にしても楽しかった。

プロファイラに詳しくなりたいし、使い勝手の良いものを実装したい。最適化をする前のターゲットや目標、成果の見積もりをするためにプロファイラが必要だ。一口にプロファイラと言ってもその対象はいろいろあるわけでこれを使えば万事解決みたいなものはないだろう。プログラミング言語に向き不向きがあるようにプロファイラにも向き不向きがあるはずだ。プロファイラの使用や設計には広いCS領域についてある程度の深さの知見が必要だろう。結構楽しめるはずだ。絶対楽しいだろうしやりがいもありそう。手始めにPython, Java, C++あたりのプロファイラやプロファイリングテクニックを学ぶのが良いだろうか。

2022-12-30

昔聴いていた音楽を久しぶりに聞きたくなったのだがSpotifyで配信されていなかった。ローカルにデータがあったのでそこからSpotifyかVLCとかで使えるようにしようと思ったのだが、ローカルデータのファイルフォーマットが変だったりディレクトリ構成がイマイチで体験が良くない。

そこでメタデータをもとにフォルダに振り分けたりフォーマットをmp3に変換するスクリプトを書いた。量があったので並列化したところ割といい感じになった。

せっかくなのであとで使いやすいようにCLIを調整した。コードをGitHubにアップロードしてある。できることや使い方はreadmeを参照すること。

ffmpegはすごいし、Pythonもすごい。

型ヒントに関する記事で欲しい要点がまとまった記事と出会ったので共有。 Enumはしらなかった。これまではLiteralとUnionでしのいでいたのでありがたい。

最近Pythonを好きになりつつある。4月からキャディで使っていた下地と、最近学んだ人権のための機能のおかげ。

別に職を探しているわけではなく、気になった人のプロフィールを見たかったので。スキルをテストして、パスするとバッジとして自慢できる機能がある。 OOPで試したらパスした。やったね！クラスベースのOOPLに関する知識を見ている感じだった。

世の中にはいろんな機能があるのだなあという感想。自己申告でスキルを履歴書とかに書くよりも客観的な感じがして良いかもしれない。

公開したいと思ってきたのだけど、スパムが嫌でずっと避けてきた。 Base64でエンコードして公開するアイデアを思いついたので試しにやってみる。このブログの自己紹介ページに載せてみた。この方法の問題点は面倒なことと、なれてない人には難しい点だろう。

それなりに頑張らないと収集できないだろうからスパムが来てもどんなところがそんなに頑張ったかを知れて楽しいだろう。

風の噂でこの方法は対策してあるソフトが存在すると聞いた。それではつまらないのでもう少し凝ったことをしてみた (該当コミット)。

Base64でhtmlにアドレスを書いておいて、JSで一定時間後にhtmlに書き込むアイデア。伝えたい人にとって楽になるのが何より良いし、クローラのタイムアウトにある程度期待できるのも良い。無限に対策と不安点は出てきそうなのでこのくらいにしておこう。

実現のためにHugoのショートコード機能を使った。もっと楽しい使いみちがあるようなので気が向いたら導入する。

2023年にやりたいこと

来年の抱負じゃないけど、一息ついたタイミングでやりたいことを整理しておくとどこかのタイミングで役に立つかもしれない。

今年は人生で一番プログラミングした気がする。 3月の末にmerpayで短期のインターンに参加したのを皮切りに、 4月にキャディでのアルバイトをはじめるなど、プログラミングをする機会が増えた一年だった。研究でもインタプリタをゴリゴリ書いてみるなどした。最近は講義で簡単な定理証明支援系の実装に挑戦している。変わり種としては、IBMの方々が講師として開催されているJVM関連のコンパイラ/VMの講義にも参加している。

型システムつきの言語ばかり触っていては視野が狭くなってつまらないだろうと思って意識的にPythonやJS/TS、Racketを使ってみるようにしていた。ライブラリをつなぎ合わせるくらいなら不便がなくてよいのだが、ある程度込み入ってきて、一つのデータ構造を複数のコンポーネントから使うようになると型システムが欲しくなる。クラスや契約である程度カバーできる面はあるが、型システムにまもってもらう安心感は得られない。抽象化をしきれないというか、しても心のどこかで実装を意識しながらデバッグしたりすることになるし、そもそも抽象化を書きにくかったりする。

なんにしてもプログラムをゴリゴリ書く能力はついたと思う。今年はとにかく動くものを作る系のコーディング技術を身につけた一年だった。年の最後にPythonで言語処理系を実装するとき、クラスを使わずdictとlistだけでどこまでいけるかやってみたのだが、型システム（依存型を含むので、いわゆるeval的な処理も必要）の実装で力尽きた。その経験からやはり型は必要だと思い直したのであった。 dataclassを使って一日かけて書き直したらまともに実装できたので感動している。もはやC++とかで書いた方がいい気がするが。

3月くらいまではあまり実装をする人ではなかった。実装に手を出し始めたのは最近の話。プログラミング言語の理論（型システムとか抽象機械とか意味論とか）ばかり見ていて論文やドキュメントを読むのが何より楽しいと思う人だった。論文を書く中で言語の使い手の気持ちがあまりわからなくなったり、論文を読んでいても、プログラマの幸せにつながる未来を想像できない研究をみたりした。

プログラミング言語や処理系はプログラムや表現したい対象があって初めて良し悪しが見えてくるものだと思う。そういうプログラミング言語の研究の動機の部分をもっと知りたくて実装に手を出してみた。結果は上々で、今の僕は去年よりもプログラミング言語やプログラミングのことが好きな自信があるし、そういう話をして楽しい人間に近づけたと思う。丸くなってしまいはしたかもしれないが。

インフラっぽいことを型システムやコンパイラの表現力/処理でまっとうに行いやすいようなしくみを考えて、実現に向けた方針くらいを打ち立てたい。インフラの勉強とRust, Scala, Haskell（適切なものを一つ）の業務で自在に使えるくらいの知識が必要だろう。

DSLやconfigでインフラ/ミドルウェアを構成するのが最近流行っているようだが、そういうのを勉強するのはつらい。あまり長持ちする技術ではないだろうし、知識としての深みも出にくそうな印象をうける。ライブラリとして提供してもらって他の便利機能はプログラミング言語に移譲するのがよいだろう。適切な言語であれば、ライブラリ特有の問題を言語の機能で扱いやすくできるはずだ。僕がやりたいのは、そのやさしく扱いやすくする部分。

その他にも全然知らない世界（技術的）をみたいし、文化的な面でも知らないところに飛び込むつもりだ。今年はそういうことをしやすい一年だと思う。楽しい一年になりそうだ。

まずは修士の研究をやろう。

2022-12-28

就職先のイベントに参加してきた。想像以上にたくさんの方に認識していただいていた。僕が初めて認識した方や、ネットで認識していた方、面接などでお世話になった方から、たくさんお話をうかがえて楽しい時間だった。みなさん、ありがとうございました。

入社が楽しみ。入社するまでに学校でのやり残しを作らないように気合を入れて頑張ろう。

Python bug trackerに議論があった。

Py_DECREFは参照カウントのオペレータか。初めてPython VMのソースを垣間見たけどなかなか面白そう。

2022-12-21

最近ちいさな言語処理系(検証器)をPythonで実装している。学校の講義でそういう講義があって、好きに言語を選んでよいということだった。参加者の間で関数型言語がメジャーな感じではなかったのこともあり、怖いもの見たさでPythonを選んでみた。ちなみに今回の実装は性能を問題にしておらず、動くことが大切。

Pythonをつかうだけでも少しドキッとするのだが、 ASTとかにクラスを使わないとどうなるかを試している。クラスとかADTを使いたくなるときはすべて辞書かタプルでゴリ押す実装をしている。

意外となんとかなるけどしんどさはある。結局ADTを自分で書いているだけなので、型システムという友達を失っただけかもしれない。クラスを使うのと比べてどちらが楽かは疑問。流石にクラスが楽であって欲しい気はするけど、 expression problemに思いを馳せるとクラスよりADTの方が今回の処理系の実装に向いている気がする。

文字列処理をググりやすいのはPythonのよいところだと思う。そもそも文字列処理を僕がPython以外でほとんどやったことがないだけかもしれないが。

今のところ、型システムがなくて絶望したことはない。（ほしいとは常に思うが）

型システムがなくて絶望した。 Dataclassを使うことにした。抽象化の機構はやはり欲しいことがわかった😇。

git grep で検索して置換

git grepは便利なのだが、置換の機能がない。ぐぐるとsedと組み合わせて置換する方法がたくさんでてくる。スクリプトファイルに書き込んだのでメモしておく。

POSIX準拠の正規表現を使える。
第２引数（置換後の文字列）ではマッチグループを参照できる。（"\1にマッチした"のように書く）

#!/bin/bash

if [ $# -ne 2 ]; then
  echo "Arity mismatch. want: 2, actual: $#" 1>&2
  exit 1
fi

git grep -lE "$1" | xargs sed -i -E "s/$1/$2/g"

個人メモ：~/.local/binに置いてある。

2022-12-18

昨日は服を買いに行った。引っ越すときに薄々気がついてはいたのだけど、冬に着る上着が一枚も手元になくてこのままでは凍えて外出できなくなるところだった。

ずっと服を買いに行くことに抵抗があったのだが、最近薄れてきた。そもそも大学に入るまでは基本的に自分で服を買いに行くことがなかった。服は親が買ってきてくれたり、一緒にお店に行ってなんやかんや言いつつ選んでもらうもので自分で買いに行くという概念が未知ですこし怖かったのかもしれない。大学生になると一人で服を買いに行く機会がでてくる。量販店にいってよくわからないという感想をもって結局なにも買わずに帰ってくることがしばしばあった。お金の使い方がつかめていなかったことが原因だと思う。

お金に困っていると感じたわけではなくて、自然にお金を出し渋っていた。無条件にお金をあまり払わなくて済むことが正義だという価値観があった。なのでよさげに見える服があっても多少高いと避けてしまってなにも買えなくなっていたのだ。話がそれるけど、高い服がいい服に見えていたということはずれた価値観は金銭の感覚だけで審美眼みたいなところは世間とあっていたのかもしれない。

本やご飯、パソコンやネット環境とかにお金を割いて幸せになる経験を通じてお金の使いかたを学んだ気がする。昨日買った服はこれまでの感覚からすると高くて買わないようなものだったけど、ここ何年か冬が寒くて悩んでいたのがある程度解決できると思うと嬉しい。何より服自体を気に入っている。

服の話と見せかけたお金の使い方の話でした。 2年ごとかに見たら愚かな考えに見えたりするのだろうか。

ここ2、3年の間で価値観が変わってきた。もうしばらく変化は続きそうなので楽しみにしている。

お金を使う話を書いたので、お金を稼ぐ話も考えてみる。当分の間は僕がお金を求める動機は先程書いたような生活水準をあげることでありつづけるだろう。気持ちとしては水準をあげるというか、自由を増やすことが達成したいことで、リッチな暮らしをしたいわけではないが、もともとお金を使わないような制約を精神的にかけて暮らしていた気がするので、自由になることとリッチな暮らしをすることは同じ向きを向いているのだろう。

なんてリッチな暮らしへの移行は一過性であるように書いたけど、そうでもないかもしれない。基本的にお金は価値の代替で、価値をアウトソーシングして自由を求めているのだから僕のお金を使うモチベーションはリッチな暮らしと表裏一体なのだろう、とも思える。

動機は何であれお金を使うためには稼ぐ必要がある。必要な額がいくら位で、そのためにこう働けばいい、みたいな考え方では長続きしないだろう。生活をどんな風に送るかを考えて、それが金銭的に破綻しないことを検証するスタイルが良いだろう。

検証する系はタイピングしながらでは辛いので、ここではやらない。その代わりに僕の社会との関わりかたを考えることにする。

僕は技術的な/理屈っぽい話が好きで、なにかにうまい説明をつけられるととても嬉しい。技術っぽい話は説明をつけがちで良い理屈からは頑強な技術を産めて、そこからさらに理屈をつける対象が得られるので都合が良いのだろう。反対に抽象に抽象を重ねるのは苦手だしあまり楽しくない。

こういう営みを続けたいと思う。気合と体力と時間を持っていかれるので、これでお金をもらえると嬉しい。他に仕事をする余裕はおそらくないだろう。その中で楽しく作業をしたり生活を送るために追加でお金をかけることになる。まともな食事や健康が必要だし、気に入った服や道具を使いたい。友達と交流するのは楽しいし一緒に理屈をつけるのは一人でやるよりも楽しい。そのための環境を用意するコストは、僕や友達の社会的な価値が上がるほど高くなるだろう。同好な人が会社に集まっていて一緒にしゃべることでお金をもらえるなら、きっと環境をだれかが用意してくれていることだろう。

いろんな欲求があって、それをお金をはらって満たすのか、ひとにお金を払ってもらって満たせるような環境を手に入れるのか、そもそもお金では解決できないものなのか異なる。お金で解決できないことはたくさんあるだろう。そのあたりは頑張ったり人を頼りにするしかない。人を頼るにしても、そのためにはまず自分が頑張らないと引き受けてもらうところまでなかなか行けない。このあたりの頑張りかたをある程度ここ2、3年で学べたと思う。これから強く生きよう。

それ以外の部分をお金で殴って解決すると幸せな空間を作れるだろうと思う。使うのと稼ぐのは対立した概念でマイナスを補うようなプラスを作るイメージではなくて、上手にバランスをとると幸せになれるパラメータの一つなのだと思う。

あたりまえの結論しかでてこなかった。いまさら主張することでもない気もするけど、まっとうな考え方は大体そんなものだろうから良かったことにしよう。しばらく経ってから読み返すとまっとうに見えなくて、過去の自分の異常性を楽しめるかもしれない。

2022-12-10

公開範囲を限定する機能をこのブログにつけたい。技術的なメモを書くこともあればちょっとした考え事をメモをすることもある。大体のことはガンガン公開すればよいと思うのだけど、勤務中に出会った技術的なことでコンプライアンス的に公開できないものや、人を傷つけるかもしれない考え事もたまにある。そういうものは公開していないところに吐き出しているのだけど、メモは一箇所にまとめたい気持ちがあるのでこの体験は良くない。今日の考え事は今日の日記にまとめたい気持ちがある。

静的なサイトでは厳しいだろうか。 AWS Lambdaくらいなら使ってもいい気がすることにしたらいい感じに実現できるだろうか。でもこの機能を入れるとソースコードをprivateにしないと意味がないのが悲しい。

今日の考え事は今日の日記にまとめたい気持ちがあると言ったがトピックごとにまとめたほうが楽しいのでは？それ系ではScrapboxがタグ機能で関連付けと表示をしてくれるのでいい線いってる気はするのだけど、タグを打つのが面倒ですぐにやめてしまった。皆さんどうやってタグを打っているのだろうか。そもそも適切なタグを用意するのが難しいことだと思う。

話がそれたけど、文章の関連付けと公開の仕方が難しいという話でした。タグは四半期に一回くらいブログを振り返って、共通性を見出すことでひねり出すのが良さそう。ひねり出したあとにそれぞれの記事にタグを振れば良い。全体との共通性を記事を書くときに考えるのは無理な話だと思う。

少し前から腕立て伏せをやることにしている。昔は腕立て伏せをすると折れるんじゃないかと感じるほど筋肉がなかった（骨が一部弱いのもある）のだが、昨日今日くらいで余裕が出てきた。これからはフォームとか効かせる部位とかを意識するのが良いだろう。

始めたきっかけはコーディング中に首の筋を痛めたことだった。淡々とキーボード叩いてるときにびきっときた。キー入力以外に動いていなかったので静かに驚いた記憶がある。

腕立て伏せをしても体調は良くならなくて、ランニングの代わりにはならない。呼吸とか全身運動を体が求めているのだろうか。外の空気？明示的な空腹と食事？インプットの中断？目をディスプレイからそむけることかも。

運動しないときは大体パソコンと向き合っているせいでランニングが与える健康そうな要因が多い。

2022-12-07

Pythonによるデータ分析入門を眺めている。これまでpandasのDataFrameを使う機会があったのだけど、ググった知識でごまかしたり、dictとlistを駆使してなんとかしてきた。そろそろインデックスや配列指向を活用したい気持ちが抑えきれなくなったので本を買ってみた。

概念の理解は公式のAPIドキュメントではなくこういう本で仕入れるのがやはり楽に感じる。まだ自在というわけにはいかないが、違和感を感じることと探すあてを思いつくことくらいはできるようになったきがする。

オライリーの読み放題プラン気になるけど高いんだよな…。そういえばPDFの横ぐし検索はどういうソフトが良いのだろう。むかしMacを使っていた頃はspot light検索を使っていた。Linuxではなにが良いのだろうか。

年末調整とか転出届けみたいな書類作成が苦手。込み入った指示にたくさん従うのがつらいのだろう。よくわからなくてコピペでプログラムを動かさざるを得ないときと同じ感覚がある。

コピペはつらいので理解した上で記述できるようになりたい。ググってもよい記事が見当たらないのが辛い。本屋にいっても似たような本がたくさん目につく。どう学ぶのがよいのだろうか…。

EchoをPCにBluetoothペアリングしたら接続するときに「<PCの名前>に接続しました」と喋ってくれて楽しい。最初は「何事！」と思ったけど、落ち着いて反芻すると気分がいい。

2022-12-03

昨日は研究が進捗した。嬉しい。

この前カルディで安いベルギービールをまとめ買いした。甘めのビールでおいしい。家に安くて美味しいビールがあるのは精神的にとてもよいのでこれからも継続的に買いたい。Engelchenという名前。

2022-11-28

AmazonでEchoが安かったので買ってしまった。特に使いみちは考えていなかったのだけど、プログラミングの新しいエントリポイントとして楽しい。

とりあえずハローワールドはできた。設定したフレーズでechoに話しかけると、設定したとおりに会話できる。プログラムが会話を通じて対話的に進行するのが新鮮だ。なかなか便利そう。定型的な記録をとるのには使えるだろう。

プログラムを書くときには発話自体を処理せずに、それをライブラリが処理した結果得られるインテントで実行を分岐させる。ビルトインのものもあるし、開発者が文字列でしていすることもできる。文字列で指定した場合、その聞き取り方？を学習してくれるみたいだ。

ついでにLambdaにも入門してしまった。Functionsの方が使い勝手が良い？ pythonの依存ライブラリをrequirements.txtで指定できないのが悲しい。

2022-11-27

タイトルを見たときには、アーキテクチャ的な話が中心なのかと思っていたけど、蓋を開けると、それを構成するための技術を基礎から説明してくれた。たとえばデータベースの種類（関係、ドキュメント、グラフ）とその実例や特性、インデックスのデータ構造の説明、比較など。データベースだけの本でもないけど、そのへんはまだ読んでいないので触れない。

そういう話が終わると、分散システムを考えだす。こういう話の持っていきかたは読者として嬉しいし、文書を書くときに見習いたい。

D2はテキストから図を生成するツールで、マーメイドとかが競合になるようなイメージだろう。企業がオープンソースで開発している。設計思想が良さげ。まだやりたいことをあまりやりきれていないようなので、開発を追いかけたいし、実際に使ってみたい。修論で使えるかな。

読書メモ: Go言語による並行処理

ちゃんと読もうと思ったときのための自分向けのメモ。

プログラミング技法を学びたいなら3,4章
Golangの復習をしたいなら3章
Golangのランタイムを覗きたいなら6章を読むと良さそう。

ざっと見た感じ、だいぶ信用して良さそうに思える。積極的に読んでいこう。

2022-11-25

ディスプレイの配置を変えたら首が楽になった気がする。今まではモニターアームを使って机の天板ギリギリの高さに設置していた。もっと低く、遠くに置きたかったのだが机に設置するモニターアームでは限界だった。

机の奥に椅子をおき、その上にモニターを置くようにした。モニタースタンドが優秀で、良い高さと傾きを実現できている。目線の高さには奥の窓やカーテンがある配置で、モニタは完全に目線の下になった。

昨日初めてオリジン弁当に行った。回鍋肉を買って食べたらおいしくて、今日は自作してみた。オリジン弁当のレシピはわからないし、どんな味だったかも割と忘れてしまったが、参考にしながら作った回鍋肉はおいしかった。作り方をメモしておく。

材料：

豚バラ肉
キャベツ
たまねぎ
味噌
みりん
醤油
めんつゆ
油

味噌をみりんと水でとかしておく。
キャベツ、たまねぎ、肉の順にフライパンにいれて炒める
適切なタイミングで味噌を溶かしたやつをフライパンに入れる
- ここで入る水分で火を通すので、炒めるのは雑でok
おいしそうになったら完成

醤油とかは気分で入れる。

今日はみりんをたくさん入れたので甘めになった。コツは肉に火を入れすぎないことと、キャベツに玉ねぎよりも火をいれることだろうか。しっかり火が入ったキャベツは美味しい気がする。

おいしかったけど回鍋肉っぽい味ではないと思う。

今まで写真をまじめに保存/整理/運用してこなかった。たまに過去の写真が欲しくなるので、良い運用を考える。

手間をかけない
- 手間がかかる方法では続かないので
- たとえばスマホでとった写真やPCの特定ディレクトリの写真がすべて自動で保存されると良い
頑強
- データを失いにくい
- ストレージの物理的な故障やクラウドサービスの停止/制限が怖い
アクセスしやすい
- 検索しやすいと良い
- 日付
- 位置情報
- 拡張子
- ソースになったデバイス
- 顔認識
- タグ付け

クラウドはamazon photoが良さげだけど、そもそもクラウドはサービス内容の変化が怖いのであんまりかも。

NASをたてて、Syncthingで同期とか？検索はスクリプトを書けばある程度できる？写真なのである程度GUIが欲しい？gThumbがGUIとしては良さそう。タグもつけられるらしい。

当面はこんな運用が便利だろうか：

syncthingでファイルを同期
- スマホ –> デスクトップPC
- スマホからはlineの写真とカメラの保存領域をソースに指定
- デスクトップPCの写真ディレクトリに送信
外部からもらった写真はすべてデスクトップPCの写真ディレクトリに展開
amazon photoでディレクトリをバックアップ

Hugoでページネーションを無効化

このコミットでトップページのページネーションを無効化した。やったことは以下の通り。

.Pagenatorを使わないようにする
対象のポストを全件表示するようにする
ページネータを消す

最初の一つがpage/2/みたいなページ生成を抑止して、次の２つがトップページの見た目を変える。ページネータを消せば自然に.Pagenatorを使わないようになるはずだ。

Hugoは.Pagenatorの使用をみつけると、page/2/みたいなページを生成する

2022-11-24

トップページでのページネーションは利益がだれにもないと判断して削除した。

検索機能がこのブログにはないので一覧表示するページがあるとテキスト検索である程度探せて便利
読み込み速度は問題にならなさそう
- トップページに画像がのることはない。
- 記事リストは静的にトップページに埋め込まれるので、ページングしてもhtmlのテキストの量がすこし減るだけ。

これからはすべての日記と普通の投稿がトップページにすべて掲載される。

設定が少し面倒だったので記事にしておく。

最近短めにしか走っていなかったのだが、今日は13kmくらい走った。心身が回復した感じがする。生活リズムもこの調子で改善したい。

2022-11-23

日記を書き始めるためのシェルスクリプトを書いた。今まではタイトルの指定が面倒だったので、日付をタイトルとして設定するようにした。

フロントマターつきのファイル作成後にエディタを勝手に起動するようにしたのも大切。 Hugoに--editorオプションがあって、newしたファイルを開いてくれるとのことなのだが環境変数の読み込みの問題を解決する必要があって諦めていた。今は愚直にスクリプトを使っているのでとくに問題はないはず。

ところで日記ファイルのディレクトリ構成はどうするのが便利なんだろう。今回はdaily/以下に2022-11-23.mdみたいなファイルを保存している。daily/2022/11/23.mdみたいにするのもありだろう。年月ごとに分けるのは自然ではないと感じたので今回はすべてまとめた。

デフォルトではcontent/postsにある記事しかトップページに表示されなかった。今回の変更でcontent/daily以下に記事を置くようにしたので、このままでは日記がトップページに表示されない。テーマで定義されているトップページのテンプレを見ると、HugoのmainSections変数を設定すれば良いことがわかった。常にこの変数を編集すればよいわけではなくて、使っているテーマがこの変数を使っていい感じにトップページを定義している必要がある。とはいえ公式で推奨されている方法なので多くのテーマがこの方法で制御できるだろう。

Goのテンプレートを勉強したい気持ちがでてきた。

今から久しぶりに多摩川に走りに行ってくる。最近体調悪いので直したい。

Church Encoded List in JS

Charch encodingで書いたリストの動くものがほしかったので書き下した。isnilを実現するためにコンスをisnil、car、cdrからなるペアとして表現した。

// cons list in Church encoding

const tr = t => f => t;
const fl = t => f => f;
const ite = c => t => f => c(t)(f);

const pair = f => s => pi => pi(f)(s);
const fst = p => p(f=>s=>f);
const snd = p => p(f=>s=>s);

const nil = pair(tr)(0);
const cons = x => xs => pair(fl)(pair(x)(xs));
const car = l => fst(snd(l));
const cdr = l => snd(snd(l));
const isnil = l => fst(l);

const fix = f => (x => f(y => x(x)(y)))((x => f(y => x(x)(y))));

const foldr = fix(folD => f => init => l => (ite (isnil(l)) (() => init) (() => f(car(l))(folD(f)(b)(cdr(l)))) ) ());

const len = l => foldr(elm => b => 1+b)(0)(l);
const len2 = fix(leN => l => (ite(isnil(l))( () => 0)( () => 1 + leN(cdr(l)) ))() );

const lst = cons(1)(cons(2)(nil));
len(lst); // -> 2

Mozc のデフォルトエンジンを設定する方法 2022 Oct

設定ファイルを書き換えるとmozcのデフォルトを日本語入力にできる。 Ubuntu22.10でしか試していないことに注意。

$ cat ~/.config/mozc/ibus_config.textproto
engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "default"
}
active_on_launch: True

Distributor ID:	Ubuntu
Description:	Ubuntu 22.10
Release:	22.10
Codename:	kinetic

Ubuntuで日本語をmozc、ローマ字を元から入っているUSのなにかで入力している。このやり方のありがちな課題として、mozcのデフォルトが直接入力になっていることがある。安直に対処するなら、ubuntuにログインするたびGUIでmozcの切り替えを行えばよいが、毎回操作するのは面倒だ。デフォルトで日本語モードにすれば良くて、その実現方法を冒頭に載せた。

今年追加されたデフォルトエンジンを指定するオプションを用いて日本語入力をデフォルトにしている。環境によっては設定ファイルを置くべきディレクトリが違うとか、既存の設定とマージする必要があるみたいなことはあるかもしれない。

この件のIssue
- 多くの人が困っていたみたいだ。
設定ファイルの説明

aptのドキュメント整理

雰囲気でaptを使っていて、リポジトリ周りの扱いに困ることがある。この手のツールは一生使うだろうから勉強して損はないだろう。この記事には読んだドキュメントと一言コメントを残しておく。

apt(man)
- 意図的に情報を絞っているとのこと。数分で読み切れる。
- ざっくりと概念をつかめた気がする。
- 次の課題はリポジトリ
sources.list(man)
- リポジトリのリスト。aptが参照/手入れする。こういう名前のファイルがあるし、似たようなディレクトリもある。それらの総称としてsources.listと呼んでいる節がありそう。
- くじらにっき++がやさしい

これでざっくりわかった。次にセキュリティのことを調べる。というのも、aptが失敗するのはセキュリティ周りの設定がうまくいっていないことが原因なことが多く感じるから。

apt-secure(man)
- ここで、apt-keyで鍵を登録すると書かれているが、この方法は非推奨になっている（apt-key）。
  - gihyoに解説記事がある
  - 代替ツールはなくて、manでは直接ディレクトリに鍵ファイルを放り込むことが推奨されている。

トラブルが起こったらこのあたりをいじればよさそうだ。 apt経由でインストールする際のおまじないの意味もわかるようになった。確かSlackをaptでインストールした際にリポジトリや鍵を追加したはずなのだが、当時はよくわかっていなかった。

エフェクトハンドラと依存性注入の関係について調べる（文献調査）

僕はエフェクトハンドラについてそれなりに理解していると思う。一方で依存性注入についてはふわっとしか知らない。

そんな状態ではあるけれど、エフェクトハンドラは関数型プログラミングで依存性注入するための素直な表現に使えるのではないかと感じている。

このポストではネットやアカデミアでどんな議論がありそうかをざっと眺める。それらの議論の細かいところとか、考察とかは明日以降の意識がはっきりしているときに扱う。

同じことを思ったひとはいるようで、検索すると2017年のブログ記事がヒットした。Hacker Newsのスレで chowells と kybernetikos が同様の議論をしている。これは2019年のこと。

Jonathan Brachthauser と Daan Leijenの論文。

エフェクトハンドラの使い方を調べるなら、モナドの使い方を調べるほうが早い気はする。そう思って調べると良さげなQiitaの記事をみつけた。

まだ列挙したドキュメントをあまり読めていないので、当初知りたかった関係についてはまだよくわかっていない。でも何かしら関係あることは間違いなさそうだし、僕の直感もそんなに的外れではなさそうに思える。明日起きたら読む。

Linuxコマンドがわからない学部生について

学部生や教育を非難したり愚痴を言ったりするつもりはない。

情報系の学部2年生向けのプログラミングの講義でTAをやっている。 Linuxコマンド（ cd とか ls 、 git など）を知らないとか、ディレクトリやパスなどの周辺の概念を知らない学生が少なくないように感じる。

講義で教える類のものではないのだろうけど、学生は真面目に講義を受けていればマスターできると想像して自律的に学ばないから僕が観測したような状況が生まれたのかなと想像する。というか、昔の僕がそうだった。

ああいう概念を身につけるためにはターミナルをたくさん使うのが推奨されがちな気がするが、卵・ニワトリ論争というか、エアーマンが倒せない理論と同じことが起きる気がする。なので個人的には適切な入門書を読むことを勧めたい。今回のLiniuxコマンドや周辺の概念は新しいLinuxの教科書に多くを学んだ。学部生たちにもこれを勧めてしまって大丈夫だろうか。

格安の引越し業者が良かった

今日引越しをした。 1年半くらい住んだ家から学校の近くへ引越した。動機は学校がオフラインになったから。告知から実行までが短くて困った。 2週間後から週4で対面参加せよと言われて強引だなあという気持ち。なんにせよ、この状況では学校の近くに住むのが有利なので引っ越すことにしたのだ。新居はそれなりにいい感じで、部屋も十分広いし町もよいところに感じた。不満は坂があることと、水回りの設備に伸びしろがあること。

新居の話はこれくらいにして、本題の引越し業者の話をしよう。大学入学から数えて、今回の引越しは3回目か4回目なのだが業者を手配したのは初めてだった。これまではヤマト運輸の単身パックや家財配送便？などを利用しつつ、気合や周囲の優しさで引越しをこなしてきた。たとえば洗濯機だけは業者に任せて、あとのものはリュックに入れたり現地で買うなど。他にはトラックを借りて荷物を運んだりもした。

今回業者にお願いしたのは単にコストパフォーマンスが良さそうなことに気がついたから。支払った金額は22,120円なので、軽トラを借りて友達にバイト代を払うとトントンになりそうだ。業者にお願いすれば僕は疲れない上に時間も短く済む。そして結果論ではあるが業者の方は丁寧な作業をしてくれた。ほんとにあの額で良かったのだろうかという気がしてくる。あの人たちはどれだけの報酬をもらえているのだろうか。まとめると、金銭的には同等のコストがかかり、時間的には業者に依頼するのが有利、得られる結果も依頼するほうが良さげ。依頼するしかないだろう。

特に安く抑えられたことが効いている。時期と依頼先が良かったのだろう。今回はよい行動ができたと思う。勝因は勢いとコミュニケーションだと思う。引越しのような行動は勢いがあれば8割くらい（10割がどんなか知らないが）のクオリティを達成できる気がする。ある程度の予備調査は必要だけど、勢いを殺さない範囲の調査で十分なはず。プラス2割を得ようとすると話が込み入ってくる印象だ。今回行った調査は以下の要領で行った：

SEO対策が効いてる系の記事で引越し業者選びの雰囲気を掴む
相見積もりサイトで業者の候補を得る（５社程度）
業者に直接問い合わせる（２社）

もっとよい選択はあったと思うのだけれど、話が込み入りそうだったのでこれくらいで打ち切った。これが8割の行動だと思っている。お金の使い方や事務処理を学んだ気がする。学びを活かしていこう。

Wishlist

欲しい / つくりたいソフトウェアのリスト。随時更新していく。

マークダウンフォーマッタ
- 全角文字にうまく対応したり、Madokoのシンタックスを理解したりしてほしい。

Syncthingがよさげ

オープンソースのソフトウェアでSyncthing というものを知った。 LAN内のデバイスとはLAN内で、インターネットの先にいるデバイスとはインターネット越しにファイルを同期できるソフトウェアだ。予めクライアントをインストールして、ディレクトリごとに共有設定をしておくと、設定に応じてよしなにファイルを同期してくれる。

USBのような手軽さはないが、クラウドストレージ越しにファイルのやりとりをするよりは便利そうだ。 UbuntuとAndroidにクライアントを入れてつかってみているのだけど、今の所いいかんじ。学校のネットワークではP2P通信を禁止している。おそらくSyncthingも引っかかるので、学校のネットワークでは動作しないように設定しておく。

設定は公式に従ってもよいし、このブログポストも参考になる。詳しいことはArchWikiが頼りになりそう。

落し蓋

ひじきの煮物をつくったのだけど、あまり上手にできなかった。その原因をさぐりたい。

まず、ひじきの量に対して他の具材を入れすぎた。ひじきが主役っぽくなくなってしまった感じ。次に味が結構こくなってしまった。これは煮物という感覚を持たなかったことが敗因だろう。水を入れずに醤油、みりん、めんつゆだけでなんとかしようとして濃くなったの思う。途中で水を追加したけど、味は変わるわけではなく…。とはいえ、食感はおいしかった。

落し蓋をしなかったことも影響しているのだろうか。落し蓋の効果はいろいろあるようだけど、水分の蒸発を防いだり煮汁の対流を促進して味を均等にする効果があるらしい。

ひじきの煮物が苦手というより、煮物を作るための基礎的な知識が不足している気がしてきた。煮物は漸進的に調理するのが難しい気がする。スープなら具材の火の通りやすさを加味して順序を決めれば、あとは味見をしつつ味付けすることでおいしくなる。カレーとか味噌汁とかはこのあたりだと思う。肉やさかなを焼くときは、下処理と焼く面に気を使えば大体満足できるものが作れる印象がある。火が通ってなかったらそこだけ焼き直せばいいし。サラダはいわずもがなだし。これらに対して煮物は水分のコントロールが難しい。具材、調味料の水分をうまく扱わないといけないので。なんというか、すべての材料のバランスを調理前に決定しておかないといけないイメージがある。

料理のさしすせそも煮物に関するtipsなのか？

「桜井政博のゲーム作るには」がおもしろい

桜井政博のゲーム作るにはというYouTubeチャンネルが面白い。ゲームの仕組みに関する知識を説明してくれる。動画のクオリティがすごいし、何より内容が面白い。

桜井さんが語っているyoutubeラジオ?があった。明日聞いてみよう。ものをつくるときに気をつけていること／ゲームクリエイター桜井政博さん第１回「ユーザーの身になる」を初回として、第４回まであるようだ。一回20minちょっとくらい。

Daily Note: 腕時計の電池交換

コロナが流行ってから外出する機会が減りそれにともない腕時計をつけることも減った。今度腕時計が必要な用事があるのだけど、電池が切れていたので交換してもらってきた。 1320円かかって、15分ほどで対応してもらえた。電池を買うと500-600円くらいかかるだろうし、工具代はもっとするだろう。作業としては簡単な気がするが、この値段でやってもらえるのはありがたい話だ。この時計の電池交換を何回することになるかはわからないが、それ以外に使いみちのない工具をさがしたり、管理する手間を考えれば安いものである。良い価格設定をしてくれている感じがして、あの時計屋さんを好きになってしまったかもしれない。

Ubuntu22でスクリーンショットの保存先を変える方法

Ubuntu22でデフォルトのスクリーンショットアプリはおしゃれな見た目をしていてかっこいいのだが、保存先を変える設定が見当たらなくて困っていた。デフォルトでは ~/Picture/スクリーンショット/ に保存されるのだが、~/Desktop/ に保存されてほしいのだ。

StackExchangeに回答があった。回答によると、やはり残念ながらユーザによる設定はできないようで、シンボリックリンクを張る手法が提案されていた。僕もそれに倣ったら具合が良いのでリンクをメモしておく。

別の解決方法として、gnome-schreenshot をインストールして使う方法もあるようだ。しっかり読んでいないのだが、やることが多くて面倒にみえる。

Todo Appを作っている話

この記事は書きかけです。

Todoアプリを作っている。就活の際に Webアプリの開発経験に関する話をするときの題材が欲しかったから。

GitHub: https://github.com/naoyafurudono/todo-app

Todoアプリを選んだのは、この手の目的でよく作られているイメージがあるから。FizzBazzみたいな？見た目だけ整えてもつまらないだろうし、コマンドラインだけで完結するようなものならSQLで良い。作るからにはなにか自分にとって得るものやソフトウェアとして売りになる点が欲しい。

細かいことはreadmeにしっかり書いている。しっかり書いたことも頑張りの一つ。ソフトウェア設計のためのツールを勉強できた。この記事では技術を選んだ理由や学んだことを書く。

フロントはTypeScriptとReactを用いた。

JSではなくTSを使ったのは、僕が常々型がほしいと思っていて、仕事でも型を大事にしたプログラミングをしたいから。 TypeScriptはほとんど初めて書いた。型システム（といってよいのだろうか）にはクセがあるが、型システムがいてくれてよかったと思う機会が何度かあった。これが静的型付言語を用いたプログラミング体験で最良だとは思わないけど、なかなか良かった。

良かった:

型としての文字列リテラル
ユニオン型
JSONとの連携

enumというか、代数的データ型っぽくオブジェクトを使える。網羅性検査やコード補完もしっかり効いて快適だった。これはTSの特権だと思うのだが、JSONとの親和性がすごく良かった。

良くない:

関数の型を書きにくい
ライブラリ関数の型が調べにくい、使いにくい
型推論の結果が欲しい型になかなかならない
any

これらの辛さの原因は、僕の文化への慣れと、構造的部分型と型エイリアスを多用する方針のどちらかだろう。関数の型が書きにくいのは慣れの問題だろう。Haskell基準で語っているので理想が高いのかもしれない。型が調べにくいのは、なれとJS向けドキュメントによる検索汚染が原因か。 Reactみたいなライブラリの型を調べる際にはどこをみるべきなんだろうか。

型推論は型システムの方針の問題だろう。たとえばオブジェクトを返す関数を書いたとき、気持ちとしてはすでに定義してある型エイリアスを提案してほしいのだが、実際にはレコード型みたいな形の型が推論結果としてフィードバックされる。主要な型は確かにそのレコード型みたいな型だろうからその挙動は理解できるし、まっとうだと思いはする。トップレベルの関数定義では、型アノテーションを書いてから本体を定義するのがやはり良いのだろう。書きはじめのころ型アノテーションの書き方がわからなくて、VSCodeに書いてもらおうとしたときにこの不満が出たのだったと思う。

anyは本当に良くない。型をつけたプログラムをデバッグするときは、強く型がついた前提で考えるので、any周りで前提が崩れて状況の認識に失敗する。 anyを書かないように頑張ることが必要だ。デバッグの際にはanyの可能性を忘れず、JSの気持ちで考えるのが良いのだろうか？それでは嬉しさ半減な気がするのだが。。。

不満が多くなってしまったが、TypeScriptはそれなりに好きだと思う。

Reactの他にElmを使うとか、UIはしょぼくするとかの案があった。判断の理由はReactの話に乗ってくれる人が多そうな気がしたから。個人的に最近Reactのことを調べていて、しっかり書いてみたい気持ちもあった。

関数コンポーネントで書いたし、useEffectやuseReducerもしっかり使った（つもり）。比較対処をそんなに知っているわけではないので、感想は少なめ。useEffectとかuseReducerはよくできているなと思った。うまい。

今回は複数クライアントがTodoを共有するようにした。WebSocketでサーバを通してイベントの同期をとって、同期が取らたイベントだけを反映させている。これはCroquetというメタバース環境の実装方針のアイデアを拝借した。イベント同期のためのWebSocketクライアントの管理のためにuseEffectを使い、イベント処理のためにuseReducerを用いた。

Golangを用いた。ゴルーチンとチャンネルの使い方や、構造体型の設計がセールスポイントだろうか。特に凝ったことをしたわけではなく、「これくらいは書けます」とアピールできるだろうと見込んでいる。

~~力尽きたのであとは宿題。~~

2年越しの再開をする。

サーバは特に工夫をしなかったと思う。サーバをできる限り薄くして、アプリケーションのロジックやデータ構造の定義をフロントエンドに寄せることを意識した。サーバはデータ構造のパースをして壊れていないことを一応検証したり、イベントにタイムスタンプをつけてイベントに全順序をつけることを責務として持つようにした。 Websocketで全てのクライアントと接続して、pub/subみたいなことを実装したのも頑張りどころではあったのかな。

Python のfilter関数が良い

ドキュメントを読むのが早い。

こういうことができる。

$ cat map-none.py                                                                                                                          17:34
def f(x):
    if x < 0:
        return x

for i in filter(f, map(lambda a: a-10, range(100) ) ):
    print(i)

$ python3 map-none.py                                                                                                                      17:34
-10
-9
-8
-7
-6
-5
-4
-3
-2
-1

静的型つき言語では f が maybe を返すようにして、filter の代わりに mapMaybe のような関数を使うところだ。 Python のおしいところは、filter という名前でよぶところか。

def map_maybe(fn, lst):
  filter(fn, lst)

とすれば良い話ではあるが。

こういう機能は Python に限らないような気はする。動的で関数型に関心のある言語ならこういう仕組みにするのが None のような値の扱いとして自然だろう

TODO: 他の動的言語での扱いを調べる。

scheme
CL
JS
ruby
julia

Reactのしくみを学ぶ

この記事は僕の勉強メモです。資料へのポインタが主なコンテンツになるかと思います。更新は随時入るでしょうし、煩わしいので追記した旨も基本的には記しません。

Reactの再描画に関するしくみを学ぶ。再計算をするかしないかの判断や、計算結果をDOMに反映するタイミング、言語としてみたときの意味論などを理解したい。

いわゆる普通のプログラミング言語のような実行モデルではない。どのような理解を詳しい人はしているのだろうか。サーバサイドレンダリングとかはどのように関係するか。 Partial evaluationだと思える？とか。

日本語の記事で、このブログ記事の著者がまじめにReactを使うために学んでその知見を発信している。
上の記事からリンクしているが、Reactの開発者が（再）レンダリングについてまとめた記事を2020年の5月に公開している。コンセプトは、「ネットに散らばったまともな説明を一箇所にまとめて理解を得られるようにする」。体系的に説明されているし、ソースを示すリンクもたくさんはられている。良いHTMLって感じ。
上の記事で紹介されているように、Reactはアプリケーションの実行時にオブジェクトを管理するためのデータ構造として、Fiberを使っている。それについてまとめた記事の日本語訳がこちら。さらにそこからReact componentなどに関する公式ブログへのリンクがはられている。

学術論文は探したけど見つからなかった。最新の情報はFacebookの人が発信する情報（ReactConとか）や公式ブログでのアナウンスに頼ることになりそう。 GitHubのIsuueとかも最新か。

救急でのITシステムについて

全然詳しくないのだけれど、救急で受け入れ先の病院が見つからない問題は改善する見込みはあるのだろうか。きっと受け入れのプロトコルやデータの管理方法や、病院のキャパビリティに課題があるのだろう。プロトコルやデータ管理はITシステムをうまく構成して普及できればなんとかなるはずだ。そういうことを実現しようとする事業は既に存在するのだろうか。少なくとも今はまだ成功していないのだろう。どんなところが実現に対しての障壁になっているのだろうか。

このあたりのことを含めて医療に関する情報処理はもっとよくできるのではないだろうか。コロナでの病院の手続きとか。どういう企業が事業の実現に近いのだろう。

円周率とユークリッド空間

タイトルがこの記事の主なコンテンツなのだが、円周率はユークリッド空間に対して定まる量なのだろう、という推測と同じことを主張しているサイトの紹介をする。

その主張をしているのはこちらの裳華房のサイトだ。裳華房は大学の理系の教科書を扱う出版社。

空間で円が定義できるためには、空間に距離が入っていて欲しいだろうし直径と円周の比がすべての「円」に対して一意に定まる必要がある。

円の定義はなにか
- 距離があれば定義できるか？裳華房の主張いわく否なのだろう。
円周率がwell-definedであるために必要な空間の条件はなにか

裳華房のページで紹介されている『円の数学』の１章が詳しそう。

Quoraのポストで球面での「円周率」を議論している。ポストを見るのが早いが、一応解釈をメモ。

球面上では円周率（円周と直径の比）は定まらない。一意性が無いことを示す。

大円の長さが$L$の球面上で直径$L/2$の円を書く。この円は大円なので、導出される「円周率」は$2$である。

直径$L$の円は一点（中心の対蹠点）なので「円周率」は定まらないというか、$0$というかに」なる（一点の長さの定義に依存する）。これで証明は終了。

直径を大きくすると円周は$0$と$L$の間で振動する。したがって、「円周率」は$0$に収束することがわかる。

Local File Transfer

近距離でのファイル交換はあまり洗練されていない印象がある。 Apple製品間ではAirdropが使えるし、Windowsにも似たような機能があったはずだ。でも汎用的に（たとえばOSを気にせずに）使える機能は見かけない。そういうときにはGoogle DriveやDropBoxみたいなクラウドサービスを使うか、USBメモリを使うのが一般的だろう。 Slackとかメールに頼ることもある。

インターネットに頼るのは不便だし、USBメモリが刺さらないデバイスも多い。 Blootoothを基本の通信方式として、それが使えない場合にインターネットを経由するのはいかがだろうか。

通信技術は既存手法を組み合わせるだけで良いだろう。難しいことはないだろう。一方でアプリケーションのUIには工夫が必要なのではないだろうか。

どこにファイルを保存するか
OS間でのファイルの互換性
送信先の選択
受信の制御

これらの選択に一般的な回答は存在するだろうか？他のアプリに組み込む形がよいかもしれない。例えばローカルの会議で各自が自身のPCで文書や画像、図面などを編集するアプリがあったとして、参加者間でのデータ共有のために今考えているものを使う。このときUIはアプリの特性から決まるだろう。

この例に対して、スマホやPCのファイルシステムは一般的すぎて設定を決め打ちできないのではないだろうか。そうすると、ファイル共有の実行時にユーザが設定をあたえることになる。大変不便だろう。

設定ファイルの編集やディスパッチの機能をつければ楽になるか？ルールエンジンとかは大げさだろうか。

REPLと単体テスト

Pythonのことを考えていて、TDDの文脈での単体テストの意義にふと気がついた。つまり、失敗するテストを先に書いて、それを通るように実装をする、という方法論の意義に気がついた、ということだ。

PythonやHaskell、Lisp、ScalaのようなREPLがある言語で開発をするとき、僕はテストを先に書く理由が今まであまり腑に落ちていなかった。それはおそらく実装して、REPLでデータを渡せば動作確認できるからだ。

もちろんユニットテストを書いておいた方が再利用性とかを考えると良いだろうし、リファクタリングの助けになるのも分かる。ただ、コードを書き始める前にやるほどのこととは思えなくて、プログラムに対してユニットテストを書くことは、文章に対して推敲するような行為だと捉えていたのだ。コードがあっていそうなことはREPLで確認するのが手軽で、ユニットテストは重い作業というか。この重さは面倒なだけでなく、実際に開発速度を落としていたように感じる。

さらには何がほしいか明確ではない段階で単体テストを書いて、実装してみて、なんか違ったときにはたくさん変更する箇所があって、テストケースとプログラムの修正順序が逆転することもある（このプログラムは正しいので、怒っているテストを修正する、ということ）。

単体テスト as 推敲のパラダイムは割と悪くないと思っている。世間の皆さんはどう思っていて、実際的な方法はどんななんだろうか。

P.S. GoとかRustみたいな言語では単体テストは、もっとガンガン単体テストを書けば良いと思う。というのもこれらの言語にはREPLいから。単体テストを書けばmain関数に手を入れずに、比較的お手軽に小さい確認をできる。

ここまで書いて思ったのだけど、REPLで確認するレベルの動作確認をGoとかではテストで確認する必要はあるだろうか？（僕はないと思うことが多い）型検査やlinterにかけることが気持ちとしては同等の検査？言語が違えばプログラムの構造が質的に変わるので、細かい比較はあまり意味がないか。

結論は「REPL ~ 静的検査」の対応がなんとなくあって、単体テストはもう少し大きめな検査？あまりスッキリしない。この辺りの考えを胸に置いて、コーディングしていれば知見が得られるかもしれない。

UNIXでのパーミッション周りでの振る舞いを調べた

systemcallを初めて書いた。パーミッションの挙動を調べるのがモチベーション。以下を実行できてほしかったのだが、sudoにそんなファイルは無いと怒られてしまう。

gcc hello.c
chmod 000 hello.c
sudo a.out

a.out をexecvで読んだところ、そこでもエラーが起きた。errno をみるとパーミッションが無いと怒られたようだ（execvを呼ぶバイナリをsudoで実行した）。

rootとして実行できていないのか、execvが認識するプロセスのユーザidがeidではなく、uidなのか…。

次の実験をした。sudo は関係ないようだ。 sudo su でrootになったあとの様子を切り取っている。

# ls -l
合計 44
---------- 1 root     root     16520  7月  8 18:22 callee
-rw-rw-r-- 1 furudono furudono   103  7月  7 15:43 callee.cpp
-rwxr-xr-x 1 root     root     16136  7月  8 18:25 caller
-rw-rw-r-- 1 furudono furudono   240  7月  8 18:25 caller.c
# cat caller.c 
#include<errno.h>
#include<stdio.h>
#include<string.h>
#include<unistd.h>

int main()
{
  char ** args = {NULL};
  char * cmd = "./callee";
  errno = 0;
  int c = execv(cmd, args);  // my first system call
  fprintf(stderr, "%s\n", strerror(errno));
  return c;
}

# ./caller 
Permission denied
# chmod 100 callee
# ./caller
hello world
# chmod 010 callee
# ./caller
hello world
# chmod 001 callee
# ./caller
hello world

カーネルかファイルシステムの都合でこうしているのだろうか。上で登場した caller.c と callee.c は GitHub で公開している：

https://github.com/naoyafurudono/test-unix-permission

Systemd

systemdでxremapを追加して、システム起動時に勝手にxremapが走るようにした。

僕の環境:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04 LTS
Release:	22.04
Codename:	jammy

xremapの作者の方が公開している設定を参考にした。

https://github.com/k0kubun/xremap/blob/6e8e1f21285ecedfa7ac88d703ad80d25a2699dd/examples/systemd/xremap.service

依存先が僕の環境では存在しないと怒られたので、default.target を指定した。この設定ファイルを ~/.config/systemd/user において、systemctl --user enable xremap を呼びだす。すると次回のsystemdが起動するときに、xremap を呼んでくれるようになる。

[Unit]
Description=xremap

[Service]
KillMode=process
ExecStart=/home/furudono/.local/bin/xremap /home/furudono/.config/xremap/xremap.conf
ExecStop=/usr/bin/killall xremap
Restart=always
Environment=DISPLAY=:0.0

[Install]
WantedBy=default.target

快適になった。

Spotify at Commit

Spotifyの再生が一瞬途切れることがある。そしてそれがシェルコマンドを叩いたタイミングと重なる。どんなカラクリなんだろうか。ただの気のせい？さっきはコミットしたときに一瞬途切れた。

Shell Commands

パーミッションのことが気になって、シェルコマンドのソースコード（C言語）を読んでいるのだけど、読んでいて楽しい。rm から読み始めたのだが errorno やコマンド引数の扱い方、トラバース (ftsを使う) の書き方で学びが得られた。 Goのエラーハンドリングの強さが分かる。

なお、パーミッションはコマンドの実装とは分離されているみたいだ。ファイル削除は unlinkat システムコールが実現していて、その前後で権限取得みたいなことは行わない。

次に chmod を読んでからシステムコールとOSの話を見にいこう。

競技プログラミング

数ヶ月前からときどきAtCoder (my account) のコンテストに参加している。就活とか関数型ではない言語でのプログラミングを意識して始めた。今回のABCで灰色を脱して茶色になったので記念に記録しておく。

はじめは入出力がなによりも難しかったし、なんなら今も悩むのはそこな気がする。次に問題文の誤読が多い。これは恥ずかしいことなので特に気をつける。慣れもあるのかもしれないが。そしてC++で書いているのに関数型な頭で取り組んで苦戦するケースもある。 forではなくて、mapとかをゴリゴリ使いたくなるのだ。今日もmapを使おうと思って検索したのだけど全然検索でヒットしなかった。まあ、mapはC++で使うべきではないことは分かる。

イテレータを使うのが面倒ですこし困る。begin() と end() をいちいち書くのは嫌なものだ。Rustに移行すれば楽になるのかな。もう少し勉強してみるか。

おかげでC++には少しなれることができた。欲しい機能がないことがよくあるけど、ちょっと頭をひねればきれいに回避できることが多い。訓練だと思ってC++で続けるのはありかもしれない。 Rust欲はあるので移行はあり。

色の話をしておこう。今のパフォーマンスだと緑色の下か真ん中くらいなようだ (900-1100)。言語と環境により慣れれば多少上がるかもしれないが、大幅な違いは生じないだろう。なにより今のアルゴリズム力で人生を終えるのは寂しいので頑張りたい。脳の老化が始まるまで、そんなに時間は残ってないはず。

とりあえず朝活するかな。

Phantom Type

Phantom type (幽霊型) をチラッと学んだのでメモ。きっかけは Gentrification gone too far? affordable 2nd-class values for fun and (co-)effect を読んでいるときに出てきたこと。

静的な型を持つ言語で使うテクニックで登場する型（パラメータ）のことをphantom typeという。

-- このaがphantom type
data Com a = String

type First ()
type Second ()
type Third ()

init :: String -> Com First 
next :: Com First -> Com Second
final :: Com Second -> Com Third

init -> next -> finalの順で呼ぶことになる。それ以外の順番では型検査を通せない。線形型とかGADTとかと組み合わせるともっとリッチなことをできるだろう。セッションタイプを似たような概念として聞いたことがある。どのように関係があるのだろうか。

Jane Street のテックブログでphantom typeをYaron Minskyが紹介していた。 readonly/readwrite/immutableみたいなアクセス制御を実現する方法を例として紹介している。

コードブロックの表示

コードブロックの表示が気に入らない。設定をいじって白地にしたい。現状では黒地。というのは、ブログの背景が白だし、僕が普段白地になれているから。白地を養護する主張に影響を受けた。実際目が楽になったような気がする。

Golang の変数キャプチャ

Golangの変数キャプチャを勉強する。

追記: 最初、変数キャプチャではなくメモリモデルを勉強しようとしていた。勉強してみて、求めている概念では無いことに気がついたのでタイトルなどを修正した。メモリモデル自体は知れて良かった。非同期処理へのコンパイラ最適化が及ぼす影響を知れる（公式サイトにおせわになった）。変数キャプチャの説明はこれを読む。３年前に僕と同じことを思ったひとがいたようだ。

クロージャをforループ内で生成してデータ構造や高階関数に渡すような処理を書いた。そこで変数の扱い（メモリモデル）でエラーを出したことがことの始まり。解決策はシンプルなのだが、イマイチしっくりこないので勉強したくなった。クロージャの変数キャプチャは言語によりけりだし、特徴が現れるように思う。 Golangがどうなっているか知るのが楽しみ。

問題のコードはこんな感じ(The Go Playground)。

words := []string{"foo", "boo", "bang"}
arr := []func(){}

for i, elem := range words {
	arr = append(arr, func() {
		fmt.Printf("%d: %s\n", i, elem)
	})
}

for _, f := range arr {
	f()
}

結果は次の通り。

2: bang
2: bang
2: bang

期待していたのはこれ。

0: foo
1: boo
2: bang

こうすると期待通りの出力を得られる(The Go Playground)。

words := []string{"foo", "boo", "bang"}
arr := []func(){}

for i, elem := range words {
	i := i
	elem := elem
	arr = append(arr, func() {
		fmt.Printf("%d: %s\n", i, elem)
	})
}

for _, f := range arr {
	f()
}

どういう理屈で振る舞いが変わったのだろうか？一般的な理屈が知りたい。２つの要素がある。for文のスコープとクロージャの変数束縛だ。

言語仕様 (rangeつきfor文) によると、range 節を伴ったfor文では、宣言した変数が使い回されるらしい。

The iteration variables may be declared by the “range” clause using a form of short variable declaration (:=). In this case their types are set to the types of the respective iteration values and their scope is the block of the “for” statement; they are re-used in each iteration. If the iteration variables are declared outside the “for” statement, after execution their values will be those of the last iteration.

言語仕様 (関数リテラル) によると関数リテラル（クロージャ）は定義もとの変数を共有するとのこと。

Function literals are closures: they may refer to variables defined in a surrounding function. Those variables are then shared between the surrounding function and the function literal, and they survive as long as they are accessible.

最初の例では、forループで宣言された変数 i をすべての関数リテラルが共有した。最初のforループが終わったあとの変数 i の値は最後の繰り返しでの値になる。なのですべて 2: bang` と表示した。

２つ目の例では、forループの中で、毎回変数 i を宣言、定義した。for文が代入する変数iは、for文がイテレーションで定義したものではなく、はじめに定義したものなのでそれぞれのクロージャは影響を受けない（クロージャはfor文の各繰り返しのブロックと変数を共有するが、ブロックはすぐに終了してそれぞれのクロージャだけが変数にアクセスしうるようになる）。したがってそれぞれのクロージャは別々の値をプリントする。

すっきりした。嬉しい。

GolangのキャプチャはC++の参照キャプチャと思ってよさそうだろうか。クロージャの側は多分良いけど、変数の生存期間が違うので類推しないのが安全か。

言語の理解が進むとその言語をもっと好きになるみたいだ。

JavaScript The Good Partsを読んだ

読んだ。きっかけはTypeScriptの関数型言語好き向けの紹介ページで事前知識として要求されていたから。読んでよかったと思う。しっかりJSの知れたのではないかと（その判定はまだできないが）。とはいえまだまだ知るべきGood Partsはある気がする、というのもconstとかletが説明されていないので、情報が古いだろうと感じたから。プロトタイプの話が載っていたり、thisの動的な意味の変化のこととか、varのスコープとかを説得力をもって説明してくれたのはとてもありがたい。そういう点で読んでよかったと思う。DOMやevent handlerなど、ブラウザ周りの話を知りたい。

JSがSchemeに近い部分があることを知られて良かったと思う（Schemeのletがあればどんなに幸せだろうと思うけど）。 JSには偏見しかなかったけど、良い言語に思えてきた。TypeScriptも知りたい。DOMとevent handlerが先だが。 UIを扱うにはJSが強い？C# with Unityもあるのか？ TSよりも関心はDOMやevent handlerにある。

JSのletを勉強している。情報源はMDN。varが作るスコープがレキシカルスコープではないことは既に知っている。letはマシだが、SchemeとかOCamlで期待するような感じにはならない。MDN 一時的なデットゾーンで解説されている。 MDNでも触れられているが、letの右側（let x = <ここ>）が常にこのletが作るスコープに所属することになる。なので、常に束縛する変数と同じ名前はletの右側には出現できない（e.g., let x = x.fooは常にエラー）。その他に、同じブロックに同じ変数に対するletを複数回使えない。シャドーイングが不便。これらはすべて良くないとは思うが、そんなに大きな問題でも無い気はする。

letの仕様によって、JSでブロックを使う意味が生まれた？[^fn]switchでそれぞれのブランチのスコープを区切るためにブロックを使うテクニックが紹介されている。

[^fn]この疑問符は、他の用法はあったのだろうか、という意図。

趣味

心に残った作品を列挙しておく。順序に意図は無い。ちなみにこの記事はお酒によったときに書いたり追記したりしている。

91Days
パリピ孔明
true tears
天元突破グレンラガン
マクロスデルタ（見た時期の影響が大きいかも）
Banana Fish

マクロスデルタは大学受験のはじめのころ、モチベーションがない時期にみた。マクロスデルタのおかげで今の僕は自分のメンタルヘルスをある程度管理できるようになった。

民主主義みたいな事柄が気にかかっていた時期があった。

人間失格
それから
学問のすすめ
エヴァ（漫画、新劇場版の破以降）

心には残っていないが、スッキリさせてくれたのが文科省の「民主主義」。戦後に出版されたやつ。

これらをもとに民主主義とかパーソナリティに思いをはせたのは、社会学について講義や本で学んだ経験が影響しているだろう。もしかしたら仏教の縁とかキリスト教の愛みたいな考え方を聞いたことも影響しているかもしれない。人間性をだそう思うと、個人は責任ある（あるいは、アイデンティティのある、自我のある、人格のある）主体として振る舞う必要があって、その上で他者といい関係を築くことが今どきの社会での人のあるべきありかたである、みたいな考え方をもつようになった。

僕は昔から自我みたいなものが弱い気がしていて、そこに課題を感じつつ、一つの主体として他者と交流することに憧れたり、それに向けてもがいたりしている節がある。とはいえエヴァのゲンドウがいっていた（気がする）ように、人と人は分かりあえないみたいな考え方をぼくももっていて、だからこの努力は一生終わることが無いものなのだろう。完璧な理解みたいなものはなくて、腹に落ちた感覚があるだけだと思っている。

know
ファンタシスタドールイブ
うさぎと縁の本（タイトル忘れた）

アムリタからハマった。

ボカロやJPOPがすき。うたってみたもすき。とりあえず好きなアーティスト:

Ado
まふまふ
ろん
ハチ
dazbee
Vaundy
King Gnu

好きな曲:

まふまふの曲が何個か（タイトルは忘れた）
Snow Song Show（そらるとろん）
夢花火（まふまふ）
リストの巡礼の年のアルバムでSpotifyで最初に流れるパート
Vaundyの踊り子（MVが特に好き、かっこいい）
King Gnuのいろいろな曲

フィンダーおじさん (Vtuber)
- トークではなくて作品

心に残ったのはこれくらい？もっとありそうなものだけど。ハマったのは他にもあるが、あれは心地よかっただけなのかもしれない。本は作家で好きになることが多い。思想や文体が好きなのか？

野崎まど
村上春樹
西尾維新
森博嗣
夏目漱石は少し
アニメはきりがない。
映画やドラマはそんなに嗜まない。
音楽もそんなに。リストの巡礼の年の不安定なパート（ピアノのソロ）はすごいと感じたくらい。
- （追記）これは嘘。音楽は割と好き。書き加えておく。
絵もあまり。大蔵美術館（だったか？倉敷の西洋絵画がある）でみた受胎告知はよかった。
建築はかっこいいとかこの辺がイカしてる、とか思うくらい
証明やプログラムは、ここでの関心とずれている？（僕の中での解像度が違うのか、立場が違う？）
人間は？

これくらいにしておこう。漫画やゲームがぱっと出てこなかったのが驚きであり、また腑に落ちる感じもする。こういうことを内省するのも楽しい。きっかけは今日見たパリピ孔明がすごく良かったから。深夜テンションで書きました。

2023-03-19: Big Peat

Golangでのlog

Golangの標準ライブラリにlogがある。いろいろ関数が提供されているが、機能はざっくりいうと「引数で与えたメッセージにタイムスタンプをつけて標準エラー出力に流す」みたいな感じ。ログにレベルをつけようと思うとこれでは足りない。レベルというのは、DEBUGとかERRORみたいなやつ。書くログ関数にレベルを設定した上で、グローバル変数とかで現在のレベルを設定する。プログラムを実行すると、現在のレベルで有効なログ関数だけが発火する。

Golangでこれをやろうと思うと、サードパーティを使うか自分で定義することになる。自分で定義するのも意外と悪くない。実装のほとんどは標準のlogに委譲すれば済むし使い勝手は最高。設計に注意が必要なのと、面倒なのは間違い無いのでそれが難点か。 Golangのインターフェースのおかげで使い勝手を簡単によくできる。感謝。

投票所のシステム

選挙に行ってきた。そこで投票用紙を一枚差し出す機械を見て驚いた。あの機械が何をやっているのかは定かではないが、おそらく正確に１枚だけ投票用紙を有権者に渡すことが責務の一つなのだろう。そんな機械があるのはびっくり（皮肉を言いたいわけではない）。正確に一枚の投票用紙を渡すことは法律を遵守するために必要なことだし、機械を使わずに人の手で配る場合、複数枚渡すミスは確実に起きるだろう。なので、そこを徹底することは尤もだと思う。

では他に良い手はないだろうか。投票用紙をもらうためには、あらかじめ有権者に配布された案内票みたいなものを持っていく必要がある。それに投票用紙の機能をつけるのはどうだろうか、と思ったけど一意性の担保が難しそう。というのは、案内票は再発行できてほしいはず。たとえば郵送中に損なわれた場合や紛失した場合。再発行するには過去の案内票を間違いなくdropしないと一意性が担保されない。 dropのためにidを振るとかが考えられるが、無記名投票の原則に影響する。そういうわけで、案内票を投票用紙として使うのは難しそうだ。

ところで、最後の投票用紙を受け取るときに、案内票を回収された。これによって投票に行ったか否かがバレてしまうのが問題にならないかと思ったが、投票所を見張っていればバレることなのでいまさらか？

電子投票ではどんな性質をどのように担保しているのだろうか？やろうと思うとフィジカルな投票所は単に、バーチャルな投票所にアクセスできない人が集う場所になるだろう。委員会のひとはネットワークやパソコンなどのセットアップをする係になりそう。求められる能力が少し変わって、人を集めるのが大変そうだ。日本での実現には10年か20年くらいかかるだろうか。今の子供がそのあたりの教育を受けることを仮定したらの話だが。とはいえ、ipadとかでもできる気がするので、そんなに難しくない？安定性が一番の懸念か？インターネットアクセスも問題になる？とはいえそういう地域はいまでも問題になっていそうだし、電子的にしたほうが楽なイメージがある。

最後に、細かいことをたくさん書いたけど、僕はこのあたりの仕組みに興味があるのであって、現行の選挙システムのセキュリティに文句があるわけではないことを明記しておく。紙の投票用紙も好きだし。

Go Context

Golangで始めてcontextを使った。リポジトリは非公開なのであしからず。

Webスクレイピングツールを作っている。ランディングページを見て良さげなページへのリンクを集め、それらのリンクから欲しいコンテンツを収集する、というのがメインの動き。基本的には起動したら放置するのだが、ときどきいらないページをスキップしたくなる。このスキップ機能を追加するためにcontextを使った。

当初はcontext.WithCancelで良いかと思ったが、同じctxに複数回cancelを送信したいので良くない。結局context.WithValueで受信チャンネルをもたせた。あとはキー入力を受け付けるgoroutineを立てて、良い感じに対応する送信チャンネルからstruct{}{}を送れば良い。 (受信側はもちろんいる。もともとDOS攻撃を避けるために待つ箇所があったので、そこでtimer.Afterと並行して件のチャンネルを待つことにした。)

標準入出力をいろいろな部分から使っているので操作画面がとてもきたない。とはいえ自分で使う分にはストレスなく思ったとおりに動くので道具としては満足。

UbuntuでIpv6を無効化する

学内ネットにVPN接続してIEEEの論文を取得しようとしたが、学内からのアクセスだと認識されなかった。 IPv6を無効化するとうまくいった。

MacではGUIでIPv6をon/offできたが、UbuntuではCUIから設定した（参考ページ）。以下を実行する。

sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1

設定は永続的ではない。永続的でないことは sysctl の manページや Red Hatのドキュメントを参照すると分かる。

逆に有効化するためには、...=1 を ...=0 にすればよいはずだ。こちらは動作確認をしていないことに注意。

僕へ: ~/.local/bin/disable-ipv6.sh に上のスクリプトを書いた。パスが通っているので sudo をつけて実行せよ。

Ubuntu22.04でZoomの画面共有がうまくいかなかった件

追記: 先日画面共有しようとしたところ、うまく相手に表示されなかった。 Zoomから退出して、Ubuntuにログインし直し、ウィンドウシステムをWayalndからXに切り替えたところうまくいった。やはりXが安定なのか。

Ubuntu22.04で画面共有しようとすると、共有候補にホワイトボードしか表示されなかった。Zoomがknown issueとして公開していた。詳しくはリンク先を読めばよいが、waylandとの相性の問題とのこと。そのうち修正したいと書いてある。

対応策としては以下が紹介されていた。

Xorgを使う
ブラウザ版zoomを使う
OBSのようなソフトで仮想カメラにキャプチャ画面をつなげて、それをzoomで共有する

僕は面倒なので、常に全画面を共有するように設定した。これはzoomアプリの画面共有設定から行える。

NeoVimでクリップボードを使う

init.vimにset clipboard+=unnamedplusと追記する。

Nvim では（vi や vim も）ヤンクやペーストで、nvim が管理するバッファを記憶領域として用いる。なのでクリップボードとは分離されていて不便なことが多い。

バッファとクリップボードをつなげれば良くて、その設定は上のコマンドで完結するようだ。ネットの記事には裏でpbcopyやそれに類するものの設定が必要、みたいなことをいう記事があるが手元の環境では上の１行を追加するだけで良かった。

:version
NVIM v0.6.1
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by team+vim@tracker.debian.org

該当コミット：関係無い変更も同時にコミットしてる…。

複数の nvim プロセス間でクリップボードを共有できる（当然）のが地味に便利。（普通は複数プロセス立てない？）

Begin Rust

Rustを勉強している。やはりライフタイムとか借用のあたりで苦労している。所有権やライフタイムはわかるのだが、借用の仕組みがイマイチわからない。特に可変な借用が同時に複数あってはならない、という規則で、同時にとは一体？という気持ちになる。同時の概念を理解させてくれる文書に出会えていない。これが原因で詰まった話をする。一応問題の回避はできたが、腑に落ちきっていない。

練習がてら、状態遷移系の各ノードで、与えられたCTL-formulaが成り立つかを調べるラベリングアルゴリズムを実装した。

labeling関数内でループを回す。考慮するすべてのCTL-formulaについて、条件が合えば add_label 関数を呼んでノードにその論理式への参照を追加する。ノード（State）につけるラベルはlabels: HashMap<State, HashSet<&Formula>>としている。

はじめ、add_labelはlabelsの可変参照をとるようにしていたのだが、借用チェッカに怒られてしまった。つまりadd_label : (..., labels: &mut HashMap<...>) -> ()。add_labelsの呼び出しが複数回あって、それぞれに参照で貸し出したのがまずいようだ。直感では関数呼び出しが終わると参照を捨てるから安全だし、型システムもそう思ってくれる気がしていたのだが…。

add_labelに所有権を一旦渡して、変更した上で返却するようにしたら、怒られがなくなった。つまりadd_label : (..., labels: HashMap<...>) -> HashMap<...>とした。呼び出し元でlabelsに再代入することで所望の追加を実現できる。

これはこれできれいだと思うけど、はじめのアイデアも悪くない気がしてしまう。きっと修行が足りないのだろう。

Favicon

ファビコンをつけてみた。素材はJDENTICONで生成した。それをもとにfavicon用のファイルをFavicon.ico & App Icon Generatorで生成。

設定はコミットを見るのが確か。https://github.com/naoyafurudono/naoyafurudono.github.io/commit/8eb6ab8952ce55832f00b3aae0264d2b9c66f227

ブログの設定を変えた

このブログはGitHub Pagesで公開していて、Hugoを用いて生成している。 Hugoの設定をろくに調べずに雑に書いていたのだが、今回少しドキュメントを読んで設定をした。

トップページ（記事へのリンクが並ぶページ）に記事の全文が表示されていたのが改善した。
- asCJKLanguage = trueが効いていそう
テーマを変えた

最近Ubuntuを使い始めたり、講義でプログラミングする機会が増えたりした。得たTipsを積極的に記事にしよう。

NeoVimを使い始めた

Neo Vimが使っていて楽しい、という話。普段はVSCodeを使っていて、全然移行したわけでもないのだけれど、NVimは文字入力に対する反応が比較的早くて楽しい。ところで、いつも思うのだけど、日本語って打ちにくくないだろうか。IMEがいるのが良くない（これ以上の日本語入力方式はないだろうか？手書きよりは良いのだけれど）。

英語だとタイプミスしてもとりあえず近い単語を入力できて、大体スペルチェッカの修正機能で直せる。だからテキトーにキーを叩いてからあとはおまかせでok。入力ミスのダメージが小さい。それに対して日本語では、IMEが正しく認識できるように文字列を入力しないといけない。多少のまちがいはIMEは許容してくれることもあるけど英語の時ほどではなくて、大抵は一字一句正確に入力しないといけない。もしも間違って入力すると、IMEがうけっとた範囲の入力が全て誤って変換されるので（部分的にあっていても、正確に変換させるために全消しすることが多い）、ダメージが大きい。だから日本語入力は大変だ。

構文エディタ実装の考え

構文エディタとは、文字単位だけでなく抽象構文木単位での編集ができるエディタのこと。一般のコードでなく、プログラムを編集することは抽象構文木のノードやエッジの編集に対応する。ならば、そういう単位での編集をエディタが直接サポートすれば楽できるという発想（だと想像する）。

アイデアとしてはそれらしい気がする。でも流行ってるようには見えない。なんでか？

需要が少ない: プログラムを新しく書くことは構文エディタの対象外であり、プログラムがあってそれに対する選択が主な操作である。なので構文じゃない編集機能はやはり必要で、そう考えるとそんなに欲しくない。とか？
使い勝手が悪い: 使ったことがないし、具体的な機能を知らないので想像でしかないけど、おそらく思ったようにASTのノードを選択できないのではないか？そもそも選択したい「ASTのノード」が実は存在しないケースがある。(e1;e2;e3)のうち、e1;e2とe2;e3のどちらかは存在しないはず。この辺りの問題は工夫すれば解決できそう。既存の実装はどのくらい工夫しているのだろうか。
普通のエディタで十分: 前の/次のセミコロンまでジャンプとか、かっこまでジャンプとかがあれば済むケースは多い。
実装が大変: 使い勝手を考えるとシンタックスハイライトとかよりは大変そう。抽象構文木をアレンジした概念が必要になりそう。

実装の話は Lisp なら簡単か。かっこを上手に扱う機能が入ればあとは普通のエディタの機能でほとんど構文エディタになる。

逆にシンタックスを弄りやすくして、普通のエディタが構文エディタ的な振る舞いをできるようにするのはどうだろう？Haskellはいい線いってる？文を消す <–> 行を消すの対応をほとんどの言語でしているので多かれ少なかれそういう側面がある。究極的にはどこまでいけるだろうか？エディタの基本操作は一文字入力/削除か。Vimでできることに広げるとどうだろうか。

関連して、エディタの話の制限を忘れて、言語デザインと使い勝手を考えたい。ソースコード –> AST –> typed-AST –> 実行結果くらいの段階がプログラマが交流しうるプログラムの表現だろう（実行結果が入るのは理論的じゃないかもだけど、気持ちとしては入るはず。みんな実行のことを考えてプログラムを書くのだから）。

プログラムの概念は色々あるが、それらは必ず上のどこかの概念として捉えることができる。プログラムの挙動は実行時のことだし、行数はソースコードのこと。では型は？ typed-ASTかそれよりも前のどこかだ。例えば型アノテーションついていればソースコードの時点でわかるが、付けずに型推論に任せていれば、typed-ASTにまで頭を巡らせないとわからない。

変数の参照はどうだろう。ソースコードなことが望ましい（lexical scope）けどそうじゃない困った言語もある。

いろんな概念があるが、なんにしても、早い段階でわかったほうが嬉しいことが多いだろう。でも一方でそれをわかあるためにプログラマがコンパイラの代わりをするのは非人道的だ。型アノテーションは大切だけど型推論を邪魔者扱いする人はいない（いないよね？）。これ以上具体的なことは言語の意味論によるだろう。HaskellとSchemeを同じ土俵で議論するのは大変そう。

読書感想: 入門コンピュータ科学

本をざっくり読んだので感想をメモ。読んでよかった。

読んだ本: 入門コンピュータ科学。

おそらく情報工学科の学部で扱うであろう内容をまとめた本。プログラミングはしないけど、それ以外の座学は大体ざっくりまとまっていそう。僕は情報工学科の講義をとっていないので、真偽はわからないのだけど。あくまで内容はざっくりしていて、専門的な内容は省かれている感じ。インターネットとはとか、データベースとは、プログラミング言語とは、みたいなことが書かれていて、それぞれの難しさを指摘するところまでを解説してくれる。技術の実装方法や難しさの解決策とかは扱わない感じ（だったはず）。CS関連で知らないことが出てきた時に、どの辺を勉強すれば良いかの手がかりとなる概観を与えてくれたんだと思う。

この本を読んで、データベースとインターネットについてざっくりとした理解を得た。手を動かしつつ、必要に応じて勉強できそうだと思う。情報系の学部出身と言ったら、このくらいは完全に理解していて、さらに専門的なところまでいけることを社会から期待されている気がする。どのあたりの知見が僕に欠けているかを（多分）理解できたし、足りていなかったところをある程度補完できた。

上の感想文を書いて、僕のバックグラウンドに疑問を抱く人がいるかもしれないと思ったので説明しておく。

僕は情報科学科（数理・計算科学系）の出身でコンピュータサイエンスを一応専攻してきた。ただ、CSだけじゃなくて統計や数学も学科が扱う範囲に入っていて、例えば確率論の基礎（σ加法族とかから初めて中心極限定理まで）とか集合と位相（和集合演算というのは…とかから濃度、ベルンシュタインの定理、選択公理をみて、位相論では分離公理（だったっけ？）とか連続性を扱った。付録的な立ち位置だったけど、有理数全体の集合を距離空間として見たとき、それを完備化して実数を構成する様も追った。）。これらは学部2年の話で、他にも色々講義があった。その傍でCSの講義も開講されていた感じなので、ある程度カルキュラムから端折ったCSの内容があったのだろうと思う。統計や数学の人からしても、端折った箇所があったと感じてるのではないかと想像する。数学か行くべきと発言していた人もいる。そういうわけで、今回本を読んで知識を補完できてよかったと思った。

学科の選択に後悔はなくて、色々楽しそうな領域を見て、そうでもないかなと判断できた。その中で生き残った楽しい領域で今勉強しているのだから、とりあえず満足。なんならプログラムングなんてしたくないと、学部3年の終わりまで思っていたし。

学部の授業で講義資料を作るのやめて、こういう教科書を指定するのが学生のためだと思う。講義資料を作るのは先生の自己満足なのだろうか。先生にとっては勉強になるだろうが、学生からすると比較的完成度の低い資料を与えられて、成績のためにそれに従った勉強を強いられる。授業内容は先生の専門になるほど細かいことではなく、多くの人が知っている教養的な内容なのだから、信頼できる文献を学生に与えることが教える側の責任の取り方なんじゃないかと思う。教科書を用いて講義を進めることにどんな問題があるのだろうか。

本を読むときに、人から与えられて読むか、自分で発見して読むかによって学習のモチベーションは大きく変わる。人から与えられた時には粗が気になるが、自分で読む時に美点に目がつく傾向がある。もちろん白黒はっきり分かれるわけではなくて、どちらかというと、くらいのふんわりとした傾向でしかないけど。その辺りを気にして良い教科書を紹介しないで、やる気のある人が自分で発見する機会をとっておくために自作の講義資料を使う、とか？

そうだとしたら、その判断は微妙に感じる。講義で一回目を通して、その時は読む気が起きなかった教科書も、後々（数ヶ月、1、2年後）に読み返すことは少なくない。その時には自分で発見して読むときと同じようなモチベーションで僕は読める。そういうわけで、良い本を知らずに過ごすリスクを減らすためにやはり先生には紹介してほしいと思う。それも、ただタイトルと概要を述べるだけではなく、実際に授業で本の中身を扱うことで内容を学生にわからせてほしい。

教訓:

良い論文とか文献は積極的に紹介する。
紹介する時には、内容まである程度紹介するとよい。

今回は読書感想文なので読んだ本の内容は紹介しない。ここでCS概論述べてもしょうがないし。僕みたいな人間がこの本を読んでどういうふうに良いと思ったかをメモすることで、似た境遇の人とかの助けになれば良いな、という程度のモチベーションでした。

My First Post

このサイトはHugoとGitHub Pagesを用いて運用しています。これらとGitHub Actionを組み合わせることで、マークダウンで記事を書いてGitHubにpushするだけで更新できるブログを構築しています。 Hugoは静的サイトジェネレータの一つで、設定を済ませたあとは、マークダウンで記事を書くことでコマンド一発でWebページのソースを生成してくれます。 GitHub PagesはGitHubに保存したコンテンツをWebページとして配信してくれるサービスです。

この構成は僕のアイデアではなくて、いろいろな人が手順を紹介してくれています。僕が参考にした記事を以下に紹介します。

Hugo on GitHub
GitHub Actionを用いたHugoの運用方法を解説しているドキュメントです。記載の方法に従うことで、mainブランチにmarkdownを書き、gh-pagesブランチに配布するためのHTMLなどを自動で生成できるようになります。
Quick Start Hugo
Hugoの始め方。Hugoのインストールからlocalhost経由でのサイト表示の確認までを教えてくれます。