2026年1月14日水曜日

React-TailwindでCDN経由で使ってみる

Reactを使ってみよう!

今回はいたって単純React使ってみようという話です。
CDN経由で使えるのでどんな感じかを直ぐに試せるのは本当に良い時代です。
一応順を追って説明しますね

CDN (Contents Delivery Network) とは

まずコンテンツ・デリバリー・ネットワークで使えるというのがどういうことかというと、通常ライブラリとかフレームワークはダウンロードしてきてサーバーアップロードして参照したりしないといけない。
正直面倒臭いし、ブログなどではそもそもサーバにファイルが置けない。
そんな時にCDNです。
CDNは超簡単に言えば直リンクです
JSとかcssとかに直リンクして必要な結果だけを貰う。
ただし、昨今のCDNはデータサイズが大きいので重いです。例えば、Tailwindcssとかはcssって名前ではあるものの実際にはjsを経由してcssのデータを貰う形です。
全乗せのcss情報が来るのでサイズが大き目でリンク時のコンソールにもCDNでの本番運用だと遅いから推奨しないって内容の文字が裏で表示されます
他にも少し問題がありますが一旦後で説明します。
取り合えず超簡単にまとめると「便利機能がリンクするだけで使える様になる」です。

Reactとは

さて、本題のリアクトとはjavascriptのフレームワークです。
jsxで記述する事でタグとjavascriptを一つにまとめる事が出来ます。
初見では相当気持ち悪さを感じますがみんながみんな慣れるというので慣れなんだと思います。
また、Tailwindとの相性がよくcssを別途使わなくても短い記述でstyleも含めて記述する事が出来ます。クラス名を考えなくて良いという事もあり開発速度が上がります。

CDNでReactで使う場合

先ほど「他にも少し問題が」って言いましたがCDN経由ビルドとなるのでmjsでは利用できません。
私は自作のDOMラッパーをインポートしたりするので最近はmjsが多かったのですが今回は使えません。
何故使えないのかというとまずjsxのアクセス方法が<script type="text/babel" src="jsx.js"></script>こんな感じですね。
babelに投げてビルドしてもらうという事ですね。投げたjsxはjavascriptとして返ってきて始めて動作するのですがbabel君は外部接続できないのでimport文が利用出来ません。
スクリプトのアクセス方法をmjsにするとそもそもbabelにデータが渡せません。

つまり変数がグローバル化してしまうという事です。
まぁ、それだけといえばそれだけです。

Reactのおおまかな流れ

①ReactDOMから必要な機能を取り出す

const { createRoot } = ReactDOM;

分割代入で取り出すのが一番楽かと思います。
一応、ReactDOMから取り出してるだけなので
const a=ReactDOM.createRootでも
const a=ReactDOM['createRoot']でもアクセスは可能です。

②コンポーネントを作る

例えば以下の様にfooterを作ってみます

const Footer = () => (
    <footer className="py-8 border-t border-[#1a1a1a] bg-[#050505]">
        <div className="max-w-[1280px] mx-auto px-5 text-center text-xs text-[#555]">
            <p>©black stray cat</p>
        </div>
    </footer>
);

定数にFooterを定義無名関数でそのまま内容を書きます。
ほぼほぼタグをそのまま記述可能ですがclassはバニラJavascriptで定義されているためJSXではclassNameにする必要があります。
ちなみに「ケースセンシティブ (case-sensitive)」なのでFooterの頭をFにする事でタグのfooterと別の判定になります。Reactは 「小文字で始まるものは通常のHTMLタグ」「大文字で始まるものはカスタムコンポーネント」 と自動で判別します。そのため、自作コンポーネントは必ず大文字で始める必要があります。

③レンダリングする

const footerEl = document.getElementById('footer-root');
if (footerEl) createRoot(footerEl).render(<Footer />);

処理的には先ずDOMを定義して次に存在確認存在したらレンダリング
先ほどReactDOMから取り出した機能を使います。
renderに指定する中身は定数に定義したコンポーネント名です。
今回で言えば「<Footer />」こうですね。

④html側

<div id="footer-root"></div>

こんな感じです
先ほどgetElementById指定した所に内容を生成します。
このdivの内側に予定と違う内容あれば全て書き換えます。

挙動だけを見るとinnerHTMLに近いものだと思ってもあまり問題ないです。
ただし内部的には仮想DOMで極力再利用する様に処理されます。
innerHTMLの場合は全て破棄された後に書き変わる処理である為Reactの方がメモリ効率が良いし高速です。

つまり、事前に使うhtmlを用意しておくと読み込みが早くなります。
基本的にはNext.jsを使う事になると思いますがhtmlが無くても生成はされますので試す分には問題ないです。

この様にしてcss-in-jsがコンポーネントとして分離サイト内でパーツとして利用できます。
新たにサイト等を作る時にも同様の機能が欲しい時全て込み込みで移植出来ます。

CDNでReactでモジュール

さて、React19では可能というか19以降はインポートでしか行けない。
しかもインラインでしかjsxをビルド出来ない。
パーツをインラインで書くなら意味がない。

さらに色々な問題が発生します。
相対パスが外のurlと相対になり参照が上手くいかないとか、CDNのTailwindが先に処理されてReact19内で使うstyleが用意されないといった問題が起きる。
一応TWの対応はできる
  <script>
    tailwind.config = {
      safelist: [
        'hidden',
        'md:block',
        'md:hidden',
        'block',
        'w-8',
        'h-8',
        'py-4',
        'bg-[#050505]',
        // 例えば事前に読み込む必要がでる
      ]
    }
  </script>
のように先に使うものを指定しておく・・・ただこれを手動でやるのはCDNの手軽さが損なわれる。TWの参照が前後するならもう普通のスタイルを埋め込んだ方が確実。

React19の一応使い方としてはまず呼び出しは
  <!-- importmap:React 19 -->
  <script type="importmap">
  {
    "imports": {
      "react": "https://esm.sh/react@19.2.0",
      "react-dom/client": "https://esm.sh/react-dom@19.2.0/client"
    }
  }
  </script>

  <!-- tsxでJSX変換 -->
  <script type="module" src="https://esm.sh/tsx"></script>
この様に変更します
コード呼びは
<script type="text/babel">ここにインラインで記述
そしてReact呼び出しは今回インポートに変わります
    import React, { useState } from "react";
    import { createRoot } from "react-dom/client";
JSXに基本的な記述変更ありません
CDNでReactをモジュールにするとかなり色々な相性が悪くなる
ただ、公式推奨はもう新しいReact19なんですよね・・・。

まとめ

cdnで使うという前提において
コードを外部参照できるのはReact18まで
この場合はTailwindもとても相性が良い

React19はコードを外置き出来ないインラインでしかjsxをビルド出来ない
コードを別ファイルで管理したい時の解決策は2つ
1.素直にReact18を使う(既にサポート終了ずみ余命のみ)
2.React19でjsxを記述せず純粋なjsモジュールとして使う

ただまぁReactをバニラjsのmjsで利用すると変化癖がつく可能性があるにはある
たぶん現在の一般的な使い方はjsxで記述するのが普通だろうし・・・。
やはりCDNは個人サイトとかで使う場合であってもお試しが限界かなぁ

2026年1月12日月曜日

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使えるし・・・。
ただベタデータは重い為変換して軽量化しないと描画が遅れる為、モダン開発環境を享受しつつユーザー体験を損なわない為には変換祭りをしなければない。

2026年1月11日日曜日

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

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

環境変数は超簡単に言えばただの「良く使う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+Rから指定実行で「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階層SYSTEMWindowsの起動や動作に絶対必要な「核」となるデータ。
第3階層CurrentControlSet今まさに正常に動いているドライバーやサービスの設定セット。
第4階層Controlタイムゾーン、マウス、キーボード、ファイルシステムなどの挙動設定。
第5階層Session ManagerOS起動時のプログラム実行順序や、メモリ管理などの「下準備」データ。
第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 バイナリ形式。人間には読めない形式。 特殊な構成情報の保存用など

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

2026年1月7日水曜日

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」になるのでもう一度アクティベートしようとすると


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

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

2026年1月6日火曜日

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で直接保存できます。
まぁ元々がテキストデータなので拡張子を変更してるに過ぎません。

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

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

2026年1月3日土曜日

DockerDesktopを入れてみる

Docker Desktopとは

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

要するに「実行環境を隔離する技術」です。
確実に隔離するならVM(仮想PC)で良いですが、PC内でPCを起動させると起動までの動作などが遅い。
そこでDockerです。
実行環境ごとアプリを最低構成で1つまとめる」これがコンテナ化という事です。
全体をエミュレートする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側から推奨されます。

2025年12月19日金曜日

GoogleAdSenseについて調べた話

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

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

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

アドセンスに必要なもの

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

Googleアカウント

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

独自ドメイン

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

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

サイト(またはブログ)

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

・レンタルサーバー

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

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

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

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

※ブログの場合

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

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

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

SSL化(https://)

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

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

Googleポリシーの遵守

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

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

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

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

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

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

お問い合わせフォーム

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

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

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

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

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


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

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

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

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

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