"alcohol"

2024-11-20

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

syntax = "proto3";

package nfurudono.sample.v1;

service SamplService {
  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;
}

こんな定義があるときに

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

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

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

package service

improt (
	"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 inpu: %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-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-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時間ほど新幹線に乗り新山口に辿り着いた。新山口で熊本から車を運転してきてくれたもう一人と合流して、あらかじめ目星をつけておいた牧場併設のステーキハウスで早めの昼食を頂いた。

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

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

秋芳洞の入口まで帰ってから、そのあたりで売っているアイス(炭のはいった、鮮やかなアスファルトの色をしていた)を食べて、口や手を汚してから翌日訪れる秋吉台を見に行った。秋吉台の展望台の看板で知ったのだが、秋吉台は割と下の方にある鍾乳洞で、もっと上にも2つほど名前のついた、観光で入れる鍾乳洞があるらしい。そこからは車でカルストロードを抜けつつ(景色がとてもよかった)なんとか弁財天という、青くてきれいな泉を見に行った。泉では軟水を汲めて、そこそこのおいしさだった。水を汲むためのペットボトルを開けるのに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を買ってから飛躍的に音楽を聞くのが楽しくなった。幸いなことにヘッドホンはまだこれしか買っていない。初手でいいものを買う戦略が功を奏した。昨日くらいから電車通勤で音楽を聞くことに良さを見出してしまい、ワイヤレスでノイキャンのついたいいヘッドホンが欲しくなってしまった。

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

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

2023-04-03

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

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

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

2023-03-19

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

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

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

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

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

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