Next.js-React-TailwindCSSなどたわいもない話

最近思ってる事を整理するために一旦書き出して整理してみるという話

今回は最近思ってる事を 整理するために一旦書き出して整理してみるという話。
昨今のWebページは基礎となるhtmlやcssやjsを素のままは書かない。 大半はフレームワークだよりになっている。 一応WebComponentsという選択肢もあるがこれもまたフレームワークの影響によるもの。

この世には「関心の分離」という言葉あって、Webページで言うなら画面のデザインと動的処理の分離をするべきだとずっと言われてきた。 だが最近の流れはそうではない。データをコンポーネント単位で「デザイン＋処理」としてカプセル化して再利用しようというのが主流である。

まず、大半はフレームワークという話。

主に流行ってるのはReact.jsとVue.jsほぼ2強…いやたぶん割合的にReact(next.js)1強。
htmlタグをjs側に取り込んでしまおうというのがこれらのフレームワークである。 通常のhtmlはhtmlからjsとcssを呼び出してhtmlを主体にそれを装飾する形だった。 フレームワークは逆にjsを主体にhtmlを吐き出すという思想の元に出来ている。

そうすると空白のページにjsが動いて始めて生成される。 これにはちょっとした問題がありページが大きいほど描画が遅れる。 そこで更にサーバー側のフレームワークNext.jsである。 サーバ側で一旦描画処理をして静的htmlを生成し描画を先にする。

フロントフレームワークは「html＋処理」だがこれらフレームワークは既にあるhtmlを生成せず差分のみを生成する様に出来ている。 今は「Svelte、Solid、Astro」みたいな軽量かつ強いものも育ってきてるが先に出来たものに対して「安定」を優先させると新規フレームワークを導入・選択肢にするのはまだ難しい気がする。

WebComponentsの話

Microsoftなどの大きいサイトの場合はページが大きすぎて使ってるフレームワークの分裂が起きている。 そして統合が難しいが同じメニューなどを付けたくなった時にフレームワークを統合するのではなくもっと原始的なWebComponentsでパーツを配る事にしたそうである。 つまり、WebComponents＋各フレームワークを使って共存させる事で落ち着いている。

TailwindCSSの話

cssやめよう。極端に言えば思想はこれである。

webページでの関心の分離はデザインとhtmlの分離ではないし、分離しない方が良いという方向で作られている。
デザイン面においてはhtmlよりもcss主体の方が再利用性があるという考え。
前回、使用感を記事にしたがhtml上にstyleでごりごり書くような地獄のような可読性になる。

ただ、Tailwindの思想としては「html＋Tailwind」ではなくあくまでもcss-in-jsのパーツとして出来ている。
そのため開発者もフレームワークを使わない＝コンポーネントにしないTailwindCSS単品の運用はあまり本意でない様である。
複数回登場するようなパーツならなおさらコンポーネント化した方が良い。

また、クラス名を考えるのは時間の無駄でさっさとデザインを反映させた方が良いという考え方。
じゃあなぜstyleではなくTailwindを使うのかというとstyle記述では出来ないメディアクエリなどのcssstyleが複数あるため。
他にも、フレームワーク全般に言える事だが記述の統一性の向上がある。

フレームワークの食い合わせの話

Reactは仮想DOM、WebComponentsはシャドーDOMを使っている。 先に述べた通りWebComponentsは他のフレームワークと共存できるが、シャドーDOMはTailwindと食い合わせが悪い。
これはcssが内部に閉じてしまいTailwindが使えなくなってしまう。
(いくつか対応方法はあるが現状あまり美しい実装ではない感じ）
逆に言えばReactとTailwindは良い組合せと言える。

現状の組み合わせで良さそうなものは？

Next.js-React-Tailwind現状ではこの組み合わせがかなり良さそうに感じる。

ちなみに今はかなり下火に見えるphpも再考した時に悪くないと思っている。 phpが凄く下げられているが現行のシェアもphpは低いわけでは無く特にWordPressは根強いシェアがある(40%以上ある)。

■変換が多すぎ問題

上記をもう少し加えるならTailwind-in-Next.js(React(TypeScript))という構造だろうか。 TypeScriptは型なしjavascriptに変換する必要があり、Next.jsはhtmlを生成する必要がある。 リアクトはビルドする必要があり、Tailwindもビルドする必要がある。 こう考えると本当に変換しすぎていて正直面倒臭い。

先ほど再考にphpが上がったのは面倒臭いからhtmlなどを直接インクルードすればいいじゃんという考えである。
この変換祭りがなんで起きるのかというと開発環境の負債をユーザに渡さない為である。

正直面倒臭いからCDN (Contents Delivery Network) ＝リンクのみで済ませたい。 ReactとTailwindはCDN使えるし・・・。
ただベタデータは重い為変換して軽量化しないと描画が遅れる為、モダン開発環境を享受しつつユーザー体験を損なわない為には変換祭りをしなければない。

■最後に読んでみて欲しい開発陣の記事あれこれ

確実に上記の駄文より為になる話なので以下英語だけど頑張って翻訳して読んで欲しい。

• React開発者の一人がtailwindについて話してるもの
• tailwind開発者がなんで現在の形になったのかの話

実をいうとReactは昔js純粋主義だったが現在は協調性を取ってる。
結局の所デザインとjsは切り離せないということでしょうね。

環境変数って何？一体どこで定義されているのか

 そもそも環境変数ってなに？

環境変数は超簡単に言えばただの「良く使うpath(パス)の集まり」です。
パスはエクスプローラーを開いた時に表示される「C:\Users\Username\Desktop\」みたいなPC上の階層の事です。
よく使うパスを登録した集合体の事を「環境変数」と呼んでいます。
PC内の処理で常にこういった長いパスを常に書き込んでいたらデータが長くなるので先に登録しておいて短い名称で呼び出そうという事です。

例えばよく使うアプリなどをデスクトップにショートカットを作ると思います。あれと同じです。ああいう感じのショートカットが1つに纏まってるという事です。

プログラミングなどのセットアップ時の環境変数

環境変数とだけ言うとつまりはただの省略パスの事なのでWindowsの特殊パス(マイドキュメントやデスクトップ)なども含まれますが一般的には「実行パス」の事を指します。
「パスを通す」などともよく言われます。

実行パスを通すと登録したexeを名前だけで実行出来ます。
例えばWin+Rでファイル名を指定で実行読んでcmdやnotepadでアプリが呼び出せるのは環境変数が登録済みでパスが通っているからです。
逆にcmdやnotepadはOSに統合されたプログラムではなく単にcmd.exeやnotepad.exeが独立して作られておりそれを実行してるに過ぎません。

環境変数の確認の仕方

一般的なパスを確認するだけならWindowsの左下の検索バーで環境変数と入れれば簡単に確認できます。

※ただし、ここにはファイルを実行する系のパスは表示されません。

コマンドラインを開いて「path」を実行すればパスを表示できます。

ただこれだとちょっと見ずらいですよね。Powershellでも同様に表示し整形も出来ます。
まずは同じ事ができる「$env:Path」を実行してみましょう。

同じパスが表示されます。

次に整形して表示「$env:Path -split ";"」セミコロンで区切られるのでそこで改行させます

はい。分かりやすくなりましたね。

これらは一体どこに情報が書き込まれているのか？

次に情報の実体が一体どこにあるのかです。
答えから言うとレジストリにバイナリ形式で保存されています。
その為、メモ帳で開いてぱぱっと更新すると言ったことは出来ません。
バイナリエディタで開くにしてもチェックサムがある為「技術的には可能だが現実的ではない」です。

詰まる所、$envが何処にあるのかですよね。パワーシェルで「Get-PSDrive Env」を叩きます。

Environmentにある事がわかります。これがレジストリのどこにあるか。まずはレジストリエディタを開きましょう。
win＋Ｒから指定実行で「regedit」

ルート名	役割（中身）	ユーザーへの説明例
HKEY_CLASSES_ROOT (HKCR)	ファイルの関連付けやプログラムの情報	「拡張子（.txtなど）をどのアプリで開くか」を決める場所
HKEY_CURRENT_USER (HKCU)	現在ログインしているユーザーの設定	「壁紙」や「自分専用の環境変数」が入っている場所
HKEY_LOCAL_MACHINE (HKLM)	PC全体（全ユーザー共通）の設定	「システム環境変数」の本当の住所はここです
HKEY_USERS (HKU)	PCに登録されている全ユーザーの個別情報	「全社員の名簿とそれぞれの設定」を保管している大元の場所
HKEY_CURRENT_CONFIG (HKCC)	現在のハードウェア構成の情報	「今使っているモニターやプリンタ」の起動用設定

パスを通す場合は全体で呼べるようにするので「HKEY_LOCAL_MACHINE\」の中です。

コンピューター\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

最終的にはここに書き込まれています。

階層レベル	フォルダ名 (キー)	具体的に何が入っているか
第1階層	HKEY_LOCAL_MACHINE	全ユーザー共通のハードウェア設定やOSの基本情報。
第2階層	SYSTEM	Windowsの起動や動作に絶対必要な「核」となるデータ。
第3階層	CurrentControlSet	今まさに正常に動いているドライバーやサービスの設定セット。
第4階層	Control	タイムゾーン、マウス、キーボード、ファイルシステムなどの挙動設定。
第5階層	Session Manager	OS起動時のプログラム実行順序や、メモリ管理などの「下準備」データ。
第6階層	Environment	【最終目的地】 Pathなどの「共通のショートカット集」の実体。

階層はこの様になっています。
環境変数と言った場合、基本的にはここに記述されているデータが本体といって差し支えないです。

更に奥にある実体パス

ただし、実体をここまで見に行くと今までみたcmdの「path」やPowershellの「$env:Path」とも違う記述があります。
例えば「%SystemRoot%」などさらに変数で指定されている事が分かります。じゃあ今度はこれらは一体どこに格納されているのか

コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

この階層です。Windowsのより心臓部で定義されています。
ここで注目すべきなのはデータの種類（型）です。

実は先ほどのパスの種類は「REG_EXPAND_SZ」であり、今回の種類は「REG_SZ」です。
この違いが何かというと中の変数を展開できるかどうかです。

型の名前	正式名称	特徴・役割	環境変数での使われ方
REG_SZ	String Value	固定された文字列。書かれた内容をそのまま読み取ります。	単純なパス（例: C:¥Tools¥App）
REG_EXPAND_SZ	Expandable String	展開可能な文字列。中に % で囲まれた変数を含むことができる。	今回のキモ！%SystemRoot%等を翻訳するパス
REG_BINARY	Binary Data	バイナリ形式。人間には読めない形式。	特殊な構成情報の保存用など

つまり、今度こそ本当に環境変数という情報の末端という事です。
これで環境変数が一体なんなのかと、その実体が何処にあり参照されているか理解できたと思います。

n8nをセットアップしてみる

 前回はDockerDesktopを入れたので今回は何かコンテナに入れてみるっていうところです。

n8nとは

n8n（エヌエイトエヌ）とは、オープンソース（fair-codeライセンス）のワークフロー自動化ツールです。
ノーコードまたはローコードで、さまざまなアプリやサービスを連携させて繰り返しの業務を自動化できるプラットフォームで、ZapierやMakeのようなツールの代替として人気！

今回はZapierやMakeをなぜ使わないのかというとn8nはクラウドもありますがホスティングがセルフホストに出来るからです。つまり無料で使えます。
残り二つはクラウドのみです。

取り合えずインストール

Powershellを開いて
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n

パラメータ	役割	具体的になにをしているか
docker run	実行指示	新しいコンテナ（仮想的な箱）を作成して起動します。
-it	対話モード	PowerShell画面にn8nの動作ログをリアルタイム表示し、キー操作を受け付けるようにします。
--rm	自動削除	コンテナを停止した際、PC内に不要なゴミ（一時ファイル）が残らないよう箱を自動で破棄します。
--name n8n	名前付け	コンテナに「n8n」という名前を固定します。これがないとDockerが勝手に名前を付けてしまい、後で探しにくくなります。
-p 5678:5678	通信の道作り	コンテナ内のn8nと、あなたのPCのブラウザをつなぎます。左がPC側、右がコンテナ側のポート番号です。
-v n8n_data:...	データの保護	最重要。 コンテナを捨てても「作成したワークフロー」が消えないよう、PC側の保存領域（ボリューム）と紐付けます。
n8nio/n8n	設計図の指定	n8n公式が配布しているプログラム一式（イメージ）を指定してダウンロード・実行します。

「ポート番号？」という方の為に説明をすると

■0 ～ 1023（ウェルノウンポート）:
Web閲覧用の 80 (HTTP) や 443 (HTTPS) など、世界的に用途が決まっている「一等地の番号」です。

■1024 ～ 49151（登録済みポート）:
特定のアプリが「この番号を公式に使うよ」と予約している番号です。
n8nの 5678 もここに含まれます。

■49152 ～ 65535（ダイナミックポート）:
一時的な通信のために自由に使える「空き部屋」です。

こんな感じに利用されています。
左側のPC側のポート番号は好きに変えても問題ないです。
変更した所でその番号でアクセスするのが右の5678となります。

右側の5678はコンテナ内の環境変数に入ってるデフォルト値で変更不要です。
コンテナの環境変数を変更すれば変更可能ですが何か調べる時に置き換えて考えるのは面倒だと思います。他のアプリとポートが被るなどよほどの理由がない限りは固定で良いです。

つまり左側は任意の番号、右はほぼ固定という事です。
そしてあえて別の番号にする必要性がないので左のポート番号であるPC側も同じ番号を指定する感じです。

実行するとインストール処理がずざーと流れます。
インストール途中でDockerがファイヤーウォールで止められたメッセージが出た時は許可してください。

最後に「Press "o" to open in Browser」と表示されたらインストールは完了。
「o」を押したらブラウザが開くという親切設計ですが私の環境ではo押しても開かなかったのでそういう場合は普通にブラウザに直接urlを入力します。
アクセス先はメッセージ「Editor is now accessible via: http://localhost:5678」とある通り「http://localhost:5678」にアクセスします。

Powershellはそのままにします（最小化でもしててください）。
✕で閉じてしまうと処理が終了してブラウザで上記URLにアクセス出来なくなります。

正しく手順が進んでいればこの画面(管理者登録画面)が表示されます。
ここで入力する情報は何処かに飛ばすデータではなくてPCの中（Dockerのボリューム）に保存するデータです。

起動時に表示されるのはアンケートです。
選択式なのでおおまか合ってるのを入力してください。

■What best describes your company?（会社の業種は？）
自分用なら Other や Education など何でもOK。

■Which role best describes you?（あなたの職種は？）
Personal use（個人利用）や Engineering など。

＞What are you looking to automate?

・CI/CD: システム開発の自動テストや公開作業
・Cloud infrastructure orchestration: クラウドサーバーの自動管理
・Data syncing: データの同期（AのデータをBに移すなど）
・Incident response: 障害が起きた時の自動対応
・Monitoring and alerting: 異常がないか見守って通知する
・Reporting: レポートの自動作成
・Ticketing systems integrations: お問い合わせ管理ツールとの連携
・Other: その他

■Who will your automations mainly be for?（誰のための自動化？）
自分用なら Myself 。

■How big is your company?（会社の規模は？）
I'm not using n8n for work: 仕事では使いません(お試しならこれで)

■How did you hear about n8n?（どこでn8nを知った？）
GoogleでもTwitterでもなんでもOK

内容的にはこんな感じです。
選択はドロップダウンなので手入力は無いですがOtherの時は理由入力が出たりするのでstudyとかPersonal useとかで良いかと思います。

次にセルフホストユーザーには初回に基本表示されるらしいこちらは有償機能を無料で使えるライセンスキーを上げるよって内容です。
セルフホストの基本機能は別に制限は掛かっていませんので面倒なら左下のスキップでも構いませんが、メール登録するだけでforever(ずっと)なので登録しといた方が少しお得です。

(※Cloud版、Self-hosted版、Enterprise版があってEnterprise(法人向け)の機能が使える用になるライセンスキーです。)

・Advanced debugging: 失敗した自動化を簡単に直して再実行できる機能
・Execution search and tagging: 過去に動かした履歴を検索したり、タグを付けて整理したりできる機能
・Folders: 作った自動化をフォルダ分けして整理できる機能

この3つが使える様になるよって内容です。
「Send me a free license key（無料キーを送って）」で良いかと思います。

登録した場合の右下に出るポップ「Your license key is on the way!Check your email, 登録したメールアドレス, to find your license key. Then head over to usage and plan to activate your license.」は「ライセンスキーが届きました！メールでライセンスキーをご確認ください。その後、使用状況とプランのページにアクセスしてライセンスを有効化してください。」です。

これでセットアップが完了です。

下部にあるのはテンプレートで内容は以下通り。

テンプレート	内容（日本語訳）	何ができるの？
Secure web form to Odoo CRM...	Webフォームから顧客管理ソフトへ連動	サイトのお問い合わせフォームに入力された情報を、自動で顧客リスト（Odoo）に登録します。
Automated LinkedIn posts with AI...	AIによるLinkedInへの自動投稿	OpenAI（ChatGPT）を使って記事を自動生成し、LinkedInへ投稿する仕組みです。
Automated lead capture, scoring...	見込み客の自動獲得とランク付け	新しい顧客情報を取得し、その重要度を判定して、HubSpotやSlackに通知します。
Automated local event monitor...	ローカルイベントの監視とAI分析	特定の地域のイベント情報を収集し、AIを使って内容を分析・整理します。
Automate restaurant customer...	飲食店向けのチャットボット対応	WhatsAppとAI（Llama）を使い、レストランの予約や質問に自動で答えます。
Ai voice & text note-taking...	音声とテキストによる自動メモ作成	LINEからのメッセージや音声をAIで要約し、データベースとGmailに保存します。

ただ、これらのテンプレートは外部サービス（LINEやChatGPTなど）のAPIキーが必要になるため、初心者がいきなり動かすには少しハードルが高いです。

まずは、一番上にある大きな四角 「Start from scratch（ゼロから作る）」 をクリックして、真っ白な画面から始めてみるのがおすすめ。

セットアップおまけ：ライセンスキーの有効化

上記で無料ライセンスキーを登録してる場合はメールが届ているのでメールの「Activate License Key」ボタンを押します。

Sign inのページに飛ぶのでメールとパスワード入れる。
これで終了です。Sign in時点でライセンスが有効化します。

Sign inするとこちらの画面に飛びます。
You’re on the Community Editionの隣に「Registered」が表示されていればライセンス登録済みです。

もしメールのボタン以外でSign inした場合は「Enter activation key」（アクティベーションキーを入力）から入力してアクティベートすればOKです。

なお、メールのボタンでSign inした場合は先ほど言った通りSign inした時点で登録済み「Registered」になるのでもう一度アクティベートしようとすると

もう登録済みって表示されます。

これで本当にセットアップ全部終了です。

svgファイルで保存できるドット絵作成webツールを作ってみた

 SVGドット絵Webエディタ

https://blackstraycat.nobody.jp/webtools/svg-pixel-art-maker/

作ったのはこちらです。
好きに使ってみてください。

そもそもSVGファイルってなーに？

画像ファイルの形式です。
ですがjpgやpngなどと違いバイナリデータではありません。
内部構造はテキストデータです。
つまり、「ファイル名.svg」という画像はメモ帳で開いて編集すら可能です。

何が便利かというと拡大縮小しても画像データが全く劣化しません。
更に内部はテキストデータであるためWebPやjpgなどよりも軽量です。

要するに、複雑な画像でない限りは最強の画像形式という事です。

何で作ったの？

単純にサイトと作ってる時に軽量な画像が欲しかったからです。
簡単なアイコンを作る時に欲しいなって思って。

webでドット絵にする方法は実はcssで影を付けるという方法(box-shadow)もあるんですがsvgデータはcssにテキストで書き込む事も出来るし、ファイルとして保存すればキャッシュ出来るし、単独で管理できるので便利だろうなって。

ただまぁドット絵にすると座標の埋め込み列挙になるので本来最強の軽量形式ですが今回は利点が少し損なわれています。まぁ、それでも十分軽量ですけどね。

他の理由

今回は他にcssフレームワークのテイルウィンド（Tailwind）を使って見たかったという理由もあります。
Tailwindはオープンソースで利用に制限が無く、CDN (Content Delivery Network) 形式で簡単に実装出来るのでお試しです。
ちなみに、CDNを使った場合、consoleにも表示されますが「遅いから本番環境で使うのはやめておけ」みたいなメッセージが表示されます。
Tailwind君が何が言いたいのかというと、別に使うのは禁止しないけどデータ群が大きいのでテストサイト等には便利だが本番で使うにはページの表示が遅くなるよって事です。

(一応補足するとちゃんと使うならTailwindはビルドして必要なスタイルだけを適用するのでCDNを使わなければ遅いわけではないです。)

まぁ、今回作ったページの速度を見る限りはCDNでも問題なさそうに感じます。
むしろ触ってみた感じではコードが気持ち悪いという印象の方が強いです。

これはまぁリアクトのコード見た時みたいな拒否反応なのでなれの問題というのは分かっています。
でもやはり、タグで構成するWebデザインという構造上このスタイルはこの為に定義している(headerとかtop-menuなど)名称みたいな方が正しいような気がします。
後ですり替える際もhtmlを変更しないで良い訳ですし。

しかし、分離したcssで定義を書くならhtmlに書いても変わらないだという気持ちもわかります。
なおかつ記述はcssの通常記述よりも短いし、style名称を毎回考えなくても良いという利点もありますので。

でもhtml内の可読性が酷いような。
styleでゴリゴリに書いてるような感覚になる。しかもいっそstyleで全部書いた方がCDNを通さない分早い。
リアクトでも関心の分離的にえぐいと思ったけどあれは機能に対してデザイン込みで含めるものなのでまだ理解出来る。

今回は全体的に「その気持ちは分かる」と「でもそれは辛くない？」が交錯しながら作ってました。閑話休題。

使い方

話を戻して使い方ですが、スマホのタップでもPCのクリックでもポチポチ出ます。
フリーラインなのでドラッグとかでもそのまま描けます。
「消しゴムボタン」
押すと消しゴムに切り替わりもう一度押すか色変更で鉛筆に戻ります。

「全消去」を押すと全てを消します。
ピクセルカンバスサイズを変更しても同様に全て消えます。

「タグコピー」はテキストデータをそのままコピーします。
メモ帳を開いて「ファイル名.svg」で保存すればすぐ使えます。

「SVGでDL」はデータをsvgで直接保存できます。
まぁ元々がテキストデータなので拡張子を変更してるに過ぎません。

感想としてはそこそこいい感じに出来たので満足です(*´ω｀*)

■余談
最初ドット絵メーカーにしてたけどエディタに名称変えた

DockerDesktopを入れてみる

Docker Desktopとは

まずはそもそもDocker Desktopが何なのかという所から。
「開発者向けの共同コンテナ化ソフトウェア」と説明されるけどつまりどういうこと？と思う人が多い気がしますのでもっと詳しく。

要するに「実行環境を隔離する技術」です。
確実に隔離するならVM(仮想PC)で良いですが、PC内でPCを起動させると起動までの動作などが遅い。
そこでDockerです。
「実行環境ごとアプリを最低構成で１つまとめる」これがコンテナ化という事です。
全体をエミュレートするVMと違い軽量で高速に起動と実行が可能

このコンテナはLinuxカーネルで動作し、OSなどで環境変わってもこのコンテナ内で動作するので自身のPC→テスト環境(サーバ)→本番環境(サーバ)みたいな移行や他の人のPCで移しても最低限の設定でどこでも同じ様に動作するという事です。

物理的な貨物コンテナの様にコンテナ内に作った機能を簡単に移動できる事ですね。
先述した通りこのコンテナはLinuxカーネルで動作するのでWindowsやMacなどの場合は必ずLinuxが必要です。
ただし、LinuxOSをフルで入れる必要はなく、カーネル(プロセス処理など最低構成)だけあれば動作します。

イメージとしては「ユーザー操作→OS→小さなLinux→コンテナ(アプリ)」たったこれだけです。
アプリなどの機能自体はLinuxコンテナ上で動くようになっていて、動作が保証されています。
基本的なPC操作などはホストのOS側で制御し、それを小さなLinuxVMで操作を情報をパイプしてコンテナ内に伝える事でどこでも動作します。

DockerDesktopダウンロード

https://www.docker.com/ja-jp/get-started/

Mac、Windows、Linux各OS用が準備されています。
一般的なWindowsユーザーならAMD64です。

(※左下の「スタートボタン」を右クリック ＞ 「システム」 を開く。「システムの種類」 という項目を見てください。「64 ビット オペレーティング システム、x64 ベース プロセッサ」 と書いてあれば ➡ Windows版のダウンロード - AMD64「ARM ベース プロセッサ」 と書いてあれば ➡ Windows版のダウンロード - ARM64 （最近のSurface Proの一部などがこれです）)

DockerDesktopインストール

1. Use WSL 2 instead of Hyper-V (recommended)
「Hyper-Vの代わりに WSL 2 を使って動かします（推奨）」
 Windowsの中でLinuxの仕組みを効率よく動かすための最新技術（WSL 2）を使う設定です。昔の技術（Hyper-V）より圧倒的に動作が速く、PCへの負担も少ないため、必ずチェックを入れたままにします。

2. Allow Windows Containers to be used with this installation
「Windowsコンテナも使えるようにしますか？」
ここはチェックを外したままでOK。世の中のほとんどのDockerアプリは「Linux用」として作られています。これをオンにするとWindows専用の特殊なコンテナ用設定になります

3. Add shortcut to desktop
 「デスクトップにショートカットを作成する」
 お好みですが、管理画面をすぐ開けるようにチェックを入れておくと便利です。

■「Close and restart（閉じて再起動）」

押すと強制でPCが再起動します。
何か作業途中などの場合は保存などしてから押してください。

■規約確認

1. 「Accept（同意）」
個人利用や、学習目的、あるいは小さな会社での利用であれば、そのまま**「Accept」**を押して進めて問題ありません。

2. 無料で使える条件（Docker Personal）以下のいずれかに当てはまる場合は、無料で使い続けることができます。
個人利用（趣味や学習など）教育機関やオープンソースプロジェクトでの利用小規模企業（従業員250人未満、かつ年間売上高1,000万ドル＝約15億円未満）

3. 有料になる条件上記の「小規模企業」の基準を超える大きな会社で業務利用する場合は、有料サブスクリプション（Pro, Team, Businessなど）の契約が必要になります

※2026年1月時点

■初回起動：WSLインストール
Powershellで「wsl --update」を入力してねと表示されます。
リンクにある通り「https://learn.microsoft.com/en-us/windows/wsl/install」で何のコマンドかちゃんとか確認してから入力してください。
(危険なコマンドなどでは無いですがユーザーにコマンドを入れさせるというのは普通はあまりないです。リンク先の内容はWindows 上で Linux を動かすための WSL (Windows Subsystem for Linux) をインストール・設定する方法が詳しく記載されています。)

最初に説明してる通りDockerDesktopはLinuxカーネルが必要なのでWSLインストールが必要です。

Windowsの検索バーに「Powershell」と入力すればこんな画面になるので一番上のPowershellをそのまま起動

（ちなみに、Windows PowerShell ISEのISE は「Integrated Scripting Environment（統合スクリプト環境）」の略です。長いプログラム（スクリプト）を書いて保存したり、間違いがないかチェック（デバッグ）したりするための「書き物用」のツールです。上半分がメモ帳のようなエディタ、下半分が実行画面になっています。今回ISEは選ばない）

Powershellが起動したら画面上で「wsl --update」を入力。
(コピペする場合はPowershell上で右クリックすると貼り付けされます）
エンターを押せばWSLのインストールが始まります。

WSLのインストールが終わったらDocker Desktopに戻って「WSL needs updating」のままなので、中央の 「Restart」 ボタンを押してください。

これでセットアップ終了です

■オマケ

VSCが入ってるならここら辺がVSC側から推奨されます。

GoogleAdSenseについて調べた話

個人サイトは弄ってるから何かお金にならないかなって今回はグーグルアドセンスについて調べてみた。

結果から言うとそもそも無理でした。
サイトは無料サーバーなんだけど、無料サーバー系は基本サブドメインなんです。
私が使っているサーバーも例に漏れずサブドメイン。
調べたところによると使い捨てサイトになる可能性が高いからサブドメイン系はそもそも申請自体が出来ないという事が分かりました。

折角調べたので備忘ついでに記事にしておこうっていうのが今回のお話。

アドセンスに必要なもの

• グーグルアカウント
• 独自ドメイン(サブドメイン不可)
• サイト(または、ブログ※)
• SSL化（https://）
• グーグルポリシーの順守
• プライバシーポリシーページ
• クッキー等について全文省略なしの記述
• お問い合わせフォーム※
• 基本全ページからポリシーページへのリンク

Googleアカウント

アドセンスの申し込みにはGoogleアカウントが必須です。普段使っているものでも可能ですが、サイト運営用のアドレスを別途用意しておくと、収益通知や重要なお知らせの管理がしやすくなります。

独自ドメイン

無料サーバーのサブドメイン（例：〇〇.fc2.comなど）では、現在アドセンスの新規申請は原則できません。
自分専用の住所である「独自ドメイン（.comや.jpなど）」を取得しましょう。
これはサイトの信頼性を証明する第一歩となります。

色々調べてみたんですが独自ドメインは無料で取得できるのはおそらく無いのでこればかりは毎月払いで契約が必要になります。

サイト（またはブログ）

独自ドメインを適用し、中身のあるコンテンツ（記事）が掲載されているサイトが必要です。
目安として1,000〜2,000文字程度の記事が10〜20記事ほど公開されている状態で申請するのが一般的。

・レンタルサーバー

ウェブサイトを運営するっていうのはデータを入れる「サーバー」と発信するための場所「ドメイン」の２つがあって初めてウェブサイトが運営出来ます。
無料レンタルサーバーの場合「サーバースペース＋サブドメイン」がセットになっているのでただウェブサイトを作るだけなら気にする必要はないですが、今回の目的である「独自ドメインのサイト」となった場合は課金が必要になります。

無料サーバーで「独自ドメイン○個」みたいな記述がある会社もありますが、あれは「独自ドメインを登録が出来る」って意味であり、無料レンタルサーバーにはサブドメインしか選べないのが普通です。

正直な所「無料サーバー＋有料ドメイン」にするぐらいだったら「有料レンタルサーバー＆独自ドメイン」を扱っている所が良いかと思います。

一応独自ドメインを単独で契約する利点はあります。
ドメインが単独ならレンタルサーバーを移動出来るからです。

※ブログの場合

「※ブログ」と表示しましたがブログは審査が通りにくいみたいです。
というのもブログはその会社のサブドメインになるのでやはり使い捨てされる可能性が高いという事ですね。
(一応、審査通る可能性が0%って事ではないです)

ただし、唯一確実に申請自体は確実に出来るものがあります！
それが今記事を書いてるブロガーです。
Google傘下のブログシステムなのでそもそもブログのメインメニュー内に収益項目があってサブドメインとかのチェックがありません。

当然ですが、あくまでも審査の開始までが100%なだけであって審査が必ず通るってわけでは無いです。

SSL化（https://）

URLが「http」ではなく「https」で始まる状態にすることです。
通信を暗号化してユーザーを保護する仕組みで、現代のサイト運営においてセキュリティ面から必須条件となっています。

これに関しては基本どのレンタルサーバーでも対応してるはずです。
というか現在は無料サーバーであっても未対応な会社はないんじゃないかと思います。

Googleポリシーの遵守

Googleが定める「パブリッシャー向けポリシー」に違反していないことが絶対条件です。
著作権侵害、アダルトコンテンツ、暴力的な表現など、公序良俗に反する内容が含まれていると審査に通りません。

一般的なコンテンツを扱う限りは大丈夫です。

プライバシーポリシーページ

「ユーザーの個人情報をどのように扱うか」を説明する独立した固定ページです。
アドセンスを利用するサイトには、法律や規約に基づいた明文化された方針が求められます。

クッキー等について全文省略なしの記述

プライバシーポリシー内には、「広告配信のためにクッキー（Cookie）を使用すること」や「Googleなどの第三者配信事業者がアクセス情報に基づき広告を表示すること」を正確に記載する必要があります。これはGoogleの利用規約でも定められています。

お問い合わせフォーム

サイトの信頼性を高めるため、運営者に連絡が取れる窓口を設置します。
プラグインや外部サービスを利用して、専用のメールフォームを作っておくのが最も望ましい形です。

一応、規約的に必須ではない・・・のですが審査的にほぼ必須なものになるようです。
更に言えば必ずもフォームじゃなくてもメールアドレスのリンクなどがあればよいというか連絡を出来る方法があればよいという事みたいです。

基本全ページからポリシーページへのリンク

作成したプライバシーポリシーは、サイトのどこからでもアクセスできるようにする必要があります。
通常は「フッター（ページ最下部）」にリンクを配置し、全ての訪問者がいつでも確認できるように設定します。

これも必ず全ページからリンクしろって規約があるわけではないですが実質審査的にはほぼほぼ必須みたいですね。

---

※最後に、あくまでもこれが基本というだけで、登録や申請をするときはGoogleの規約を個々でちゃんと読んで下さいね。

補足でもう一つだけ、仮にアドセンスが通った場合にお金を受け取れる最低ラインというものがあって、日本円だと約8000円を超えないと収益を換金出来ません。
よほど人気サイトじゃないと厳しい・・・。

てなわけで、サイトのアドセンスは一旦諦め

ゲーム情報的には結構コアで有意義な情報を提供してるけどまぁあれは趣味なのであんまり頑張らなくて良いかなって。
ツール系はurlで復元出来る機能つけてるからドメイン取って変更すると古いurlがアクセス出来なくなって復元出来なくなるし、副次的な話でいえばページランクも一時的に落ちちゃうだろうし。
上の補足でも書いた通り内容がコア過ぎてサイトのPVあんまりないので仮に可能だったところで収益を受け取るには１・２年以上…いやもっとかかるかもなので。

ちなみに、もしサイトで収益が出せるなら無料サーバーのオーバーレイ広告？を外したいなって思ってたんだけど暫くは無理そうですね_(:3 」∠)_

Automatic Semicolon Insertion; ASIで沼った話

久々に原因特定に時間が掛かったので備忘録。

今回問題になったのが「Automatic Semicolon Insertion」、通称ASIによる影響です。

直訳すれば「自動セミコロン挿入」ですが、簡単に言うと「セミコロン（;）で処理を自動的に終了位置として判定してくれるよ」という仕組み。
コード自体が勝手に書き換わるわけではなく、JavaScriptエンジンがセミコロンを「挿入したつもり」で文の境界を解釈します。
便利な機能ではあるのですがちょっとした「落とし穴」になりえるのでJavaScript弄っている人は暇つぶしにでも読んでみてください。

ASIって何？（＝処理末端解釈）

ASIの最大の目的は、開発者の利便性向上です。JavaScriptはインタープリタ系言語の代表格で、型指定が不要、変数の自動型変換が可能という「ゆるさ」が売り。

数千行のコードを書くときに、毎文の終わりにセミコロンを手動で付けるなんて面倒くさいですよね？ ASIがあれば、エンジンが自動でセミコロンを「仮想挿入」して文を区切ってくれるので、セミコロン漏れの心配が減ります。

JavaScriptのようなスクリプト言語は、C++やJavaのようなコンパイル言語と比べて、型の指定が不要であったり、変数の型が自動変換されたりと、開発の自由度やスピードが重視される傾向にあります。ASIもまた、開発者の負担を減らし、柔軟な記述を可能にする自然な流れと言えます。

ASIの落とし穴

ASIの問題は、文の境界が曖昧になる点にあります。

簡単に言えば「自動判定」が誤作動する…いやまぁ機械的に処理してるわけだから正確にはユーザーがASIが意識の外にある場合があるってだけですが。
最も有名なのがreturn文の例です。

return // ここで改行
a + 1

本来は a + 1 の結果を返したい意図で書いたとしても、JavaScriptは改行された時点で「ここで処理が終わったな」と判断し、内部的に以下のように解釈します。

return; //  ASIによってセミコロンが挿入
a + 1;  //  別の処理として解釈

結果、returnは何も値を返さず処理が終了し、期待した動作になりません。JavaScriptは変数名やメソッド名の途中ではない限り、基本的にどこでも改行可能なので、この自由さがASIと衝突することで、予期せぬ挙動を生み出すのです。

今回、ASIで沼った話

さて、本題の「ASIで沼った話」。これは単純なイベントリスナー登録の話です。

と、その前に、通常はこの様に書きますが

document.getElementById(id).addEventListener(type, listener);

個人コーディングの時はBSCオリジナルラッパーを使っているので

$i('aaa').ael('change', bbb);

こんな感じに圧縮記述出来ます。

普段、可読性を重視して、リスナーは次のように列挙して記述しています。

$i('aaa1').ael('change', bbb)
$i('aaa2').ael('change', bbb)
$i('aaa3').ael('change', bbb)

これは何の問題もありません。ASIによって、各行の末尾にセミコロンが補完され、それぞれ独立した処理として実行されます。まさに「ASI様様」という状態です。

リスナーをまとめてみた

今回は同じ関数を呼ぶ処理があったので可読性と効率を考えて、forEachでまとめて登録することにしました。

// リスナーまとめエリアでの記述
['aaaAbc','aaaDef','aaaGhi'].forEach(id=>{$i(id).ael('change', aaaAAA);});

このコード自体はテストして問題もありません。
DOMも読み込み済みでこれといったエラーはありません。

ところが、このコードを「リスナーまとめエリア」に移動した瞬間、aaaGhiの要素でエラーが発生！ 原因不明で頭を抱えました。DOMはOK、個別記述ならOK、隔離してもOK、上部移動してもOK。でも、このエリアに置くとダメ…。

沼の原因：配列の誤解釈

forEachをばらせば正常になるのでバラで登録しても良かったんですが今後の為にも一応調査した事で一応特定は出来ました。

今回の具体的な配置は以下の通りです。

$i('aaa1').ael('change', bbb) // 1行目
$i('aaa2').ael('change', bbb) // 2行目
$i('aaa3').ael('change', bbb) // 3行目
['aaaAbc','aaaDef','aaaGhi'].forEach(id=>{$i(id).ael('change', aaaAAA);}); // 4行目

実は、内部的に発生していたのは、3行目と4行目の結合でした。

$i('aaa3').ael('change', bbb)['aaaAbc','aaaDef','aaaGhi'].forEach(id=>{$i(id).ael('change', aaaAAA);});

JavaScriptのインタプリタはこの様に解釈しました。

具体的には：

1. $i('aaa3').ael('change', bbb) の実行結果（addEventListenerは通常 undefined などの値を返します）
2. その結果に対して、次の行の配列をインデックスとしてアクセスしようとする
3. undefinedなどの値に配列アクセス（[ ]）を試みたためエラーが発生
4. 結果的に「undefined.addEventListener」のような状態になり、処理全体が破綻した

改行によって処理の継続と判断される箇所で、たまたま次の行が(や[など、前の行の処理の続きと解釈できる記号で始まっていたため、ASIが発動せず、予期せぬ文法解釈（配列アクセス）が行われてしまったという事ですね。

利便性 vs リスク：JavaScriptのジレンマ

結局、ASIでセミコロンから解放されたはずなのに、「セミコロンを明示的に付けた方が安全」

という話になりますが、そうなると「ASIの存在意義は？」という根本的な問いに行き着きます。

①自由さと厳密さのトレードオフ

JavaScriptの設計思想は元々「柔軟な記述」を重視していますが、現在のコーディングの潮流はより厳密な方向に向かっています。

②TypeScriptという名のJavaScript
TypeScriptという言葉を聞いたことがある人も居るかもしれませんが、JavaScriptに静的型付けの概念を持ち込み、コンパイル時に厳密なチェックを可能することでコーディングを厳格堅牢にできます。
ですが・・・結局のTypeScriptはJavaScriptに過ぎません。コンパイルという表現を使いますが一般的なプログラムのように機械語にするわけでは無い為、処理が高速化するわけでもありません。
JavaScriptは結局ブラウザ依存です。つまり、折角型を付けたコードを削除して低級のJavaScriptに戻すというここだけ聞くと馬鹿らしい処理をしています。

個人的に最近はモジュール形式（.mjs）で書くことが増えましたが、これはローカルスコープやstrict modeの適用など、より厳格なコーディングを促しますがASIは有効です。

JavaScriptの未来：柔軟性と厳格性の狭間

正直、現状のJavaScriptがどこを目指しているのか、掴みどころがありません。

柔軟性を保ち続けたいのか、それともTypeScriptのような厳格な方向へ完全にシフトしてしまうのか。言語には通常、何らかの明確な「信念」がありますよね。

例えば、C言語系は高速実行を、Javaはプラットフォーム非依存を、Pythonは読みやすさと生産性を、PerlやRubyは簡潔さを、それぞれの強みとして進化させてきました。一方、JavaScriptは「どっちつかず」の状態が長すぎて、信念のなさが逆にその独自の魅力——いや、ブレブレの個性——を生んでいる気がします。

もちろん、見守るしかない部分もありますが、心から願うのは、この「ゆるさ」が失われないことくらいでしょうか・・・。

まとめ

• セミコロンを積極的に付ける：ASIに頼りすぎず、明示的に。
• 改行前に一文完結を確認：returnやメソッドチェーンの後、特に注意。
• ツール活用：PrettierやESLintで自動整形・警告を。
• テストを忘れず：個別動作OKでも、文脈で壊れる可能性あり。