お知らせ

現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。

imgタグで画像が取得できなかった時に代替画像を表示する

投稿日：
言語::HTML言語::JavaScript::CommonJS

事前にバイナリをHTTPクライアントで取得してハンドリングするのかと思っていたが、実際にはimgタグのonerrorイベントでハンドリングできた。

確認環境

Microsoft Edge 130.0.2849.56

サンプルコード

<html>
<head>
  <script>
    function handleError(ev) {
      ev.target.src="https://example.com/empty.gif";
    }
  </script>
</head>
<body>
  <img src="https://example.jp/hoge.jpg" onerror="handleError(event)" />
</body>
</html>

最初に考えていたコード

これでも同じようなことはできるにはできるが、CORSやlazy loadとか考えると面倒で、コードも増えるし、採用するメリットはあんまりないと思う。

<html>
<head>
  <script>
    window.onload = () => {
      const img = document.getElementById('img');

      fetch('https://example.jp/hoge.jpg')
        .then((res) => {
          if (res.status === 200) {
              res.blob().then((data) => {
                img.src = URL.createObjectURL(data);
              }).catch(() => {
                img.src = 'https://example.com/empty.gif';
              });
            } else {
              img.src = 'https://example.com/empty.gif';
            }
        }).catch(() => {
          img.src = 'https://example.com/empty.gif';
        });
    }
  </script>
</head>
<body>
  <img id="img" />
</body>
</html>
コメント（0件）

紙のカレンダーを買った

投稿日：
ジャンル::買い物

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

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

20241110_173101021.JPG

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

20241110_173151339.JPG
20241110_173219209.JPG

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

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

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

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

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

コメント（0件）

冷蔵庫とトレードオフと銀の弾丸

投稿日：
ジャンル::雑記

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

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

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

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

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

コメント（0件）

Next.jsのディレクトリ設計案

投稿日：
ライブラリ::Next.js開発::設計

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/**/*

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

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

コメント（0件）

かに道楽に行ってみた

投稿日：
ジャンル::雑記

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

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

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

kanid1.jpeg

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

kanid2.jpeg

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

kanid3.jpeg
kanid4.jpeg

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

kanid5.jpeg

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

kanid6.jpeg

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

kanid7.jpeg

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

kanid8.jpeg

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

kanid9.jpeg

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

kanid10.jpeg

澄まし。

kanid11.jpeg

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

kanid12.jpeg

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

kanid13.jpeg
kanid14.jpeg
kanid15.jpeg

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

kanid16.jpeg

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

20241102_202459359.JPG

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

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

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

コメント（0件）