Kangetsu Blog RSS Feed

GitHub の Secrets に JSON などの構造化データを登録してはいけない

Tue, 03 Jan 2023 00:00:00 GMT

JSON などは GitHub Secrets にそのまま登録してはいけない

表題の通り、JSON をはじめとした構造化データを GitHub の Secrets に登録することは非推奨です。これは GitHub 公式ドキュメントで、以下の通り明言されています¹。

To help ensure that GitHub redacts your secret in logs, avoid using structured data as the values of secrets. For example, avoid creating secrets that contain JSON or encoded Git blobs.

具体的には、一例として actions/runner の Issue で問題になったケースが報告されています。

I have this json secrets. And this will give readable prints which is not very secret. Only { and } are masked.
Registered secrets
{
  "id": 123,
  "uname": "john-doe",
  "password": "foobar"
}
Workflow example
      - run:  echo "${{ secrets.ITEM_JSON }}"
Output
***
  id: 123,
  uname: john-doe,
  password: foobar
***

このケースでは、Secrets に登録した JSON のうち {} のみが秘匿化され、本当に隠したいはずのその内側の key / value ペアはそのまま出力されてしまっています。このように、JSON 形式の Secrets を登録しても、適切に Secrets が秘匿化されずに露出するなどの問題が起きる場合があります。

JSON 形式の秘密情報を GitHub Secrets に登録している記事をいくつか見かけますが、非推奨なのでご注意ください。

代替案

では JSON のようなデータを Secrets で扱いたい場合どうしたら良いかですが、公式ドキュメントに記載がある方法を使えます。

1. Base64 でフラットな構造にする

例えば、Base64 でフラットなデータ構造にして登録することは可能です。そしてそのデータを取り出す時にデコードして利用します。

cf. https://docs.github.com/en/actions/security-guides/encrypted-secrets#storing-base64-binary-blobs-as-secrets

base64 コマンドの利用方法は base64(1) の man などを参照してください。

なお、Base64 エンコーディングは容易にデコード可能なので、Base64 エンコードした値が露出することは必ず避けてください。
言うまでもなく、Base64 でデコードした値ももちろん露出させてはいけません。

Base64 エンコーディング時の注意点

Base64 エンコードしたデータを Secrets に登録する際は、エンコードした値から改行コードを取り除いてから Secrets に登録 する必要があります。
これをしないと、デコード時に改行コード部分までで区切られてしまい、中途半端なデータしか得られませんのでご注意ください。

2. 暗号化したファイルをリポジトリに登録し、そのファイルの複合キー・パスフレーズを Secrets に登録する

大きいサイズの Secrets を利用する workaround として紹介されているものですが、Storing large secrets の方法も使えます。

結論

JSON をはじめとする構造化データは GitHub Secrets に登録する際は気をつけてください。
Base64 でフラットな構造にする、暗号化したファイルの複合キー・パスフレーズを Secrets に登録して利用するなどの workaround が公式ドキュメントで紹介されているのでそちらを参照して利用してください。

https://docs.github.com/en/actions/security-guides/encrypted-secrets#naming-your-secrets ↩

Discord フォーラムチャンネルの仕様について

Thu, 29 Dec 2022 00:00:00 GMT

Discord のフォーラムチャンネル (Forum Channel) は一週間投稿がないと自動アーカイブされる

とあるきっかけで、Discord のフォーラムチャンネルについて調べる機会がありました。問題としては、「勝手に Discord のフォーラムチャンネルが見えなくなって困るが回避方法はあるか」というものでした。

簡単に調べたところ、2022年12月現在では、一週間そのチャンネルに投稿がないと自動でアーカイブされる ようです。参考にしたのは、以下の公式への Feedback です。 https://support.discord.com/hc/en-us/community/posts/8043171964183-Add-a-forum-archive-timer-for-a-month-year-or-infinite

The layout of the forum cards in a forum channel are great too but it's a shame they dissapear quickly after a week. That way I can not scroll forums for hours looking at interesting older posts about the game of the discord that I'm in.
I'd say extend the archive timer to months, years, inifinite. I know it will cost resources to upkeep these forum posts so maybe limit a forum post of x amount of MB to only a X amount of time.

Reddit にも同様の意見が投稿されています。 https://www.reddit.com/r/discordapp/comments/xrvuvy/feature_request_ability_to_disable_automatic/

We've noticed that these forum posts automatically get archived after a week of inactivity, causing our members to longer be able to see the channels. Can we please get the option to turn this automatic archiving off?

回避策としては、その場凌ぎ感は否めませんが、定期的にフォーラムチャンネルに投稿を行う bot を利用するなどはあります。

私自身は Discord のフォーラムチャンネルは使っていないのですが、困る人がいそうな仕様だけど、日本語の情報が見つけられなかったので記録しておきます。

作成済みの multipass インスタンスのリソースを後から変更する

Mon, 29 Aug 2022 00:00:00 GMT

multipass の disk を後から変更したかった

今使っているマシンが M1 Mac で, 開発には multipass の Ubuntu を使っています。開発中にインスタンスがディスクフルになってしまい, 事後的にディスクサイズを更新したのでその方法をメモします。

日本語であまり記事がなかったのと, これから困る人も出そうだから書き残しておきます。なお, ディスクだけでなく CPU やメモリなどの他のリソースも更新可能とのことです。

方法: `multipass set local.<instance-name>.(cpus|disk|memory)`

公式ドキュメントにあります。 multipass バージョン 1.1.0 から利用可能で, 2022/8/29 現在プレビュー機能です。

ドキュメントの通り, インスタンスを停止後, 以下のコマンドを実行すれば良いです:

multipass set local.<instance-name>.(cpus|disk|memory)

例えば, 私の場合ディスクを 40GB から 60GB にしたかったので, インスタンスの停止後に以下のコマンドを実行しました (ubuntu20 は私のインスタンス名)。

multipass set local.Ubuntu20.disk=60GB

ヘルプを見るともっとわかりやすいかもしれません。 <key> が local.Ubuntu20.disk で, value が 60GB ですね。

$ multipass set -h
Usage: multipass set [options] <key>[=<value>]
Set, to the given value, the configuration setting corresponding to the given key.

Some common settings keys are:
  - client.gui.autostart
  - local.driver
  - local.privileged-mounts

Use `multipass get --keys` to obtain the full list of available settings at any given time.

Options:
  -h, --help     Displays help on commandline options
  -v, --verbose  Increase logging verbosity. Repeat the 'v' in the short option
                 for more detail. Maximum verbosity is obtained with 4 (or more)
                 v's, i.e. -vvvv.

Arguments:
  keyval         A key, or a key-value pair. The key specifies a path to the
                 setting to configure. The value is its intended value. If only
                 the key is given, the value will be prompted for.

コマンドが成功したらインスタンスを起動すれば終わりです。簡単にできてありがたい限り。

jsx ファイルを tsx ファイルに一括置換する

Fri, 19 Aug 2022 00:00:00 GMT

TypeScript 移行するときに既存の JSX ファイルを一括置換したかった

このブログは Gatsby.js で書いているのですが, JavaScript から TypeScript に移行しました。このときに, .jsx から .tsx にファイルの拡張子を置換したのですが, 一つ一つやっているととても大変なのでワンライナーでやりました。

そのメモです。

コマンド

以下のコマンドで実行しました。なお, もし実行する際は 必ず echo などで期待結果になるか確かめてから実行してください。当ブログでは実行の結果に責任を持ちません。

# カレントディレクトリ以下の jsx ファイルを tsx ファイルに置換する

# echo による確認を必ず先にする
find ./ -name *.jsx | while read f; do echo $f ${f%.*}.tsx; done
# mv で実際に置換する
find ./ -name *.jsx | while read f; do mv $f ${f%.*}.tsx; done

コマンドの解説

分解して順に解説します。

1. `find ./ -name *.jsx`

実行内容: カレントディレクトリ以下の .jsx ファイルのパスを全て取得

実行例:

kangetsu@ubuntu20:~/work/my_blog$ find ./ -name *.jsx
./src/components/footer/Footer.jsx
./src/components/util/Note.jsx
./src/components/pagination/Pagination.jsx
./src/components/header/HeaderMenu.jsx
./src/components/header/Header.jsx
./src/components/sideMenu/SideMenu.jsx
./src/components/sideMenu/Tags.jsx
./src/components/sideMenu/SideSocialList.jsx
./src/components/sideMenu/SideAuthorProfile.jsx
./src/components/sideMenu/SideAboutBlog.jsx
./src/components/Layout.jsx
./src/components/main/Main.jsx
./src/components/main/ArticleSummary.jsx
./src/components/Seo.jsx
./src/templates/tagPages.jsx
./src/templates/articleList.jsx
./src/pages/{mdx.slug}.jsx
./src/pages/404.jsx
kangetsu@ubuntu20:~/work/my_blog$

./: カレントディレクトリを指す
-name: -name の後で指定したパターンにマッチするファイルを検索する

詳細は find コマンドの man を見てください。単純に名前パターンで jsx ファイルのパスを取得しているだけ。

2. `| while read f; do mv $f ${f%.*}.tsx; done`

実行内容: 1. find ./ -name *.jsx で得られた結果 (カレントディレクトリ以下の全ての .jsx ファイルのパス) を | で標準入力として渡して, while ループで回して一つずつ mv コマンドで .tsx にリネーム

mv ではなく echo の 実行例:

kangetsu@ubuntu20:~/work/my_blog$ find ./ -name *.jsx | while read f; do echo $f ${f%.*}.tsx; done
./src/components/footer/Footer.jsx ./src/components/footer/Footer.tsx
./src/components/util/Note.jsx ./src/components/util/Note.tsx
./src/components/pagination/Pagination.jsx ./src/components/pagination/Pagination.tsx
./src/components/header/HeaderMenu.jsx ./src/components/header/HeaderMenu.tsx
./src/components/header/Header.jsx ./src/components/header/Header.tsx
./src/components/sideMenu/SideMenu.jsx ./src/components/sideMenu/SideMenu.tsx
./src/components/sideMenu/Tags.jsx ./src/components/sideMenu/Tags.tsx
./src/components/sideMenu/SideSocialList.jsx ./src/components/sideMenu/SideSocialList.tsx
./src/components/sideMenu/SideAuthorProfile.jsx ./src/components/sideMenu/SideAuthorProfile.tsx
./src/components/sideMenu/SideAboutBlog.jsx ./src/components/sideMenu/SideAboutBlog.tsx
./src/components/Layout.jsx ./src/components/Layout.tsx
./src/components/main/Main.jsx ./src/components/main/Main.tsx
./src/components/main/ArticleSummary.jsx ./src/components/main/ArticleSummary.tsx
./src/components/Seo.jsx ./src/components/Seo.tsx
./src/templates/tagPages.jsx ./src/templates/tagPages.tsx
./src/templates/articleList.jsx ./src/templates/articleList.tsx
./src/pages/{mdx.slug}.jsx ./src/pages/{mdx.slug}.tsx
./src/pages/404.jsx ./src/pages/404.tsx
kangetsu@ubuntu20:~/work/my_blog$

while read f: 標準入力を一行ずつ読み込む。f は仮引数みたいなもの (変数名)

${f%.*}.tsx: ↑で指定した変数名 f を参照して, $fの拡張子を .tsx に置換

${f%.*}: シェルの変数参照で, ${f} の内容のうち % の後で指定した部分の後方最短一致で除去する。つまり ./src/pages/404.jsx だと .* に後方最短一致する部分を除去するので, .jsx がマッチして除去され ./src/pages/404 となる (${f%.*}.tsx としているので除去された結果の ./src/pages/404 に .tsx がつき, ./src/pages/404.tsx になる)。以下の bash の man 参照 (dash も同様):

[...]
    ${parameter%word}
    ${parameter%%word}
            Remove matching suffix pattern.  The word is expanded to produce a pattern just as in pathname expansion, and matched against the expanded value of parameter using the rules described under Pat‐
            tern Matching below.  If the pattern matches a trailing portion of the expanded value of parameter, then the result of the expansion is the expanded value of parameter with the shortest matching
            pattern (the ``%'' case) or the longest matching pattern (the ``%%'' case) deleted.  If parameter is @ or *, the pattern removal operation is applied to each positional parameter  in  turn,  and
            the  expansion  is the resultant list.  If parameter is an array variable subscripted with @ or *, the pattern removal operation is applied to each member of the array in turn, and the expansion
            is the resultant list.
[...]

もっと良い方法があるのかもしれないけど, とりあえずわたしはこれでやりたいことは実現できました。

GitHub 上で markdown ファイルをそのまま表示する

Tue, 31 May 2022 00:00:00 GMT

GitHub でのレビューで Markdown ファイルでも行数指定したい: モチベーション

短いので TL;DR なしで。

GitHub で, markdown ファイルをレビューするときがあります。 GitHub でのレビュー時, コードであればビューの左にある行数の部分をクリックすると、その行を指定した URL を取得できます。よくコードレビュー時に使う方が多いと思います。

しかし, markdown のファイルは, GitHub では通常 HTML に変換されて表示されるため, この行数指定ができません。このため, これまで私は苦肉の策として blame 画面で行数をポイントしていましたが, 本来の趣旨とは異なるので少し気持ち悪さがありました。

ところが, 先日他の方が GitHub 上で, blame を使わずに markdown ファイルの行数を指定した URL を取得できているのを発見しました。周知なのかもしれませんが, とても便利なので記録 & 共有します。

方法

GitHub 上で markdown ファイルを表示し, URL 末尾に ?plain=1 をつける です。

例: https://github.com/kangetsu121/my_blog/blob/e2ef0be04a90a7acc952e8da7331c97861d74a6f/README.md?plain=1#L1

なお, これは有名ですが, GitHub のリポジトリ上のファイルを開いている状態で y を押すと URL がパーマネントリンクになるので, これも組み合わせるのが便利です¹。
例えば y を押さない https://github.com/kangetsu121/my_blog/blob/main/README.md?plain=1 だと, URL が /main/ になっているので main リポジトリのそのファイルの内容が変わると URL が指し示す内容も変わるのですが, パーマネントリンクなら main が更新されてもその時の内容のままになります。

公式ドキュメント

GitHub 公式ドキュメントはこちらです。Linking to Markdown

History を見ると, この機能のドキュメントは 2022 年 1 月 12 日に公開されたようです。
https://github.com/github/docs/commits/main/content/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet.md

だから知らなかったのか。機能追加が嬉しい。

非常に便利なので積極的に使っていきたいですね。

Getting permanent links to files ↩

Markdown All in One と mdx ファイルを関連づける

Sun, 29 May 2022 00:00:00 GMT

TL;DR

mdx 形式のファイルを Markdown All in One に関連づけると, md の時と同じように自動補完などが使えて書きやすい
- やり方は VS Code の settings から mdx を markdown で解釈させるよう設定追加するだけ
ただし 2022 年 5 月 29 日現在で機能としては未対応なので JSX を書いた部分はハイライトされない

MDX でブログを書いているのでもっと便利に書きたい

私はエディタは VS Code を使っており, 読書メモなんかも markdown で書いているので, VS Code 拡張である Markdown All in One には大変お世話になっています。これを使うと, 例えば - や 1. などでリストを書いたときに, Enter を押しただけで次の行頭に - や 2. を自動挿入してくれたり, 単語を選択して _ や * を入力するとその単語の前後に挿入してくれて, 強調などが楽になるなど, 良い感じの補完をしてくれます。また, 私はほぼ書きませんが, 数式も書けます。

しかし, 先日はてなブログから Gatsby を使った自作ブログに移行したことで, mdx でブログを書くようになりました (今のところブログ移行の話を毎回書いてる気がする)。

この記事も mdx で書いているのですが, 残念ながら MArkdown All in One は 2022 年 5 月 29 日現在, mdx に対応していません。それでも mdx はほぼ markdown だし, JSX を書かないこともあるので, なんとか Markdown All in One を mdx でも使えないか調べました。

結論: VS Code の設定で mdx を関連づければ良いだけ

Ctrl (Command) + Shift + P でコマンドパレットを開く
settings と入力
出た候補の中から Preferences: Open Workspace Settings を開く (現在のワークスペースのみに反映させたい場合。常に適用したい場合は, ローカルの場合は Open Settings (UI), Remote Code で開発している場合は Open Remote Settings (SSH: <HOST>))
Markdown All in One Associations などで検索し, Files: Associations の Item に *mdx, Value に markdown と入力
または settings.json を直接編集する場合は, 以下のように記述
```
{
  "files.associations": {
    "*.mdx": "markdown"
  }
}
```

調査内容

ということで, プラグインのオプションから関連づけてやればいいだけでした。一応ここに至るまで少し調べもしたので, その内容を書いておきます。

やはり同じことを考えた方はいたようで, Markdown All in One のリポジトリの Issue が存在しました。
Suggestion: Allow extension to work within MDX files #758

この Issue は 2022 年 5 月 29 日現在, Open のままです。ただし, 上で書いたような暫定解決策が, プラグイン作者である yzhang-gh さんによってコメントされています。私もこれを読んで解決しました。

なお, Allow extension to activate in MDX files #759 で一度実装されたのですが, 実装が不適切だったようで revert されてますね。Issue は Closed になってますが, Issue #758 の通り依然根本解決はしていないままです。

補足: この解決法の問題や Gatsby での MDX 利用でつらいところ

なお, この解決法は, 単純に mdx ファイルを markdown として認識させただけです。MDX にあって Markdown にない, JSX などの記法は当然 Markdown All in One 本家が未対応なので, ハイライトされません。

また, このブログは Gatsby を利用していますが, 2022 年 5 月 29 日現在, Gatsby は MDX v2.0 に対応していません。 MDX 公式によると, MDX v2.0 では JavaScript の式が評価されるようになったり, コンパイル速度が速くなったり, バンドルサイズが小さくなったり, markdown 記法と JSX の組み合わせがより柔軟になったりと, 嬉しいことが多いので是非対応を待ちたいですね。

例えば MDX v2 では以下のようなコードを書いたときに, JSX の内部に markdown 記法で書いた文字列もちゃんと markdown として評価してくれます！ (v1 では # hi? は <h1><h1?/h1> にならないのです。素直に書いて評価されなかった時は思わずため息が出る気持ちになった)

<div>*hi*?</div>

<div>
  # hi?
</div>

<main>
  <div>

    # hi?

  </div>
</main>

Gatsby 公式でも着々と対応の準備は進んでいるようなので, 楽しみに待ちたいですね。
Feat: MDX v2 #35650

Gatsby で React の JSX Transform の新方式を導入し, ついでに新旧比較をしてみた

Sat, 28 May 2022 00:00:00 GMT

Note

本記事はフロントエンド技術に関わるものですが, 筆者はフロントエンドを本業でやっている人間ではありません。また, 本記事の結果は, あくまで偏った 1サンプルの結果のメモに過ぎないことにご留意ください。

TL;DR

Gatsby で React 17 から使える new JSX transform を試してみた
パフォーマンスやバンドルサイズに影響が出るかと思い旧来の方式と比較した
- 結果はパフォーマンスもバンドルサイズも旧方式の方が良かった
- ただし偏ったサンプルの結果であるので注意。おそらくそれなりの規模の環境では, 公式ドキュメントにあるように新方式の方がパフォーマンスやバンドルサイズが改善すると思われる。

きっかけ: 自分のソースコードから `import React from 'react';` を消してスッキリさせたい

先日, ブログをはてなブログから Gatsby を利用した自作ブログへと移行しました¹。より保守性・生産性の高いコードにしたい, スキルを身につけたいという思いがあり, TypeScript で実装しようと当初考えたのですが, とりあえずものを作りたかったので, ひとまず JavaScript で実装しました。

そろそろ TypeScript への移行を始めたいと思いましたが, まだまだ React のことも理解できていないので, React と TypeScript を一緒に学べる『りあクト！ TypeScript で始めるつらくない React 開発』シリーズを読み直していました。

すると, 気になる記述が目に入りました。

「...React 17.0 以降はパフォーマンス改善などを目的とした新しい変換形式が導入されてて、Create React App でも 2020 年 10 月にリリースされた 4.0 からはデフォルトの設定はそっちが有効になってるのね。...」²

「...ちなみに TypeScript 4.1 以降では React 17.0 から導入された新しい JSX 変換形式に対応してて、tsconfig.json の jsx オプション設定が react-jsx になってるとそれが有効になる。こっちはこんなふうにインポート文込みで変換されるので、import React from 'react' が省略できるよ」³

詳しくは React 公式の Introducing the New JSX Transform で紹介されているのですが, つまるところ以下の内容です。

React 17.0 から JSX の変換で, React.createElement() に変換されない新形式が使えるようになった
新形式では import React from 'react' のインポート文が不要になる

そして, 新方式の恩恵として, 上記の React のドキュメントでは以下が挙げられています。

With the new transform, you can use JSX without importing React.
Depending on your setup, its compiled output may slightly improve the bundle size.
It will enable future improvements that reduce the number of concepts you need to learn React.

確かに, Gatsby でコードを書いているとき, 全ての JSX ファイルの冒頭に import React from 'react'; を書いており, 冗長だなと思っていました。もはや JSX ファイルを作成したらまず無心でタイプする, 魔法の文字列じみた状態でした。それが省略でき, かつパフォーマンスなども上がるのであれば, これは是非導入してみたい。ただし, 先ほども触れたように, 私はまだ TypeScript を修得していないので, TypeScript 前提で書かれている『りあクト！』の記述をそのままは使えません。 JavaScript で, かつ Gatsby でこの新方式を導入できるのか調べる必要があります。

ということで, 本記事では, Gatsby + JavaScript で React の JSX Transform の新方式を利用する方法 を調べました。また, 旧方式とのパフォーマンス比較も, せっかくなのでごく簡易にではありますが試してみました。

Gatsby で React JSX Transform の新方式を導入する

TypeScript であれば, tsconfig.json を編集すれば良いようです。しかし, Gatsby ではどうすれば良いか。

Gatsby の設定

検索していたら, まず次の issue にたどり着きました。
React 17 new JSX Transform: ReferenceError: React is not defined #28657

この Issue の末尾から, 根本的に解決された Issue も確認できました。
feat(gatsby): Add JSX Runtime options to gatsby-config.js #33050

どうやら, Gatsby でもちゃんと新方式に対応しているようです。ちなみにリリースノートもちゃんとあり, Gatsby 4.1 から対応したようでした。
JSX Runtime Options in gatsby-config.js

これらの記述によれば, gatsby-config.js に以下のエントリを足してやれば良いようです。

gatsby-config.js

module.exports = {
  jsxRuntime: 'automatic',
};

ESLint の設定

これで無事冗長な import React from 'react'; を消せる, と思って消したら, ESLint に怒られました。 Prevent missing React when using JSX (react/react-in-jsx-scope) に抵触しているようです。それはそう。

抵触したこのルールのドキュメントに飛ぶと, 末尾に以下のように書かれています。

If you are using the new JSX transform from React 17, you should disable this rule by extending react/jsx-runtime in your eslint config (add "plugin:react/jsx-runtime" to "extends").

素直に従って, ESLint の設定ファイルに追記しましょう。私の場合は, .eslintrc.json の "extends" 部分が以下のようになりました。

.eslintrc.json

  "extends": [
    "eslint:recommended",
    "plugin:import/recommended",
    "plugin:jsx-a11y/recommended",
    "plugin:react/recommended",
    "plugin:react/jsx-runtime",
    "plugin:react-hooks/recommended",
    "prettier"
  ],

これで, import React from 'react'; を消しても ESLint に怒られなくなりました。安心して全ての jsx ファイルから冒頭一行を消し去ります。ビルドも無事できたので, 問題なさそうです。

新旧方式でのパフォーマンス比較

せっかくなので, パフォーマンスが良くなるということなので計測してみます。と言っても全然記事のないブログで, 大して凝った作りもしていないので, 厳密ではなく簡易に様子を見る程度でやってみます。

環境情報

主要 npm package

kangetsu@ubuntu20:~/work/my_blog$ npm ls | grep -E ' gatsby@| react@| react-dom@'
├── gatsby@4.12.1
├── react-dom@17.0.2
├── react@17.0.2
kangetsu@ubuntu20:~/work/my_blog$

ビルドタイム

まず, ビルドタイムを測ってみます。 Gatsby なので, gatsby clean 後に gatsby build の時間を見ます。

とりあえず 5 回分計測しました, 結果は以下の通り (単位: sec)。

	旧	新
1 回目	30.89	34.67
2 回目	32.26	34.03
3 回目	32.25	35.20
4 回目	31.99	34.37
5 回目	30.06	33.69
平均	31.49	34.39

正直結果を疑いましたが, 私の手元では旧方式の方が早かったです。

バンドルサイズ

では, せめてバンドルサイズは良くなっているのではないか。これは一回計測すれば十分です。 Gatsby では, public/ 以下に出力されるので, このサイズを比べます。

	旧	新
サイズ (KB)	4208	4212

ここでもわずかながら旧方式の方が軽いという, 旧方式の方が優れた結果となりました。

パフォーマンス

最後の頼みの綱, パフォーマンスです。どう測るか迷いましたが, CLI の lighthouse を使うことにしました。

と言ってもそのまま実行したら大量にログが出たので, mizchi さんの記事を参考に, 必要なデータだけ抜き出しました。中身がほぼない軽量なブログなので, 結果としてはほぼ天井を打っていたので, 差分だけ抽出します。 diff をとった結果は以下です。

$ diff default_lighthouse_score.log new_lighthouse_score.log
59c59
<   'unused-javascript': 0.93,
---
>   'unused-javascript': 0.88,

差分はこの 'unused-javascript' のみですが, 見方を間違えてなければ, やはり旧方式の方がスコアが優れていました。

unused-javascript はどこで差が出ているのか？

一体どこで差が出たのか。 lighthouse の CLI では, 具体的にどの JavaScript がどれくらいのサイズなのか, などはパッと出せなかったので, 結局 GUI の lighthouse で確認しました。

旧方式:

新方式:

数字上は, 以下の違いがあります。

app-[0-9a-z]+\.js の Transfer Size が旧方式の方が大きいが, Potential Savings も大きい
fontawesome-svg-core/index.es.js の Potential Savings が 0.1KiB 小さい

あとは誤差レベルのもののようです。細かい数字が異なるのは分かりますが, 新旧どちらも "Potential saving of 44 KiB" と, 潜在的な削減可能容量は 44KiB と表示されています。すなわち, 削減可能サイズも少なくとも 1KiB = 1024 Byte 内の誤差ではあるようです。

lighthouse の 'unused-javascript' のスコア算出方法がどうなっているのか次第ですが, またドツボにハマって「気楽に記事を書く」が達成できなくなるので, 今回は深追いするのはやめておきます。

まとめ

ということで, 私の環境では新方式の JSX Transform を使ってもパフォーマンスの向上は見られませんでした。しかし, 冒頭に書いた通り, 計測の方法も環境も適切とは言えないので, 参考にしなくて良いと思います。パフォーマンス値については気になって調べて, せっかくなのでメモとして記録を残した, というのみです。私は import React from 'react'; を削除できただけで満足 です。もし React を書いていて, 冗長なコードが気になる方は, ぜひ新方式の JSX Transform を利用してみると良いかなと思います。

移行報告は過去の記事で書いています。↩
大岡由佳, りあクト！ TypeScript で始めるつらくない React 開発第 3.1 版【Ⅱ. React 基礎編】, p.12.↩
大岡由佳, りあクト！ TypeScript で始めるつらくない React 開発第 3.1 版【Ⅱ. React 基礎編】, p.30.↩

「コンテナには OS はない」ということについて

Fri, 11 Feb 2022 00:00:00 GMT

TL;DR

コンテナには OS はない
- Ubuntu や CentOS のコンテナは存在するが, カーネルを含まないディストリビューションのようなものであり OS ではない
コンテナは Linux カーネルの機能で実現しているので, ホスト OS に Linux カーネルが必須
- Windows や Mac でも Docker が使えるのは Docker Desktop が Linux VM のようなものを作ってその上で動かしているため

コンテナと OS の関係

コンテナ技術の話になるとよく「コンテナに OS はない」という話を目にします。これまできちんと理解できていませんでしたが, 調べて納得したので記録しておきます。

Ubuntu や CeontOS などのコンテナイメージは何者か

Dokcer 公式のレジストリである Docker Hub には, Ubuntu や CentOS のイメージが存在します。これを見て, 「コンテナにも OS があるのでは」と思ってしまいがち¹ ですが, これは 「ディストリビューション」「カーネル」「OS」に関する誤解 に基づきます。

まず, 重要な点として, Ubuntu や CentOS はディストリビューションです。ディストリビューションは大抵, Linux カーネル + 基本ソフトウェア群 を指します。シェルや, 普段よく使うコマンド群 (例えば echo や grep) も「基本ソフトウェア群」の範疇です。ただしややこしいのですが, ディストリビューションは 「広義の OS」 と呼ばれることもあります。

一方カーネルは, ディストリビューションに比べ, よりコアの部分を指し, 例えばハードウェアとソフトウェアの仲介を行います。 「狭義の OS」 と呼ばれることもあります。上述の通りシェルもカーネルに含まれないので, カーネルだけでは通常は何もできません²。ちなみに Linux カーネルは GitHub 上で開発されています³。

ここからが本題ですが, では Docker Hub にある Ubuntu や CentOS のコンテナは何なのでしょうか。

コンテナの仕組み

そもそもですが, コンテナは Linux kernel の namespaces, cgroups などの機能によって実現されています⁴。

namespaces: プロセス, ネットワーク, ユーザーなどのグローバルなリソースを独立させる⁵
cgroups: CPU, メモリなどのリソース割り当てをプロセスごとに制限する

このため, 前提として, 通常は Linux kernel 上でないと Docker をはじめとするコンテナは作れません。

そしてコンテナは, これらの機能によって, ホスト OS の一部を論理的に切り離している に過ぎないと言えます。このように, あくまでコンテナは「ホスト OS の一部」なので, Linux 以外のコンテナは存在しません。 Docker Hub などのコンテナレジストリを見ても Windows や macOS のコンテナが存在しないのはこのためです。

実際のコンテナの様子を確認する

では実際に操作して確認してみます。 Docker を動かすホスト OS は Ubuntu 20.04, コンテナは Docker Hub にある CentOS イメージを使います。

ホスト OS

kangetsu@ubuntu20:~$ uname -a
Linux ubuntu20 5.4.0-97-generic #110-Ubuntu SMP Thu Jan 13 18:28:08 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
kangetsu@ubuntu20:~$

コンテナ

kangetsu@ubuntu20:~$ docker image inspect centos | jq -r '.[].RepoTags[]'
centos:latest
kangetsu@ubuntu20:~$

まずコンテナのディストリビューションを確認します。

[root@fdda8cec6fe2 /]# cat /etc/os-release
NAME="CentOS Linux"
VERSION="8"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"
[root@fdda8cec6fe2 /]#

ホスト OS は Ubuntu であるにもかかわらず, 確かにコンテナのディストリビューションは CentOS になっていました。次に, Ubuntu, CentOS それぞれが 標準で実行できるはずのパッケージ管理コマンド を実行してみます。

[root@fdda8cec6fe2 /]# dpkg -l
bash: dpkg: command not found
[root@fdda8cec6fe2 /]# apt-get
bash: apt-get: command not found
[root@fdda8cec6fe2 /]#

[root@fdda8cec6fe2 /]# rpm -l
[root@fdda8cec6fe2 /]# yum history
Failed to set locale, defaulting to C.UTF-8
ID     | Command line                                                                                                                                                    | Date and time    | Action(s)      | Altered
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[root@fdda8cec6fe2 /]#

コンテナ上では, Ubuntu なら通常は実行できるはずの dpkg, apt-get が実行できず, CentOS が通常実行できる rpm, yum が実行できました。

ここでもう一度, 今度は uname -a でコンテナの OS の情報を見てみます。

[root@fdda8cec6fe2 /]# uname -a
Linux fdda8cec6fe2 5.4.0-97-generic #110-Ubuntu SMP Thu Jan 13 18:28:08 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
[root@fdda8cec6fe2 /]#

よく見ると, /etc/os-release には CentOS と書いてあったのに, uname -a の結果は Ubuntu になっており, ホスト OS 上で実行した結果とほぼ同じになっています。ただし, ホスト名のみコンテナ名になっており, コンテナ上で hostname を実行した結果と同じになっています。

[root@fdda8cec6fe2 /]# hostname
fdda8cec6fe2
[root@fdda8cec6fe2 /]#

結論

上の実験から, 以下のことがわかりました。

Ubuntu のホスト OS 上で, ディストリビューションの異なる CentOS のコンテナが動かせた
CentOS コンテナ上では CentOS に含まれるコマンド群が実行でき, Ubuntu に含まれるコマンド群は実行できなかった⁶
uname -a の結果は, コンテナ上での実行でもホスト OS とほぼ同じ⁷

以上から, 結論ありきであれば, 「コンテナに OS はない」ということに納得できるのではないでしょうか。コンテナレジストリなどにあるディストリビューション別のコンテナは, 確かに固有の OS (カーネル) があるわけではなく, ディストリビューションからカーネル部分を除いた, ファイルシステムやソフトウェア, コマンド群のパッケージ と言えそうです (カーネルがないので広義の OS ですらない)。

少なくとも自分はこの辺りを確認できたので, 「コンテナに OS はない」の意味に納得できました。

おまけ 1: Docker Desktop の仕組み

上で「Linux kernel 上でないと Docker をはじめとするコンテナは作れません」と書きましたが, では Linux カーネルではない Windows や Mac でなぜ Docker が使えるのでしょうか。

Windows や Mac では, Dokcer 使用時には Docker Desktop を使えます⁸。

Docker Desktop がどのようにコンテナを Windows, Mac などの非 Linux カーネル上で実現しているかというと, 実は軽量の Linux VM を構築して, その上で Docker を動かしています。この仕組みは例えば, Docker 公式ブログの記事, The Magic Behind the Scenes of Docker Desktop で次のように説明されています。

At the heart of Docker Desktop we have a lightweight LinuxKit VM that Docker manages for you.

おまけ 2: コンテナ上で「OS」を停止しようとするとどうなるか

本筋に関係ない実験 1。

少し怖いですが実験として, shutdown や poweroff --halt を実行して, コンテナの「OS の」電源を切れるか試してみます。

[root@fdda8cec6fe2 /]# poweroff
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Failed to talk to init daemon.
[root@fdda8cec6fe2 /]# shutdown --halt
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
[root@fdda8cec6fe2 /]#

エラーになりました。エラーメッセージに「systemd が init system (PID 1) として実行されていない」と出ているので, プロセスを確認します。

[root@fdda8cec6fe2 /]# ps auxf
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   3916  2908 pts/0    Ss   12:00   0:00 /bin/bash
root          48  0.0  0.0   8604  3024 pts/0    R+   12:17   0:00 ps auxf
[root@fdda8cec6fe2 /]#

docker run した時に指定した /bin/bash が PID 1 になっています。通常は init プロセスが存在して, それを頂点とするプロセスツリーができているはずなのですが, コンテナはこのようになります。ホスト OS の方では, 確かに init プロセス (systemd) が PID 1 になっていることを確認できます。

kangetsu@ubuntu20:~$ ps auxf
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...]
root           1  0.0  0.1 101664 10416 ?        Ss   16:09   0:01 /sbin/init splash
root         400  0.0  0.4  83780 38560 ?        S<s  16:09   0:00 /lib/systemd/systemd-journald
root         429  0.0  0.0  18448  4704 ?        Ss   16:09   0:00 /lib/systemd/systemd-udevd
root         530  0.0  0.2 279988 16352 ?        SLsl 16:09   0:09 /sbin/multipathd -d -s
systemd+     584  0.0  0.0  90324  6284 ?        Ssl  16:09   0:00 /lib/systemd/systemd-timesyncd
systemd+     628  0.0  0.0  26284  6824 ?        Ss   16:09   0:00 /lib/systemd/systemd-networkd
systemd+     630  0.0  0.1  23892 10940 ?        Ss   16:09   0:00 /lib/systemd/systemd-resolved
root         669  0.0  0.1 240816  8456 ?        Ssl  16:09   0:01 /usr/lib/accountsservice/accounts-daemon
root         674  0.0  0.0   8336  2580 ?        Ss   16:09   0:00 /usr/sbin/cron -f
message+     675  0.0  0.0   8268  4308 ?        Ss   16:09   0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root         681  0.0  0.0  80908  2932 ?        Ssl  16:09   0:01 /usr/sbin/irqbalance --foreground
root         684  0.0  0.2  35188 18652 ?        Ss   16:09   0:00 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers
syslog       685  0.0  0.0 220936  4044 ?        Ssl  16:09   0:00 /usr/sbin/rsyslogd -n -iNONE
root         687  0.0  0.4 1093412 36980 ?       Ssl  16:09   0:04 /usr/lib/snapd/snapd
root         692  0.0  0.0  16448  6536 ?        Ss   16:09   0:00 /lib/systemd/systemd-logind
root         693  0.0  0.0  15904  5788 ?        Ss   16:09   0:00 /lib/systemd/systemd-machined
root         698  0.0  0.1 393692 12368 ?        Ssl  16:09   0:00 /usr/lib/udisks2/udisksd
daemon       703  0.0  0.0   3592  1844 ?        Ss   16:09   0:00 /usr/sbin/atd -f
root         704  0.6  0.4 1407488 38180 ?       Ssl  16:09   2:00 /usr/bin/containerd
root         721  0.0  0.0   6836  1756 ?        Ss+  16:09   0:00 /sbin/agetty -o -p -- \u --keep-baud 115200,38400,9600 ttyAMA0 vt220
root         725  0.0  0.0   5312  1484 tty1     Ss+  16:09   0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
root         728  0.0  0.0  12212  6404 ?        Ss   16:09   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root        1245  0.0  0.0  15336  7648 ?        Ss   16:09   0:00  \_ sshd: kangetsu [priv]
kangetsu    1366  0.0  0.0  15352  4212 ?        S    16:09   0:01  |   \_ sshd: kangetsu@pts/0
kangetsu    1367  0.0  0.0   9928  4880 pts/0    Ss   16:09   0:00  |       \_ -bash
kangetsu   10428  0.1  0.5 1418496 45464 pts/0   Sl+  21:00   0:01  |           \_ docker run -it centos /bin/bash
[...]
kangetsu@ubuntu20:~$ pstree
systemd─┬─accounts-daemon───2*[{accounts-daemon}]
        ├─2*[agetty]
        ├─atd
        ├─containerd───9*[{containerd}]
        ├─containerd-shim─┬─bash
        │                 └─10*[{containerd-shim}]
[...]
kangetsu@ubuntu20:~$

kangetsu@ubuntu20:~$ ls -la /sbin/init
lrwxrwxrwx 1 root root 20 Jan 10 13:56 /sbin/init -> /lib/systemd/systemd
kangetsu@ubuntu20:~$

おまけ 3: コンテナ上で保存した一時データの行方

本筋に関係ない実験 2。

コンテナ上で保存したデータがホスト上のどこに保存されているのか見ます。

まずコンテナ上で, 1GB のファイルを作成します。

[root@fdda8cec6fe2 /]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
overlay          39G   18G   21G  46% /
[root@fdda8cec6fe2 /]# dd if=/dev/zero of=/data.dat bs=1G count=1
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.556696 s, 1.9 GB/s
[root@fdda8cec6fe2 /]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
overlay          39G   19G   20G  49% /
[root@fdda8cec6fe2 /]#

この時, 当然ホストにも 1GB のファイルが増えていることになります。このようにしてコンテナ上で作られたファイルがどこにあるかというと, /var/lib/docker/overlay2/ 以下にありました (後述する docker image inspect であたりをつけた後, 愚直にファイル作成前後で du して探しました)。

kangetsu@ubuntu20:~$ sudo ls -l /var/lib/docker/overlay2/337886ef932e709fecd0e4b11e0977bbf5da390c022be2deebd1dc8f7042e1d4/diff
total 1048592
-rw-r--r-- 1 root root 1073741824 Feb 11 22:26 data.dat
drwxrwxrwt 2 root root       4096 Feb 11 21:08 tmp
drwxr-xr-x 5 root root       4096 Sep 15 23:25 var
kangetsu@ubuntu20:~$

このようなコンテナ上に作成されたファイルは, コンテナを停止しても消えませんが,

kangetsu@ubuntu20:~$ docker container start fdda8cec6fe2
fdda8cec6fe2
kangetsu@ubuntu20:~$ docker exec -it fdda8cec6fe2 /bin/bash
[root@fdda8cec6fe2 /]# ls /data.dat
/data.dat
[root@fdda8cec6fe2 /]#

kangetsu@ubuntu20:~$ sudo ls -l /var/lib/docker/overlay2/337886ef932e709fecd0e4b11e0977bbf5da390c022be2deebd1dc8f7042e1d4/diff/data.dat
-rw-r--r-- 1 root root 1073741824 Feb 11 22:41 /var/lib/docker/overlay2/337886ef932e709fecd0e4b11e0977bbf5da390c022be2deebd1dc8f7042e1d4/diff/data.dat
kangetsu@ubuntu20:~$

コンテナのインスタンス削除時に一緒に消えます。

kangetsu@ubuntu20:~$ docker container rm fdda8cec6fe2
fdda8cec6fe2
kangetsu@ubuntu20:~$

kangetsu@ubuntu20:~$ sudo ls -l /var/lib/docker/overlay2/337886ef932e709fecd0e4b11e0977bbf5da390c022be2deebd1dc8f7042e1d4/diff/data.dat
ls: cannot access '/var/lib/docker/overlay2/337886ef932e709fecd0e4b11e0977bbf5da390c022be2deebd1dc8f7042e1d4/diff/data.dat': No such file or directory
kangetsu@ubuntu20:~$ sudo ls -l /var/lib/docker/overlay2/337886ef932e709fecd0e4b11e0977bbf5da390c022be2deebd1dc8f7042e1d4/
ls: cannot access '/var/lib/docker/overlay2/337886ef932e709fecd0e4b11e0977bbf5da390c022be2deebd1dc8f7042e1d4/': No such file or directory
kangetsu@ubuntu20:~$

ちなみに docker image inspect に .GraphDriver.Data という key があり, value が /var/lib/docker/overlay2 以下のパスになっているのですが, 上で作った data.dat が保存されたのはそことは違うディレクトリでした。

kangetsu@ubuntu20:~$ docker image inspect centos | jq '.[].GraphDriver'
{
  "Data": {
    "MergedDir": "/var/lib/docker/overlay2/4c506c18e194df7f7396d93a287027d81e0ceac12856df9b7e5c25175fd169f5/merged",
    "UpperDir": "/var/lib/docker/overlay2/4c506c18e194df7f7396d93a287027d81e0ceac12856df9b7e5c25175fd169f5/diff",
    "WorkDir": "/var/lib/docker/overlay2/4c506c18e194df7f7396d93a287027d81e0ceac12856df9b7e5c25175fd169f5/work"
  },
  "Name": "overlay2"
}
kangetsu@ubuntu20:~$

この辺りは理解できていないので, また後で調べてみようと思います。

私はそう思ってました↩
頑張ればもちろんいろいろできるけどユーザーが直接使うようなものではない↩
本来 Linux はこの Linux カーネルのみを指す, と言われる↩
一緒に語られることもありますが, 呼び出したプロセスにとってのルートディレクトリ (/) を変更する chroot はコンテナ技術とは別物です↩
プログラミングにおける「名前空間」をイメージするとわかりやすい↩
コマンドや関連ファイルがあるかないかの違いなので, 厳密には Ubuntu などの Debian 系で rpm や yum を実行することもできるはず。逆も同様。デフォルトで入っていないというだけ↩
本当は実装をちゃんと見ないとこれが証拠になるかは断言できないが↩
Docker Desktop を使わなくても, Windows でも例えば WSL (Windows Subsystem for Linux) などを使えば Docker を使える↩

はてなブログから Gatsby を利用した自作ブログに移行しました

Fri, 14 Jan 2022 00:00:00 GMT

TL;DR

Gatsby を利用した自作ブログを作成 (ここ)
記事は markdown で書ける
フロント, React, React base の framework の良い練習になった

Gatsby に移行しました

表題の通り, ブログをはてなブログから自作ブログに移行しました。
主な動機は, フロントエンドに全然触れていないので練習をしたいと思ったこと, 手頃な題材がブログだと思ったこと, ブログのデザインも自作すればカスタマイズしやすいかも, と考えたことです。

Gatsby には Gatsby Starter Library というテンプレートのようなものもあるのですが, このような動機なので, Starter Library は使っていません。
リポジトリも公開しておくので, 実装が気になる方がもしいれば閲覧は可能です。
https://github.com/kangetsu121/my_blog
なお, 実装はきれいではないと思うので悪しからず。
フロント経験を積みながらリファクタリングしたり機能追加, デザイン更新をしていきたいです。

フロントエンドのキャッチアップ

仕事で触れることがほぼないフロントエンドでしたが, キャッチアップについては, 大体以下にお世話になりました。
いつかまとめ記事を書くかもしれません。

分かりやすい公式 Document は偉大ですね。
Gatsby は Document の Tutorial が結構親切でした。
また, JavaScript Primer と『りあクト！』シリーズは現代の JavaScript 入門者に本当にありがたい存在だと思います。
『りあクト！』の【Ⅰ. 言語・環境編】でも JavaScript の解説があり, これもとても親切でした¹。

もちろんこれだけで必要な知識は網羅できるわけではなく, 都度調べたりしています。

今後

しばらくはてなブログの更新は止まっていましたが, ブログ移行を考えていたことも理由の一つでした。
これからは気楽に学習メモをためていきたいです。

アクティブに更新するのは, 今後はこのブログと Zenn にしようと考えてます。
今年こそは三日坊主にならないように。

これらが難しいと感じる場合は, Progate などから進めるのがお勧めです (私もまともにプログラミング始めたのは progate からでした)。↩

Privacy Policy

Mon, 03 Jan 2022 00:00:00 GMT

アクセス解析ツールについて

当ブログでは、Google によるアクセス解析ツール「Google アナリティクス」を利用しています。
Google アナリティクスはトラフィックデータの収集のために Cookie を使用しています。
このトラフィックデータは匿名で収集されており、個人を特定するものではありません。
この機能は Cookie を無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

この規約に関して、詳しくは Google アナリティクス利用規約、または Google のサービスを使用するサイトやアプリから収集した情報の Google による使用をご参照ください。

運営者情報
運営者: kangetsu_121
更新日: 2022 年 1 月 3 日

免責事項

Mon, 03 Jan 2022 00:00:00 GMT

免責事項

当ブログからのリンク遷移先で提供される情報、サービス等について、一切の責任を負いません。
また当ブログのコンテンツ・情報について、できる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。情報が古くなっていることもございます。
当ブログに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

Kangetsu Blog RSS Feed

GitHub の Secrets に JSON などの構造化データを登録してはいけない

JSON などは GitHub Secrets にそのまま登録してはいけない

代替案

1. Base64 でフラットな構造にする

Base64 エンコーディング時の注意点

2. 暗号化したファイルをリポジトリに登録し、そのファイルの複合キー・パスフレーズを Secrets に登録する

結論

Discord フォーラムチャンネルの仕様について

Discord のフォーラムチャンネル (Forum Channel) は一週間投稿がないと自動アーカイブされる

作成済みの multipass インスタンスのリソースを後から変更する

multipass の disk を後から変更したかった

方法: multipass set local.<instance-name>.(cpus|disk|memory)

jsx ファイルを tsx ファイルに一括置換する

TypeScript 移行するときに既存の JSX ファイルを一括置換したかった

コマンド

コマンドの解説

1. find ./ -name *.jsx

2. | while read f; do mv $f ${f%.*}.tsx; done

GitHub 上で markdown ファイルをそのまま表示する

GitHub でのレビューで Markdown ファイルでも行数指定したい: モチベーション

方法

公式ドキュメント

Markdown All in One と mdx ファイルを関連づける

TL;DR

MDX でブログを書いているのでもっと便利に書きたい

結論: VS Code の設定で mdx を関連づければ良いだけ

調査内容

補足: この解決法の問題や Gatsby での MDX 利用でつらいところ

Gatsby で React の JSX Transform の新方式を導入し, ついでに新旧比較をしてみた

TL;DR

きっかけ: 自分のソースコードから import React from 'react'; を消してスッキリさせたい

Gatsby で React JSX Transform の新方式を導入する

Gatsby の設定

ESLint の設定

新旧方式でのパフォーマンス比較

環境情報

ビルドタイム

バンドルサイズ

パフォーマンス

unused-javascript はどこで差が出ているのか？

まとめ

「コンテナには OS はない」ということについて

TL;DR

コンテナと OS の関係

Ubuntu や CeontOS などのコンテナイメージは何者か

コンテナの仕組み

実際のコンテナの様子を確認する

結論

おまけ 1: Docker Desktop の仕組み

おまけ 2: コンテナ上で「OS」を停止しようとするとどうなるか

おまけ 3: コンテナ上で保存した一時データの行方

はてなブログから Gatsby を利用した自作ブログに移行しました

TL;DR

Gatsby に移行しました

フロントエンドのキャッチアップ

今後

Privacy Policy

アクセス解析ツールについて

免責事項

免責事項

方法: `multipass set local.<instance-name>.(cpus|disk|memory)`

1. `find ./ -name *.jsx`

2. `| while read f; do mv $f ${f%.*}.tsx; done`

きっかけ: 自分のソースコードから `import React from 'react';` を消してスッキリさせたい