全ての記事

「究極の鍛錬」を読んだ

「究極の鍛錬」を読んだ。A Philosophy of Software Design の冒頭で紹介されていて気になったので読んだ。日本語のタイトルはだいぶ怪しいし表紙も僕はギョッとしてしまったのだけど、内容は真っ当そうな感じがした。それなりに面白くて2,3回の読書で読み切った。なんだって！みたいなことは書かれていなくて、まあそうだろうなという内容ばかりではあるのだけど、そういうことを主張する人が存在することをしれたことと、色々推論した結果を読み込めたことが嬉しい（ここ何年かそういうパターンの読書が増えてきた。エコーチェンバーになっていそう）。改めてこの手のことを考えるきっかけになったし、今の自分の状況をこの本の視点で振り返るきっかけになった。

この本の他には、学問のすすめ、エミール、各種幸福論がその類の本だと思う。

本の内容に触れる。何かの専門領域ですごくなるためには練習を適切にたくさんする必要がある、みたいなことが主張されている。適切な練習をすることが難しくて、モチベーション、観察、フィードバック、指導とかがそれに影響を与えるとも。練習と実践は違うのであって、単に経験年数を積んでもうまくなるとは限らない、とかは印象的。その手の話ってキャリアとか成長とかを考えるときに気にする話題だし頭を悩ませるものではあるが、ここで議論をショートカットできるようになったのはいいこと。

23:59:59という時刻を扱うのはやめよう

この記事は生成AIを使って書いた記事です。ほとんど生成したものですが、レビューしてありますし加筆修正を人間が行なっています。

プログラミングやシステム設計において、しばしば「23:59:59」という時刻が“終端”（end of day）として扱われます。しかし、このアプローチには多くの落とし穴（pitfalls）や混乱が潜んでいます。本稿では、なぜ23:59:59のような終端時刻を避けるべきかを整理し、より堅牢で明快な代替手法をご紹介します。

課題

1. 境界値（Boundary Value）の問題

  • オフバイワンエラー（Off-by-one Error）23:59:59を終了時刻として設定すると、しばしば「23:59:60」や「24:00:00」をどう扱うかで混乱が生じます。特に、うるう秒（leap second）の挿入時には「23:59:60」が発生し、想定外のバグを誘発することがあります。
  • 不明瞭な閉区間（Closed Interval）と開区間（Half-open Interval）23:59:59を含むか否か、すなわち区間を[00:00:00, 23:59:59]（閉区間）で扱うのか、[00:00:00, 23:59:59)（半開区間）で扱うのかが曖昧になり、仕様書（specification）と実装に齟齬が生じがちです。

2. 日付変更との齟齬

  • 日次バッチ（Daily Batch）とカレンダー表示例えば、日次バッチ処理を「23:59:59までのデータを集計」と定義すると、処理が終わるわずかな遅延で翌日の00:00:00以降のデータが取りこぼされたり、重複集計されたりする恐れがあります。
  • ユーザーインターフェース（UI）の混乱ユーザーに「23:59:59表示」を強いると直感的ではなく、かえって誤操作を招くことがあります。多くの人にとって「23:59:59」はピンと来にくく、特にミリ秒（milliseconds）やタイムゾーン（time zone）をまたぐ場合の理解が難しくなります。

3. システム実装の複雑化

  • データベース（Database）のクエリWHERE timestamp <= '2025-04-30 23:59:59' といった条件は、ミリ秒精度のタイムスタンプやタイムゾーンが絡むと正確性を欠きやすいです。
  • テスト（Testing）とモック（Mock）の難易度テスト時に23:59:59を意図的に生成・モックするのは手間がかかり、テストケースの網羅性を落とす原因となります。

解釈を変えて00:00:00(24:00:00)を扱う

23:59:59を扱いたいときは、きっと何かの期間の終わりを表すことを目的としているでしょう。「終わりの時刻まで」、と捉える代わりに終わりの時刻の直前までと捉えることで、23:59:59ではなく00:00:00を扱えば済むようになってすっきりします。具体的には以下の通りです。

半開区間（Half-open Interval）を使う

  • [開始, 終了) の形式例：[2025-04-01 00:00:00, 2025-05-01 00:00:00)
    • 「2025-04-01 00:00:00以上かつ2025-05-01 00:00:00未満」という明確な条件設定が可能。
    • オフバイワンエラーを防ぎ、うるう秒も意識不要。

ISO 8601の24:00を活用する

  • 「24:00」表記
    • 同日23:59:59の次に位置づけられるため、論理的な終端（end-of-day）を明示できます。
    • 例：2025-04-30T24:00:00 は 2025-05-01T00:00:00 と同一視されます。
    • ただし、すべてのライブラリがサポートしているわけではない点に注意。

23:59:59を終端時刻として安易に扱うのは、多くの境界値エラーや実装・運用の混乱を招く原因となります。代わりに、半開区間（half-open interval）[開始, 終了)やISO 8601の24:00表記を採用し、仕様（spec）から実装（implementation）、テスト（testing）まで一貫して明確な時刻管理を行いましょう。これにより、バグの減少と運用コストの削減が期待できます。

参考情報

以上を踏まえ、次回からは「23:59:59」という時刻を見直し、より堅牢な方法で時刻管理（time management）を実践してみてはいかがでしょうか。

A Philosophy of Software Designの読書メモ

各章のまとめをする。随時僕の思ったことを差し込む。なのでこのドキュメントを読んであの本を読んだ気になってはいけないし、あの本と同じくらいに信頼してはいけない。

Preface

ソフトウェアの設計とか、良いソフトウェアが何かとかの議論が未熟である

  • 以下のような事項については議論がされている
    • 開発プロセス
    • 開発ツール
    • プログラミングテクニック
      • OOP
      • functional
    • デザインパターンとかアルゴリズム
  • 設計については1971の "On the Criteria to be used in Decomposing Systems into Modules" から発展がない

設計技法を体系的に身につけて複雑さを減らせるようにすることを目指す

  • 分割統治が大きな関心ごとだが、そのための教育はされていない
    • どのように問題を分割するか
    • 問題の分割を決めることは設計のでかいタスクの一つ
  • プログラマの品質とか生産性にはそれなりにばらつきがある
    • 能力には才能ではなくて良い練習が効くのは一般的に言われているらしい
  • 設計のスキルがプログラマのすごい・普通を分けるだろうと仮定して、学部一年生に対して講義を始めた
    • 原理・原則を座学で伝える
    • ソフトウェア開発のプロジェクトもやって、それらを活かす練習をする
      • 学生はたくさんコードを書いて講師にレビューを受けて改善する
  • その講義で伝えた設計の原則を集めたのがこの本
  • この本を書いた人はスタンフォードの教授で色々ソフトウェアを作ってきた
  • 複雑さを減らすことがどの原則よりも大切

Chapter 1. Introduction (It's all about complexity)

良いソフトウェアをいい感じに作るためには複雑さに対処することが必要

  • ソフトウェアはそれがどんなものであるかを表現できれば作れたも同然である。例えば筋肉がなくても作れる
  • そのためソフトウェアを書くのを律速する能力は、作っているシステムがどんなものであるかを理解する能力である
  • 残念なことにプログラムを成長させていくに連れて複雑さは増していく。
  • 複雑さを増すとそのソフトウェアを理解することは難しくなり、成長させる速度やコストは増す。バグも入る
  • 開発ツールで複雑さに対処することはできるし、そうしてきた
    • コード生成とかバージョン管理とかプログラミング言語とかはその例
  • ツールの力だけでなんとかしきることは、とはいえ無理
  • ソフトウェアを簡単に作れるようになって、もっとすごいシステムを安価に作れるようになるためにはソフトウェアをシンプルに保つことが必要
  • まあ複雑さはどう頑張っても増えるものではあるのだけど、設計をシンプルにしておけばソフトウェアがでかく強力になってもまだ耐えられるようにできる

複雑さを減らすためには二つのアプローチがある

  • コードをシンプルで明らかにすること: こっちはまあそうでしょう、と思える
    • 名前の付け方に一貫性を持たせる
    • 特別扱いを減らす
  • 複雑性をカプセル化する。(moduler designと呼ぶらしい)
    • 分割統治をするということ
    • 丁寧に説明すると、でかい問題を解決するために部分問題の証明を忘れられるようにすること

開発者はソフトウェアの複雑さに対処し続ける必要がある

橋とかのデザインと違って、ソフトウェアはずっと設計を変え続けるもの。この考え方に足していないのがウォーターフォールな開発で、一度に全体を設計したらそれを開発の過程で変更することはなく、もし微妙なところが出ても書く開発対象の範囲内で対処する。

アジャイル開発は設計を変え続けるアプローチに即している。将来的に開発したいでかいものは見据えつつ全体の設計は後回しにして欲しいソフトウェアのサブセットをまずは設計して開発する。開発の段階でまずそうとわかった設計は、次の開発の前に変更してまずさを潰す。こうすることで設計の問題が小さいうちに課題を発見し解決できる見込みが増える。

こういうイテレーティブな開発では設計が終わることはない。開発者は常に設計に気をかける必要があるし再設計する必要がある。改善するために小さく刻んで開発しているのだからそれはそう。設計を改善できないのならば、アジャイルに開発する意味がない。

今日ではアジャイルな開発をしているわけで、開発者常に設計の課題について考える必要がある。設計のことに常に気をかけないということは、常に複雑さに対処しなければならないということ。

この本の目的

二つある

  1. ソフトウェアの複雑さを理解すること
  • 複雑さとは何か
  • 複雑さは何が問題なのか
  • 不必要な複雑さを持っていることにどのようにして気がつくか
  1. ソフトウェア開発にあたって、複雑さを最小化するための個別なテクニックを習得すること

Chapter 2. The Nature of Complexity

この章では複雑さとは何かや、どのようにシステムが不必要に複雑であるかを見分けるかを議論する。設計がシンプルかを見分けるだけでは設計をシンプルに作ることはできないが、その判断をもとにシンプルに作るためのアプローチをできる。

設計方針を色々試してみれば良くて、その結果いい感じになるやつを使えば良い。そのいい感じになるかの評価をできるようにすることがこの章の目的である。

複雑さの定義

この本で議論を進めるために以下のように複雑さを定義する: 複雑さはソフトウェアシステムの構造に関するもののうち、システムの理解や修正を難しくするものである。

例えば以下のような例がある

  • コード片がどのように動作しているか理解できない
  • システムのどこを修正して良いかわからない
  • 他に影響を与えずにバグ修正をするのがむずい

要するに、理解と修正が難しければそのソフトウェアシステムは複雑であるということ。それが簡単だったらシンプル。

システムの複雑さは、コンポーネントの複雑さをその変更頻度で重み付けした上での総和であると思える。

また、読み手にとっての複雑さと書き手にとっての複雑さは異なる。書き手にとってシンプルであっても読み手にとって複雑であればそれは複雑である。自分がそういうコードの書き手であったら、その分断が起きた理由を探ると良いだろう。そのギャップを埋める必要がこの仕事にはあるのだから。

複雑さの症状

一般的に三つの兆しがあって、開発を辛くする

  • 変更範囲の拡大: 簡単にできそうな変更が思ったより大変なパターン。メンタルモデルとその実現方法があっていないときに生じる。メンタルモデルを表現する力が足りていない
  • 認知負荷: うまく使うためにやらないといけないことが多いことが原因
  • unknow unknown: 変更する必要性に気がつけなくなっていること

unknown unknownが特に辛い。変更範囲が広いのはめんどいのは間違い無いのだけど、全部対処すれば自信を持って変更を完遂できる。一方でunknown unknownは自信を持つために全てのコードを読む必要があって辛い。システムがでかいとそもそも無理。

設計の目標の一つにシステムを明らかにすることがある。認知負荷とunknown unknownを減らすことにつながる。理解もコーディングもシュッとできるのがいい。何かを考えてそれが実際に通じるかの判断も簡単になる。

複雑さの原因

複雑さの症状をざっと見て、なんでソフトウェア開発が辛くなるのかを議論した。次に複雑さの原因を議論してシステムに問題が入らないように設計できるようになりたい。

複雑さは依存と不明瞭さによって生じる。ここではそれらをざっくり語って、後の章では細々とした設計での意思決定がどのようにそれらと関係するかをみる。

依存

扱う対象がそれ単体では理解できない、変更できないときに一緒に変更するやつに依存するという。頻繁に変更するコンポーネントが他のコンポーネントに依存していると、依存されているコンポーネントまで頻繁に変更するハメになる。そこで以下のシステムの複雑さの定義の言い換えを思い出す。

システムの複雑さは、コンポーネントの複雑さをその変更頻度で重み付けした上での総和であると思える。

依存が多いシステムではたくさんのコンポーネントの変更頻度が上がるため、システムの複雑さも大きい。

特に複雑なコンポーネントを他の変更が多いコンポーネントから依存させないことがシステム全体の複雑さを抑えるために効く。

不明瞭さ

大事な要素が明らかになっていないことを指す。例えば数値の単位がわからないとか、名前がなんの意味も表してないとか。あるいは依存が存在することが明らかじゃ無いのもそう。一貫性のなさもこの要因で、同じ名前が異なる用途に使われているとやばい。

ドキュメントがやばいことが多くの原因で、コメントをちゃんと書けばよかったりする。デザインが良ければそもそも明らかであってドキュメントを不要にすることもできる。

めっちゃコメントがいるような場合はデザインがまずいことの兆しだし、明瞭さを増すためにはシステムの設計を改善するのが正攻法。

依存は変更範囲の拡大と認知負荷に作用して、不明瞭さはunknown unknownと認知負荷に作用する。依存と不明瞭さを下げる設計技法が手に入ればソフトフェアの複雑さを下げられるはずだ。

複雑さはシステム全体のもの

一個一個の細かい要因が全体を壊すほどの複雑さ単独で生むわけではなくて、複数が重なり合って首が回らなくなるもの。対処するためには "zero tolerance" philosophy に従うべきらしい。

複雑さは既存のコードベースを修正することを難しく、またリスキーにする。

Chapter 3. Working Code Isn't Enough (Strategic vs. Tactical Programming)

プログラミングタスクに際してのマインドセットは良いソフトウェア設計のために大事な要素である。

良いデザインを得るためには、すぐにコードが動くことを至上とするするtacticalなマインドセットではなくて、綺麗なデザインのために時間をかけた上で問題点を修正する方針が必要だ。

この章ではなんで戦略的なアプローチが良い設計を生むのか、そして戦略的なアプローチの方が結果的には安いことを主張する。

Tactical Programmingとはどんなか

多くの開発ではtacticalな手法が取られる。例えばバグを治すためにその場しのぎの対症療法をするようなこと。確かにそのときは早いのだけど、良いシステムの設計が得られることはないだろう。そういうときに、少しずつ不必要な複雑さがシステムに入り込む。

そのうちしんどさに気がついてリファクタリングとかをしたくなるのだけれど、仕事には期限があって新しい機能を追加しないといけないからやはり複雑さは残ったままになる。今見えている問題にはすぐに効くパッチだけ当てて、全体をよくすることはない。

そのうちマジでヤバくなるのだけど、その頃には全体を治すのが大変になっていて、当然そんな時間を取ることはできないので諦めてずっとその場しのぎの変更を入れ続けることになる。

一回tacticalな道に足を踏み入れるとそこから抜け出すことは容易ではないのだ。

Storategic Programmingとはどんなか

まともなソフトウェア設計者になるための第一歩は動くだけのコードでは不十分であることに気が付くことだ。タスクを早く終わらせるために不必要な複雑さをコードに入れることは許されない。コードは既存のものに追加されていくものなので、今書かれているコードを将来誰かが編集することにもなる。なので今書くコードは動くだけでなく素晴らしい設計を体現することを目標にしないといけない（もちろん動く必要はあるけど）。

Strategic programmingには投資の心構えが必要で、例えばよく考えることに時間を投資するとか、いくつか設計してみて一番綺麗なやつを選ぶとかする。変更の可能性をいくつか想定してみてまあいけそうだと思えることを検証する。良いドキュメントを書くこともその一環である。colliraryとして、良い設計をするためにはソフトウェアを変更する能力が効く、が主張できる。ソフトウェアを変更する能力がないひとは変更に強いことを主張できないが、変更する能力がある人はその設計がどこまでの変更をどのくらいの大変さで実施できるかを評価できる。他にも、設計がまずいことに気がついたときに目を瞑るのではなくちょっと時間をかけてよくする必要がある。

どれくらい投資するべきか

最初に全部設計するのは効果的ではなさそう。理想的な設計は作りながらわかっていくものなので、少しずつのたくさんの投資を基礎の上で行うこと。1-2割の時間を設計にかけることをここでは提案している。スケジュールを破壊するほどは長くはないし、利益を産むために十分な時間でもあるはず。

スタートアップだから、みたいな言い訳は通じなさそう

Facebook, Google, VMWareを引き合いに出してstorategicにやった方が良さそうですよ、と主張している。意味的に新しいことはここでは特に言ってなさそう。よくある（本当によくある）tactical programmingの正当化への反論をここではしている。

教訓

  • storategic programmingをしろ、効果は思ったよりもすぐに現れる
  • 明日ではなく今日やるもの
  • 全てのエンジニアが良い設計への投資をすることが効果的

Chapter 4. Modules Should Be Deep

開発者がシステム全体ではなく一部の複雑さだけに対処すれば良い方にすることを目的とするソフトウェア設計着本がある。Modular designと呼ばれていて、ソフトウェアの複雑さをなんとかするためにすごく大切。

この章ではこの基本的な原則を解説する。

Modular designとは何か

ソフトウェアシステムを複数の（それなりに独立した）モジュールに分解する。ここでいうモジュールはクラスかもしれないし、サブシステムかもしれないし、サービスかもしれない。理想的にはそれぞれのモジュールは他には全く依存しないで欲しい、つまり開発者はそれぞのれモジュールを他のモジュールのことを完全に忘れて開発できるようになっていて欲しい。そういう理想的な世界では、ソフトウェアシステムの複雑さはそれを構成するモジュールたちの複雑さの中で一番複雑なやつの複雑さである（あれ、そういう定義だったか。まあ気持ちはわかる）。

現実世界ではそうは問屋が卸さなくて、あるモジュールは他のモジュールの関数とかを呼ぶ必要があって、多かれ少なかれ他のモジュールを知っておく必要がある。モジュールの間いに依存が生じることもあるはず（つまりあるモジュールを変更したら、他のモジュールを変更する必要が出てくるかもしれないということ）。Modular designの目的はモジュール間の依存を最小化すること。

依存を管理するためにはモジュールを二つの要素、インターフェースと実装に分けて捉えると良いだろう。モジュールを外から使うために知っておくべきものがインターフェースで、そのモジュールが何をするかを表す。それをどのように実現するかは表さないのが典型的。実装はインターフェースを満たすためのもの。あるモジュールで仕事をする開発者は、他のモジュールのインターフェース、そのモジュールのインタフェース、そのモジュールの実装を頭に入れて働くことになる。他のモジュールの実装を頭に入れる必要はないし、そうしないべきである。

ここでいうインターフェースはプログラミング言語の意味論で強制されるものに限らなくて、自然言語でドキュメントとして記述されることもある。そのモジュールを使うために開発者が知るべき情報は全てインターフェースの一部である。形式的でない部分はコメントとして書くしかなくて、それが正しいことをプログラミング言語が保証することはできない。そして残念なことにそういう形式的でない部分は複雑でより多い傾向にある。

明瞭に書かれたインターフェースは開発者がそのモジュールを使うために知る必要のあることを占めることであって、unknown unknownを減らす。

抽象化

Modular designと関係する概念。抽象化は対象を単純化した見方のことで、重要でない詳細を捨てたもの。複雑なことをしなくてもそれを扱えるようになるので抽象化は便利。

モジュラなプログラミングではモジュールがインターフェースによってその抽象化を提供することになる。インターフェースはモジュールの単純化された機能を説明することになるということ。モジュールを使うためには重要でない詳細を捨ててそのモジュールを理解すれば済むので嬉しい。

捨てているのが重要でない部分であるのが大切。抽象化のミスり方には二つある。

  1. 重要でない詳細を抽象化に含めること: 抽象化を複雑にする点でよくない
  2. 重要な詳細を抽象化に含めないこと: 不明瞭なシステムになるのが良くない。抽象化だけをみている開発者はその抽象化を正しく使うために必要な情報を見落とすことになる

後者のことをfalse abstractionと呼ぶ。一見シンプルだけど実はそうでもないやつ。抽象化を設計するためにはどんな情報が大切かと、どのように大切な情報を減らすかが鍵。

Deep/shallow modules, classiti

機能的でシンプルなインターフェースを持つモジュールが最高のモジュールということになりそう。抽象化がうまくいったやつがいい。そういうモジュールのことをdeepなモジュールと呼んでいる。

反対にインターフェースが複雑な割に大した機能を提供してないものはshallowなモジュール。

我々はモジュールをdeepにすることを目指すべきであって、そのインターフェースの絶対的なサイズは問題ではない。

まとめ

  • モジュールをインターフェースと実装に分けて捉えることで、その複雑さをシステムの他の部分から隠せる
  • そのモジュールを使う側はそのインターフェースだけに気をかければ良い
  • 大事なことはモジュールが深くなるように設計すること。そうすれば隠蔽できる複雑さを最大化できてシステム全体の複雑さを抑えることに貢献できる

漏れなくスタックトレースをGoで取りたい！

k1LoW/errors でスタックトレースをエラーにつけられるようになる。便利なのだがトレースをプログラマが明示的に指示しないといけない。設定をコードベースで一回やれば終わりではなく、エラーの発生源で書かないといけない点が気になっている。書くこと自体は許容しているが、漏れがないように人間が頑張るのは許容したくない。漏れをなくすための仕組みを主張する。

k1LoW/errorsの説明

ライブラリとして使うためにはreadmeの説明で十分だと思うが、議論のためにここでも説明する。以下のように用いる。

https://go.dev/play/p/Cwp4n-vZONv

package main

import (
	"encoding/json"

	"github.com/k1LoW/errors"
)

func f() error {
	// このようにWithStackを呼び出した箇所でのスタックトレースがerrorオブジェクトに記録される
	return errors.WithStack(errors.New("ouch!")) // ここは11行目
}

func main() {
	err := f()
	// スタックトレースを含んだエラー内容をフォーマットする
	s := errors.StackTraces(err)
	b, _ := json.Marshal(s)
	println(string(b))
}

実行すると以下のような出力が得られる。見やすさのために jq にかませてフォーマットした。

[
  {
    "error": "ouch!",
    "frames": [
      {
        "name": "main.f",
        "file": "/tmp/sandbox123757503/prog.go",
        "line": 11
      },
      {
        "name": "main.main",
        "file": "/tmp/sandbox123757503/prog.go",
        "line": 15
      },
      {
        "name": "runtime.main",
        "file": "/usr/local/go-faketime/src/runtime/proc.go",
        "line": 272
      },
      {
        "name": "runtime.goexit",
        "file": "/usr/local/go-faketime/src/runtime/asm_amd64.s",
        "line": 1700
      }
    ]
  }
]

スタックトレースの先頭 (frames配列の先頭要素) はWithStackを呼び出した位置を指す。

したがって、アプリケーションの中でのエラーの発生源をスタックトレースから漏れなく特定するためには、エラーの発生源の全てでWithStackを呼び出す必要がある。

なお、WithStackを重ねて呼び出しても問題ようになっている（深いスタックトレースを持つものが生き残るようになっているし、他のも気遣いがされている）。

背景・既存のアイデア

名前付き返り値とdeferを使って忘れないようにする手法も紹介されている。

func f() (err error) {
	defer (func(){
		err = errors.WithStack(err)
	})()
	b := strings.Builder{}
	_, err := b.Write([]byte("hello"))
	if err != nil {
		return err
	}
	// ...
}

ある程度楽をできるし、この後の議論をした上でもバランスの良い選択肢だと思うが課題も感じている。その課題と解決案を以降で議論する。

課題

  1. deferを書くのを忘れそう
    • こちらはリンターでなんとかなるだろう。ここでは深く議論しない
  2. deferの中でerrors.WithStackを呼ぶと、エラーの発生源から離れるため、具体的にどのreturn errで落ちたかがスタックトレースから追えない
    • エラーメッセージから判断できる可能性は大きいけど

二つ目の課題の例を以下に挙げる。fではどの行で落ちたか分からないが、gではどちらのwithStackで生成したかが残る。

func f() (err error) {
	defer (func() {
		err = errors.WithStack(err)
	})()
	if err := ok(); err != nil {
		return err
	}
	if err := ng(); err != nil {
		return err
	}
	return nil
}

func g() (err error) {
	if err := ok(); err != nil {
		return errors.WithStack(err)
	}
	if err := ng(); err != nil {
		return errors.WithStack(err)
	}
	return nil
}

func ok() error { return nil }
func ng() error { return errA }
var errA = errors.New("this is error")

https://go.dev/play/p/SGr1B4sDF9I で動かせる。

解決案: 型で頑張る

k1low/errorsでは、errors.WithStackはfunc(error) error 型を持つ。それを func(error) errors.T とする。ここでTは以下のようなerrorをStackTraceメソッドで拡張したようなインターフェース。

package errors

type T interface {
	error
	StackTraces() stackTraces // 戻り値型には議論の余地があるが、ここでは重要ではない。
}

// 唯一のT型のコンストラクタ
func WithStack(err error) T { ... }

スタックトレースを取りたいアプリケーションでは、すべての関数定義で返すエラー型を標準の errorではなく errors.Tとする。そうすると、すべてのreturnされるエラーオブジェクトからスタックトレースを取得できることが保証される。

以下の二点が嬉しい。

  1. errors.Tを返す関数しか呼ばない関数は繰り返しerrors.WithStackを呼ぶ必要がなくなる
  2. errors.WithStackをエラーが発生するたびに (deferの中ではない！) 呼び出すように保証できるので、スタックトレースがちゃんと深くなる

この方法の問題は以下。人によっては許容できるだろう（ぼくはありだと思っている）。

  1. すべての関数定義で返すエラー型をerrors.Tに統一する方法が定まっていないこと
  2. errors.WithStackをたくさん呼ばないといけないこと
  3. 独自のエラーインターフェースを定義していて気持ち悪いこと

一つ目はリンターを書けば良い。error型を返す関数を定義したら怒るだけなので簡単。deferでちゃんと書くことを保証するよりも難易度は低いはず。

二つ目は諦めるしかない。生成AIに頑張ってもらいたい。手書きするのは嫌だけど、補完があるならギリギリ許容できる気持ちがある。

三つは対処を思いつかない。これも諦めて受け入れるしかないだろう。標準のエラーとは別物として扱おうとしているのだから型は真っ当に手法を表現している。解決手法がGoぽくないのだろう。

結論

  • deferを使う手法ではスタックトレースがちょっと足りない
    • とはいえエラーメッセージが適切に設定されていれば問題ではない
    • 込み入ったこともしないでいいし簡単
  • とはいえ設定もれが怖い気持ちや、スタックトレースをもう一段深く取りたい気持ちもある
    • そのときは今回提案した型で頑張る手法をとれば良いと思う

Goのanalysisとtypesに入門する

概要

Goで静的解析してリンターを実装したい。具体的には、あるT1インターフェース型の変数がスコープにあるときは、T1よりゆるい任意の型の使用を禁止する、みたいな制約を入れたい。その辺に転がっている記事ではASTを覗いてみたり、SSAを覗いてみたりするようだけど、ASTとその型をまともに扱っていつつ、いい感じに静的解析ツールとして仕上げる記事を見つけられなかった。

この記事ではGoプログラムの静的解析ツールを実装するために存在する標準的なツールチェーンの思想を説明する。Go Analyzerは静的解析ツールフレームワークとして用いる。具体的な静的解析には標準ライブラリを用いる。

作りたいもの

具体的には、あるT1インターフェース型の変数がスコープにあるときは、T1よりゆるい任意の型の使用を禁止する、みたいな制約を入れたい。

これを検証するGoの静的解析ツール。例えば以下のようなrの使用を検知したい。

func parse(r io.Reader) (string, error) { ... }

func (rw io.ReadWriter) {
	var r io.Reader = getReader()
	s, err := dump(r) // 「rじゃなくてrwを使ってくれ〜！」と指摘したい。
	...
}

analysis

https://pkg.go.dev/golang.org/x/tools/go/analysis これ。準標準なパッケージ。ドキュメントの冒頭に思想がちゃんと書かれているのでそれを読むのが良さそう。

Analyzer構造体

一個の解析ツールに対応する。Analyzer.Runに解析を実行する関数を定義する。この解析ツールを実行するとき（実行するのはフレームワークの仕事）に、Pass構造体が渡される。

Pass構造体

Pass構造体は解析対象のパッケージごとに作成される。なので解析の単位はパッケージごとということになりそう。いいじゃん。

type Pass struct {
	Fset         *token.FileSet
	Files        []*ast.File
	OtherFiles   []string
	IgnoredFiles []string
	Pkg          *types.Package
	TypesInfo    *types.Info
	ResultOf     map[*Analyzer]interface{}
	Report       func(Diagnostic)
	...
}

こいつを通じて解析をする関数は処理対象のデータにアクセスしたり、処理結果を報告したりするぽい。モナドとか代数的エフェクトみたいで綺麗だ。そう思うとあれらは抽象化された一つの振る舞いの切り口を表現するための基本的な演算を定義していたのだから、まあそうだなと思える。Kokaで静的解析ツールを作るときにはpassエフェクトを定義するのだろう。

The Fset, Files, Pkg, and TypesInfo fields provide the syntax trees, type information, and source positions for a single package of Go code.

これは本質情報の予感。このあたりにうまくアクセスすることで、ぼくたちの頭の中で想像する型付き抽象構文木へのアクセスを実現できるんだろう。データ構造が思ったのと違いそうなことには気をつけよう。

これらに加えて、他のanalyzerが出力してくれる結果をこのanalyzerの入力として使える。それにアクセスするためには pass.ResultOf[a].(aResType)を参照すればよい。

診断(diagnostics)を出したければPass.Reportとか、パッケージで提供されているReportfとかを使うらしい。

Goの型付き構文解析木

ここまでで、モジュラーに静的解析ツールを実装するフレームワークの構造がわかった。それに乗っかれば静的解析をいい感じに動かすことはできそうだ。静的解析の処理を実装する方法もなんとなくわかった。Pass構造体の世界観に乗っかればokな感じがする。

次に自在にプログラムを解釈する方法を知りたい。プログラムはコンパイラに処理されていろんな形態に変換されるので、ユースケースに応じて適切な表現を選ぶ必要がある。今回は型付き抽象構文木を扱いたいので、Pass構造体のFset, Files, Pkg, TypesInfoあたりを上手に使えると良さそうだ。特にTypesInfoが気になる。これは types.Info型をとるみたいなので、typesパッケージを見に行く。

typesパッケージはこれ https://pkg.go.dev/go/types。冒頭の説明がスッキリしていてまだ何をやれば型付き抽象構文木に対してクエリっぽいことをできるか、どんなクエリっぽいことが許されるかを理解できない。なので貼ってあったチュートリアルのリンクを辿る。なお、スッキリしている説明自体は読んでよかった。このパッケージが扱うフェーズで何をやるか説明されていて、もっと詳しく読んで良さそうなことに自信を持てた。

なお、僕の目的のためには他の解析ツールの結果を使う方が良いかもしれないとも思う。暇だし気になるのでチュートリアルを読むのに時間をかけるけど。

チュートリアル

脱線したがチュートリアルを読み進める。https://go.dev/s/types-tutorial これ。これを読む目的は、何をやれば型付き抽象構文木に対してクエリっぽいことをできるか、どんなクエリっぽいことが許されるかを理解すること。

このチュートリアルはジェネリクスには対応してないらしい。ジェネリクスのためのドキュメントは別途あるとのことだけど、今回は基礎を知りたいので気にしない。

イントロと例くらいは読んでみて、あとは斜め読みでいいかな。まずはイントロ。

Measured by lines of code and by API surface area, it is one of the most complex packages in Go's standard library, and using it requires a firm grasp of the structure of Go programs.

とのこと。大変だ。

Starting at the bottom, the go/token package defines the lexical tokens of Go. The go/scanner package tokenizes an input stream and records file position information for use in diagnostics or for file surgery in a refactoring tool. The go/ast package defines the data types of the abstract syntax tree (AST). The go/parser package provides a robust recursive-descent parser that constructs the AST. And go/constant provides representations and arithmetic operations for the values of compile-time constant expressions, as we'll see in Constants.

データ構造とアルゴリズムを分けるの賢そう。parserにastを定義しないとか偉い感じがする。色々あるんだろうな。どう嬉しいのかはわからないけど。定数畳み込みをastに対して実装したいが、parserに依存するわけではないよね、みたいな話かな。

名前解決、型検査、定数式の計算は一緒にやらないといけないなるほど。ここでいう名前解決とは、名前の出現に対してその宣言を対応させること。

例まで読んだがパッケージレベルの話しかわからないな。ぼくは式とかのレベルでプログラムを処理したいんだ！ということで本命のInfo構造体への言及を探すことにすると、TypeAndValueでそれらしいことを述べている。

Info.Typesは map[ast.Expr]TypeAndValue らしい。そろそろ手を動かして、プログラムのこの要素は式として扱われるか？とかをみたい。と思ったらドキュメントが例を出してくれた。こういうときが一番楽しい。式があったら型は得られるようになってるのね。ただまだよくわかってなくて、mapの定義域をast.Exprとしているが、そのExprとして本当に登録されるのはどの範囲のExprなのかがわからない。当然 ast.Expr{} なんて渡しても、その型を計算しているわけがない。どういう操作で手に入れたast.Exprに対しては、Info.Typeがその型を教えてくれるんだろうか。Infoを生成するやつが知ってるのかな。analysisパッケージはよくわからんPassがInfoを持っていたので微妙だけど、パッケージの単位で処理をするのでパッケージに存在するすべての式の型を教えてくれると思って良さそう？

確かにConfig.Checkはパッケージを型検査して、引数にInfoへのポインタをとって結果を書き込みそう。

次に、型同士の比較をしたい。具体的には、T1が必要な文脈でT2は使えるか (assignable) を判定する方法が欲しい。そのためにこれが使えるhttps://pkg.go.dev/go/types#AssignableTo。引数に渡すTypeインターフェースの値はTypeAndValueで取れるので、ほとんど勝ったようなもの。ちなみに僕は、最初ConvertibleToを使っていて全然ダメだった。ConvertibleToは数値が変換できるか判定するやつぽい。

Neovimにlazyを入れてプラグイン管理することにした

これまで特にプラグインを使っていなかった（それくらいで済む用途にしか使っていなかった）のだけど、カラースキームを指定したくなったのでプラグインマネージャを入れた。

どれども大差ないといろんな記事で言われていたので名前とかが気に入ったlazyを使うことに。

https://github.com/naoyafurudono/dotfiles/blob/add-lazy/nvim/init.lua#L17-L55 で設定している。

AHK入門

Windowsマシンでキーボード操作が不便なので導入する。悪態をつきながらも使っている人を知っているので内容を理解していないが期待している。

インストール

https://www.autohotkey.com/ 公式ページからバイナリを落とせる。インストールするとwelcome画面が開いたのだが、そこに「コンパイルする」ボタンがあって、ちょっと不安になる。僕はプログラムをボタンを押してコンパイルしないといけない？

ついてきたマニュアルはいい感じのスタイリングでよみやすそう？

マニュアルを読んでみる

頭から飽きるまで読んでいく。

  • スクリプトの作成 (Create a Script)

    • Be sure to save the file as UTF-8 with BOM if it will contain non-ASCII characters. For details, see the FAQ.

    • BOMがいるらしい。そういえばBOMってなんなのだろう。結局まだちゃんと理解してない。
  • スクリプトの実行 (Run a Script)
    • なんかソースファイルをダブルクリックしたりして実行できて、実行してる間だけ効くらしい。
    • イベントハンドラみたいなやつの定義がそれぞれのスクリプトに対応するかと思っていたが、なんかメンタルモデルがあってなさそう
  • それぞれのスクリプト実行がWindowsのトレイアイコンに反映されるらしい。なるほど

飽きたのでhello worldする。

hello world

以下はCapsLockを押すとhello, worldと出力するよう設定するahkスクリプト。ちなみにこれらのhello, worldはCapsLockを打って入力している。

#Requires AutoHotkey >=v2.0.0

CapsLock::
  {
    SendInput "hello, world"
  }
  Return

CapsLockで英数変換するのは以下で実現できた。

#Requires AutoHotkey >=v2.0.0

CapsLock::
  {
    SendInput "^{Space}"
  }
  Return

紆余曲折あって、以下のようになった。Windowsでもいい感じにvim使えるようになって幸せ。

https://github.com/naoyafurudono/dotfiles/blob/main/autohotkey.ahk

#Requires AutoHotkey >=v2.0.0

IME_SET(SetSts, WinTitle:="A")    {
    hwnd := WinExist(WinTitle)
    if  (WinActive(WinTitle))   {
        ptrSize := !A_PtrSize ? 4 : A_PtrSize
        cbSize := 4+4+(PtrSize*6)+16
        stGTI := Buffer(cbSize,0)
        NumPut("Uint", cbSize, stGTI.Ptr,0)   ;   DWORD   cbSize;
        hwnd := DllCall("GetGUIThreadInfo", "Uint",0, "Uint",stGTI.Ptr)
                 ? NumGet(stGTI.Ptr,8+PtrSize,"Uint") : hwnd
    }
    return DllCall("SendMessage"
          , "UInt", DllCall("imm32\ImmGetDefaultIMEWnd", "Uint",hwnd)
          , "UInt", 0x0283  ;Message : WM_IME_CONTROL
          ,  "Int", 0x006   ;wParam  : IMC_SETOPENSTATUS
          ,  "Int", SetSts) ;lParam  : 0 or 1
}

IME_GET(WinTitle:="A")  {
    hwnd := WinExist(WinTitle)
    if  (WinActive(WinTitle))   {
        ptrSize := !A_PtrSize ? 4 : A_PtrSize
        cbSize := 4+4+(PtrSize*6)+16
        stGTI := Buffer(cbSize,0)
        NumPut("DWORD", cbSize, stGTI.Ptr,0)   ;   DWORD   cbSize;
        hwnd := DllCall("GetGUIThreadInfo", "Uint",0, "Uint", stGTI.Ptr)
                 ? NumGet(stGTI.Ptr,8+PtrSize,"Uint") : hwnd
    }
    return DllCall("SendMessage"
          , "UInt", DllCall("imm32\ImmGetDefaultIMEWnd", "Uint",hwnd)
          , "UInt", 0x0283  ;Message : WM_IME_CONTROL
          ,  "Int", 0x0005  ;wParam  : IMC_GETOPENSTATUS
          ,  "Int", 0)      ;lParam  : 0
}

IME_TOGGLE() {
  current := IME_GET()
  IME_SET(!current)
}

IME_OFF() {
  IME_SET(0)
}

CapsLock::
  {
    IME_TOGGLE()
  }

~Esc::
  {
    IME_OFF()
  }

認可に入門 wip

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

イントロ

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

Chapter II: What authorization is: how to organize your authorization codeChapter III: Role-based access control: grouping permissions in your app into roles like User and AdminChapter 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?

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

What is Authorization?

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, 呼ばれる側の責務にdecisionという名前をここではつけている。

Enforcement

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

Decision

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

まとめ

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

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

課題

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

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

Role-Based Access Control (RBAC)

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

半開閉区間

参照

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

余談

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

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

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

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

むずい。

ChatGPTに整理してもらった

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

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

プログラミングで区間を表現するのに半開閉区間を用いると良い理由を説明してください

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

  1. 直感的なインデックス操作:

    • 配列やリストなどのデータ構造において、インデックスは通常0から始まります。半開閉区間 [start, end) を使うと、start から end-1 までのインデックスが含まれるため、範囲を扱う際に計算がシンプルになります。例えば、要素数が10の配列に対して [0, 10) という範囲を指定すると、全ての要素を含むことになります。

  2. 区間の連結が容易:

    • 半開閉区間は連結する際に便利です。例えば、 [start1, end1) と [start2, end2) という2つの区間を連結する場合、end1 と start2 が同じであれば、それらを連結して [start1, end2) とすることができます。このように、区間の端点が明確に分かれているため、エッジケースが少なくなります。

  3. 境界の一貫性:

    • 境界条件を処理する際、開区間の端点は含まれないため、範囲外アクセスのリスクが減少します。これにより、特にループ処理や再帰的なアルゴリズムの実装が一貫しやすくなります。

  4. 数学的な整合性:

    • 半開閉区間の表現は、数学的にも広く使われており、理論的な背景からも自然な表現です。例えば、集合の分割や区間の分割などで、一貫した扱いが可能です。

  5. プログラミング言語のサポート:

    • 多くのプログラミング言語やライブラリが、半開閉区間をデフォルトでサポートしています。例えば、Pythonのリストスライスや、C++の標準ライブラリの範囲は、半開閉区間の形式を採用しています。このため、言語やライブラリの機能を活用する上で半開閉区間を使うのが自然です。

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

数学的な生合成で一貫した扱いとありますが、専門的にはどのような性質が成り立つのでしょうか？

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

  1. 区間の連結性:

    • 2つの半開閉区間 ([a, b)) と ([b, c)) を連結すると、新しい半開閉区間 ([a, c)) を得ます。これにより、連続する区間を簡単に扱うことができます。
    • 例： ([1, 3)) と ([3, 5)) の連結は ([1, 5)) となります。

  2. 区間の分割性:

    • 半開閉区間 ([a, c)) を点 (b) で分割すると、2つの区間 ([a, b)) と ([b, c)) になります。このように、区間を分割する際の扱いがシンプルです。
    • 例： ([2, 7)) を (5) で分割すると ([2, 5)) と ([5, 7)) になります。

  3. 一意性と包含関係:

    • 各点は1つの半開閉区間に一意的に属します。具体的には、点 (x) が区間 ([a, b)) に属するのは (a \leq x < b) の場合のみです。このため、区間の包含関係を判断するのが容易です。
    • 例： (x = 3) は ([1, 5)) に含まれますが、([3, 7)) にも含まれます。

  4. 空集合の扱い:

    • 半開閉区間において、区間 ([a, a)) は空集合となります。これにより、区間のサイズが負になることを避け、理論的な一貫性を保ちます。
    • 例： ([4, 4)) は空集合として扱います。

  5. 順序性と計算の簡便性:

    • 半開閉区間は順序を持っているため、数直線上の位置関係を直感的に理解できます。これにより、範囲の計算や比較が簡単になります。
    • 例： ([2, 5)) と ([5, 8)) の関係は明確に非重複であると分かります。

  6. 測度論との整合性:

    • 測度論（特にルベーグ測度）においても、半開閉区間は重要です。半開閉区間は測度が容易であり、特に区間の長さが (b - a) で計算できるため、実際の応用において便利です。

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

好きな区間発表ドラゴン

![](./nc355601_好きな惣菜発表ドラゴンのドラゴン.png)

RubyKaigi2024参加メモ

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

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

shopifyがすごい

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

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

名前空間とかモジュールの話題が楽しみ

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

人と会えてよかった

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

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

2024年4月での振り返り

近況

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

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

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

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

学生時代の狙い

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

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

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

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

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

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

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

Elmアーキテクチャ

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

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

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

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

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

Reactで実現する話

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

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

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

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

Elmアーキテクチャとエフェクトハンドラ

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

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

やったこと

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

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

参考

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

推し言語機能 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

次は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-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);
    }
  }
}

ベストバイ

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

本棚

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

パソコン

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

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

ルンバ

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

echo dot

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

リュックサック

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

まとめ

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

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

ブログを分割したい

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

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

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

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

契約と型検査

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

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

契約とは何か

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

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

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

  1. 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の間である、みたいなことを検査するのは型検査では大変ですが、契約ならちょちょいのちょいです。

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

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

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

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

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

テストはいらない？

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

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

タスク分解と見積もり

見積もりと目標

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

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

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

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

タスクと期限

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

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

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

見積もりの安定

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

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

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

チームでの仕事

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

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

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

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

動機

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

やったこと

CLI環境のセットアップを簡単にした

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

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

さらに動作確認のためのDockerを用いたテストも書いた

test

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

気になりごと

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

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

arm64のメモ

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

公式ドキュメント

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

ツール

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

  • 既存コンパイラがはくアセンブリを覗く方法
    • アセンブリをはく: gcc -O0 -S
    • ディスアセンブル: otool -vVt
  • デバッガで調査する

感想

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

2023-05振り返り

5月のふりかえり

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

会社

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

週末

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

平日勤務時間外

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

そのほか

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

6月目標

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

生活のこと

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

仕事のこと

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

趣味のこと

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

alcoholタグの運用

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

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

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

まえがき

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

学部の選択

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

化学から数理・計算への興味の転向

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

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

数学・論理学からプログラミング言語理論への転向

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

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

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

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

プログラミング言語理論

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

プログラミング

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

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

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

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

あとがき

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

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としている。

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

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

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

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

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

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

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

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

懸念事項は以下の通り:

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

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

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

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

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

を考える。

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

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

エフェクトハンドラの嬉しさ

エフェクトハンドラが実際的 (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を使う上での義務教育だと感じた。

Linux (gnome) でよくやる設定

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

gnome-terminal でctrl-(shift-)?tabを有効にする

以下を実行

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

capslockで英数変換

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

xkeysnailをsystemdに起動してもらう

課題が2つある:

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

以下のように解決する

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

権限を与える

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

systemdに登録する

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

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

起動時にmozcの日本語入力を有効にする

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

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

軽いドキュメントを印刷するためのツールが欲しい

さくっと書いた文書を印刷したいことがある。ビジネスライクな手紙とか、その日の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

Google Docs APIを利用するのはどうだろうか。APIはあまりリッチではなくて、create, update, pullができるのみ。文書構造の編集はJSONをごりごりいじることで実現する。JSONスキーマが定義されているので、これを見ながら必要な変換を定義すればよい。

テンプレートをGoogle DocsのGUIで作成して、それをAPIでpullした上で、コンテンツを注入したドキュメントをcreateすれば、やりたかったことを実現できそうだ。テンプレートの置き換え箇所の指定方法はどうするのが良いだろうか。

(開始記号)名前(引数リスト)(終了記号)を文書に埋め込む。これがひとかたまりの文書オブジェクトとして認識されることが必要。また、これにスタイリングを適用した場合、埋め込み後もそのスタイリングが保たれるようにする。引数に他の名前が出現しうることに注意する

テンプレに埋め込むテキストを定義する側では、埋め込み内容の定義リストを作成する:

def name(args: list[str]) -> str:
  return f"""\
ここに置換後の文字列を書く。
ここにも埋め込みの出現を許す。
"""

埋め込み処理では、JSON形式のテンプレのすべてのテキストについてマクロ展開をすればよい。

追記: Web技術で「本」が作れる ...

リブロワークスからCSSで組版するノウハウをまとめた本が5/12に出るらしい。途中までをオフィシャルが公開している。Vivliostyleというソフトを使って、MarkdownとCSSで書籍を作るらしい。その手のソフトは他にもあるようで、比較サイトを先の書籍で紹介されていた。

こう思うとmadokoはだいぶ良いものだなと感じる。適用範囲を限定した置換とlatexはなかなか強い。latexとcssを完全に理解すればmadokoが最高かもしれない。

PCの構成メモ

PCを自作して使っているのだけど、どんなパーツを使ったか忘れて後でなにか買い足すときに互換性があるかわからなくてこまる。今回調査してメモしておく。

Ubuntuを入れて使っているけど特に不満はない。不満はないのだが、この間Gentooのことを教えてもらって面白そうなので使ってみようと思っている。

余談だが、このPCは親に就活で必要だろうからといって渡してもらったお金で組んだのだった。自由に使えと言ってもらったが、きっとスーツとかを想定していたのだろう。幸いなことにスーツは買わずに済んでいるので（兄のお下がりがまだ着れる）、ずっと気になっていた自作PCに手を出すのに使ったのだった。少し後ろめたい気持ちがないでもなかったが、Linuxとか触るの楽しいことが分かって仕事でもこの手のものを触りたいと思えたし、面接の話のネタにもなったので結果オーライだろう。学校とか本で学ぶOS周りの技術をそのまま試せるのが僕には嬉しかったのだろう。Windowsでは厳しいし、Macもどこか違っているので。

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"
]
---

好きなPL本

プログラミング言語を勉強するとイディオムとかその言語界隈でのベストプラクティスが学べて良い、みたいなことが巷でよく言われる。確かにそれはそのとおりだとぼくも感じるのだが、雑にチュートリアルをこなしたりするだけでは言語をよく学べないだろうと思うし、良い情報源を見つけることはそんなに簡単ではないと感じている。

僕がこれまで呼んだPL系の本でこれはと思ったものがいくつかあるので紹介する。(注意: 好奇心でアフィリエイトを試しています。アマゾンへのリンクはアフィリエイトを有効にしています。)

どれも勉強になる。文化の共通部分と異なる部分があって楽しい。共通部分はプログラミング全般で大切なのだろうと思うし、異なる部分は言語の活かし方なのだろうと思う。

そういえばこういう本を読んだときと、良いPLの論文を読んだときでは感想が異なる。PLの論文はすごいアイデアを中心として、周辺の概念がうまく回っていく様を見せつけられると感動するのだが、この手の本はもっといろんな機能や習慣がうまく組み合わさる様を見せつけてくれる。甲乙つくものではないだろう。

ちなみに、いま述べた類の感動を与えてくれたのはこれら2つがぱっと思いついた:

1つ目は背景知識がたくさんいる気がするので人にはおすすめしない。2つめは必要な背景知識が少なめなはず。

このように整理すると、local reasoningがPL意味論で大切にしたい中心的な概念に思える。本当だろうか。

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年にやりたいこと

来年の抱負じゃないけど、一息ついたタイミングでやりたいことを整理しておくとどこかのタイミングで役に立つかもしれない。

今年のまとめ

今年は人生で一番プログラミングした気がする。3月の末にmerpayで短期のインターンに参加したのを皮切りに、4月にキャディでのアルバイトをはじめるなど、プログラミングをする機会が増えた一年だった。研究でもインタプリタをゴリゴリ書いてみるなどした。最近は講義で簡単な定理証明支援系の実装に挑戦している。変わり種としては、IBMの方々が講師として開催されているJVM関連のコンパイラ/VMの講義にも参加している。

型システムつきの言語ばかり触っていては視野が狭くなってつまらないだろうと思って意識的にPythonやJS/TS、Racketを使ってみるようにしていた。ライブラリをつなぎ合わせるくらいなら不便がなくてよいのだが、ある程度込み入ってきて、一つのデータ構造を複数のコンポーネントから使うようになると型システムが欲しくなる。クラスや契約である程度カバーできる面はあるが、型システムにまもってもらう安心感は得られない。抽象化をしきれないというか、しても心のどこかで実装を意識しながらデバッグしたりすることになるし、そもそも抽象化を書きにくかったりする。

なんにしてもプログラムをゴリゴリ書く能力はついたと思う。今年はとにかく動くものを作る系のコーディング技術を身につけた一年だった。年の最後にPythonで言語処理系を実装するとき、クラスを使わずdictとlistだけでどこまでいけるかやってみたのだが、型システム（依存型を含むので、いわゆるeval的な処理も必要）の実装で力尽きた。その経験からやはり型は必要だと思い直したのであった。dataclassを使って一日かけて書き直したらまともに実装できたので感動している。もはやC++とかで書いた方がいい気がするが。

3月くらいまではあまり実装をする人ではなかった。実装に手を出し始めたのは最近の話。プログラミング言語の理論（型システムとか抽象機械とか意味論とか）ばかり見ていて論文やドキュメントを読むのが何より楽しいと思う人だった。論文を書く中で言語の使い手の気持ちがあまりわからなくなったり、論文を読んでいても、プログラマの幸せにつながる未来を想像できない研究をみたりした。

プログラミング言語や処理系はプログラムや表現したい対象があって初めて良し悪しが見えてくるものだと思う。そういうプログラミング言語の研究の動機の部分をもっと知りたくて実装に手を出してみた。結果は上々で、今の僕は去年よりもプログラミング言語やプログラミングのことが好きな自信があるし、そういう話をして楽しい人間に近づけたと思う。丸くなってしまいはしたかもしれないが。

2023年の話

インフラっぽいことを型システムやコンパイラの表現力/処理でまっとうに行いやすいようなしくみを考えて、実現に向けた方針くらいを打ち立てたい。インフラの勉強とRust, Scala, Haskell（適切なものを一つ）の業務で自在に使えるくらいの知識が必要だろう。

DSLやconfigでインフラ/ミドルウェアを構成するのが最近流行っているようだが、そういうのを勉強するのはつらい。あまり長持ちする技術ではないだろうし、知識としての深みも出にくそうな印象をうける。ライブラリとして提供してもらって他の便利機能はプログラミング言語に移譲するのがよいだろう。適切な言語であれば、ライブラリ特有の問題を言語の機能で扱いやすくできるはずだ。僕がやりたいのは、そのやさしく扱いやすくする部分。

その他にも全然知らない世界（技術的）をみたいし、文化的な面でも知らないところに飛び込むつもりだ。今年はそういうことをしやすい一年だと思う。楽しい一年になりそうだ。

まずは修士の研究をやろう。

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に置いてある。

rg版はこちら

#!/bin/bash

if [ $# -ne 2 ]; then
  echo "Arity mismatch. want: 2, actual: $#" 1>&2
  exit 1
fi

rg -l "$1" | xargs sed -i -E "s/$1/$2/g"

読書メモ: Go言語による並行処理

ちゃんと読もうと思ったときのための自分向けのメモ。

  • プログラミング技法を学びたいなら3,4章
  • Golangの復習をしたいなら3章
  • Golangのランタイムを覗きたいなら6章を読むと良さそう。

ざっと見た感じ、だいぶ信用して良さそうに思える。積極的に読んでいこう。

Hugoでページネーションを無効化

このコミットでトップページのページネーションを無効化した。やったことは以下の通り。

  • .Pagenatorを使わないようにする
  • 対象のポストを全件表示するようにする
  • ページネータを消す

最初の一つがpage/2/みたいなページ生成を抑止して、次の２つがトップページの見た目を変える。ページネータを消せば自然に.Pagenatorを使わないようになるはずだ。

参考ドキュメント

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の切り替えを行えばよいが、毎回操作するのは面倒だ。デフォルトで日本語モードにすれば良くて、その実現方法を冒頭に載せた。

今年追加されたデフォルトエンジンを指定するオプションを用いて日本語入力をデフォルトにしている。環境によっては設定ファイルを置くべきディレクトリが違うとか、既存の設定とマージする必要があるみたいなことはあるかもしれない。

参考

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を用いた。

TypeScriptに関して

JSではなくTSを使ったのは、僕が常々型がほしいと思っていて、仕事でも型を大事にしたプログラミングをしたいから。TypeScriptはほとんど初めて書いた。型システム（といってよいのだろうか）にはクセがあるが、型システムがいてくれてよかったと思う機会が何度かあった。これが静的型付言語を用いたプログラミング体験で最良だとは思わないけど、なかなか良かった。

良かった:

  • 型としての文字列リテラル
  • ユニオン型
  • JSONとの連携

enumというか、代数的データ型っぽくオブジェクトを使える。網羅性検査やコード補完もしっかり効いて快適だった。これはTSの特権だと思うのだが、JSONとの親和性がすごく良かった。

良くない:

  • 関数の型を書きにくい
  • ライブラリ関数の型が調べにくい、使いにくい
  • 型推論の結果が欲しい型になかなかならない
  • any

これらの辛さの原因は、僕の文化への慣れと、構造的部分型と型エイリアスを多用する方針のどちらかだろう。関数の型が書きにくいのは慣れの問題だろう。Haskell基準で語っているので理想が高いのかもしれない。型が調べにくいのは、なれとJS向けドキュメントによる検索汚染が原因か。Reactみたいなライブラリの型を調べる際にはどこをみるべきなんだろうか。

型推論は型システムの方針の問題だろう。たとえばオブジェクトを返す関数を書いたとき、気持ちとしてはすでに定義してある型エイリアスを提案してほしいのだが、実際にはレコード型みたいな形の型が推論結果としてフィードバックされる。主要な型は確かにそのレコード型みたいな型だろうからその挙動は理解できるし、まっとうだと思いはする。トップレベルの関数定義では、型アノテーションを書いてから本体を定義するのがやはり良いのだろう。書きはじめのころ型アノテーションの書き方がわからなくて、VSCodeに書いてもらおうとしたときにこの不満が出たのだったと思う。

anyは本当に良くない。型をつけたプログラムをデバッグするときは、強く型がついた前提で考えるので、any周りで前提が崩れて状況の認識に失敗する。anyを書かないように頑張ることが必要だ。デバッグの際にはanyの可能性を忘れず、JSの気持ちで考えるのが良いのだろうか？それでは嬉しさ半減な気がするのだが。。。

不満が多くなってしまったが、TypeScriptはそれなりに好きだと思う。

Reactに関して

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の変数キャプチャを勉強する。

追記: 最初、変数キャプチャではなくメモリモデルを勉強しようとしていた。勉強してみて、求めている概念では無いことに気がついたのでタイトルなどを修正した。メモリモデル自体は知れて良かった。非同期処理へのコンパイラ最適化が及ぼす影響を知れる（公式サイト におせわになった）。変数キャプチャの説明はこれ を読む。３年前に僕と同じことを思ったひとがいたようだ。

Overview

クロージャを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文のスコープとクロージャの変数束縛だ。

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でクリップボードを使う

NeoVim でクリップボードを使う

TL;DR;

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 [email protected]

該当コミット：関係無い変更も同時にコミットしてる...。

複数の 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に再代入することで所望の追加を実現できる。

これはこれできれいだと思うけど、はじめのアイデアも悪くない気がしてしまう。きっと修行が足りないのだろう。