"alcohol"

2025-01-13

昨日は友達とキリンビール工場に行ってきた。500円のツアーがあってビール作りの概要を教えてもらいつつビールを飲ませてもらえる。だいぶ楽しかった。あの体験は優しさで成立していると思う。

原料となる麦やホップを食べさせてもらえたほか、ビール製造の中間生成物である麦汁の飲み比べをさせてもらえた。何より説明してくれるお姉さんがビール好きで、1つ質問すると厳選した3つを返してくれるのが良かった。一緒に飲んで欲しい。飲ませてもらったビールもめちゃくちゃおいしいし。併設されているレストランに行けていない（リサーチ不足でご飯を食べてから行ってしまった）のと、他にも見学コースがあるみたいなのでまた行きたい。

ホップを使ったリンスを買って使ってみたら、髪からフルーティ系なビールの匂いがして最高。

AIに仕事を奪われることはないだろう。とはいえ単に作業をするだけの労働はAIに奪われる。コードを単に書くのは作業であって、仕様からコードを生み出すだけならAIでやった方が早いし（今の相場なら）安いから。

とはいえそんな単純作業が仕事であることはなくて、将来のこととか仕様の考慮に入っていなかったことをコードを書きながら調整して主体として責任を持って成果を出すことは、社会がまだAIに対して認めていないように感じる。

誰もが優秀な部下を持つようになったが、人々は誰かに責任を持った主張をして欲しくいのだろう。ポジションをとって主張をし、ダメだったときは失落したり挽回することを人格に求めている。信頼をして仕事を任せる相手は人間じゃないと嫌だと社会が思っている。

そういうわけで人間は労働力としての生成AIを手に入れただけであって、人間社会で主体として認められたあらたな人格を手に入れたわけではない（今のところは）。成果を出すためには社会が理解できるポジションを取ることが必要で、そのロールモデルの振る舞いとして社会と交流しないといけない。どんな振る舞いをするのが良いか決めるために生成AIを駆使する仕事の仕方が増えるだろう。ロールモデルには矛盾なくとりうるアトミックな行動があって（思想とか哲学みたいなもの）、それを組み合わせることでその人らしい振る舞いが形成される。思想とか哲学とかに一貫性がないと社会から信頼してもらえない。一方で外部から同じ要求がなん度もくることはないため、それに応じた異なる振る舞いをする必要はある。思想や哲学から外部刺激に対して振る舞うことにはエネルギーとか思考とかが必要で面倒だから生成AIを使うと便利だろう。

これはプログラミングにも応用できる。アプリケーションのコアなロジックのインターフェースは綺麗に設計されてクライアントから受け入れてもらう必要がある。そこがブレると利用するのがそもそも大変だし、見出した価値がすぐに失われてしまうだろう。一方で、それを活用して振る舞いを追加したり修正することは生成AIがこなすだけで十分なのではないだろうか。振る舞いを追加することは、そのアプリケーションのコアな部分のインターフェースと世の中によく知られた技術要素のインターフェースを組み合わせて表現できるだろう。

外部からの要求に応答して振る舞いをしたりインターフェースを利用して新たな機能を提供する際に、コアな思想を見直してアップデートすることもあるだろう。とっているポジションをちょっと変えるということ。使う側からすると理解の仕方をちょっと変えないといけないのでこの変更が気に食わなかったり理解できなかったりすると嫌な感じがする。変化の速度が早すぎて理解が追いつかないとたとえ良い変化であったとしてもアンチになってしまい信頼をなくすことに繋がる。そのため人間に直接理解されるインターフェースは人間に合わせた進化をしないと社会に適合できなず、市民権を失う。

したがって生成AIはインターフェースを提供するソフトウェアエンジニアの職業を奪うことはない。一方でインターフェース設計に関与しない、定義されたインターフェースの中だけで作業をして、他人と相互作用をするインターフェースを定義しないエンジニアリングは生成AIのコストに負けて自動化されるだろう。

次に、他人と相互作用するインターフェースのあり方が変化するかが問題になる。これまで公開されて使われていたようなインターフェースは今後も必要だろうか。インターフェースを解釈するのが生成AIだけになれば、その変化が早くても理解が追いつくためわざわざポジションをとったり人間の理解速度に変化の速度に合わせる必要がなくなる。これは作り上げるものの抽象度の違いに依存するだろう。何かを作り上げたかったらその一段下の抽象度の言葉で構成を説明してほしい。妥当性を検証するために。そこから下は信じることにして（信じられる何らかの根拠を持つことになる、ここも何か困難があるかも、今は著名なOSSだからokとか言って信用することにしている）、欲しいものの一段下のレイヤで自分で納得がいけば良いものであると判断する。

そして、人間の思考とか議論のレイヤは高々10とかにおさまっており、それが生成AIの登場で変わるとも思わない。なのでインターフェースを人間が作ってポジションをとる必要性も今後変わらないと思う。根拠はなくて直感だし、多分僕の願望も入っっている。

良いインターフェースを定めるために、鍛錬を積む必要はあり、それは生成AIによって取って代わられる仕事でなされることが多い。生成AIを使って仕事をやる先端のインターフェース提供者と、そこから学べない後進が場所によっては生成AIがやる仕事をするローカライズされたインターフェースの提供者が並行して存在する世界になるだろう（生成AIに限らずこの状況はあるだろうが）。

2025-01-02

せいろを買った。18cmの竹でできたやつ 店が中華街にあって賑わっていた。夜に行ったのははじめてで、明かりがきれいで印象的だった。

学生時代の先生がお薦めしていたのと、帰省して兄が気になっていそうだったので試すことに。餃子を包んで蒸してみた。焼くのとは違って記事がつやつやした感じになるのと小麦の味が違って感じた。今度は厚めの生地で包んで試したい。白菜やもやしをまとめて蒸してもみようと思う。

2024-12-25

関数の引数はそれぞれ何で、どんな性質を期待するかや、そのほかの事前条件を満たした上でこの関数を呼び出すと、その結果としてどんな返り値が得られてそれ以外にどんな副作用があるかを表明するのが関数の契約。文章を用いるのが簡単だし、伝えやすくするには図を用いても良いし、型とかバリデーションのための式で表現しても良い。何にしても契約を表明すると楽しくプログラミングできる。

この関数の呼び出し側はどんなふうにこの関数を使って処理を実現するだろうかとか、この関数を実装するときはどんなふうに作ろうかと考えるのがまず楽しい。みんなが幸せになれる契約をデザインするのが楽しい。ソフトウェアのテストは契約を守っていることを検証することだと思う。型を用いた表現は契約の表明で、型検査が検証（それも厳密な）である。

このように良い契約をデザインするのがプログラミングでまずやることだと思う。その次に自動で検証するためのコードを書くのがTDDの人だし、関数型の怖い人は型で契約を表現しようとするかもしれない。そのためにすごい表現力を持つ型システムを考えて勉強して使う印象がある。

TDDで最初から完成版のテストを書かないことからわかるように、契約を最初から詳細まで書く必要はない。そんな契約を満たす実装を書けるだろうかと思うこともある。なので最初はふんわり「ユーザの情報を返すAPI」とか決めておいて、IDが欲しいとか、シャーディングしてるから作成日時も欲しい、みたいな事前要件を足したり、ユーザ情報全部返すのはきついし呼び出しがわも幸せじゃないから、名前とメルアドだけ返すことにする、みたいな調整も入るだろう。課金が滞っているユーザに対しては普通の結果は返さない、代わりにエラーを返す、みたいな変更も実装したり呼び出しているうちにしたくなるはず。

結局のところ普通のプログラミングをしようと言っているだけなのだが、僕が強調したいのは契約と実装を分けて考えようということ。契約が先にあってそれに実装を合わせる（合ってない状態はバグってる状態）考え方でいたいし、僕と契約を共有する人には（その共有する契約のレイヤで）いて欲しいと思う。

僕はmac osのコードがどうなっているかを気にすることはなくて、普通にパソコンが動けば満足するし、実際動いているので不満はない。キーボード叩いたら文字が出るという契約を守ってくれている。でもosのapiを叩く友達はそもそもドキュメントが公開されてなくて辛い、みたいなことを言っていた。このように、自分が関心のあるレイヤの契約が問題になるのだと思う。

契約はプログラミングの細かいレベルだと変数の名前とか、改行の置き方によって表明されるもので、大きいレベルだとサービスやロールの責務として表現されると思う。サービスのAPIは代表的な契約だと思う。APIという言葉は契約と同じような意味だと思うけど、エンドポイントみたいな意味でも使われているし責務みたいな概念には適用されないと思っていて使わない。

僕たちが欲しいものは何かを表明しよう、というのが契約を表明しようということだと言い換えられる。使う側からしたらその実現方法は関係ないし、提供する側からしたら契約さえ満たせば何をやっても良い。 getterとsetterを提供するからと言ってそういうフィールドをよく知られた方法で提供しないといけないわけではないし、バッファリングとか遅延実行をしても良い。

未定義な状況とか意図しない状況はある。今と昔では状況が変わって、その頃は妥当に思えた契約が時代に合わなくなることもある。契約がないと実装が良くないで話が終わってしまうが、契約があれば仮定が違ったのだと結論づけられる。人の記憶があればその人の心に契約があって仮定が違ったと判断できるだろう。記憶を失ったりその人が失われたりする場合は契約を表明しておくべきだろう。

型はデータ構造やその不変条件を表現したりそれらに名前をつけることで、契約を表現する。そして型を用いて表明された契約は普通型検査によって契約が満たされていることを検証する。正しい場合には正しいと判定するし、正しくない場合には正しくないと判定する。さらに、ある程度ちゃんとした型検査器は、どのように契約が満たされなかったかを説明してくれる。

テストは契約を検証するためのコードで、そのテストが契約のどんな部分を検証するか、テストケースの名前として表明される。その表明を満たすようにテストコードが実装されて、テストランナーに呼ばれる。契約のどんな側面をそれぞれのテストケースで検証するか、検証すると幸せか（誰にとって？）を決めるのはテスト実装者のスキルに依存するだろう。契約の中で脆いところを普通は検証するのだろう。明らかに正しそうなやつは手を抜いてしまえるはず。

バリデーションも契約を表現する手段の一つ。契約を検証処理として実装して表明するのがバリデーション。型と同じようにすべての実行について契約が満たされるかを検証する。一方でテストと同じように実際に動くものに対して検証を行う。

実際に動かして試すのは何だろう。契約とはあまり関係なさそう。実装したやつがどんな感じになってるか微妙なので試して動作を観察するのがとりあえず動かしてみる目的。これは脇道だったな。ただし、あまりによくわからなくなっているときは分割統治をするときだと思う。自分の手の中にある対象をコンポーネントに分割して、それぞれに対して契約をデザインする。その契約を満たすように実装しつつ、その契約を期待して組み合わせて元々の目的を達成すれば良い。わからない部分が新しい契約の内側にはいれば小さくなった簡単な契約を満たすことに問題は帰着できたし、それらの契約を組み合わせることに課題があるなら詳細を忘れて便利な道具を手に入れられたのだからやはり問題は簡単になっているはず。うまく契約を設計することが難しいなら、それは楽しいから問題ない。ずっと取り組んでいればいい。

何にしても契約を表明することが何より先にくる。これだけでプログラミングが楽しくなる。その後に型、テスト、バリデーションを書いたり実装をしたりする。

そういう考え方が how to design programsにデザインレシピとして書いてあるのでよかったら読んでみてください。

プログラミング言語はこの辺りが優秀で、型システムの研究とかで契約を表明して保証する方法を検討しているし実際に生かされている。なので言語に守られているうちは割と安心できる。あとは怠慢にならなければいいだけ。

プログラミング言語に閉じられなくなるとき、例えばWeb APIを提供するときは急に難易度が上がる。Web APIでも契約を表明して検証するためにスキーマ駆動開発がある。契約を書き下すことを支援するのはもちろん、型とかバリデーションで表明することも支援する。テストツールの支援もある。

僕たちが求めているのは以下である。

  • 契約を表明すること
  • 契約を洗練すること
  • 契約を犯せないようにすること
  • 契約を犯しかけたらなるはやで誰かに教えてほしい
  • これらを簡単に実現できること

最初のやつは設計しようぜ！という話。次が設計技法とか良い設計みたいな話。三つ目は型とかバリデーション、テストの話。次もそう。最後のやつはそれら全てを支援するエンジニアリングの話。

契約の話をしたのでパラダイムの話をしたい。オブジェクト指向と普通のやつの話。どっちでもいいけど、契約を表明しやすいパラダイムが良いと思う。

オブジェクト指向な考え方だと、内部状態を持つオブジェクトがメソッドを受信してその結果内部状態を変えたり返信したりする。そういうふうに契約を表明して守っていくならオブジェクト指向を使えばいい。

関数型みたいな普通のやつは、仮定が与えられた状況で関数を呼ぶと結果を出す。そういう契約の書き方をするなら関数型みたいに書けばいい。

どちらも相互に変換可能だから力まず表現しやすい言葉遣いを使えば良いだろうと思う。

割と思いの丈をダンプした。これは就職したからできたことのように思う。学生の頃に培った理想が現実世界では必ずしも簡単に実現しないことを体験できた。自明だと思っていた領域の非自明な部分に気がついて思うところが出てきた。

プログラミングの楽しいところは、ロールを分けてうまく契約群を設計することにあると思う。フレームワークを作るのはそういう契約の集まりを定義することだから楽しい。一方でフレームワークを使うと契約を設計する機会を奪われる分楽しくないかもしれない。

その分他のレイヤに注力すればいいのだろうが。

自分が自由に設計したいレイヤで他人に契約を決められるとストレスだろう。本当につまらない。反対に自分が関心なくて誰かにうまくやって欲しいときには良い契約を強い人に決めて欲しいと思う。そういうレイヤを担当するフレームワークを使って欲しいし、技術を選定したい。

アーキテクチャ設計についても言及できそう。アーキテクチャは中長期的には変遷するものだが、短期的には変わらない。アーキテクチャに乗っかってここのコンポーネントを作り込む。ここのコンポーネントをストレスなく作り込みやすくするアーキテクチャが良いアーキテクチャなのだろう。

2024-12-22

週末はずっと漫画を読んでいました。荻窪に住んでいた頃に24時までやっていた本屋さんで買ったり試し読みした続きを再開しました。あかね噺と地政のあれ（八田が主人公のやつ）です。あかね噺は3巻まで物理本で買っていたので続きも物理で買いました。どっちも面白い。

たまに（特に冬は）漫画とかアニメとか小説に浸かりたくなる。今週末もそれなのでした。浸かると心身ともに不健康な感じになりがちだけど、そろそろ慣れてきて運動と食事と入浴をちゃんとやったので成長。機嫌が良いので飲酒もしている八田の方がまだまだ残っているので日記はこれくらいにする。

2024-11-20

  • proto2cliを実装する
    • やった
    • 名前を決める：connectはブラウザやgRPCと互換性のあるAPIを提供するのに必要なボイラープレートが必要なのを軽減してくれるやつ。
      • これはそれらにCLIをインターフェースとして加える。つまりローカルから、サーバを立てる事なく実行できるようにする。そういう立ち位置がいい。単にインターフェースを一個加えるだけ。実装はできるだけシェアしたい。
      • まずはconnectを採用するアプリケーションを一個用意して、それにCLIを入れる。ここで上手い入れ方を探る
      • 次にその入れる作業を自動化する。そのためのCLIがproto2cli
    • サブコマンドでサービス、位置引数でメソッド、フラグ引数(-d)でリクエストメッセージを受け取る。
      • サブコマンドと位置引数は最初は特に区別しなくていいか。 cmd <service> <method> -d <request message json> の形式で呼び出すだけ。
      • CLIへの入力はそのままサービス名、メソッド名、リクエストメッセージがそれぞれbyte列かstringのどちらかで得られる。それらをなんとかするのは一旦別のコンポーネントの役割にしよう
      • ここまでは普通にflagsパッケージとかを使うだけでいける
    • 次にリクエストメッセージのデコードを自動化する。
      • func unmarshalRPC(service, method, req string) (MessageInterface, error)
        • 対応する型のunmarshellerへのディスパッチとその呼び出しが責務
      • dispatchUnMarshelelr(service, method string) (func(byte[], MessageInterface) error, error)
        • ディスパッチだけでも良さそう
    • 次に、サービスの呼び出しを行う
      • connect サーバをclient経由で呼び出す
      • 単にサービスを呼び出す
        • インターセプタを通過できない、特にproto validateを通せない
      • インターセプタとサービスを合成する
        • できればhttpサーバの仕組みに乗っかりたい
        • でも無理がありそう、intercepter (unaryfunc) を受け入れてデコレートする感じにしそう

以下のようなprotoスキーマを定義する。

syntax = "proto3";

package nfurudono.sample.v1;

service SampleService {
  rpc Say(SayRequest) returns (SayResponse) {}
}

// SayRequest is a single-sentence request.
message SayRequest {
  string sentence = 1;
}

// SayResponse is a single-sentence response.
message SayResponse {
  string sentence = 1;
  bool dry_run = 2;
}

こんな定義があるときに

$ ./sample say --sentence "hello world" --dryrun
sentence: "I will say: hello world"

みたいなやりとりを定義するためのCLIテンプレート生成ツールを作る。あくまでテンプレートなので、生成ツールではインターフェースとかグルーコードだけ提供して、ユーザは以下のようなコードを書くことになる。

  • connectとかでサービスとサーバの起動を定義してmainからいい感じに呼ぶようにすると、gRPCサーバがたつのに対して、
  • CLIテンプレート作成ツールでサービスとCLIコマンドの呼び出しを定義してmainからいい感じに呼ぶようにすると、CLIから実行できる

package service

import (
	"fmt"
	
  sample "github.com/nfurudono/gen/go/sample"
)

type SampleImpl struct {}
// sample.SampleServiceはprotocとかが生成するようなinterface。gRPCとかconnectとかで使われているようなやつ。
var _ sample.SampleService = &NewSampleImpl()

func NewSampleImpl() { return SampleImple{} }

func (* SampleImpl) Say(ctx *context.Context, req *connect.Request[samplev1.SayRequest]) (*connect.Response[samplev1.Response], error) {
	s := req.GetSentence()
	d := req.GetDryRun()
	if d {
		return fmt.Sprintf("I will say: %s", s), nil
	}
	return fmt.Sprintf("%s!!", s), nil
}


package main

import (
	slog
	
	tool "github.com/naoyafurudono/good-tool"
	"github.com/naoyafurudono/sample-cli/service"
)

func main() {
	s := service.NewSampleImpl()
	// NewCLI()の結果（CLI）はサービスを登録される。
	// サービスを保持するCLIはサービスが契約するrpc（名前、入力、出力）を知っている。
	// これらはprotoの仕組みで生成される。protovalidateなどのプラグインもそのレイヤで対応できるはず。
	cli := tool.NewCLI().AddService(s)  // このあたりのインターフェースはもうちょい考えても良いかも？
	// Runがコマンドライン引数を読んで以下を半ドアリングする
	//   - 呼び出すrpcの判定（ルーティング）、サブコマンドの名前が対応する
	//   - rpcに渡す入力messageのデコード、サブコマンドへのフラグ引数が対応する
	//   - rpcの出力メッセージやエラー内容の出力、コマンドの標準出力、標準エラー出力、コマンドのステータスコードの出しわけが対応する
	if err := cli.Run(); err != nil {
		slog.Fatalf("unexpected input: %w", err)  // 予期しないサブコマンドが来たらエラーを返すのもまた一興かな。
	}
}

便利じゃない？

2024-11-09

ぼくが酒を飲みながら書いた文章がLLMの学習に使われて、お固い用途に使われると思ったら人生だいぶ楽しい。

2024-10-28

昔は親の顔より見た lambda をこの頃は全然見ていないしタイプしてもいない。寂しいねえ。クロージャをぼちぼち使うのだけど、評価規則や型規則とにらめっこする時間は完全に失ってしまった。

2024-10-26

  • aboutページの収取をするプラグインを実装して組み込んだ。あとはそれをいい感じに表示する必要がある
  • 今度人の結婚式に出るので身だしなみとか常識を身につける・髪切るとか服を用意する計画を立てる
    • 受付やるらしいのでちゃんとした方が良さそう
    • 礼服着れるか確認しておくか
  • helm完全に理解する。リリースとか意味わからん。installって何？kubectl applyとの関係は？

2024-10-17

イマジナリーの3巻を読んでいる。良い。あんじゅうも続きが欲しい。

プログラミングについて語りたいので一家言持とうと思いました。

陣屋を語彙として獲得した。Wikipediaを読んで最初に浮かんだのは高山の陣屋だった。古い街並みにある奉行所か何かだったと記憶している。と思って調べたら聴きなれない言葉で表現されていた https://www.hidatakayama.or.jp/spot/detail_1106.html 。

2024-10-15

見出しにidを振るようにした。 idが振られている要素に対するCSSとクリックでリンクをクリップボードに貼り付ける実装と相まっていい感じ。やったね。パーマリンクは意味のある単位ごとに簡単に取れるべきだと信仰している。なのでハッピー。

今日はリンクをたくさん取れるようにセクション多めな日記にしてみる。

中目黒のめちゃでかポークステーキを出しているお店に会社の人たちと行ってきた。案外いけたがやはりデカかった。あと見せてもらったマジックがすごかった。

同僚とお昼で料理得意そうと言われて意外だった。料理のことは好きだけど。

2024-10-11

昨日は健康診断だった。身長は縮み（多分測定時の姿勢の問題）、体重はちょっと増え、腹囲は3cm増加、視力は片方0.3落ちるという散々な結果だった。体重と腹囲は運動しようねと思う。視力も運動の頻度を上げて遠くを見る時間を増やすと良いかな。

明日はイベントが何個かある上に明後日は5時に家を出て山に行かないといけないので試される。

2024-10-08

レバレッジの効いた仕事をしたいと思う。教育とか仕組みを作ることは、それが使われ続ける限り効果を発揮するのでレバレッジが効くだろう。やった努力の量に対して（十分な時間が経つと）線形よりでかいオーダーの効果が得られるということ。

教育は曖昧なものだしぼくはあまり信じていない（少なくともぼくにはできない）ので、自分が取れる手段ではない。となると仕組みを作るのが良いかなと思える。いい仕組みを作って、以降みんながそれに乗っかるとか、自分の貢献をめちゃデカにすることがレバレッジの効く仕事かな。

良いエディタを作ってシェアするのはレバレッジの効いたことだよね。認証とかフレームワークみたいな入れたらその中で暮らすことになるものは、使っている間は呼吸するだけでそれらの恩恵に預かるのでレバレッジが効いてる。家賃を抑えるのもそう。住んでるだけで支出が減るので。

家賃が減る話はそれなりに面白い。住居に住んで得る便益は家賃と相関するのが、それを単に減らすだけでレバレッジが効いていそうと思える（側面がある）。もちろん1000億円持ってて特に大志がない人が月5万円のアパートに住むのは意味わからないけど、特にでかい貯蓄があるわけでもない1000万円の年収の人が20万円のアパートから10万円のそれに引っ越すなら、レバレッジが効いた節約の仕方をしたねえと思う。

資本が1000あるときに10から12を生み出すプランを考えだしても1000の一部を使って1002にすることしかできなくて嬉しくないが、 100を110にする方法があれば、1000から1100にできる。割合としては前者の方がでかいが、得られる利益は後者がでかい。資本をより有効活用したのが後者だから後者の方が利益がでかいのだ。レバレッジが効いているのは後者な気がする。

スケールする方法だとなお良いだろう。10から12を生み出すプランは実は一捻りすると1000から1200を生み出すことができるのなら最高だ。レバレッジを考える上では、利率も大事かもしれないが、それ以上にでかい入力に対してスケールすることがより重要なのだろう。狙っていたわけではないが、冒頭の段落で （十分に時間が経つと） と書いていた。あれは大事なポイントであるが含みが結論とは違う。十分な時間が経っても、得られる効果が線形を保つことが求められるのではないだろうか。

2024-09-18

日記からtodo一覧を抽出して専用ページにtodoアイテムとその文脈を列挙する機能を実装した。この手の機能はtodoに限らず文章で考えや記録をつける人を幸せにするだろう。

例えば、読書メモをする場合、ぼくはそれを日記に書きたい。でもある本についての読書メモはまとめてみたい気持ちもある。そんなときに、その本に関する記述をまとめてみる機能があると幸せなはずだ。あくまでメモなので、その内容はその日の自分に依存する主張を持つ。なので、日記としての文脈は必要なはず。日記はぼくの考えたこととか記録を時系列でまとめたものであって、ぼくにまつわるいろんなものは時系列に沿って進んでいく。考えて、書くのも時間的な変化とともに進めていくものだし。なので書き出すフォーマットは日記が良い。楽だし、情報が失われにくそうなので。

その反面、読み方によっては他のアスペクトで抽出したりまとめたいこともある。それは日記を切りはりしたものとしてある程度表現できるはず。普通にぼくたちがあるアスペクトでまとまった記述をするときには、時間をかけて一つの側面から解釈しやすいようにする。文書を作成するときは反復して改善するものだし、推敲をするものでもある。では推敲をしない文書作成は、あるテーマについて日記を切り貼りしたものなのではないだろうか。

その切りはりをやるツールとしてtodo一覧の抽出みたいな機能を使えると思う。

セクションの単位でアスペクトを宣言できると良いだろうと思っている。あるいはAIでアスペクトを後付けしてもいいかもしれない。でも、どちらかというと、ぼくは普段の日記を書くときに後から見返す解釈を意識してかけたら楽しいだろうと思う。なのでアスペクトは明示的に日記を書く人が付けられるといいと思う。ふとアスペクトを思いついて、これまでの自分はどう思ってたんだっけと気になることもある。そのときには確かにAIに全部みていい感じにタグ付けしてほしい。

あと、今はunifiedを使って実装しているけど、pandocに移行しても楽しそう。型が辛いと思っているので。pandocはhaskell製なので型が弱くて文句を言いたくなることはないはず。

2024-09-13

今日は（昨日は）会社の人とunrailedをやった。はじめてちゃんと一緒にゲームをしたのだけど楽しかった。またやりたいな。

明日は（今日は）会社で型の話をちょっとするので準備しなきゃ。

2024-06-25

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

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

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

List

クラシックは全然聴かないのだけど、このリストのアルバムだけはたまに聴くし割と好き。不安定なのに気持ち良い感じというか、そこで音入るの！？でも良いな、みたいなところが好き。

「多崎つくると…」を読んで、その主人公が大変な時期をやり過ごした後にその友達に聴かされるのがリストの何かでせっかくだからと思って僕も聴いてみたのだった。彼とは多分同じ学校出身なので変な愛着がありそう。

高校生の頃エヴァのQがやっていて、それがなんだか刺さったのだった。 CDも買って鷺巣詩郎作曲の劇中曲を大学受験にかけてWalkmanに入れてずっと聴いていた。あのCDもたまに不安定な音楽が入っていた気がしていて、そういうのに差し掛かるとゾクゾクしたような気がする。そういえば勉強しながら音楽聴いたことはあったが音楽聴きながらプログラミングしたことはないな。明日やってみるか？

別に捗るわけではなくて、勉強が嫌すぎたのでせめてもの楽しみとして音楽を聴いて気を紛らわせないと勉強なんてできなかったから聴いていたのだが。それに対してプログラミングは普通に楽しいので（というか楽しくないと思うタイミングにはしない）音楽がなくてもよかったのだろうな。

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 これはその逆かな。

2024-05-23

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

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

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

2024-05-22

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

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

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

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

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

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

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

2024-05-12

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

2024年4月での振り返り

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

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

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

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

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

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

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

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

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

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

2024-04-21

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

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

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

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

2024-04-20

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

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

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

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

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

2024-04-13

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

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

2024-03-20

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

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

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

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

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

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-02-26

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

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

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

2024-02-18

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

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

2024-02-10

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

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

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

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

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

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

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

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

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

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

2023-11-22

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

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

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

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

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

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

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

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

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

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

2023-11-16

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

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

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

2023-10-29

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

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

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

飽きたのでこの辺で。

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

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

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

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

契約と型検査

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

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

契約 (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を返さないことを型検査では保証できます。

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

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

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

タスク分解と見積もり

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

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

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

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

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

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

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

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

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

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

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

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

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

2023-08-31

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

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

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

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

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

2023-08-04

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

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

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

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

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

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

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

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

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

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

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

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-06-16

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

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

2023-06-06

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

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

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

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

今日はいい日。

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-17

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

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

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

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

2023-05-07

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

2023-04-28

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

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

alcoholタグの運用

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

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

2023-04-27

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

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

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

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

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

2023-04-03

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

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

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

2023-03-19

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

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

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

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

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

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