Lycolog

検索条件

日付で絞り込み 2019年(1) 2020年(6) 2021年(36) 2022年(8) 2023年(20) 2024年(24) 2025年(2)

全97件 (1/20ページ) 一覧表示に切り替え記事本文を表示

お知らせ

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

Next.jsの設計に対する最近の考えを殴り書き

投稿日：: 2025/02/27

開発::設計開発::Web言語::TypeScriptライブラリ::Next.js

最近思っているNext.jsを使った画面設計に関する考えを箇条書きで雑に殴り書きしていく。この記事は考えの垂れ流しなので深い説明はしない。AppRouterではなく、PageRouterの考え。

TypeScriptで実装し、型が騙せるような実装は極力避け、コードによる戻り値の型指定は不具合の原因になることがあるため、可能な限り型推論に任せる
SOLIDな設計を意識することで疎結合でテストしやすい設計になる
Clean Archtectureを意識することでSOLIDのSを意識しやすくなる
- 画面として考える場合、実装レイヤーとしてはAPIを呼ぶ以外何もしないAdapter、ビジネスロジックやイベントハンドリングの実処理などを行うController、画面要素を配置しただけのView、画面状態を保持するState、それらをつなぎ合わせるUsecaseが、Usecaseを置くだけのPage（Next.jsのpageコンポーネントに埋め込むコンポーネント）、SSGやSSRをする場合のServer Side Controllerがあるとよいと考えている。大まかには下図のような感じで考えていて、過去の実務でもこれに相当するものを作ったことがある。
- ただこれはModelに相当するものがなく、ビジネスロジックの共通化に課題が出てくるのと、ControllerがFatになりすぎると考えており、そこが課題になると考えている。
テストが容易なコードは必然的に疎結合になる
疎結合にする場合、命名を抽象的にしておくと処理の入れ替えが容易になる（命名が具象、つまり実装の詳細に依存しないため）
疎結合にするとパーツが増えるので認知負荷が上がる
疎結合でかつ、命名が抽象化されている場合、仕様を知らない人にとっては実際の処理内容を推測しづらくなる
- つまりこれは属人性が増えると考える
例外についてはErrorクラスを継承し、カスタム例外を作成して、用途に応じたハンドリングができるようにする
- 原則として処理を止める場合にのみ用いるべきで、続行する場合には使わない
- 例外は原則としてスローして、カスタムエラーは特定の階層でフィルタしてハンドリング、全てすり抜けてきたものはルート処理でキャッチしてハンドリングすることで、取りこぼしをゼロにする。例外の握り潰しは原則行わない
  - 基本的にすべてロギングする
- 処理を継続するものについては例外とせず、ワーニング用の処理フローを作成し、それに則って行う（例えば入力バリデーションはワーニング）

コメント（0件）

Windows Formを使ってシステム通知を出す

投稿日：: 2025/01/23

言語::C#.NETライブラリ::Windows Form

C#を使ったWindows Formでなんでもいいから通知を出したかった。

確認環境

Env	Ver
Windows 11 Pro	22631.4751
.NET	8.0
C#	12

手順

Windows Formでプロジェクトを作る
デザイナにNotifyIconを突っ込む
デザイナでNotifyIconに適当なアイコンを設定する

適当な場所に以下を書く

notifyIcon1.BalloonTipText = "ほげ";
notifyIcon1.ShowBalloonTip(5000);

備考

アイコン設定してないと何も出てこないので注意。

クリック時に何かしたい場合、NotifyIconにイベントハンドラが生えてるのでそれを使う。

あとがき

ググるとDLLをコールしたり、Nugetを使ってUWPのコンポーネントを使ったりと、コレジャナイ情報ばっかり出てくるのだが、OSの機能なので標準で出せるんじゃね？と調べてたらここに突き当たった。

コメント（0件）

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

投稿日：: 2024/11/13

言語::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件）

PrettierでMarkdownを整形する

投稿日：: 2024/07/30

言語::MarkdownNode.js::Prettier

PrettierというとTypeScriptやJavaScriptのコードを整形するツールであって、Markdownを整形するツールという意識のある人は少ないかもしれない。

それが実はPrettierはMarkdownの整形に使えるのだ。例えば次の図はPrettierを使ってMarkdownを整形しているシーンを撮ったものだ。具体的にはnpx prettier -w hoge.mdした時の前後を撮っている。

これは別の文書からコピペしたなどで書式が崩れることや単純なtypoでズレたりしたときに地味に効果を発揮してくれる。Prettier v2以前だと全角と半角文字の間の自動スペース挿入が嬉しかった人もいるだろうが、v3でこの機能は廃止されている。

他にもチーム開発だとMarkdownの細かい仕様に熟知した人は多くないので、最低限の書式を合わせるのにも役立つだろう。Markdownのインデント幅を変えたいが、コードフェンスの中のインデントは変えたくないみたいな用途みたいなカスタマイズもできるし、個人用途でも結構使える。

しかしフォーマッタの挙動がアップデートでころころ変わるのは割と不快なので、この辺りは何とかなってほしい気もする。

コメント（0件）

TypeScriptに限界を感じてきた

投稿日：: 2024/07/16

言語::TypeScript

五年くらい公私ともにTypeScriptを書いているが、なんか最近限界を感じたので吐露していく。半分くらいNode.jsに対する不満かもしれない。内容としてはただの書きなぐりの愚痴。

非同期制御多すぎ

asyncとawaitを書く面倒さや、それが漏れた時のふるまいの微妙さ。

例えば終わらないJestというのは日常的に見る光景だと思うし、実務をしていてPromiseの例外ハンドリングをしていなかったからサーバーがクラッシュしたというのも聞いたことがある。

これはチーム開発において、チームの意識や技術レベルが低いと容易に引き起こされる問題であり、その面で考えると非常に微妙な言語仕様だと思う。

なんだかんだC10K問題はコンテナ大量起動で回避する世界線になってしまっている気がするので、標準が非同期である必要性はあんまないよねみたいな感触は抱いている。C10K問題回避のために非同期にしてるんだよね？そうだよね？（正直非同期にしたいのであればユーザー側がPromiseに包めばいいと思う）

Node.jsのLTS短すぎ

GitHubやAWSですら最新版への追従は遅れがちなくらいLTSが短い。2年くらいしかない。2年ごとにフルリグレッションなんてやってられない。不可能だ。

しかも破壊的変更を平気で入れてくるし、v16は予定より早くサポートが打ち切られた。正気とは思えない。

実行環境多すぎ

Node.js + 各種トランスパイラにDenoにBunに…他にも最近なんか出ていた気がするが忘れた。なんでこんなにあるのか…。

TypeScriptの型パズルに疲れた

型パズルするために開発してるんじゃないんだよ…。

型が信用できない

実務だと意図しているのか、していないのか型を騙している光景を多々見るが、これによって型が信用できない状態になっていることが往々にしてあり、割と殺意を覚える。なにも信用できない。何のためにこの言語使ってるんだっけ…？ナウいから？

CLI作る時のハマりどころが多い

nvmのようなバージョン管理システムを使っているとグローバルインストールが通常ユーザーとスーパーユーザーで別れる問題があり、sudo実行が前提のCLIで誤った動作確認をしてしまいやすい。

他にもnpmjsで公開しているパッケージをnpm installしたものと、開発中に実行するのでは、意識してないと実行方式が変わってしまい、上手く動かないことがある。気を付ければいいのはそうだが、割とムカつく。

具体的にはshebang書いて無くて動いてなかったとかそういうやつ。基本的にjsファイルを直に叩いて動かす文化ないじゃん…。

ビルド工程が面倒くさい

ビルドに関してtscやswc、esbuildのように様々なトランスパイラが存在するほか、webpackやvite, esbuildといったバンドラの存在があり、バージョンアップで振る舞いが変わるので面倒くさい。TypeScript開発は膨大なパッケージに依存しがちで、何か不具合が起きた時に原因の特定が困難だが、根幹に破壊的変更が来ると割と精神的にきつい。

先ほどswcでビルドしたところ/dist/index.jsとして出てくるはずのものが、/dist/src/index.jsになっていた。正直こんなのはデグレードだ。ありえない。

もちろんこれはfix: pass in --strip-leading-paths to swc when buildingで対応されているのだが、正直しんどい。

てかNode.js系のパッケージって息を吸うようにデグレ起こすような気がするのは私だけだろうか。以前はNewRelicがプリフェッチしまくるバグとかあった気がするし、Jestのモックが正常に動かないケースにも遭遇したことがある。

エコシステムが壊れかかっている

TypeScriptでLintをするとなればESLintがデファクトスタンダードだと思うが、v8で導入されたFlat configがあまりにも不案内で、v9.7が出た今でさえ対応できていないPluginがゴロゴロある。むしろできてるほうが珍しい。

私も三日くらい格闘したが、いずれかのプラグインが不整合を起こすか、不整合を起こさなくなったと思ったら無視設定が機能しなかったり、今度はLint機能そのものが死んだりで手に負えないのであきらめた。v9に上げると使えなくなるプラグインもあるので、v8.57.0で旧式の設定を使うのがきっと無難だと思うが、これがいつまで続くのかという話だ。恐らく追従できないプラグインはサポートのやる気をなくすだろう。

Prettierも破壊的変更を繰り返しフォーマットをガタガタにしてくる困りものだ。こいつもv3が出て一年たった今でもVSCodeの公式拡張機能がv3に対応していない。一応ローカルにv3を入れれば最低限動くが、ネイティブで動いてほしいケースもあるので、そういう場合は運用に難儀する。過去に対応させようと手を付けてみたが、最新版はテストが落ちる状態になっていて、もはや救いがなかったので投げた。

正直ESLintとPrettierが死にかけている現状を見るに、もうなんというか駄目じゃないかという気がしてくる。

Biome.jsなんてのもあるが、あれはMarkdownのフォーマットができないとか、ESLintのプラグインをサポートしてないとかで使い勝手がいまいちよくないのだ。まぁ、MarkdownのフォーマットだけPrettier使うとかはアリか。

あとがき

とはいえ、フロントエンド開発において、ブラウザではJavaScriptしか動かないのでTypeScriptをの利用はやむを得ない側面もある。やむを得ないのだ。ただ、それ以外ではもう使う必要ないんじゃないかなと思うし、正直Node.js界隈が魔境というか地獄過ぎて、あんまり関わり合いになりたくないという思いが日に日に強くなっている今日この頃だ。

コメント（1件）