Lycolog

去る2024年11月7日 14時55分、ソードアート・オンラインがクリアされた。しかし残念ながら現実世界ではVRMMOやARMMOが普及することはなく、XR系は風前の灯状態だ。

前置きはさておき、今日は紙のカレンダーを買った。小型の卓上カレンダーだ。たった660円で、たぶんそこら辺のカレンダーアプリより安いと思う。

表面は普通のカレンダーで、裏面はメモが書けるように行状になっている。西暦と和暦が両方見れるのは地味に便利だ。毎回検索しなくてもよい。他にも六曜や二十四節気に、月相も書かれていて地味に便利だし、前後の月が一目で見れるのもいい。

買った理由としては机の前にいるときにパッと今月の日程を見るのに使いたかったからだ。一々スマホを開いてカレンダーアプリを表示するのは面倒だし、PCで見るのもやはりカレンダーを開く必要があり、デフォルトではスケジュール表示にしているので確認が煩雑だ。他にも運用上の都合でカレンダーそのものが容易に見れないとかいうケースも度々あり、手間だった。

しかし紙のカレンダーが真横にあれば一発で見れる。スケジュール管理はカレンダーアプリでやるとして、祝日や曜日の確認などはカレンダーだけで済む話なので、これは便利になるのではないかと感じている。

ポスター状のカレンダーも検討したが、私は近眼でデスクにいるときは眼鏡をはずしており、遠くにあるものが見づらいため、机の上にあっても邪魔にならず、視認性も保たれる程度のサイズのものにした。実用性を抜きにしてみれば日めくりカレンダーも面白そうだったが、三日で飽きるのは目に見えていたし、要件に合致しないのでこれはやめた。

昔は紙のカレンダーなんて時代遅れだとか考えていたものだが、昨今は考えが徐々に変わってきており、変革シリーズにあるように、アナログの見直しを進めている。これもその一環ということになる。紙の良さの一つとして、同時展開性があると思っていて、例えば紙であればカレンダーと、ポスターと、資料と、参考書などのように複数の印刷物を同時に展開するのは容易だが、いわゆるデジタルではこうはいかない。そんなにモニタがあるのは邪魔だし、電気代もかかる。

もしもSAOのようなVRMMOが現実に生まれ、その中で過ごすことができたら、また話も違ったのかもしれない。

世の中には大抵の事柄にトレードオフがあると思う。

例えば冷凍冷蔵庫（以下、冷蔵庫と表記する）には霜取り機能付きと、霜取り機能なしがある。霜取り機能というのは冷蔵庫に発生する霜をとる機能で、本来冷蔵庫は外気温との差で内部で結露が起る。そして冷蔵庫は庫内全体を冷やすために強力な冷却機構を備えており、氷点下まで下がる部分を持つ。ここが結露すると、水が凍り霜ができるという流れだ。放っておくと霜は無限に増え続け、そのうち庫内を埋め尽くしてしまうので定期的に霜をとる必要がある。

そこで登場したのが霜取り機能付き冷蔵庫だ。一般的な冷蔵庫はこちらが主流だ。一見すると霜をとる手間が省けて便利な冷蔵庫で、何の問題もないかもしれない。

しかし、霜取り付き冷蔵庫にも欠点がある。それは氷が消えることことだ。これは霜取り機能というのは霜という名前の氷を除去する機能なので、氷も消してしまうのである。試しに霜取り機能のない1ドア冷蔵庫の冷却版と、霜取り機能のある冷凍庫で氷を作ってみるとわかるのだが、後者は氷が気づいたら消えており、前者は消えない。つまり作った氷を保持しておくには霜取り機能がない方が都合がいいのである。氷はすぐに作れないため、いつでも氷が欲しい場合は霜取り機能がない方が都合がいい。

といったように、冷蔵庫を一つ見てもこういったトレードオフがある。世の中の変化というのは大抵どんなことでもトレードオフがあると思う。開発でいうと密結合なコードと疎結合なコードにもあるし、何かを変えるということは何かしらのトレードオフがあり、銀の弾丸はないものだと感じる。銀の弾丸というのは絶対的な唯一無二の回答であり、要するにほかの選択肢の存在がない存在だと思う。なので、もし銀の弾丸があるとしたら、それは絶対的な価値観を規定し、選択肢を消し去ることで初めて成立するのではないかと感じる。なぜなら選択肢がないということは、逆説的に必然的に銀の弾丸になるからだ。

Next.jsのディレクトリ構成を、かれこれ3年くらい考えているのだが、ローカルのメモ帳に溜め込んでいても腐るだけなので一旦雑に吐き出してみる。

やりたいこと

大きくは基本の開発ルールを定めて、チームで混乱が生じないようにしたい。

• コードファイルの配置ルールを決め円滑な開発ができるようにする
• ディレクトリごとにスコープを作り、ある機能で使うコードは一か所にまとめる（コロケーション）
• ロジック・状態・ビューを分離し、コードの肥大化を抑制することで、見通しをよくする
  • 大まかなルールとしてはロジックはcontroller.ts, util.tsに置き、状態はstate.tsに、ビューはview.tsxに配置する
• 共通部品と共通部品でないものを明確に分ける
• 命名規則を単純化して命名で悩んだり属人化することを防ぐ

大きなこと

基本的なデザインパターンはMVCをベースにしていて、controller.tsにはイベントハンドラを、state.tsには画面の状態を、view.tsxにはTSXを持つという設計。controller, state, viewの定義は以下の通り。

• controller.ts
  • viewに差し込むイベントハンドラ群
  • useEffectはここに書く
• state.ts
  • 画面で利用するstateを実装する
  • 中にはusePageState()という関数を一つだけ作り、これで画面の全状態を管理する
    • この関数の引数は状態の初期値のみを渡す
  • この中にTSXやuseEffectは書かない
• view.tsx
  • 基本的にTSXだけが書かれている
  • 表示非表示を切り替えるために以下のようなboolean分岐はあってよいが、ネストするなどで複雑になる場合は別コンポーネントに切り出す
    • props.isHoge ? <Hoge /> : < />

ただ、これだとstateはModelではなくVewModelになるので、MVVCみたいな構成になってしまうので、一般的なデザインパターンから外れてしまうのがやや懸念だ。但しModelがないことで、Modelを修正したら参照している全画面に影響が出てデグレしたみたいなのは回避できると思っている。MVCというよりClean Archtectureとかレイヤーアーキテクチャの方が近いかもしれない。

ディレクトリ・ファイル構成例

└─src
    ├─adaptors
    │  ├─HogeRequest
    │  │  ├─index.ts
    │  ...
    ├─components
    │  ├─Fields
    │  │  ├─Checkbox
    │  │  │  ├─controller.spec.ts
    │  │  │  ├─controller.ts
    │  │  │  ├─view.spec.ts
    │  │  │  └─view.ts
    │  │  ...
    │  ├─Layouts
    │  │  ├─HogeLayout
    │  │  │  └─index.tsx
    │  │  ...
    │  └─Pages
    │      ├─Dashboard
    │      │  ├─ui-parts
    │      │  │   ├─HogeSection
    │      │  │   │  ├─controller.spec.ts
    │      │  │   │  ├─controller.ts
    │      │  │   │  ├─view.spec.ts
    │      │  │   │  └─view.ts
    │      │  │   ...
    │      │  ├─controller.spec.ts
    │      │  ├─controller.ts
    │      │  ├─state.spec.ts
    │      │  ├─state.ts
    │      │  ├─view.spec.ts
    │      │  ├─view.ts
    │      │  ├─usecase.spec.ts
    │      │  └─usecase.ts
    │      ...
    ├─hooks
    │  ├─ValueState
    │  │  ├─index.spec.ts
    │  │  └─index.ts
    │  ...
    ├─pages
    │  ├─Dashboard
    │  │ ├─index.page.ts
    │  │ ├─server.spec.ts
    │  │ └─server.ts
    │  ...
    ├─resources
    │  ├─RoutingConfig.ts
    │  ...
    └─utils
       ├─HttpClient
       │  ├─index.spec.ts
       │  └─index.ts
       ...

各ディレクトリ・ファイルの役割

src/adaptors/**/*

API通信などのリクエストを投げる処理だけを置く場所。投げる処理以外は一切書かない。ここではパースや例外処理を行わなず、必要な処理がある場合は、呼び出し元に委任する。

これは呼び出し元によってハンドリングが変わるケースがあり、機能AとBでは最初同じハンドリングだったが、のちに機能Aだけハンドリングが変わりアダプタ側に手を入れるというケースを防ぐためだ。要するに開放閉鎖の原則を守るためである。

src/components/**/*

Pageコンポーネント以外の全てのUIコンポーネントと、それに付随する処理を配置する場所。MVC一式がここに入る。

Modelをここに入れることに関しては悩みがあるが、MVVMのViewModelとして考える場合はそこまで違和感がないように思う。

src/components/Fields/**/*

<input type="text" />みたいなフォーム系の入力コンポーネントの部品置き場。

ここに配置されるコンポーネントは原則として状態を持たず、状態は親コンポーネントからprops経由で渡される。このため、viewとcontrollerのみがある。

src/components/Layouts/**/*

ページ全体のレイアウト置き場。大外のレイアウトを入れる想定、そんなに数は生まれないと思う。

例えば以下のコードで～Layoutとなっているのがここに入る。基本的にはViewしかない想定だが、必要ならControllerなどを置いてもよい。Stateが存在することはない（props経由で差し込まれることはある）

<CommonLayout>
  <FullWideViewLayout>
    <ヘッダーコンポーネントとか />
  </FullWideViewLayout>
  <HalfWideViewLayout>
    <ボディコンポーネントとか />
  </HalfWideViewLayout>
  <FullWideViewLayout>
    <フッターコンポーネントとか />
  </FullWideViewLayout>
</CommonLayout>

src/components/Pages/**/*

ページコンポーネントの実体置き場。この設計ではNext.jsのページコンポーネントはこのディレクトリにあるUsecaseを参照するための存在なので、ページ本体の実装はここに置く。

src/components/Pages/Hoge/ui-parts/**/*

このページコンポーネント内で使う細かいUI部品置き場。src/components/Fields/**/*などにある共通UIコンポーネントや、巣のTSXの組み合わせ。stateは持たず、controllerとviewのみを持つ。

src/components/Pages/Hoge/*.{ts, tsx}

このページコンポーネントの本体。

• controller
  • viewに差し込むイベントハンドラ群
  • useEffectはここに書く
• state
  • 画面で利用するstateを実装する
  • 中にはusePageState()という関数を一つだけ作り、これで画面の全状態を管理する
    • この関数の引数は状態の初期値のみを渡す
  • この中にTSXやuseEffectは書かない
• view
  • controllerとstateを受け取るpropsを持つ
  • 基本的にTSXだけが書かれている
  • 表示非表示を切り替えるために以下のようなboolean分岐はあってよいが、ネストするなどで複雑になる場合はui-parts側に実装することが望ましい
    • props.isHoge ? <Hoge /> : < />

• usecase

  • getServerSidePropsの結果を受け取るpropsを持つ
  • controller, state, viewの橋渡しをする場所

  • この階層でcontrollerにstateを差し込みラップした関数を作り、viewに差し込む

    ```tsx
    import { sendHoge } from './controller';

    const ps = usePageState();
    const onClickHoge = (ev: EventT) => {
    // これは中でHTTPリクエストを行っており、ローディングの状態を切り替えている
    sendHoge(ps.hoge, ev.target.value);
    }

    return ;
    ```

viewやcontrollerレベルで切り替わる場合は、切り替え先をcontroller, state, view, usecaseの単位で子にして、親側でラップする

src/hooks/**/*

共通的な状態操作用のHooks置き場。

src/pages/**/*

Next.jsのページコンポーネント置き場。*.page.tsxにはusecaseコンポーネントの呼び出しのみを記述する。SSRする場合はserver.tsに関数を実装し、*.page.tsx側から参照して使う。

src/resources/**/*

定数置き場。

src/utils/**/*

共通処理置き場。全体的に利用する共通処理のみ配置する。局所的に使うものは置かない。

一定のドメインの範囲で利用するものをどこに置くかは考え切れていない。

七月から体調を崩していて、更に先々週から大きく崩していたけど、この週末は徐々に調子が良くなってきたのもあり、何か美味しいものを食べようと思い、やはりこの季節はカニだろうというのが浮かんだので、近所のかに道楽に行ってみた。

思い立ったが吉日ということで、かに道楽のサイトを開き予約状況を確認して、予約してから向かった。これは高い店なので突撃は危険そうに感じたのと、ググった感じ、カニの季節は予約しないと入れないという情報を見たからだ。結論から言うと、この日の少人数席は空いていて予約は不要だった。

大阪を代表する看板の一つ「かに道楽」の文字が光る、かに道楽三宮店。カニのオブジェもいい。これを見るだけでワクワクするというものだが、明らかに高いのが解っていたので今までは見ても素通りするだけだった。しかし神戸に住んでいて、かに道楽に行ったことがないというのももったいない話な気がするので、今回これてよかった。いやまぁ、家から歩いてこれる距離にあるので、店の前に来るだけならいつでも来れるのだが。

少人数席は掘りごだつ式の座敷席だった。このタイプの席は半数程度しか埋まっておらず、そのまま突撃しても問題なさそうだったし、受付以降は店員も無予約客として接してきたので、恐らく予約客はそう多くないのだろう。来る店員ごとに「予約しています」「注文も予約しています」という感じで説明する羽目になったので、一人で行く場合は予約しないほうが楽かもしれない。Web予約メニューより店舗にある献立表の奴のほうが見やすく、その場の気分で選びやすいというのもある。

そこそこ高そうな店という雰囲気を醸し出す机の上、ホジホジ棒(R)と書かれた竹製使い捨てのカニほじ棒が面白い。箸置きもカニの形をしていながらも二列配置できる工夫？があって面白かった。

前菜として出てきた、カニの軽食たち。ゆでガニ、白和え、ポン酢の三点セットだ。小皿料理が好きなので、こういうのが胸が高鳴る。

かに刺し。紅たでや山葵がいい感じの小道具に収まっていて風流だ。

炊きあがるのに30分かかるといわれ机の下に置かれる釜飯。

かわいらしい容器に入った茶碗蒸し。

天ぷら。さつまいもとカニとエリンギ。和食の中にエリンギがいるのはどうなのかと思いながら食べていた。

焼きガニ。とびきりぷりぷりで、全料理の中でこいつだけ格の違いを感じた。

澄まし。

炊きあがった釜飯とお茶漬けセット。

カニほぐし身を、おこげ入りの釜めしに入れて頂く。釜めしには下味がついており、これはかなり良かった。

デザートのアイスには流石にカニは入っていなかった。手についたカニの臭いを消すためのレモンという不思議なものがついてきたので、試しにレモンで指を拭ってみたところ、確かにカニの臭いが消えた。手洗い用のレモンとは、なんとも贅沢な逸品だ。

受付前にカニの生簀があったので、恐らく出てくるカニの一部は冷凍ではなく生なのではないかと思う。全部ここからとっているとしたらちょっと夢があるが、どうなんだろうか。

行ってみた感想としては近くにあって気軽にカニが食べれる店としてはいいなと思った。例えばこれが香住まで行ってカニを食べるとなると、どうしても大変だ。例えば、はまかぜで香住に行ってカニを食べるのも悪くない体験なのだが、私が住んでいる三宮から行くとなると距離が距離なので時間がかかるし、運賃も高い。往復で1.3万程度する。その代わりに優雅な鉄道旅と、壮大な日本海を眺めながら安い値段でカニを始めとした、日本海の恵みを食べることができる。食事代だけでいえば香住で食べたほうが圧倒的に安い。かに道楽と同じ値段で倍以上食べれたと思う。単なる思い出補正かもしれないが、カニ自体も、かに道楽より美味しかった記憶がある。参考までに今回頼んだのは凪咲（なぎさ）というコースメニューで、6,000円ほどだった。

香住は見るところも多く観光で行くことを考えれば悪くない選択肢だ。しかし、手軽さでは歩いて行けるかに道楽に軍配が上がる。本気でカニを楽しむなら香住。手軽に楽しむなら、かに道楽という使い分けが良いだろう。他にもかに道楽の方が高級感があり、待ち時間が少ないのもある。香住にもそういう店はあるかもしれないが、前に行ったKAN-ICHIだと食堂風の店舗で、高級というよりはカジュアル寄りだった。しかも二時間くらい並ぶ必要があり、なかなかしんどい。前に行ったときは、いつ呼ばれるかわからないので観光もできず、日本海を眺めるか、土産を物色するか程度しかできないのが手痛いかった。良くも悪くもかに道楽は日常の中にあるので、手軽さが魅力だといえるだろう。

あと確か近日中に兵庫県日本海側のカニが入った気がするので、地物を楽しみたいなら来週末辺りから行くのがよさそうだ。流石に高いので今年はもう行かないが…ｗ

もともと映画館というのはテレビがなかった時代に興行を見る場だったと見聞きしたことがある。テレビが普及し、そしてインターネットが普及した結果、テレビが衰退したといわれ、インターネット配信も増えてきた今では映画館の価値というのは相対的に低下していると考えている。そんな中、個人的に映画館で映画を見る理由は何かというのを書いていく。

まず一つ目は大きなスクリーンと迫力のある音響だ。これは家では中々味わえない体験で、これを目的に映画館に来ている人も少なくないことだろう。またこの部分は映画館や、シネコンのスクリーンによっても違うので、映画館やスクリーン巡業をするオタクがいるほどのものにもなっている。なぜか全国津々浦々の映画館やスクリーンを知り尽くしたオタクとかいる。

次に映画館独特の雰囲気を体験できるところだ。これは映画館によってだいぶ変わってくるが、シネコンだと独特の匂いや、ひんやりした空気感、静寂みたいなのがあって、私はこれが好きだ。幕間や上映終了後のこの雰囲気を楽しみに行くのも一つだ。特に上映終了後の空気を吸いながら家に帰るのは至高の体験の一つだ。他にも上映中のポップコーンの香りや、観客のざわめき・笑い声、コンビニの袋をくしゃくしゃする・後ろから蹴られるなどの不快感も混みで、その回にしかない、一期一会な上映体験を得るのも侘び寂がある。経験した中で過去最悪だったのは神戸国際松竹でARIA The CREPUSCOLOを鑑賞していた時に後ろの列でおじさんが床に転がって寝ていたことだ。しかも大きないびきをかいて寝ていた。こんな光景は中々忘れることができないし、無駄に頭に焼き付くので面白い。いや、観ているときはただただ不快でしかないのだが、家でネット配信を見ていたらこんな体験はできない。

他にもオタクと映画館について話し合ったり、遠方のオタクを地元の映画館に呼び込んだりというのもするのだが、普段映画館で映画を見ているからこそできる活動の一つだ。こういうのも楽しい。つまり、私は映画館で映画を見ることそのものより、そこに付随してくる要素を楽しんでいるのだろう。特にトラペジウムについてはXで多くのオタクたちと大いに過熱し盛り上がったので、あれはよかった。正直トラペジウムという作品自体は私の中でそこまでの存在ではないが、それで盛り上がった熱気というのは格別だった。まるで往年のインターネット、そう、インターネットがまだ黎明期だったころ、今ほど細分化しておらず、2chやはてなみたいなのがネットの中心にあって、似たようなパソコンオタクたちが集まっていたころに、ネット全体が熱を帯びて何か一つに向かっていたような、あのころの体験を呼び起こしてくれるような作品だった。

鑑賞外の要素であれば、アニメ映画に限ってだが、誰によっていつ公開されたどの作品を観たかを記録しているし、映画館で何かを見たときは、いつどこで何を見たかも記録している。下図はその記録内容だ。最初は映画館で鑑賞したアニメ映画作品だけを記録していたのだが、いつ何処で観たかの情報が欲しくなったので、観た作品の記録と、観た場所の記録を分けている。これをクロス集計すれば封切日に見た割合を出すことや、私が映画を観ることになった2019年以前の作品をいつ観たかというのも出せる。単体でもどこのスタジオの作品を多く見ているかや、どこの映画館によく行っているか、よく行く映画館の変遷など、様々な要素を見ることができる。

そんなことに何の意味があるのかといわれると分からないが、集計が楽しいのでやっている。なお、本記事の執筆時点では下図が上手く拡大できないため全体を見る場合、上手いことして拡大してほしい。

結論としては、私は映画作品を見るためだけではなく、映画作品を見ることによって得られる副次的な要素を楽しむために、映画館に行っているのだと思う。