<figure>
 <img src="https://user-images.githubusercontent.com/3617124/133427228-5e1a9054-6fd3-41d5-845a-789137502392.jpg" alt="Grovemade製品" loading="lazy">
 <figcaption>Grovemade®</figcaption>
</figure>
<h2>Grovemade とは</h2>
<a href="https://grovemade.com/" target="_blank" rel="nofollow noopener">Grovemade®</a> は、アメリカのオレゴン州ポートランドで、天然素材から手作りの商品を製造している会社。
木材を生かした製品が多く、デザイン性も優れているため、デスク周りを整えている界隈から根強い人気がある印象。
<h2>注文した商品</h2>
<ul>
<li>Wood Apple Keyboard Tray</li>
<li>Wood Trackpad Tray</li>
</ul>
以前から Grovemade 製の keyboard Tray が欲しかったのだが、1 点注文するには海外配送の敷居が高かったため、断念していた。直近、 Trackpad を購入したこともあり、Keyboard と Trackpad でトレイを統一できるため購入することにした。
それぞれ素材は、オークとウォールナットが用意されている。個人的な好みとデスク周りが黒系統なためウォールナットを選択した。
<h3>Wood Apple Keyboard Tray</h3>
<img src="https://user-images.githubusercontent.com/3617124/134023511-5341dd81-94ab-48b0-b170-8c4a63fc09b3.png" alt="Wood Apple Keyboard Tray" loading="lazy">
<ul>
<li>素材: Walnut</li>
<li>サイズ: Pre May 2021</li>
<li>値段: $80</li>
</ul>
<a href="https://grovemade.com/product/wood-keyboard-tray/" target="_blank" rel="nofollow noopener">https://grovemade.com/product/wood-keyboard-tray/</a>
<hr>
Touch ID 搭載 Magic Keyboard 用は未販売。所有しているキーボードは販売されている規格に合っていた（Pre May 2021）ため、そのまま購入。
<h3>Wood Trackpad Tray</h3>
<img src="https://user-images.githubusercontent.com/3617124/134023540-c10a5205-b447-4a74-9f7b-3b743920214b.png" alt="Wood Trackpad Tray" loading="lazy">
<ul>
<li>素材: Walnut</li>
<li>サイズ: Pre-2021 Apple Magic Trackpad</li>
<li>値段: $110</li>
</ul>
<a href="https://grovemade.com/product/wood-trackpad-tray/" target="_blank" rel="nofollow noopener">https://grovemade.com/product/wood-trackpad-tray/</a>
<hr>
Magic Keyboard と同じく所有していた Trackpad は規格が合っていた（Pre-2021）ため、そのまま購入。
<h2>注文</h2>

















<div class="p-post-table-container"><table><thead><tr><th>品名</th><th>値段</th></tr></thead><tbody><tr><td>Walnut Trackpad Tray</td><td><del>$80.00 USD</del> $72.00 USD</td></tr><tr><td>Walnut Keyboard Tray - Pre-2021 Apple Keyboard</td><td><del>$110.00 USD</del> $99.00 USD</td></tr></tbody></table></div>
<ul>
<li>小計: $171.00 USD</li>
<li>割引: -$19.00 USD</li>
<li>送料: $23.35 USD</li>
<li>合計: $194.35 USD</li>
</ul>
公式のページ（<a href="https://grovemade.com/coupon-discount-philosophy/" target="_blank" rel="nofollow noopener">Our Approach to Discounts</a>）でクーポンコードがあったため、10％オフになった。
<h2>発送から到着までの流れ</h2>
2021/8/22 に注文し、8/25 に注文処理が完了した。日本への到着が 9/10 だったので、19 日間で手元に届いた。
発送時に Grovemade からトラッキングナンバーの付いたメールが届いた。
配送の流れは以下の通り。













































































<div class="p-post-table-container"><table><thead><tr><th>日時</th><th>出荷状況</th></tr></thead><tbody><tr><td>2021/09/10 12:22</td><td>Delivered Japan</td></tr><tr><td>2021/09/10 8:51</td><td>配達中です Japan</td></tr><tr><td>2021/09/10 5:04</td><td>国際運送会社に荷物到着 Japan</td></tr><tr><td>2021/09/09 1:00</td><td>国際運送会社に荷物が処理されました Japan</td></tr><tr><td>2021/09/09 0:59</td><td>海外税関による荷物の通関手続きが完了しました Japan</td></tr><tr><td>2021/09/08 8:59</td><td>荷物が海外の税関事務所に到着しました Japan</td></tr><tr><td>2021/09/07 22:26</td><td>国際運送会社に荷物が処理されました Japan</td></tr><tr><td>2021/09/06 22:17</td><td>国際運送会社に荷物到着 Japan</td></tr><tr><td>2021/09/05 19:06</td><td>荷物が運送会社の施設を出発しました United States</td></tr><tr><td>2021/09/05 0:51</td><td>国際運送会社に荷物到着 United States</td></tr><tr><td>2021/09/03 2:45</td><td>国際運送会社に荷物到着 United States</td></tr><tr><td>2021/09/03 2:45</td><td>国際運送会社に荷物到着 United States</td></tr><tr><td>2021/09/02 20:00</td><td>USPS に配達済み、荷物受領保管中 SAN BERNARDINO, CA, United States</td></tr><tr><td>2021/09/02 17:34</td><td>国際運送会社より電子貨物情報を受領しました SAN BERNARDINO, CA, United States</td></tr><tr><td>2021/09/02 10:42</td><td>荷物を処理済 FONTANA, CA, United States</td></tr><tr><td>2021/08/30 16:28</td><td>処理のため荷物を受領 FONTANA, CA, United States</td></tr><tr><td>2021/08/25 19:01</td><td>注文情報を受信済 United States</td></tr></tbody></table></div>
<a href="https://www.ups.com/track?loc=ja_JP&#x26;requester=ST/trackdetails" target="_blank" rel="nofollow noopener">https://www.ups.com/track?loc=ja_JP&#x26;requester=ST/trackdetails</a> で確認。
<hr>
関税など追加費用は特にかからなかった。
<h2>使用感</h2>
質感や見た目もさることながら、特に Keyboard Tray は Magic Keyboard の打鍵感がよくなったように感じる。キーボードの傾きで打ちやすくなったこと、キーボードとトレイの接地面との間に空洞があるためか打鍵時の響きがいい感じになっている。
また、Apple 純正の Magic Keyboard に合わせて作られているため、他社製のキーボードは合わない模様（<a href="https://satechi.net/products/slim-x1-bluetooth-backlit-keyboard" target="_blank" rel="nofollow noopener">Satechi のキーボード</a>がミリ単位で入らないらしい）。今後の Apple 製品のアップデートによって、使えなくなる可能性があるのは気がかりである。

[Amazon] アソシエイトリンクのURLフォーマットの覚え書き

Grovemadeで商品を注文をした時の流れと覚え書き

<h2>仕様</h2>
<pre><code>https://www.amazon.co.jp/dp/{ASINコード}/ref=nosim?tag={アソシエイトID}
</code></pre>
上記の URL の特定の箇所を置き換えれば良い。
<h3>置き換え</h3>
<ul>
<li><code>{ASINコード}</code>: <code>B009JZHVMW</code></li>
<li><code>{アソシエイトID}</code>: <code>chafuso-22</code></li>
</ul>
<a href="https://www.amazon.co.jp/dp/B009JZHVMW/ref=nosim?tag=chafuso-22" target="_blank" rel="nofollow noopener">https://www.amazon.co.jp/dp/B009JZHVMW/ref=nosim?tag=chafuso-22</a>
<h2>参考</h2>
<ul>
<li><a href="https://affiliate.amazon.co.jp/help/node/topic/GP38PJ6EUR6PFBEC" target="_blank" rel="nofollow noopener">Amazon.co.jp の特定の商品へのシンプルなテキストリンクはどのように作ればよいですか</a></li>
</ul>

lint-stagedで特定のパスを対象外にする方法

<h2>概要</h2>
<a href="https://github.com/okonet/lint-staged" target="_blank" rel="nofollow noopener">lint-staged</a> を利用して、Git の pre-commit 時にファイルを検証している。
検証対象のファイルは、<code>*.js</code>などのように指定できるが、その中で除外したいファイルがあり、それを除外したい。
<h2>方法</h2>
仕様
<ul>
<li>lint-staged.config.js で定義</li>
<li><code>.config.js</code>が含まれるパスを除外する</li>
</ul>
<pre><code class="hljs language-js" data-language="js">// lint-staged.config.js
const path = require("path");

module.exports = {
 "*.js": (files) => {
 const cwd = process.cwd();
 const relativePaths = files
 .map((file) => path.relative(cwd, file))
 .filter((relativePaths) => !relativePaths.includes(".config.js"));

 return `eslint --fix ${relativePaths.join(" ")}`;
 },
};
</code></pre>

[GitHub Actions] Dependabotがパッチバージョンアップの場合にPull Requestをオートマージする方法

<h2>環境</h2>
<ul>
<li>GitHub を利用で<a href="https://docs.github.com/ja/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/about-dependabot-version-updates" target="_blank" rel="nofollow noopener">GitHub Dependabot</a>を利用している</li>
</ul>
<h2>仕様</h2>
以下の流れを想定。
<ol>
<li>Dependabot が Pull Request を作成する</li>
<li>Pull Request の内容が patch バージョンアップの場合は自動でマージする</li>
</ol>
<h2>方法</h2>
<a href="https://github.com/ahmadnassri/action-dependabot-auto-merge" target="_blank" rel="nofollow noopener">ahmadnassri/action-dependabot-auto-merge</a>を利用する。
設定ファイルは下記。
<pre><code class="hljs language-yaml" data-language="yaml">#.github/workflows/dependabot-auto-merge.yaml
name: dependabot-auto-merge

on:
 pull_request_target:

jobs:
 auto-merge:
 runs-on: ubuntu-latest
 if: ${{ github.actor == 'dependabot[bot]' }}
 steps:
 - uses: ahmadnassri/action-dependabot-auto-merge@v2
 with:
 target: patch
 approve: false
 github-token: ${{ secrets.BOT_TOKEN }}
</code></pre>
<h3>パラメータ</h3>
パラメータのデフォルト値で今回の仕様を満たすため指定は任意だが、下記のような指定をした。
<ul>
<li><code>target</code>を<code>patch</code> 
デフォルトは<code>patch</code></li>
<li><code>approve</code>を<code>false</code> 
オートマージをしているので Approve の指定はしなかった</li>
</ul>
<h4>github-token</h4>
GitHub トークンが必要になるため、GitHub の Setting から<a href="https://github.com/settings/tokens" target="_blank" rel="nofollow noopener">Personal Access Tokens</a>でトークンを作成する。
必要なスコープは下記。
<ul>
<li><code>repo</code>: プライベートリポジトリ用</li>
<li><code>public_repo</code>: 公開リポジトリ用</li>
</ul>
<h4>トークンの登録</h4>
対象のリポジトリの設定から、Secrets → Actions → New repository secret へアクセスして、下記を指定して保存（Add Secret）する。
<ul>
<li>Name: BOT_TOKEN</li>
<li>Value: 発行した token</li>
</ul>
<hr>
以上の設定で、Dependabot が Pull Request を作成すると、patch バージョンアップの場合に自動で PR がマージされるようになる。

[Git] コミット時に画像ファイルを最適化する方法

<h2>背景</h2>
非エンジニアから提供される画像は最適化されていないものが多くある。それをそのままプロダクションに公開すると、画像のサイズが大きくなりページの読み込みに影響を与える。そのため、提供されてた画像を個別で最適化して管理していくことになる。
Git 管理（コミット）時に画像の最適化を自動化したい。
<h2>方法</h2>
<ol>
<li>コミット時に画像ファイルがあるか 
husky + lint-staged を利用して pre-commit を設定する</li>
<li>対象の画像ファイルがあれば最適化を行う 
sharp を利用して画像最適化を行う</li>
<li>対処ファイルをコミットする</li>
</ol>
<h3>パッケージの準備</h3>
パッケージのインストールを行う。
<pre><code>npm i -D husky lint-staged sharp
</code></pre>
それぞれの用途で追加する。
<ul>
<li>Git フック
<ul>
<li><a href="https://www.npmjs.com/package/husky" target="_blank" rel="nofollow noopener">husky</a></li>
<li><a href="https://www.npmjs.com/package/lint-staged" target="_blank" rel="nofollow noopener">lint-staged</a></li>
</ul>
</li>
<li>画像最適化
<ul>
<li><a href="https://www.npmjs.com/package/sharp" target="_blank" rel="nofollow noopener">sharp</a> 
ファイル形式によってライブラリを変える必要がない事と ImageMagick などより 4〜5 倍高速との事で採用 
→ <a href="https://sharp.pixelplumbing.com/performance" target="_blank" rel="nofollow noopener">パフォーマンスの結果</a></li>
</ul>
</li>
</ul>
<h4>husky の設定</h4>
設定方法は環境によって異なるが、以下のような設定をした。基本的には husky のインストール時のスクリプトによって自動的に設定されるため、lint-staged の対象拡張子の指定をしておけば良い。
<code>.husky/pre-commit</code>:
<code>npx husky add .husky/pre-commit "npx lint-staged"</code> を実行して追加すれば良い。
<pre><code class="hljs language-sh" data-language="sh">#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged
</code></pre>
<code>package.json</code>:
<pre><code class="hljs language-json" data-language="json"> "lint-staged": {
 "**/*.{png,jpeg,jpg,gif}": "node compress-image.js"
 }
</code></pre>
<h3>実装</h3>
pre-commit 時に渡されたファイルパスを最適化するスクリプトは下記の通り。
<pre><code class="hljs language-js" data-language="js">// compress-image.js
const fs = require("fs");
const path = require("path");
const sharp = require("sharp");

const changeFormat = (image, extname) => {
 switch (extname) {
 case ".jpeg":
 case ".jpg":
 return image.jpeg({ quality: 85 });
 case ".png":
 return image.png({ quality: 100 });
 default:
 return image;
 }
};

const minifyFile = (filename) => {
 new Promise((resolve, reject) => {
 fs.readFile(filename, function (err, sourceData) {
 if (err) throw err;

 const extname = path.extname(filename).toLowerCase();

 changeFormat(sharp(sourceData), extname).toFile(filename, (err) => {
 err ? reject(err) : resolve();
 });
 });
 });
};

Promise.resolve(process.argv)
 .then((x) => x.slice(2))
 .then((x) => x.map(minifyFile))
 .then((x) => Promise.all(x))
 .catch((e) => {
 console.error(e);
 process.exit(1);
 });
</code></pre>
ファイル形式によって最適化の設定が異なるので、拡張子によって sharp に渡すパラメータを出し分けしている。

[Google] 検索結果にサムネイルを指定する方法

husky を v4.3.8 から v7.0.0 へアップグレードする。
※ v5 はライセンス問題があるため、MIT に戻った v7 へアップグレードする
<h2>CHANGELOG</h2>
<ul>
<li>husky-4-to-6 CLI → husky-4-to-7 CLI に変更になったので修正</li>
</ul>
<h2>環境</h2>
<ul>
<li>husky: 4.3.8 -> 7.0.0</li>
<li>lint-staged: 10.5.4</li>
</ul>
<h2>方法</h2>
husky のドキュメントにある<a href="https://typicode.github.io/husky/#/?id=migrate-from-v4-to-v7" target="_blank" rel="nofollow noopener">Migrate from v4 to v7</a>を参照した。
<h3>husky-4-to-7 CLI</h3>
<a href="https://github.com/typicode/husky-4-to-7" target="_blank" rel="nofollow noopener">husky-4-to-7 CLI</a> という CLI が用意されており、簡単に移行ができる模様。
npm で管理しているプロジェクトだったので、README の内容通り下記を実行した。
<pre><code>npm install husky@7 --save-dev \
 &#x26;&#x26; npx husky-init \
 &#x26;&#x26; npm exec -- github:typicode/husky-4-to-7 --remove-v4-config
</code></pre>
実行すると要所で<code>Ok to proceed? (y)</code>と訊かれるので<code>y</code>と続けていく。
<pre><code>removed 16 packages, changed 2 packages, and audited 950 packages in 4s

8 packages are looking for funding
 run `npm fund` for details

found 0 vulnerabilities
Need to install the following packages:
 husky-init
Ok to proceed? (y) y
husky-init updating package.json
 setting prepare script to command "husky install"
husky - Git hooks installed
husky - created .husky/pre-commit

please review changes in package.json
Need to install the following packages:
 github:typicode/husky-4-to-6
Ok to proceed? (y) y
husky - created .husky/pre-commit
husky - deleted husky field from package.json

⚠️ pre-commit hook may need to be manually updated to be run via package manager.

Examples:
 jest → npx --no-install jest
 → yarn jest

 jest &#x26;&#x26; eslint → npx --no-install jest &#x26;&#x26; npx --no-install eslint
 → yarn jest &#x26;&#x26; yarn eslint

 commitlint -E HUSKY_GIT_PARAMS → npx --no-install commitlint --edit $1
 → yarn commitlint --edit $1

See https://typicode.github.io/husky/#/?id=migrate-from-v4-to-v7
</code></pre>
処理後、以下のような差分が出る。
<ul>
<li>変更：
<ul>
<li>package.json</li>
<li>package-lock.json</li>
</ul>
</li>
<li>追加：
<ul>
<li>.husky/.gitignore</li>
<li>.husky/pre-commit</li>
</ul>
</li>
</ul>
<h4>package.json の差分</h4>
<pre><code class="hljs language-diff" data-language="diff">+ "prepare": "husky install"
</code></pre>
<pre><code class="hljs language-diff" data-language="diff">- "husky": "^4.3.8",
+ "husky": "^6.0.0",
</code></pre>
<pre><code class="hljs language-diff" data-language="diff">- "husky": {
- "hooks": {
- "pre-commit": "lint-staged"
- }
- },
</code></pre>
<h3>.husky/pre-commit</h3>
CLI で移行されていた記述だと package.json に記述していた<code>"pre-commit": "lint-staged"</code>の<code>lint-staged</code>がそのまま記述されていた。これを実行できるように<code>npx</code>経由で実行できるように<code>npx lint-staged</code>を<code>.husky/pre-commit</code>に追加した。
<pre><code class="hljs language-sh" data-language="sh">#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged
</code></pre>
これで pre-commit 時に lint-staged の設定のものが適応される。
参考: <a href="https://typicode.github.io/husky/#/?id=locally-installed-binaries" target="_blank" rel="nofollow noopener">https://typicode.github.io/husky/#/?id=locally-installed-binaries</a>
<h2>まとめ</h2>
<ul>
<li>移行は husky-4-to-7 CLI を実行するだけで良い</li>
<li>.husky/pre-commit に lint-staged を実行できるようにする
<ul>
<li>lint-staged の定義はそのままで良い</li>
</ul>
</li>
</ul>

[CSS設計] ITCSSとは

[Next.js] Qiita と Zenn の 記事一覧（フィード）を取得する方法

husky v4 から v7 へ移行する手順の覚書

2020 年も<code>&#x3C;meta name="keywords"></code>を散見する 1 年であった。
<h2>TL;DR</h2>
<ul>
<li>検索エンジン（Google, Yahoo!, Bing）は meta keywords 情報を利用しない</li>
<li>SEO として meta keywords の記述はプラスにはならないが、マイナスにもならない</li>
</ul>
<h2>meta keywords とは</h2>
下記のような要素を<code>&#x3C;head></code>要素内に記述する。
<pre><code class="hljs language-html" data-language="html">&#x3C;meta name="keywords" content="メタタグ, keywords, seo" />
</code></pre>
<code>name</code>には<code>keywords</code>、<code>content</code>に単語（キーワード）をカンマ区切りで列挙する。
<h2>meta keywords と SEO との関係性</h2>
以前は SEO として効果があった。
しかしながら、ブラックハット SEO での乱用の影響で現在は Google 検索から評価されることはなくなった。2009 年 9 月には、「Google は、ウェブ検索ランキングで"keywords"メタタグを使用していません」と公式的に声明を出している。
<blockquote>
At least for Google's web search results currently (September 2009), the answer is no. Google doesn't use the "keywords" meta tag in our web search ranking. This video explains more, or see the questions below.
<a href="https://developers.google.com/search/blog/2009/09/google-does-not-use-keywords-meta-tag" target="_blank" rel="nofollow noopener">Google does not use the keywords meta tag in web ranking 
</a>
</blockquote>
<a href="https://developers.google.com/search/docs/advanced/crawling/special-tags?hl=ja&#x26;ref_topic=4617741&#x26;visit_id=637448893659733022-2818023169&#x26;rd=1" target="_blank" rel="nofollow noopener">Special tags that Google understands | Google 検索セントラル</a>にサポートしているメタタグの一覧があるが、「すべてではない」と但し書きがあるものの <code>&#x3C;meta name="keywords"></code> の記載はない。
<hr>
また、Yahoo! や Bing についてもほぼ同様の見解を示している。
<h2>meta keywords を記述したままで良いのか</h2>
ブラックハット SEO での乱用された背景があるが、「検索ランキングで使用していない」と言っているだけなので記述していても SEO に悪影響はない（記述のありなしで評価が変わることはなさそう）。ただし、今後 <code>&#x3C;meta name="keywords"></code> の記述をブラックハットの判定として使用する可能性も否定できない。逆に評価されるようになる可能性もあるが、その際はどうようのアルゴリズムを使われることはないと思うので、いずれにしても書き換えは必要なように思う。そのため、個人的には意味のない記述はせず、記述しているのであれば削除しておいた方が無難だと考える。
<h2>まとめ</h2>
記述するのは自由だが、現在主要となっている検索エンジンでは SEO として meta keywords の記述は評価されない。SEO 目的ではなく meta keywords をサポートするアプリケーション、また SEO として、サポートする新進気鋭の検索エンジンはあるだろう。
意味のない meta keywords に時間を使うより、コンテンツの良さを検索エンジンにヒットさせるようなコンテンツ作りをする方が有意義だろう。また、無意味な HTML を記述していることになるのでレスポンスのサイズも無駄である。
<h2>参考</h2>
<ul>
<li><a href="https://developers.google.com/search/blog/2009/09/google-does-not-use-keywords-meta-tag" target="_blank" rel="nofollow noopener">Google does not use the keywords meta tag in web ranking bookmark_border</a></li>
<li><a href="https://searchengineland.com/yahoo-search-no-longer-uses-meta-keywords-tag-27303#" target="_blank" rel="nofollow noopener">Yahoo Search No Longer Uses Meta Keywords Tag</a></li>
<li><a href="https://blogs.bing.com/webmaster/2014/10/03/blame-the-meta-keyword-tag/" target="_blank" rel="nofollow noopener">Blame The Meta Keyword Tag</a></li>
</ul>

[Next.js] Google Adsenseを表示させる方法

竈門炭治郎をCSSだけで再現する

[HTML] meta keywords の記述は SEO として不要

日本国内であまり言及のない CSS 設計手法である ITCSS（Inverted Triangle CSS）について基本情報を記述する。
<h2>TL;DR</h2>
<ul>
<li>CSS を実装上の問題点</li>
<li>ITCSS とはどういうアーキテクチャなのか</li>
<li>ITCSS が CSS 実装への課題へどういうアプローチをしているか</li>
</ul>
<hr>
<h2>CSS の問題</h2>
CSS の仕様（グローバルスコープや詳細度）により、スタイル定義は複雑化しやすく破綻しやすい。
<ul>
<li>カスケードと継承</li>
<li>ソースの順番に大きく依存する</li>
<li>詳細度</li>
</ul>
CSS の定義において、ソースの記述順と詳細度は非常に重要である。これらの関係性が複雑になっていくと、既存定義を上書きするためにまた新しい定義をしていく必要がでてきてしまい、多くの無駄や冗長性が発生し、破綻してしまう。
<h3>詳細度の解決方法</h3>
── CSS を詳細度順で書く。
コードの記述順をいきあたりばったりで記述していくとする。そうすると、下記の図のように詳細度（山なりになっている箇所）が意図しない部分で現れていき、あとから対応をしていく度にコードの複雑さが増してしまう。複雑性が増したコードの場合、コードの末端で上書きしたつもりでもコードの先頭部分での定義の詳細度が強いケースなどもあり得る。
<img src="https://user-images.githubusercontent.com/3617124/115998030-529b3600-a620-11eb-8d13-df770b06e925.png" alt="悪い記述順" loading="lazy">
対して、コードを詳細度を意識した順番で記述していくとする。そうすると、下記のように当然詳細度は徐々に上がっていく形になる。あとから対応が必要な場合、別の場所の詳細度に影響を受けずに後述していけば良くなり、コードの見通しも良くなる。
<img src="https://user-images.githubusercontent.com/3617124/115998026-5038dc00-a620-11eb-8c94-4992dfd09717.png" alt="良い記述順" loading="lazy">
大まかにいえば、ITCSS はこの詳細度での記述順を可視化するための枠組みである。
<h2>ITCSS</h2>
<a href="https://itcss.io/" target="_blank" rel="nofollow noopener">ITCSS</a>は、CSS のための健全でスケーラブルに管理されたアーキテクチャである。
<h3>ITCSS とは何か</h3>
<ul>
<li>逆三角形の CSS アーキテクチャ</li>
<li>健全でスケーラブルな管理されたアーキテクチャ</li>
<li>ライブラリではなく、考え方の流儀</li>
<li>メタフレームワークであり、フレームワークのためのフレームワーク 
信じられないほどシンプル</li>
</ul>
<img src="https://user-images.githubusercontent.com/3617124/116028973-41d7d800-a693-11eb-8dd3-779f5bca4102.png" alt="ITCSS 逆三角形" loading="lazy">
CSS のスタイル定義を詳細度の広い順に記述（階層化）することを提唱している。その記述が逆三角形として視覚化されるため、この呼び名となっている。
<h3>レイヤー</h3>
ITCSS には、デフォルトで下記の 7 つの種別（レイヤー）で分類する。
<ol>
<li>Settings</li>
<li>Tools</li>
<li>Generic</li>
<li>Base</li>
<li>Objects</li>
<li>Components</li>
<li>Trumps</li>
</ol>
<img src="https://user-images.githubusercontent.com/3617124/116067628-48327800-a6c4-11eb-8663-a91e44f49a5b.png" alt="ITCSSの構造" loading="lazy">
必要に応じてレイヤーを追加や削除ができる。
<ul>
<li>CSS プリプロセッサを利用していない場合、<code>Settings</code>や<code>Tools</code>などのレイヤーを削除しても良い</li>
<li>OOCSS を使用していなければ<code>Objects</code>レイヤーを削除しても良い</li>
<li>テーマ性が必要であれば<code>Theme</code>レイヤーを追加しても良い</li>
</ul>
レイヤーの原則として、上位レイヤーを下位レイヤーが上書きできるような実装になっていなければ良い。そのため、プロジェクトに応じて必要なレイヤーを継ぎ足しすることも問題ない。
<h4>Settings</h4>
プリプロセッサなどで利用するグローバル変数や全体の設定を置く（SASS 変数や CSS Variables の定義）。
<pre><code class="hljs language-scss" data-language="scss">$font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
 "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji",
 "Segoe UI Symbol", "Noto Color Emoji" !default;

$color-ui: #bada55;
$spacing-unit: 10px;
</code></pre>
<h4>Tools</h4>
プリプロセッサで利用する<code>mixin</code>や<code>function</code>などの定義を置く。
<pre><code class="hljs language-scss" data-language="scss">@function str-replace($string, $search, $replace: "") {
 $index: str-index($string, $search);

 @if $index {
 @return str-slice($string, 1, $index - 1) + $replace + str-replace(str-slice($string, $index +
 str-length($search)), $search, $replace);
 }

 @return $string;
}

@mixin font-brand() {
 font-family: "UI Font", sans-serif;
 font-weight: 400;
}
</code></pre>
<h4>Generic</h4>
リセットスタイル（normalize.css など）や固有のリセットスタイル定義を置く。低詳細度、広範囲に当たる初期のスタイルを定義する。
<pre><code class="hljs language-scss" data-language="scss">@import "~normalize.css/normalize.css";

* {
 -webkit-box-sizing: border-box;
 -moz-box-sizing: border-box;
 box-sizing: border-box;
}
</code></pre>
<h4>Base</h4>
素の HTML 要素（a, h1…6, ul…li など）のスタイルを定義する。クラスセレクターなどは使用せず、要素セレクターのみで定義する。
<pre><code class="hljs language-scss" data-language="scss">ul {
 list-style: square outside;
}
</code></pre>
※ Base ではなく Elements という記述の資料もあるが、提唱者の資料をみると Base のようであった
<h4>Objects</h4>
OOCSS（Object Oriented CSS）の概念に基づいた定義をする。装飾を持たないレイアウトを定義する。
<pre><code class="hljs language-scss" data-language="scss">.ui-list {
 margin: 0;
 padding: 0;
 list-style: none;
}

.ui-list__item {
 padding: $spacing-unit;
}
</code></pre>
<h4>Components</h4>
名前の付けられた明確なコンポーネント（UI パーツ）を定義する。
<pre><code class="hljs language-scss" data-language="scss">.products-list {
 @include font-brand();
 border-top: 1px solid $color-ui;
}

.products-list__item {
 border-bottom: 1px solid $color-ui;
}
</code></pre>
<h4>Trumps</h4>
ヘルパー・ユーティリティ系のスタイルを定義する。1 つの DOM にのみ影響するものに焦点を置いて定義する。明示的なスタイル定義（テキストの中央寄せ等）などスコープがもっとも狭い定義になる。
<pre><code class="hljs language-scss" data-language="scss">.one-half {
 width: 50% !important;
}
</code></pre>
最下層のレイヤーであるため、 ID セレクターや<code>!important</code>の定義が許容される。
<h3>レイヤーの特徴</h3>
<ul>
<li>詳細度はレイヤーが下位へいくごとに増す</li>
<li>一度に DOM のより小さな部分に影響を与えていきます</li>
<li>下のレイヤーを上のレイヤーが上書きすることはしない</li>
</ul>
<h3>ITCSS の成果</h3>
<ul>
<li>すべてのコードを置く場所がある</li>
<li>人々は、どこを見ればどんな種類のルールがあるか分かる</li>
<li>健全なソースの順序</li>
<li>無駄を省き、冗長性を高める</li>
<li>スケーラビリティの向上</li>
<li>詳細度戦争が終わる</li>
</ul>
<h2>参考</h2>
<ul>
<li>Managing CSS Projects with ITCSS - speakerdeck 
<a href="https://speakerdeck.com/dafed/managing-css-projects-with-itcss" target="_blank" rel="nofollow noopener">https://speakerdeck.com/dafed/managing-css-projects-with-itcss</a></li>
<li>Harry Roberts - Managing CSS Projects with ITCSS 
<a href="https://www.youtube.com/watch?v=1OKZOV-iLj4" target="_blank" rel="nofollow noopener">https://www.youtube.com/watch?v=1OKZOV-iLj4</a></li>
<li>itcss/itcss-netmag 
<a href="https://github.com/itcss/itcss-netmag/" target="_blank" rel="nofollow noopener">https://github.com/itcss/itcss-netmag/</a></li>
</ul>

[JavaScript] オブジェクトのプロパティを条件指定で追加する方法

受け手は気にする必要はありませんが、送り手としては、これらを必要に応じて使い分けられると良いかもしれません。

<h2>違い</h2>
<ul>
<li><code>&#x3C;b></code>は太字（スタイル）</li>
<li><code>&#x3C;strong></code>は重要性を意味する（セマンティック） 
テキスト読み上げ</li>
</ul>
<h3>strong</h3>
入れ子にして重要性を変えることができる。
<pre><code class="hljs language-html" data-language="html">&#x3C;p>&#x3C;strong>Warning.&#x3C;/strong> This dungeon is dangerous.
&#x3C;strong>Avoid the ducks.&#x3C;/strong> Take any gold you find.
&#x3C;strong>&#x3C;strong>Do not take any of the diamonds&#x3C;/strong>,
they are explosive and &#x3C;strong>will destroy anything within
ten meters.&#x3C;/strong>&#x3C;/strong> You have been warned.&#x3C;/p>
</code></pre>
<h2>参考</h2>
<ul>
<li><a href="https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-strong-element" target="_blank" rel="nofollow noopener">https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-strong-element</a></li>
<li><a href="https://momdo.github.io/html/text-level-semantics.html#the-strong-element" target="_blank" rel="nofollow noopener">https://momdo.github.io/html/text-level-semantics.html#the-strong-element</a></li>
<li><a href="https://web.archive.org/web/20091124170143/http://lists.evolt.org/archive/Week-of-Mon-20010521/032901.html" target="_blank" rel="nofollow noopener">https://web.archive.org/web/20091124170143/http://lists.evolt.org/archive/Week-of-Mon-20010521/032901.html</a></li>
</ul>

[JavaScript] 簡単なlocalhostの判別方法

[Windows7] ファイルの関連付けを変更する方法

との違い

<h2>状況</h2>
手元に iPhone などの iOS 端末がなく、iOS 特有のバグ確認ができなかった為、シミュレータで検証を行うことにした。
<h2>確認した環境</h2>
<ul>
<li>macOS Sierra</li>
<li>macOS Catalina</li>
</ul>
<h2>方法</h2>
残念ながら Xcode のインストールをする必要がある。
<ol>
<li>Xcode をインストール 
初回起動をしていない場合は起動しておく 
その時に<code>Installing components...</code>が走るが、それがないとシミュレーターが起動しない</li>
<li>Xcode.app を右クリック 
→ パッケージの内容を表示 
<img width="384" alt="Finder" src="https://user-images.githubusercontent.com/3617124/97997291-27cbe400-1e2c-11eb-89a2-993b0ed387a5.png" loading="lazy"></li>
<li>以下のパスにあるので実行する 
<code>/Applications/Xcode.app/Contents/Developer/Applications/Simulator.app</code></li>
</ol>
エイリアスを作って、「アプリケーション」ディレクトリに入れておくと Lanchpad からもアクセスできて便利。

Home

Recent Articles