OmniAICreator/Qiita-1.07M huggingface dataset:
CSS変数（カスタムプロパティ）を使いこなす：スケーラブルなスタイル設計のための戦略と実装


## 概要

CSSが本格的に“設計”の領域に進化し始めたのは、**カスタムプロパティ（CSS変数）**が登場してからだ。  
単なる色指定やマージンの定数化ではない。  
**スタイルの「意味」と「関係性」を抽象化し、制御可能にする手段**としてのCSS変数は、現代のフロントエンド設計に欠かせない。

この記事では、CSS変数の構文・スコープ・使い所・計算式への応用・テーマ切り替え対応まで、**設計視点で使いこなすためのノウハウ**を凝縮して解説する。

---

## 対象環境

```text
CSS Custom Properties（CSS Variables）対応ブラウザ  
（IEを除く主要ブラウザすべて）
```

---

## 基本構文

```css
:root {
  --primary-color: #007aff;
  --spacing-unit: 1rem;
}

.button {
  background: var(--primary-color);
  margin-bottom: var(--spacing-unit);
}
```

- `--変数名` で定義
- `var(--変数名)` で参照
- `:root` はグローバルスコープ（CSS全体に適用）

---

## スコープ（継承）を意識した設計

```css
.card {
  --card-padding: 1.5rem;
  padding: var(--card-padding);
}

.card-small {
  --card-padding: 0.75rem;
}
```

→ 親にスコープを限定することで、**コンポーネントごとの微調整が可能**

---

## デフォルト値の指定（フォールバック対応）

```css
color: var(--headline-color, #333);
```

→ 変数が未定義の場合は `#333` を使用  
→ **フェイルセーフで堅牢なスタイル**

---

## 計算と連携：`calc()` と組み合わせてダイナミックに

```css
:root {
  --base-size: 1rem;
}

.box {
  padding: calc(var(--base-size) * 2);
  font-size: calc(var(--base-size) + 0.5rem);
}
```

→ 数式に組み込むことで、**設計の一貫性を保ったまま柔軟なUI**が構築可能

---

## 状態切り替え：ダークモードやテーマ変更への応用

```css
:root {
  --bg-color: #ffffff;
  --text-color: #000000;
}

[data-theme="dark"] {
  --bg-color: #121212;
  --text-color: #e0e0e0;
}
```

```html
<body data-theme="dark">
  <div class="container">Dark Theme Active</div>
</body>
```

→ 属性切り替えで**全体テーマの即時切り替え**が可能に。JavaScriptも不要。

---

## 実務例：ユーティリティ変数セットの構築

```css
:root {
  /* カラー */
  --color-primary: #007aff;
  --color-danger: #ff3b30;

  /* タイポグラフィ */
  --font-base: 1rem;
  --font-heading: 1.5rem;

  /* スペーシング */
  --space-xs: 0.25rem;
  --space-sm: 0.5rem;
  --space-md: 1rem;
  --space-lg: 2rem;
}
```

→ このような「設計ルール」を変数で抽象化することで、**コードの意味が伝わり、変更にも強くなる**

---

## よくあるミスと対策

### ❌ SCSSの変数と混同する

```scss
$primary-color: #007aff;
```

→ CSS変数とは別物。**SCSS変数は事前にコンパイルされるが、CSS変数はランタイムで評価**される。

→ ✅ 使い分けるポイント：
- SCSS → 計算やミックスインの補助
- CSS変数 → **DOMスコープと状態に応じた柔軟な変更**

---

### ❌ IE対応が必要な場合に使ってしまう

→ IEはCSS変数を一切サポートしない。**プロダクト要件に応じてPolyfillやSCSSにフォールバックすべき**

---

## 結語

CSS変数は、単なる見た目の定数化にとどまらない。  
それは**スタイルの意味と構造をコード化し、再利用とスケーラビリティを担保するための言語的な機能**である。

見た目を変えるだけでなく、**意味を抽象化して操作できる**という点で、CSSは進化している。

設計の主語を「色」から「意味」に。  
CSS変数はその最初の一歩となる。
CSS Grid vs Flexbox：いつ、どちらを選ぶべきか？ レイアウト設計の選定軸を言語化する


## 概要

現代のフロントエンドにおけるレイアウト設計は、`Flexbox` と `CSS Grid` の2大巨頭によって支えられている。  
どちらも強力で柔軟、そして一見似たような構文と効果を持つ。

しかし、**適材適所を誤れば、柔軟さは崩壊に変わる。**  
無意識に使い分けているうちは、設計は安定しない。  
**どのような場面でどちらを選ぶべきか？**  
それを言語化し、意図して選び取るための指針をこの記事で提供する。

---

## 対象環境

```text
CSS3以降対応の主要ブラウザ（Chrome / Firefox / Safari / Edge）  
モバイル・PCどちらも対応
```

---

## それぞれの定義と役割

### Flexbox：**一軸方向の並びに最適化されたレイアウトモデル**

- 主軸（row / column）に対して子要素を並べる
- 子要素の**間隔・整列・縮小・成長**を制御
- **コンテンツ駆動**（内容の大きさに応じて形が決まる）

### CSS Grid：**二軸方向を完全に制御できるグリッドシステム**

- 縦横（行列）を同時に制御可能
- 要素を**明示的に配置する**ことができる（row / column のマッピング）
- **レイアウト駆動**（構造が先にあり、内容がそこに入る）

---

## 判断基準（5つの指針）

| 判断軸                     | Flexbox                             | CSS Grid                               |
|---------------------------|-------------------------------------|----------------------------------------|
| 並びの方向が一方向か？     | ✅ 適している                        | ❌ オーバースペック                    |
| アイテムのサイズが可変か？ | ✅ 向いている                        | △ 明示的な設計が必要                  |
| レイアウトが複雑か？       | ❌ 管理が困難                        | ✅ 行列で柔軟にコントロール可能       |
| レスポンシブ性を重視するか？| ✅ wrap や grow で柔軟に対応可能     | ✅ メディアクエリ連動も容易           |
| 要素の位置を制御したいか？ | ❌ 難しい                            | ✅ `grid-area`, `row`, `column` で指定可 |

---

## 実例で比較

### Flexbox：ボタンを横並びにし、端で均等に配置

```html
<div class="flex-container">
  <button>Yes</button>
  <button>No</button>
</div>
```

```css
.flex-container {
  display: flex;
  justify-content: space-between;
}
```

→ 一方向での並びに非常に強い。

---

### Grid：2列×2行で完全に制御されたカード配置

```html
<div class="grid-container">
  <div class="card">A</div>
  <div class="card">B</div>
  <div class="card">C</div>
  <div class="card">D</div>
</div>
```

```css
.grid-container {
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  grid-template-rows: auto auto;
  gap: 1em;
}
```

→ 縦横の制御が完璧。メディアクエリとも相性が良い。

---

## よくある混乱とその処方箋

### 「Flexboxで頑張りすぎる」問題

```css
display: flex;
flex-wrap: wrap;
width: calc(50% - 10px);
```

→ 無理にグリッドっぽく並べようとして、**計算地獄と崩れの温床**に。

→ ✅ 明らかにグリッドパターンなら素直に `display: grid` を使うべき。

---

### 「Gridの設計が重すぎる」問題

```css
grid-template-columns: repeat(12, 1fr);
```

→ 内容が単純なのに、**フレームワークのノリで過剰な構造を持ち込む**ケース。

→ ✅ 一方向で済むなら、柔軟性の高いFlexboxで十分。

---

## 併用という選択肢

- 親要素に `display: grid`
- 子要素内部の整列に `display: flex`

例：

```css
.grid-item {
  display: flex;
  flex-direction: column;
  justify-content: center;
}
```

→ **レイアウト：Grid / コンテンツ内整列：Flex** のハイブリッド設計が王道

---

## 結語

FlexboxとCSS Grid。  
どちらも強力なレイアウトツールだが、**用途を見極めることで真価を発揮する**。

- Flexboxは「並べる」ためにある
- Gridは「配置する」ためにある

この一言に尽きる。

見た目を揃えるのではなく、**設計思想で選ぶ**こと。  
それがプロフェッショナルのCSS設計だ。
電子工作： エフェクターの自作、事始め

<h1>エフェクターの自作について</h1>
- 楽しい
- 学ぶ理由になる→電気工学、電子工学
- 大して低コストに収まらない
- 結局市販の物も買ってしまう

<h2> 知っとくといい事</h2>
リンク
- http://effectslayouts.blogspot.com/?m=1
- https://tagboardeffects.blogspot.com/?m=1 
- https://www.sabrotone.com/oc-2-octaver-build/
英単語 
- stomp: エフェクター (直訳：踏みつける)
- verified: 設計道理に作った物が保証された(他の人から動いた報告がある)
- Layouts: 電子部品のレイアウト図 (回路図やPCBレイアウトよりヤサシイ)
例： ![1000029624.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2709872/87915424-7868-495c-8248-334e6e714e65.png)
CSSの優先順位を制する者はバグを制す：セレクタの強さ、カスケード、そして`!important`の真価


## 概要

「なんでこのCSS当たらないんだ？」──  
フロントエンド開発で最も多く聞かれるセリフの一つがこれだ。

実際、CSSが効かない原因の大半は「書き方」ではなく「**優先順位**」にある。  
この“目に見えないルール”を正確に把握していなければ、**スタイルは意図せず上書きされたり、反映されなかったりする**。

本記事では、CSSの**カスケード・セレクタの優先順位・`!important` の影響範囲**を網羅的に解説し、  
「なぜ効かないのか」ではなく「どう書けば確実に効くのか」を理解できる状態を目指す。

---

## 対象環境

```text
CSS2.1 / CSS3 対応ブラウザ全般（Chrome / Firefox / Safari / Edge）
```

---

## そもそもCSSはどうやってスタイルを決定しているか？

CSSには、**複数のスタイルが同じ要素に競合したときに、どれを適用するか**という厳密なルールがある。  
このルールは以下の3段階で構成されている：

1. **重要度（Origin）**
2. **優先順位（Specificity）**
3. **カスケード（定義の順序）**

---

## 1. 重要度（Origin）

- **ユーザーエージェントスタイルシート**（ブラウザ標準）
- **開発者スタイルシート**（自分が書いたCSS）
- **ユーザー定義スタイル**（特別な設定）
- **`!important`** で強制されるスタイル（全てを上書き）

`!important` は最も強いが、**乱用すると設計が崩壊する**ので注意。

---

## 2. 優先順位（Specificity：セレクタの強さ）

各セレクタは、以下の「スコア」に基づいて競合を判定される：

| セレクタ例               | スコア（A,B,C,D） | 意味                                  |
|--------------------------|-------------------|----------------------------------------|
| `div`                    | 0,0,0,1           | タグセレクタ                          |
| `.btn`                   | 0,0,1,0           | クラスセレクタ                        |
| `#header`                | 0,1,0,0           | IDセレクタ                            |
| `button.btn.primary`     | 0,0,2,1           | クラス2つ + 要素1つ                   |
| `div#main .btn.active`   | 0,1,2,1           | ID1 + クラス2 + 要素1                 |
| `style="color:red"`      | 1,0,0,0           | インラインスタイル（最も強い）       |

- **ID > class > element**
- より強いスコアを持つスタイルが適用される

---

## 3. カスケード（定義の順序）

スコアが同じ場合は、**後から書かれたスタイルが優先される**。

```css
.btn {
  color: black;     /* 無視される */
}
.btn {
  color: red;       /* 上書きされる */
}
```

---

## `!important` の真価と危険性

```css
.btn {
  color: red !important;
}
```

- `!important` は優先順位・定義順序を**すべて無視して強制的に適用される**
- ただし、**より強いセレクタ + `!important`** によって上書きされることはある

```css
/* 上書きできる例 */
#main .btn {
  color: blue !important;
}
```

### ❌ 乱用パターン

- スタイルが当たらないからとりあえず `!important` をつける
- 後から他の場所でさらに `!important` を重ねる

→ **管理不能なスタイル競合地獄へ**

---

## 実践Tips：特定セレクタを確実に勝たせたいとき

### 方法1：セレクタのスコアを高める

```css
/* 弱い */
.button {
  background: gray;
}

/* 強い（クラスを増やす） */
.page .form .button {
  background: blue;
}
```

### 方法2：インラインスタイル（緊急性が高い場合）

```html
<div style="color: red;">緊急スタイル</div>
```

### 方法3：設計でレイヤーを分ける（BEM/SMACSSなど）

命名規則やレイヤー設計を導入すれば、無理にセレクタを強くする必要がなくなる。

---

## よくある疑問と回答

### Q. `style属性` が最強？

→ はい、インラインスタイルは基本的に全ての外部CSSより強いです。ただし `!important` 付きのIDセレクタには負ける場合があります。

### Q. `!important` は一切使ってはいけないのか？

→ いいえ。どうしても強制が必要なケース（例：ライブラリ上書き）では有効。ただし**局所的に限定して使うべき**です。

### Q. なぜBEMやUtility CSSが推奨されるのか？

→ 特定セレクタの強さに依存しなくても、スタイルが意図通りに適用されるから。**構造で管理する時代**へ。

---

## 結語

CSSが“効く”かどうかは、見た目の問題ではなく、**ルールの競合に勝っているかどうか**で決まる。

その勝敗を分けるのは「何をどう書いたか」──セレクタの設計力だ。  
そして、`!important` を使わずに済む設計が、美しいCSSの基準である。

スタイルが乱れるのは、書き方ではなく**設計の乱れ**。  
優先順位のルールを理解し、CSSと「戦う」のではなく「操る」側へ進もう。
GitもGitHubもさっぱりだった初心者が、NotionのメモをTILにして草を生やせた話

初めまして。プログラミングを学習中のKoSax🎷です。
最近、ようやくGitHubで人生初の草を生やすことができました🌱

「え、それだけ？」と思われるかもしれませんが、  
僕にとっては本当に大きな一歩でした。

---

## 🌲 Gitって何？木にたとえて考えたらスッと理解できた 🪵

最初は `git init` や `commit`、`push` といった言葉の意味もまったくわかりませんでした。  
調べても抽象的で、正直「これは自分には難しいな」と思っていました。

そんなとき、**Gitを“木”にたとえて考えるとわかりやすい**という話を見かけて、実際にやってみたら腑に落ちました。

| Gitの用語 | 木の構造にたとえると | 意味 |
|---|---|---|
| ローカルリポジトリ | 鉢植え | 自分のパソコン上で育てる場 |
| リモートリポジトリ | 畑 | GitHubなど、みんなと共有する場所 |
| main（master）ブランチ | 幹 | 開発の中心となる大黒柱 |
| ブランチ | 枝 | 試したり、実験したりする分岐 |
| コミット | 節目・年輪 | 作業の記録。幹や枝を太くする印 |

---

## 📚 Notionに学びを書き溜めていたけれど…

日々の学習記録はNotionにまとめていました。
学び自体は少しずつ積み上がっていきました。

でも、ふとこんなことを思いました。

> この学び、ただ書いて終わりじゃもったいないな。  
> せっかくなら形として残して、自分の成長として記録したい。

---

## 🌱 GitHubに「TIL（Today I Learned）」を作ることにした 🟩

「よし、GitHubにTILリポジトリを作って、学びを残そう」  
そう決めたものの、**操作がまったくわからない。**

```bash
git init
git remote add origin https://github.com/KoSaxophone/til.git
git add .
git commit -m "first commit"
git push -u origin main
```
ひとつひとつのコマンドの意味が理解できず、
git push したら「403エラー（アクセス拒否）」が出て心が折れかけました。
（※Personal Access Token？なにそれ？状態でした）

でも、調べたり、詳しい人に聞いたりしながら少しずつ前に進みました。


---

## ✅ そして、初めて草が生えた

Notionに書いた内容を `.md` ファイルにして、  
`til` フォルダに保存し、GitHubにプッシュ。

GitHubのプロフィールに**草が生えた瞬間**、本当に感動しました。

> 「自分でもできた」  
> そんな小さな成功体験が、自信につながりました。

---

## 🔄 自分のTIL運用ルール（Notion → GitHub）

学習内容を記録 → 成果としてGitHubにアップするまでの流れを、表にまとめました。

| ステップ | やること | 備考・ターミナル操作例 |
|----|----|----|
| ① | Notionに学習内容（概要・メモ）を記録する | 手動で記入 |
| ② | ```til```フォルダに移動 | ```cd ~/til``` |
| ③ | 新しい```.md```ファイルを作成 | ```touch ファイル名.md``` |
| ④ | ファイルに内容を書く（コピペOK） | ```手動で記入``` |
| ⑤ | Gitに変更をステージに追加 | ```git add .``` |
| ⑥ | コミットする | ```git commit -m "メッセージ"``` |
| ⑦ | GitHubにプッシュ | ```git push``` |
| ⑧ | 草が生える🌱 | - |


---

## ✅ この運用を始めてよかったこと

- **Notionの記録が「流れるだけ」で終わらず、形として残る**
- **GitHub上で草が生え、自分の成長が見える化される**
- **Markdownに慣れることで、アウトプット力も上がる**

---

## 🌿 これからやってみたいこと

- TILファイルをタグやカテゴリで分類して読みやすく整理する
- 月ごとにフォルダを作って学びの履歴を時系列で追いやすくする
- Markdown記法をもっと整えて読みやすくする（表、リスト、コードなど）

---

## 🍀 最後に

GitやGitHubは最初難しく感じていましたが、  
「とりあえずやってみる」「1つの草を生やしてみる」ことで、大きな自信につながりました。

TILは完璧でなくてもいい。  
**「学んだことを1つ、アウトプットとして残す」**だけで、それは確かな一歩になる。

もしNotionで学びを記録している方がいたら、ぜひ`.md`にまとめて、GitHubにアップしてみてください。  
1本目の草が生えた瞬間、きっと嬉しくなるはずです。
`<input type="date">` の罠と向き合う：日付入力UIの選定と代替戦略

## 概要

HTML5の登場により、フォーム入力の種類は劇的に進化した。  
その代表的存在が `<input type="date">`──一見すると、**手軽に日付入力を実現できる理想的なUI**に思える。

だが、実務の現場ではこの要素が持つ**ブラウザ依存・表示の不統一・UXの不確実性**に悩まされることが多い。  
見た目は便利、しかし中身は意外と扱いづらい。  
そのギャップに気づかないまま導入すると、ユーザー体験に悪影響を及ぼす可能性すらある。

本記事では、`<input type="date">` の仕様と問題点、実務でのベストプラクティス、そして代替案までを体系的に解説する。

---

## 対象環境

```text
HTML5準拠の主要ブラウザ（Chrome, Firefox, Edge, Safari, モバイル各種）
```

---

## `<input type="date">` の基本構文

```html
<label for="birthday">生年月日</label>
<input type="date" id="birthday" name="birthday">
```

- ユーザーはカレンダーUIから日付を選択可能
- 入力値は ISO形式（例：2025-03-30）で送信される
- バリデーションに自動対応（形式不正・未入力）

---

## 表面上の利点

- カレンダー選択でユーザーの負担軽減
- 入力ミスを防げる
- モバイルでは専用のUIが表示される（例：iOSの日付スピナー）

だが──この「利点」が、**すべての環境で成立するとは限らない**。

---

## 問題点1：ブラウザごとのUIが統一されていない

| ブラウザ      | カレンダーUI | プレースホルダー表示 | 表示形式        |
|---------------|---------------|------------------------|------------------|
| Chrome        | ✅             | ❌（一部表示されない） | YYYY-MM-DD       |
| Firefox       | ✅             | ❌（カスタム不可）     | YYYY-MM-DD       |
| Safari（mac） | ❌             | ❌                     | 手入力のみ       |
| Safari（iOS） | ✅             | ✅                     | スピナーUI       |

結果として：

- **デザインが乱れる**
- ユーザーによって **見えているUIが違う**
- テストが難しくなる

---

## 問題点2：カスタマイズがほぼ不可能

- アイコンの変更不可（デフォルトカレンダーアイコンが使われる）
- プレースホルダーが見えない（Chromeなど）
- バリデーションメッセージの内容が制御できない

```html
<input type="date" placeholder="YYYY-MM-DD"> <!-- 効かない場合あり -->
```

---

## 問題点3：手入力とUI選択で不整合が起きる

- 一部ブラウザでは「無効な日付」でも入力可能（例：`2025-02-30`）
- 手入力で想定外のフォーマットが入るとバグの温床に

---

## 実務における代替戦略

### 1. JavaScript製のDatePickerライブラリを使う

例えば：

- [flatpickr](https://flatpickr.js.org/)
- [Pikaday](https://github.com/Pikaday/Pikaday)
- [Air Datepicker](https://t1m0n.name/air-datepicker/)

これらは以下の特徴を持つ：

- クロスブラウザ対応
- フォーマット指定・ローカライズ・バリデーションも柔軟
- カスタマイズ自由

```html
<input type="text" id="datepicker">
<script>
  flatpickr("#datepicker", {
    dateFormat: "Y-m-d",
    defaultDate: "today"
  });
</script>
```

---

### 2. UIの段階的強化（Progressive Enhancement）

```html
<input type="date" id="start" name="start" />
<script>
  // サポートされていないブラウザ用に置き換え処理
  if (!('valueAsDate' in document.createElement('input'))) {
    // fallback処理をここに
  }
</script>
```

`valueAsDate` や `type="date"` のサポート有無をチェックし、必要に応じて**JSで強化**するという戦略。

---

### 3. プレースホルダーやマスクによる手入力支援

```html
<input type="text" placeholder="YYYY-MM-DD" pattern="\d{4}-\d{2}-\d{2}" title="例: 2025-03-30">
```

これは最も柔軟だが、ユーザーエラーを防ぎきれないので、**フロント側での補完ロジックが必要**。

---

## どう判断すべきか？

| プロダクト性質         | `type="date"` 採用可否 | コメント                             |
|------------------------|--------------------------|--------------------------------------|
| 管理系の社内ツール     | ✅ 問題なし              | ブラウザが制限されている場合が多い  |
| パブリックなBtoCサイト | ❌ 避けるべき            | ユーザー環境が多様                  |
| スマホ専用フォーム     | △ iOS/Android限定なら可  | モバイル特化UIなら使い道あり        |
| デザイン重視のアプリ   | ❌ 使用不可               | 見た目を制御できないため非推奨      |

---

## 結語

`<input type="date">` は「便利そうに見えて、実は不確実性が高い」要素だ。  
開発者がそれを理解せず導入すれば、ユーザーは不可解な体験に直面し、運用側も検証・サポートで疲弊する。

UI設計は「表示」ではなく「制御」の領域でもある。  
**一貫性・可搬性・拡張性を考えるなら、`type="date"` を使うかどうかは慎重に選ぶべき**だ。

最終的に重要なのは、技術的選択ではなく、**ユーザー体験に対する責任**である。
`<button>` タグの `type` 指定を忘れるな：意図しないフォーム送信を防ぐ必須知識


## 概要

HTMLフォームで最も多く使われる要素の一つ、`<button>` タグ。  
しかし、このタグを**何も指定せずに使うことがバグの原因になる**と知っている開発者は意外と少ない。

実は `<button>` は `type` 属性を明示しないと、**自動的に `type="submit"` として振る舞う**。  
この挙動により、「ボタンを押しただけでフォームが送信される」「JSのイベントが阻害される」など、**意図しない副作用が発生することがある**。

本記事では、`<button>` タグにおける `type` のデフォルト動作、ユースケースごとの正しい指定方法、よくある落とし穴とその回避策を体系的に解説する。

---

## 対象環境

```text
HTML5対応のすべてのブラウザ  
（Chrome / Firefox / Safari / Edge ほか）
```

---

## なぜ `type` を明示するべきなのか？

```html
<button>クリック</button>
```

このコードは、見た目には問題ないが、**実際には `type="submit"` として解釈される**。

つまり、このボタンが `<form>` の内部にある場合、**押すとフォームが送信される**。

意図的に「送信ボタン」として作っていない場合、これは明確なバグである。

---

## `<button>` の3つの `type` 値と意味

| type         | 説明                                                                 |
|--------------|----------------------------------------------------------------------|
| `submit`     | フォームを送信する（デフォルト動作）                                 |
| `reset`      | フォーム内のすべての入力値をリセット                                 |
| `button`     | 何もしない。JavaScriptのトリガー用途に使う場合はこれを**明示すべき** |

---

## 使用例：意図しない送信が発生するケース

```html
<form onsubmit="alert('送信されました')">
  <button onclick="console.log('クリック')">押すな</button>
</form>
```

この場合、ボタンをクリックすると：

1. `console.log('クリック')` が実行され
2. フォームが `submit` されて
3. `alert('送信されました')` が表示される

→ **ボタンに `type="button"` を指定していれば、送信は起きなかった**

---

## 正しく防ぐ書き方

```html
<form>
  <button type="button" onclick="console.log('実行')">実行ボタン</button>
</form>
```

このように、**JSによる処理だけをしたい場合は `type="button"` を明示**することで、送信を防げる。

---

## `reset` はいつ使うべきか？

```html
<button type="reset">リセット</button>
```

- 入力フォーム全体を初期状態に戻したいときに使う
- JavaScriptなしで一括リセットが可能
- あまり使われないが、**入力補助系UIでは便利**

---

## Reactなどのフレームワークでも同様

たとえばReactにおいても、以下のように指定しないと意図せずsubmitされてしまう。

```jsx
<button onClick={handleClick}>処理</button> // ← デフォルトで type="submit"
```

正しくは：

```jsx
<button type="button" onClick={handleClick}>処理</button>
```

---

## よくあるミスとその代償

- 「モーダルを開くボタン」が押された瞬間に画面がリロードされる  
- 「JavaScriptだけのトリガー」が `form.submit()` を引き起こす  
- `e.preventDefault()` を書き忘れたイベントが暴走する

どれも「typeを書かなかっただけ」で起きる不具合だ。

---

## 結語

`<button>` タグは、**その用途によって「明示的に意味を与える」必要がある要素**である。

フォーム送信用なのか、リセットなのか、単なるJSのトリガーなのか。  
その意図を `type` で言語化することで、**予期せぬバグを未然に防ぎ、意図が明確なコード**を実現できる。

HTMLは「書けば動く」ではない。  
**書き方が伝える意味**こそが、バグのないプロダクトを支えている。
`autofocus` / `required` / `pattern` を正しく使う：フォーム入力支援属性の真価と落とし穴


## 概要

HTML5以降、フォームの入力支援のために数多くの属性が導入された。  
その中でも特に利用頻度の高いのが `autofocus` / `required` / `pattern` の3つ。

これらは見た目に現れない「静かなアシスト機能」だが、**UX・アクセシビリティ・入力精度に直結する影響力を持っている**。  
一方で、よくある誤用・乱用によって、逆にユーザーを混乱させたり、バリデーションがすり抜けたりするケースも後を絶たない。

本記事では、それぞれの属性の仕様・効果・ベストプラクティスと共に、**よくある落とし穴**も網羅的に解説する。

---

## 対象環境

```text
HTML5対応ブラウザ全般  
（Chrome / Firefox / Edge / Safari / モバイルブラウザ含む）
```

---

## `autofocus`：自動フォーカスによる入力誘導

```html
<input type="text" name="email" autofocus>
```

### ✅ 効果：
- ページ読み込み直後にこのフィールドにフォーカスが当たる
- ユーザーが即座に入力を開始できる

### ⚠ 注意点：

1. **ページ内で複数箇所に `autofocus` を指定しても、効くのは最初の1つだけ**
2. **モバイル環境では `autofocus` が無視されることがある**（UX的配慮で）
3. スクロール位置が飛ぶ副作用がある（特にSPAやページ遷移時）

### ✅ ベストプラクティス：

- 重要な最初の入力項目だけに使う（例：ログインフォームのID欄）
- JavaScriptによる `element.focus()` の方が柔軟性は高いが、`autofocus` は手軽に使える

---

## `required`：入力必須のクライアントバリデーション

```html
<input type="email" name="email" required>
```

### ✅ 効果：
- 入力されていないとフォーム送信できない
- ブラウザが自動的に警告表示を行う
- スクリーンリーダーはこのフィールドが「必須」であることを伝える

### ⚠ 注意点：

1. **JavaScriptでフォーム送信した場合（`form.submit()`）、バリデーションをバイパスできてしまう**
2. **`readonly` な `required` フィールドは送信できない状態になる**（一見バグに見える）
3. `required` が機能しない原因の多くは `name` 属性の欠落

### ✅ ベストプラクティス：

- サーバー側でも必ずバリデーションを行う（クライアント側は“補助”）
- アスタリスク `*` を表示するなど、視覚的に「必須項目」であることも示す

---

## `pattern`：正規表現による入力ルールの定義

```html
<input type="text" name="zip" pattern="\d{3}-\d{4}" placeholder="例: 123-4567">
```

### ✅ 効果：
- 入力が正規表現にマッチしないと送信できない
- ブラウザは不一致時にエラーを表示してくれる

### ⚠ 注意点：

1. **`pattern` は `type="text"` にしか効かない**（`email` や `number` には独自の制約があるため無効）
2. **ブラウザによってエラーメッセージの表示内容は異なる**（制御できない）
3. **サーバー側のバリデーションが不一致だとバグの原因になる**

### ✅ ベストプラクティス：

- `title` 属性を併用して「どんなパターンが求められているか」を明示する

```html
<input type="text" name="zip" pattern="\d{3}-\d{4}" title="郵便番号は 123-4567 の形式で入力してください">
```

---

## 実用例：ログインフォームの実装例（3属性使用）

```html
<form>
  <label for="email">メールアドレス</label>
  <input type="email" id="email" name="email" required autofocus>

  <label for="password">パスワード</label>
  <input type="password" id="password" name="password" required pattern=".{8,}" title="8文字以上で入力してください">

  <button type="submit">ログイン</button>
</form>
```

- `autofocus`：ID欄へ即座に入力可
- `required`：必須チェック
- `pattern`：パスワードの長さ制限（クライアント側）

---

## 結語

HTML属性による入力支援は、**コード量を増やさずにUXを向上させる優れた手段**だ。  
だが、便利だからといって漫然と使えば、逆にユーザーを迷わせる結果になりかねない。

`autofocus`, `required`, `pattern`──  
それぞれが果たす役割を理解し、**意図をもって配置する**ことが、信頼されるインターフェースの第一歩となる。

HTMLは見た目の記述ではない。**意味の設計**である。
`<fieldset>` / `<legend>` を使いこなす：フォームを意味で分割するセマンティックな設計法

## 概要

フォームを設計する際、ただ項目を並べていくだけでは、**ユーザーにもコードにも文脈が伝わりにくい**。  
特に複数のグループ（たとえば「基本情報」「配送先」「支払い情報」など）を1ページに詰め込む場合、視認性と意味構造の分離は重要になる。

そこで登場するのが、`<fieldset>` と `<legend>`。  
これらのタグを正しく使うことで、**フォームに意味のグルーピングを与え、見た目と構造の両面で整った設計**が実現できる。

本記事では、`<fieldset>` / `<legend>` の仕様、ユースケース、アクセシビリティ効果、スタイリング方法までを詳しく解説する。

---

## 対象環境

```text
HTML5対応のすべてのブラウザ  
スクリーンリーダー・支援技術にも対応
```

---

## 基本構文

```html
<fieldset>
  <legend>個人情報</legend>
  
  <label for="name">氏名</label>
  <input type="text" id="name" name="name">
  
  <label for="email">メールアドレス</label>
  <input type="email" id="email" name="email">
</fieldset>
```

---

## `<fieldset>` の役割

- フォーム項目を**論理的なグループにまとめる**
- **視覚的な区切り**（ブラウザによりボックス風のスタイルがつく）
- アクセシビリティ的に、**構造が明示される**
- `<form>` の中でのみ使用される（フォーム外での使用は非推奨）

---

## `<legend>` の役割

- `<fieldset>` に対して**そのグループの「見出し」**を与える
- 画面上では `<fieldset>` の枠内の左上に配置される
- スクリーンリーダーでは**そのグループの説明**として読み上げられる
- `<fieldset>` の直下に配置する必要がある（順序が重要）

---

## 使用例：ラジオボタンのグループ化

```html
<fieldset>
  <legend>性別</legend>
  
  <label><input type="radio" name="gender" value="male"> 男性</label>
  <label><input type="radio" name="gender" value="female"> 女性</label>
  <label><input type="radio" name="gender" value="other"> その他</label>
</fieldset>
```

ラジオボタンは**排他選択肢**としてまとめておくことで、スクリーンリーダーでも「性別」という文脈のもとで読み上げられる。

---

## 使用例：住所ブロックの分割

```html
<fieldset>
  <legend>配送先情報</legend>
  
  <label for="zip">郵便番号</label>
  <input type="text" id="zip" name="zip">
  
  <label for="address">住所</label>
  <input type="text" id="address" name="address">
</fieldset>
```

---

## スタイリング：見た目をカスタマイズする

標準の `<fieldset>` / `<legend>` スタイルはブラウザ依存でやや古臭い印象がある。  
以下のようにスタイルを調整することで、モダンなUIにも自然に統合できる。

```html
<style>
fieldset {
  border: 1px solid #ccc;
  padding: 1.2em;
  margin-bottom: 1.5em;
  border-radius: 8px;
}

legend {
  font-weight: bold;
  padding: 0 0.5em;
  font-size: 1.1em;
}
</style>
```

---

## アクセシビリティの観点

- `<fieldset>` / `<legend>` を使用することで、**スクリーンリーダーがグループ化された意味を理解**できる
- `role="group"` や `aria-labelledby` をわざわざ書かなくても、HTMLネイティブで意味が伝わる
- 特に複雑なフォームや選択肢が多い画面では、**セマンティックな構造がUXに直結**する

---

## よくある間違い

### ❌ `<div>` + `<h2>` で代替してしまう

```html
<div class="section">
  <h2>支払い情報</h2>
  <!-- フォーム項目 -->
</div>
```

→ 見た目は似ていても、**構造的な意味が失われる**  
→ スクリーンリーダーで「これはフォームのグループです」と認識されない

---

## 結語

`<fieldset>` / `<legend>` は、視覚的な装飾ではなく、**意味を持つ構造タグ**である。  
それは「フォームを正しく分ける」「ユーザーに文脈を示す」「支援技術に意味を伝える」──すべてを叶える存在だ。

美しいコードは、見た目だけではなく、**構造の純度**にも宿る。

フォームを設計するすべての人にとって、この2つのタグは、最も誤解され、そして最も強力な味方となる。
`hidden` と `disabled` は何が違う？フォーム設計で混同しがちな2つの属性を正しく使い分ける


## 概要

HTMLのフォーム設計において、「要素を使えなくする」あるいは「非表示にする」というニーズはよくある。  
その際によく使われる属性が `hidden` と `disabled`。

見た目や動作が似ているため、混同しがちだが、**この2つの役割と仕様は本質的に異なる**。  
特にバリデーション、アクセシビリティ、データ送信における挙動の違いを理解せずに使うと、**意図しないバグやUI崩壊を引き起こす**。

本記事では、両者の違いを明確にし、正しいユースケースとともに実践的に整理する。

---

## 対象環境

```text
HTML5準拠ブラウザすべて（Chrome / Firefox / Edge / Safari）  
```

---

## `hidden` の意味と挙動

```html
<input type="text" name="username" hidden>
```

### 特徴：

- 要素が完全に**非表示**になる（CSSの `display: none` と同様）
- **フォーム送信には含まれる**
- スクリーンリーダーでも**読み取られない**
- JavaScriptで `element.hidden = true/false` という操作も可能

---

## `disabled` の意味と挙動

```html
<input type="text" name="username" disabled>
```

### 特徴：

- 要素は**表示されるが入力不可**になる（グレーアウトされる）
- **フォーム送信には含まれない**
- スクリーンリーダーでは読み取られる（ただし読み取り方法はブラウザ依存）
- ユーザー操作が**完全に無効化**される

---

## 一覧比較表

| 属性      | 表示されるか | 入力できるか | フォーム送信に含まれるか | スクリーンリーダー対応 |
|-----------|---------------|---------------|---------------------------|--------------------------|
| `hidden`  | ❌ 非表示      | ❌ 不可        | ✅ 含まれる                | ❌ 読まれない             |
| `disabled`| ✅ 表示        | ❌ 不可        | ❌ 含まれない              | ✅ 読まれる（要注意）     |

---

## 使用例：`hidden` を使う場面

### ✅ JavaScriptで表示・非表示を切り替えたいとき

```html
<div id="advanced-section" hidden>
  <input type="text" name="advancedOption">
</div>

<script>
  document.getElementById('advanced-section').hidden = false;
</script>
```

### ✅ サーバーに値を送りたいが、ユーザーに見せたくないとき

```html
<input type="hidden" name="session_token" value="abc123">
```

---

## 使用例：`disabled` を使う場面

### ✅ 入力欄を一時的に操作不可にしたいとき

```html
<input type="text" name="email" disabled>
```

### ✅ UIの状態に応じて有効化・無効化を切り替えたいとき

```html
<select id="plan" onchange="toggleInput()">
  <option value="basic">Basic</option>
  <option value="pro">Pro</option>
</select>

<input type="text" id="coupon" placeholder="クーポンコード" disabled>

<script>
  function toggleInput() {
    const plan = document.getElementById('plan').value;
    const coupon = document.getElementById('coupon');
    coupon.disabled = (plan === 'basic');
  }
</script>
```

---

## 注意点

### `disabled` 要素は JavaScript からも `.value` を取得できるが、送信されない

```javascript
document.querySelector('#myInput').value // ← 取得可能
```

ただし、`form.submit()` を使っても値は送信されない。  
これは**仕様通りの挙動**である。

---

## 補足：`readonly` との違い

```html
<input type="text" value="固定値" readonly>
```

- 表示：✅
- 入力：❌
- 送信：✅

`readonly` は `disabled` との中間のような存在で、**表示して送信もしたいが、編集はさせたくない**という場面で使う。

---

## 結語

`hidden`, `disabled`, `readonly`──  
これらは一見似ているが、それぞれに**意味と目的が明確に違う**。

HTMLの属性設計は、UIだけでなく、**UX・アクセシビリティ・データ連携すべてに影響する**。  
だからこそ、「なんとなく」ではなく、意図を持って正しく選ぶことが求められる。

本当に優れたインターフェースは、目に見えない部分での配慮が支えている。
フォームUXを変える小さなタグ：`<label>`の正しい使い方と実践テクニック

## 概要

フォームUIにおいて、`<input>` や `<select>` の設置だけでは、ユーザーにとって快適な操作体験は得られない。  
そこで重要になるのが `<label>` タグの適切な活用だ。

`<label>` は、単なる見出しではない。  
**クリック可能なラベル、関連付けによる操作性の向上、スクリーンリーダー対応**など、フォームUXを根本から支えるセマンティックな存在である。

本記事では、`<label>` タグの基礎から、実践的な活用テクニック、注意点、そして意外と知られていない応用までを網羅的に解説する。

---

## 対象環境

```text
HTML5対応ブラウザすべて（Chrome / Firefox / Edge / Safari 等）  
支援技術（スクリーンリーダー）を利用する環境にも有効
```

---

## なぜ `<label>` が重要なのか？

- **クリック可能な領域を広げられる**（小さなラジオボタンやチェックボックスでも押しやすく）
- **視覚障害者にも文脈が伝わる**（スクリーンリーダー対応）
- **入力値との対応関係が明示的に定義できる**
- **スタイリングの自由度が高く、HTMLだけで整えられる**

フォームにおいては、見た目ではなく**「意味のある設計」**が重要だ。  
それを支えるのが `<label>` タグである。

---

## 基本構文（for属性を使った関連付け）

```html
<label for="email">メールアドレス</label>
<input type="email" id="email" name="email">
```

この構成により、`<label>` をクリックすると対応する `<input>` にフォーカスが当たる。  
IDとforが一致することがポイント。

---

## 入れ子構文（for属性を省略できる）

```html
<label>
  <input type="checkbox" name="subscribe">
  ニュースレターを受け取る
</label>
```

このように、`<input>` を `<label>` の内側にネストすると、`for` 属性は不要になる。  
ラジオボタンやチェックボックスとの組み合わせでよく使われる構文。

---

## 応用：スタイルを当てて見た目を整える

```html
<style>
label {
  display: block;
  font-weight: bold;
  margin-bottom: 0.5em;
}

input, select {
  padding: 0.4em;
  width: 100%;
  box-sizing: border-box;
}
</style>

<label for="username">ユーザー名</label>
<input type="text" id="username" name="username">
```

見た目を整えることで、ラベルとしての役割がより視覚的に強調される。  
フォーム項目の並びを整えたいときにも有効。

---

## よくあるミスとアンチパターン

### NG: ラベルをプレースホルダーだけで代替する

```html
<input type="text" placeholder="名前を入力">
```

これは視覚的には問題なさそうに見えるが、以下の点でNGとなる：

- フォーカス時にプレースホルダーが消える
- スクリーンリーダーに文脈が伝わらない
- 自動入力が誤動作する可能性がある

→ 必ず `<label>` を明示的に併記すること。

---

## 応用：クリック可能領域の拡大

小さなチェックボックスを押しにくいと感じたことがあるなら、`<label>` をうまく使うべきだ。

```html
<label>
  <input type="checkbox" name="terms">
  利用規約に同意する
</label>
```

このように記述すると、「利用規約に同意する」の文字自体をクリックしてもチェックが入る。

---

## `<label>` は `aria-label` や `aria-labelledby` にも代替可能？

HTMLのアクセシビリティ機能の中には、ARIA属性を用いたラベリングも存在するが、**原則として`<label>`を優先すべき**である。

理由：

- ARIAは補助的な手段であり、**ネイティブ要素によるマークアップが最優先**
- ブラウザ間のサポートが `<label>` に比べて限定的
- 保守性・読みやすさ・バグの起きにくさの点で `<label>` に軍配が上がる

---

## 結語

`<label>` は、ただの装飾ではない。  
それはフォーム設計における**意味と操作性の架け橋**だ。

セマンティックで、アクセシブルで、操作しやすく──  
ユーザー体験に優れたフォームを目指すなら、最初に整えるべきはラベルである。

コードは見えるものだけが全てではない。  
その裏にある意味まで整えてこそ、真のフロントエンド開発者といえる。
個人開発　Habitica-外部連携　概念設計

# 概念設計の目的
概念設計とは、システム全体で解決すべき課題をどのような概念で解決するかを表すものです。


# インプットとなる資料

特になし



# 成果物

## 1.課題
　タスク管理アプリHabiticaについて以下の課題がある
　・タスクを開始～終了までの日数が記録に残らない。
記録に残らないため、将来的に作業の工数を振り返れない。
  
　・完了したタスクは３０日以上経過すると削除されて記録に残らない

## 2.改善方法
　・Habiticaのタスク情報を、自前のデータベースに保存する。
　・データベースに保存した情報を活用するためにBIツールを活用する。

## 3.配置図
```plantuml
@startuml

agent Habitica as "Habitica\nタスク管理ツール"
agent Batch as "連携バッチ(日次) \n 13:00実行"
database DB as "データベース"
agent BI_Tool as "BIツール"

Habitica --> Batch : "日毎のタスクデータ"
Batch --> DB:"日毎のタスクデータ"
DB --> BI_Tool:""

@enduml
```



## 4.ユースケース記述

### ユースケース記述とは

```
アクターの目的を達成するために、システムが実行する（すべき）振る舞いを文章で記述したもの。
```

https://www.itmedia.co.jp/im/articles/0806/24/news130.html#:~:text=%E6%9C%8824%E6%97%A5-,%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9%E8%A8%98%E8%BF%B0%EF%BC%88%E3%82%86%E3%83%BC%E3%81%99%E3%81%91%E3%83%BC%E3%81%99%E3%81%8D,%E3%81%A4%EF%BC%89%E6%83%85%E5%A0%B1%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E7%94%A8%E8%AA%9E%E8%BE%9E%E5%85%B8&text=%E3%82%A2%E3%82%AF%E3%82%BF%E3%83%BC%E3%81%AE%E7%9B%AE%E7%9A%84%E3%82%92%E9%81%94%E6%88%90,%E3%82%B7%E3%83%8A%E3%83%AA%E3%82%AA%E3%81%A8%E3%81%84%E3%81%86%E5%A0%B4%E5%90%88%E3%82%82%E3%81%82%E3%82%8B%E3%80%82


```

ユースケースでは、画面遷移や具体的なシステムの実現方法にはできるだけ言及しません。

```

書籍：はじめての設計をやりぬくための本 p98


### ユースケースの粒度
粒度はユーザ目的レベルにする

```
ユーザー目的レベル：
一番重要で基本になる。システムの利用者が仕事を完了させるための目的を表したレベル。
具体的な例としては、「その仕事が終わったらコーヒーブレイクできる、それが終わると一息入れられる仕事の単位」
一人の人間が中断無しに行える仕事です。

```

書籍：はじめての設計をやりぬくための本 p105-p106





### ユースケース記述の各項目

項目名|説明
---------|-------
ユースケース名|--
主アクター|ユースケースを実行する人
事前条件|ユースケースが始まる前に真であると保証されていること
主シナリオ|ユースケースを完了するための手順
ビジネスルール|業務を遂行するには従わなければないルール</br>ユースケースを補足するもの



### Haibitica標準機能
Habiticaの機能をそのまま使います。

#### タスクを作成する
項目|説明
---------|-------
ユースケース名|タスクを作成する
主アクター|私
事前条件|無し
主シナリオ|1.私はタスクTodoを作成する。</br>2.私はタイトル、チェックリスト、難易度を入力する</br>3.私はタグに「未着手」を選択する
ビジネスルール| 無し

#### タスクに着手する

項目|説明
---------|-------
ユースケース名|タスクに着手する
主アクター|私
事前条件|タスクを作成
主シナリオ|1.私はタグから「未着手」を外す。</br>2.私はタグに「着手」を選択
ビジネスルール|無し



#### タスクを完了する
項目|説明
---------|-------
ユースケース名|タスクを完了する
主アクター|私は
事前条件|タスクに着手する
主シナリオ|1.1.私はタグから「着手」を外す。</br>2.私はタグに「完了」を選択
ビジネスルール|無し


### 自前で実装する機能

#### バッチ処理
##### abiticaのタスクをデータベースに書き込む

項目|説明
---------|-------
ユースケース名|Habiticaのタスクをデータベースに書き込む
主アクター|サーバー
事前条件|・Habiticaから 現在の
主シナリオ|1.HabiticaAPIからタスクのデータを取得する</br>2.取得したデータをデータベースに保存する。
ビジネスルール|バッチ実行頻度ルール



項目|説明
-|----
ビジネスルール|外部連携実行頻度
内容|・１日１回実行</br>・13:00に実行する


#### BIツール側

##### タスクの着手開始時間と完了時間を確認する
項目|説明
---------|-------
ユースケース名|タスクの着手開始時間と完了時間を確認する
主アクター|私
事前条件|・Habiticaとデータベース連携 </br>・タスクを完了する
主シナリオ|１．タスクを一覧から検索</br>２．タスクの実績を確認



## 5.データのライフサイクル

### データのライフサイクルとは

ライフサイクルが変化するデータに対しては、変化するときのイベント、変化後のデータの状態を明示しておく必要あります。
タスクデータには「未着手」、「着手中」、「完了」の３種類のライフサイクルがあるので記しておきます。





### 図
```plantuml

@startuml
start
:１．タスク作成;
->タスク始める;
:２．タスク着手中;
->タスクを完了する;
:３.タスク完了;
stop
@enduml

```
状態|条件
----|---
1.タスク作成|タグ=未着手
2.タスク着手中|タグ=着手中
3.タスク完了|タグ=完了,チェックボタンを押す



# 参考


### Habitica

https://habitica.com/

## 概念設計について
書籍：システム設計の謎を解く p12

## ユースケース記述

書籍：はじめての設計をやりぬくための本
p101-109

## データのライフサイクル

書籍：システム設計の謎を解く p55

### 個人開発の目次
https://qiita.com/RYA234/private/c7918ebadb035c12aca2
HTMLの魔法使い：`<meta>` タグでページ挙動を制御する必須5選

## 概要

HTMLの `<meta>` タグは、ページの**設定・動作・情報伝達**を司る静かな司令塔だ。  
「SEOだけのもの」と思っているなら、それは誤解。

本記事では、特にフロントエンド開発者が押さえておくべき **5つの実用的な`meta`活用法**を紹介する。

---

## 対象環境

```text
HTML5準拠の全ブラウザ  
```

---

## 1. 文字コード設定（エンコーディング）

```html
<meta charset="UTF-8">
```

全ページで必ず入れるべき。文字化け回避の基本中の基本。

---

## 2. ビューポート制御（モバイル対応）

```html
<meta name="viewport" content="width=device-width, initial-scale=1.0">
```

スマホやタブレットでの表示崩れを防ぐレスポンシブ設計に必須。

---

## 3. 自動リダイレクト（または自動更新）

```html
<meta http-equiv="refresh" content="5; url=https://example.com">
```

5秒後に別URLへ自動遷移。  
カスタムエラーページやメンテナンス通知に便利。

---

## 4. キャッシュ制御（古いブラウザ向け）

```html
<meta http-equiv="Cache-Control" content="no-cache">
```

一部ブラウザではこれで再読み込みを強制できる。

---

## 5. SEO用ディスクリプション

```html
<meta name="description" content="このページは〇〇に関する技術的な解説です。">
```

検索結果の説明文に表示され、クリック率に影響。

---

## 結語

`<meta>` タグは見た目に現れないが、**振る舞いと伝達力をコントロールする裏方の王**だ。  
開発者なら、**見えない場所に宿るロジック**を疎かにするべきではない。

一行の`meta`が、ユーザー体験を左右することもある。
`<input type="number">` を制す者はフォームUIを制す：`min` / `max` / `step` の正しい使い方


## 概要

数値入力フォームを設計するとき、ユーザーに自由に何でも入力させてしまうのは非効率で危険だ。  
そこで活躍するのが、`<input type="number">` による入力制御。

`min` / `max` / `step` 属性を正しく指定すれば、**ユーザーが無効な値を入力するリスクを低減**できる。

---

## 対象環境

```text
HTML5以降対応ブラウザ（Chrome / Firefox / Edge / Safari）  
```

---

## 基本構文

```html
<input type="number" min="0" max="100" step="10">
```

この入力フィールドでは：

- 0〜100 の間のみ有効
- 10単位で増減（0, 10, 20, ..., 100）
- マウスホイール・↑↓キー・手動入力すべてに適用

---

## 使用例：年齢入力欄

```html
<input type="number" name="age" min="0" max="130" step="1" placeholder="年齢を入力">
```

---

## 使用例：数量入力（偶数のみ）

```html
<input type="number" min="2" max="10" step="2">
```

この場合、有効値は `2, 4, 6, 8, 10`。

---

## UXの改善：`required`と組み合わせる

```html
<input type="number" min="1" max="99" step="1" required>
```

- 空欄のまま送信しようとすると警告
- 数値が範囲外ならバリデーションエラーになる

---

## 結語

`<input type="number">` の真価は、**属性でロジックを宣言的に表現できる**点にある。  
JavaScriptに頼らず、HTMLだけで安全で使いやすいUIを提供できるのは強力だ。

**バリデーションはフロントエンドの第一防衛線。**  
その守備をHTMLでしっかり固めておこう。
`<details>` / `<summary>` タグで簡易UIを構築する：クリック展開のベストプラクティス


## 概要

情報量の多いUIでは、「詳細を見せたいけど、最初から全部表示するのはうるさい」──そんな場面がある。  
そこで便利なのが、HTML標準タグ `<details>` と `<summary>`。

これらを使えば、**JavaScriptを一切使わずにクリック展開UI**を実装できる。  
アクセシビリティ的にも優秀で、**ネイティブでサポートされているのが魅力**。

---

## 対象環境

```text
ブラウザ: Chrome / Firefox / Edge / Safari（主要ブラウザすべて対応）  
HTML5以降（標準仕様）
```

---

## 基本構文

```html
<details>
  <summary>詳細を表示</summary>
  <p>ここに詳細な説明や補足テキストを記述。</p>
</details>
```

---

## 表示例（実際のブラウザではこうなる）

▼ 詳細を表示  
　→ クリックすると中のテキストが展開される。

---

## 応用：リストや画像も入れられる

```html
<details>
  <summary>ショートカット一覧</summary>
  <ul>
    <li>Ctrl + S: 保存</li>
    <li>Ctrl + Z: 戻る</li>
    <li>Alt + Shift + ↑: カーソル追加</li>
  </ul>
</details>
```

テキストだけでなく、リスト・画像・テーブルなどあらゆるHTML要素をネストできる。

---

## スタイリング例（見た目を整えたいとき）

```html
<style>
details {
  margin: 1em 0;
  padding: 0.5em;
  border: 1px solid #ccc;
  border-radius: 5px;
}

summary {
  font-weight: bold;
  cursor: pointer;
}
</style>
```

---

## アクセシビリティ面でも優秀

- `<summary>` は自動的にボタン扱いされ、**キーボード操作もOK**。
- スクリーンリーダーにも**意図が正しく伝わるセマンティクス**。

---

## 結語

UIを軽くしたい、JSなしで完結したい──そんな願いをHTMLだけで叶えてくれる `<details>` / `<summary>`。  
ちょっとした設定やオプション表示、補足説明、FAQパネルなど、用途は無限。

**HTMLだけでここまでできる**ということを、今こそ思い出してほしい。

軽やかで、セマンティックで、しかも美しい。  
それがこのタグの力だ。
VSCodeで縦の列を一括選択・編集：`Alt + ドラッグ` / `Ctrl + Alt + ↑/↓`


## 概要

コード上で、特定の列（たとえば変数名や値）だけを選択して一括で変更したい──  
そんなニーズに応えてくれるのが、**VSCodeの「矩形選択」機能**（ボックス選択とも呼ばれる）。

`Alt + マウスドラッグ` あるいは `Ctrl + Alt + ↑/↓` を使えば、  
**縦方向の文字列をピンポイントに選択・編集**できる。

---

## 対象環境

```text
エディタ: Visual Studio Code  
OS     : Windows / Linux  
```

> ※ macOSの場合は `Option + Command + ↑/↓` または `Option + ドラッグ`

---

## 操作方法

### 方法1：マウスで選択

```text
Alt + マウスでドラッグ
```

矩形（ボックス）で範囲を囲むように選択。  
複数行の同じ列（例えば同じ位置の値や記号など）をまとめて編集可能。

### 方法2：キーボードのみで選択

```text
Ctrl + Alt + ↑ / ↓
```

現在のカーソル位置を起点に、**縦方向にカーソルを増やす**。  
列単位での同時編集が可能。

---

## 使用例：縦に並んだ値を一括で書き換え

```typescript
const x = 1;
const x = 2;
const x = 3;
```

この `x` の列だけを変更したいとき：

1. 最初の行の `x` にカーソルを置く
2. `Ctrl + Alt + ↓` を2回押す
3. すべての行の `x` を `value` に打ち換える

結果：

```typescript
const value = 1;
const value = 2;
const value = 3;
```

---

## 補足：矩形選択は空白行でも有効

たとえば以下のようにインデントだけがある空白行でも、**矩形選択で一括挿入**が可能：

```text
    |
    |
    |
```

ボックス選択したまま `// TODO:` と打てば、すべての行に同時に挿入できる。

---

## 結語

矩形選択は、**「行」ではなく「列」を意識するプロフェッショナルの武器**。  
変数名、インデント、コメント、桁揃え──どれもこのテクで一気に整えることができる。

VSCodeを使いこなすとは、こういう細部を制することに他ならない。  
マルチカーソルと組み合わせれば、**あなたのエディットは次の次元へ進化する。**
【Rails】form_withのhidden_field_tag と f.hidden_field

# はじめに

こんにちは。アメリカに住みながら独学でエンジニアを目指しているTairaです。

Railsでフォームを作成するとき、隠しフィールドを設定する方法として`hidden_field_tag`と`f.hidden_field`があります。それぞれの違いを具体的に理解しましょう。

### 1. hidden_field_tagとは
`hidden_field_tag` はフォームに関連付けられたモデルとは独立したパラメータを送信するときに使います。フォームオブジェクトとは無関係な単純なパラメータを設定したいときに最適です。

```erb
<%= hidden_field_tag :email, @user.email %>
```

フォーム送信後、パラメータは以下のように受け取れます。

```ruby
params[:email] #=> user@example.com
```

### 2. f.hidden_fieldとは
一方、`f.hidden_field`はフォームが持つモデルの属性として値を送信するときに使います。

```erb
<%= form_with(model: @user) do |f| %>
  <%= f.hidden_field :email, value: @user.email %>
<% end %>
```

フォーム送信後、パラメータは以下のようになります。

```ruby
params[:user][:email] #=> user@example.com
```

### 3. どちらを使うべき？

- **hidden_field_tagが適している場合**
  - モデルとは関係ない一時的なパラメータ（認証用トークン、確認用情報など）を送りたいとき。
  - 明示的にモデル属性とは分離して、フォーム処理を明確化したいとき。

- **f.hidden_fieldが適している場合**
  - モデルの属性を更新または作成する際に、フォーム入力欄では表示せずに内部的に値をセットしておきたいとき。

### まとめ
- `hidden_field_tag`はフォームモデルと無関係にトップレベルのパラメータをセット。
- `f.hidden_field`はフォームのモデル属性として値をセット。
VSCodeで複数行に同時カーソル：`Alt + Shift + ↑/↓` で爆速編集


## 概要

変数名の修正、複数行の同時編集、縦並びのインデント調整…。  
こうしたタスクでマウスや矢印キーを使っていては、**生産性が大きく落ちる**。

Visual Studio Code（VSCode）には、**複数行にカーソルを一瞬で配置できるショートカット**が用意されている。  
`Alt + Shift + ↑/↓` を使えば、直感的かつ爆速で複数行を同時に操作できる。

---

## 対象環境

```text
エディタ: Visual Studio Code  
OS     : Windows / Linux  
```

> ※ macOSの場合は `Option + Shift + ↑/↓` で同様の動作を実現可能

---

## 基本操作

```text
Alt + Shift + ↓   ← 下にカーソルを追加  
Alt + Shift + ↑   ← 上にカーソルを追加
```

---

## 使用例：連続行の変数を一括編集

以下のようなコードがあるとする：

```javascript
const a = 1;
const b = 2;
const c = 3;
```

各行の変数名（a, b, c）を同時に `value` に変更したいとき：

1. 最初の行にカーソルを置く
2. `Alt + Shift + ↓` を2回押して3行選択
3. 変数名を一括編集

```javascript
const value = 1;
const value = 2;
const value = 3;
```

わずか数秒で完了する。

---

## 応用：マルチカーソルで同時入力・同時削除

このショートカットで作成した複数カーソルは、**同時入力・同時削除・同時インデント**すべてに対応する。

```text
Tab / Shift+Tab    → 複数行の一括インデント  
Delete / Backspace → 複数箇所の一括削除  
文字入力           → 複数位置への同時入力
```

---

## 補足：非連続の複数カーソルも使いこなすなら `Ctrl + クリック`

```text
Ctrl + マウスクリック
```

で、任意の行にカーソルを追加可能。  
`Alt + Shift + ↑/↓` と組み合わせれば、**柔軟なマルチ編集が可能**になる。

---

## 結語

VSCodeはただのエディタではない。  
**カーソル操作だけで編集効率が10倍以上変わる**ことを知っておくべきだ。

`Alt + Shift + ↑/↓` は、あなたの編集スタイルを一段引き上げる。  
マウスでカーソルをチマチマ動かす時代は終わった。

「速く、正確に、美しく」── それがプロのエディットだ。
PowerShellでも使える履歴検索ショートカット：`Ctrl + R` で過去コマンドを一瞬で再利用


## 概要

コマンドラインで作業していると、「あのコマンド、もう一回使いたい」と感じることは多い。  
そんなときに便利なのが、**履歴検索ショートカット `Ctrl + R`**。

過去に入力したコマンドをキーワードでインクリメンタル検索し、即座に再実行可能。  
Linuxのbash/zshだけでなく、**WindowsのPowerShellでも使える**ことをご存じだろうか？

---

## 対象環境

```text
OS   : Windows 10 / 11  
Shell: PowerShell 5.x / 7.x（標準プロンプト / Windows Terminal）  
```

---

## 基本操作：`Ctrl + R`

PowerShell上で以下のキー操作を実行：

```text
Ctrl + R
```

すると、以下のようなプロンプトに切り替わる：

```text
(reverse-i-search)`': _
```

ここでキーワードを入力すると、**履歴から該当コマンドを順次表示**してくれる。  
Enterでそのまま実行、矢印キーで微調整も可能。

---

## 使用例

たとえば以前に以下のようなコマンドを実行していたとする：

```powershell
Get-Content .\access.log -Tail 50 -Wait
```

再度使いたい場合は、`Ctrl + R` を押してから `access` と入力すれば一瞬で見つかる。

```text
(reverse-i-search)`access': Get-Content .\access.log -Tail 50 -Wait
```

---

## 応用：複数候補の中から選ぶ

キーワードが複数マッチする場合は、`Ctrl + R` を**連打**して、履歴の古い順に遡れる。

```text
(reverse-i-search)`npm': npm run dev
(reverse-i-search)`npm': npm install
(reverse-i-search)`npm': npm ci
```

---

## 結語

`Ctrl + R` は、**CLI操作を劇的に高速化する最短ルート**だ。  
PowerShellにおいても問題なく使えるため、GUIで履歴を探すより圧倒的に効率的。

毎回似たようなコマンドを打ち直しているなら、それはもう「時間の浪費」。  
指先一つで履歴を呼び出せるこのショートカットは、CLIユーザーにとって最強の武器になる。
PowerShellでファイルの中身をサクッと確認するTips：`Get-Content` × `-Tail`


## 概要

ログファイルや設定ファイルをチェックする際、「テキストエディタを開くのが面倒」「とりあえず中身だけ確認したい」という場面は多い。  
特に開発中やデバッグ中など、**素早く情報にアクセスしたいとき**には、エディタよりCLIの方が圧倒的に速い。

本記事では、PowerShellでファイルの中身を即座に確認するためのコマンドを紹介する。

---

## 対象環境

```text
OS   : Windows 10 / 11  
Shell: PowerShell 5.x / 7.x  
```

---

## 基本構文

```powershell
Get-Content .\path\to\file.txt
```

ファイルの中身を行単位で標準出力に表示する。

---

## 応用：末尾のみ確認したいとき（ログ確認に最適）

```powershell
Get-Content .\app.log -Tail 20
```

`-Tail`オプションを使うことで、**ファイル末尾のn行だけを取得**できる。ログ確認においてはほぼ必須と言っていい。

---

## リアルタイムでログ監視（`tail -f` 的に）

```powershell
Get-Content .\app.log -Wait
```

- `-Wait`を付けると、**ファイルの更新を監視しつつリアルタイムで出力**される。
- `tail -f` 相当の動作。

---

## 組み合わせ例：末尾20行だけ + 監視モード

```powershell
Get-Content .\app.log -Tail 20 -Wait
```

これは最強のログ確認コマンド。実運用に即投入できる。

---

## 補足：エイリアスでもっと短く書く

```powershell
gc .\app.log -Tail 10
```

`Get-Content`は`gc`のエイリアスでもあるため、短縮して書ける。  
PowerShellならではの柔軟さが光る。

---

## 結語

「テキストファイルを開く」という行為に、GUIエディタを起動する必要はない。  
PowerShellの `Get-Content` は、**"今すぐ見たい" を叶える最短ルート**だ。

ログ、設定ファイル、結果出力、すべてに使えるユーティリティ。  
CLIから高速でプレビューする習慣を持てば、あなたの開発速度は確実に一段上がる。
数値リテラルの視認性を高める：`1_000_000` と書いて `1000000` を得る



## 概要

コードを読む際、大きな数値リテラルは読み間違いやすく、バグの温床になる。  
たとえば `1000000` や `86400000` のようなリテラルは、**ぱっと見て意味が分かりにくい**。

このような場面において、視認性を飛躍的に高めるテクニックが、**アンダースコアによる区切り**だ。

---

## 対象環境

```text
言語: JavaScript / TypeScript / Python / Kotlin / Swift ほか多数  
```

---

## 問題提起

次のようなコードを見たとき、直感的に値を理解できるだろうか？

```javascript
const TIMEOUT = 86400000; // ← これ何時間？
```

---

## 解決手段

アンダースコアで区切ると、圧倒的に可読性が上がる。

```javascript
const TIMEOUT = 86_400_000; // ← 24時間（ミリ秒）
```

```python
MAX_LIMIT = 1_000_000  # ← 100万
```

---

## 解説

### JavaScript / TypeScript

ES2021からサポート。アンダースコアは無視されるため、**実行時には数値そのものとして扱われる**。

```javascript
console.log(1_000_000 === 1000000); // true
```

### Python

Python 3.6 以降で正式サポート。

```python
print(1_000_000 == 1000000)  # True
```

### Swift / Kotlin など

これらの言語でも同様に使用可能。数値リテラルを視覚的に整理する文化が根付いている。

---

## 応用：時間や容量の定義に使う

```javascript
const ONE_MINUTE = 60_000;        // ミリ秒
const ONE_HOUR   = 3_600_000;     // ミリ秒
const ONE_GB     = 1_073_741_824; // バイト (1024^3)
```

```python
ONE_KB = 1_024
ONE_MB = 1_048_576  # 1024 * 1024
```

---

## 結語

可読性は、コードの信頼性に直結する。  
特に定数やハードコーディングが避けられない場面では、**数字の見た目**が理解度を左右する。

アンダースコア区切りは、**誰もが一瞬で取り入れられるテクニック**でありながら、  
プロフェッショナルなコードに不可欠な要素だ。

「1_000_000」は「1000000」と等しい。  
だが、**伝わり方はまったく違う。**
【Vite+Supabase】Uncaught Error: supabaseUrl is required.

# はじめに
環境変数ファイルを作成時につまったので記事にします。

# 問題
正しいURL、キーを入力したはずなのに表題のエラーがでる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3993509/701af45b-9e10-4205-b770-204c4ff7a550.png)


# 解決方法
環境変数名を.envで定義したものと違うものを指定していた。

```.env
VITE_SUPABASE_URL='https://~'
VITE_SUPABASE_ANON_KEY=キー
```

```diff_typescript:supabase.ts
import { createClient } from '@supabase/supabase-js'

- export const supabase = createClient(import.meta.env.VITE_SUPABASE_URL!, import.meta.env.VITE_SUPABASE_KEY!)
+ export const supabase = createClient(import.meta.env.VITE_SUPABASE_URL!, import.meta.env.VITE_SUPABASE_ANON_KEY!)

+ // 環境変数が正しく設定されていることを確認
+ console.log("Environment Variables:", import.meta.env);
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3993509/b324b1d2-739a-4e73-a674-c20c70604bf6.png)




# おわりに
:writing_hand:学んだこと
VITEプロジェクトの場合、環境変数の先頭に`VITE_`をつける
環境変数を読み込む際は`import.meta.env.環境変数名`にする
`process.env.環境変数名`にしたい場合は[こちら][1] の記事を参考に設定を変える

[1]:https://qiita.com/shunii/items/b00d556f3730e6b88708

# 参考

https://qiita.com/shunii/items/b00d556f3730e6b88708
npm ERR! code ERESOLVEが発生して困った話

`npm install`をしていたらエラーが発生しました。

```
PS E:\workspace\Python\tmp\front-back-end\frontend> npm install react-query
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: frontend@8.19.4
npm ERR! Found: react@19.1.0
npm ERR! node_modules/react
npm ERR! react@"^19.1.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react@"^16.8.0 || ^17.0.0 || ^18.0.0" from react-query@3.39.3
npm ERR! node_modules/react-query
npm ERR! react-query@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
```

`npm audit fix --force`や`rm -rf node_modules package-lock.json`, `npm cache clean --force`をしても全く直りませんでした。

# 原因

`react-scripts`が悪さをしてました。

> react-scriptsを使っているとreact-scriptsのバージョンが古すぎて他のパッケージと競合が起きる問題が発生しました
> create-react-app がどうやらメンテされなくなったようで react-script が邪魔をして 
> TypeScript を5以降にバージョンアップできなくなりました。
https://zenn.dev/xronotech/articles/11e671bf0315e7

`package.json`から`react-scripts`を外して`npm install`したところ、うまくいきました。
RSpecの初期セットアップと便利な設定

# RSpec のセットアップ

## Gemfile に rspec を追加

以下の gem を追加して、bundle install を実行。
rspec-rails には rspec-core とその他の独立した gem が含まれている。

```ruby
group :development, :test do
  gem 'rspec-rails' end
end
```

## テストデータベースを作成

```ruby:config/database.yml
test:
  <<: *default
  database: db/test.sqlite3
```

上記のように設定(されていることを確認)し、以下コマンドでテストデータベースを作成。

:::note info
すでに作成済みなら、rails タスクはテストデータベースがすでにあることをちゃんと教えてくれるので、既存のデータベースを間違って消してしまう心配はいらない。
:::

```bash
$ bin/rails db:create:all
```

## RSpec の設定

以下コマンドで RSpec の設定ファイルを生成。

```bash
$ bin/rails generate rspec:install
```

以下のファイルが作成されたことがターミナルに表示される。

```bash
  create  .rspec                 # RSpecの設定ファイル
  create  spec                   # テストファイルのディレクトリ
  create  spec/spec_helper.rb    # RSpecの動きをカスタマイズするヘルパーファイル
  create  spec/rails_helper.rb   # 上記と同じ
```

テストを実行(`bundle exec rspec`)し、以下のようなメッセージが表示されれば設定は完了。

```bash
  no examples found  # テストが作成されてないときのメッセージ
```

### RSpec の出力をドキュメント形式に変更

以下のように `.rspec` を編集することで RSpec の出力をデフォルトの形式から読みやすいドキュメント形式に変更できる。

```bash:.rspec
--require spec_helper
--format documentation
```

- テストスイートの実行中にどのスペックがパスし、どのスペックが失敗したのかがわかりやすくなる
- スペックのアウトラインが美しく出力
- 出力を仕様書のように使える

### rspec binstub を使って短いコマンドで実行できるようにする

通常の RSpec の実行は`bundle exec rspec`となるが、rspec binstub を使うと`bin/rspec`という短いコマンドで実行できるようになる。
以下のコマンドで binstub を生成。bin ディレクトリ内に rspec という名前の実行用ファイルが作成される。

```bash
$ bundle binstubs rspec-core
```

## ジェネレータの設定

`rails generate` コマンドを実行してモデルやコントローラーを作成すると、RSpec のファイルを spec ディレクトリに同時に作成できる。
RSpec をインストールしたことで、もともとデフォルトだった Minitest のファイルは test ディレクトリに作成されなくなり、RSpec のファイルが spec ディレクトリに作成されるようになる。
デフォルトの設定だと、不要なスペックが作成されることがあるので、好みで以下のように設定を変更できる。

```ruby:config/application.rb
config.generators do |g|
  g.test_framework :rspec,
    fixtures: false,       # テストDBにレコードを作成するファイルの作成をスキップ
    view_specs: false,     # ビューのテストファイルの作成をスキップ
    helper_specs: false,   # ヘルパーのテストファイルの作成をスキップ
    routing_specs: false   # ルーティングのテストファイルの作成をスキップ
  g.factory_bot false      # factory_botのファイルの作成をスキップ
end
```

:::note info
--pretend (-p) オプションを使用して実際に何が生成されるかを確認することができる

```bash
rails generate controller admin/campaigns/descriptions -p
```

:::

:::note info

spec ファイルの命名規則

`app/helpers/projects_helper.rb` >> `spec/helpers/projects_helper_spec.rb`

`lib/my_library.rb` >> `spec/my_library_spec.rb`

:::
個人開発：Habitica-外部連携ツール　目次


# 開発

## 概念設計
https://qiita.com/RYA234/items/675442e8a2acc17c0f3e

## 基本設計
https://qiita.com/RYA234/items/8a0016fc057cd977c44f

## 詳細設計

https://qiita.com/RYA234/items/b3b1c9771815b59d63a4

## 例外設計

## ログ設計


## 単体テスト設計




# 運用

## バックアップ/リストア運用

https://qiita.com/RYA234/items/4292a0f7cc1121eb2998


## 監視設計

## リリース デプロイ設計
Git LFSを使って巨大ファイルをGitHubで管理する

# 初めに
GitHubには、一度にPUSHできる容量の制限があり、大きなファイルはPUSHできません。
この記事ではそれを解決するGit LFSの簡単な使い方についてまとめます。


# 課題：GitHubでは100MB以上のファイルをPUSHできない
GitHubでは、一度にPUSHできるファイルサイズに制限があります。
上限は100MBです。

```powershell: 100MB以上のファイルをPUSHしようとする
> git push
remote: error: See https://gh.io/lfs for more information.
remote: error: File largeFile/largefile is 200.00 MB; this exceeds GitHub's file size limit of 100.00 MB
```

合計で100MBを超えた場合は100MBを超えないように分割してPUSHすれば問題ありませんが、一つのファイルが100MBを超えている場合はどう頑張ってもPUSHすることができません。

# 解決策：Git LFSを使えば大きなファイルをGitHubにPushできる

この問題を解決するのが、Git Large File Storage（Git LFS）です。
巨大ファイルを専用の別ストレージに管理し、そのポインターをリポジトリに格納するというものになります。

https://docs.github.com/ja/repositories/working-with-files/managing-large-files/about-git-large-file-storage


## Git LFSを試してみる
では、Git LFSを使って大きなファイルをアップロードしてみましょう。
環境は`Windows11 Pro`です。

### 1. Git LFSのインストール
以下からGit LFSをインストールしましょう。

https://git-lfs.com/

私の環境では、Git for Windowsに付属していたのか、最初からインストールされていました。


```powershell
> git lfs --version
git-lfs/3.6.1 (GitHub; windows amd64; go 1.23.3; git ea47a34b)
```

### 2. Git LFSで管理するファイルを選ぶ
`git lfs track`コマンドでGit LFSで管理するファイルを選択します。

```powershell
> git lfs track .\largeFile\largefile
Tracking "largeFile/largefile"
```

すると、プロジェクト直下に`.gitattributes`というファイルが作成されます。
どうやらこのファイルに、Git LFSで管理するファイルが記録されるようです。

```text:.gitattributes
largeFile/largefile filter=lfs diff=lfs merge=lfs -text
```

### 3. コミット
まずは`.gitattributes`をコミットしましょう。
その後、Git LFSで管理したファイルをコミットすれば完了です。

GitHubにアップロードされるのは、実際のファイルではなくポインタです。実態はGitHubのストレージに格納されています。
また、Git LFSで管理されているファイルには`Stored with Git LFS`という記載があり、一目で分かるようになっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/430841/7a7006d7-afbc-40ed-b6df-28de408100e7.png)

## Git LFSの注意点

### 無料枠は2GBまで
2025年3月時点で、GitHubのGit LFSの無料枠は2GBまでです。それ以上を超える場合は有料になります。

https://docs.github.com/ja/repositories/working-with-files/managing-large-files/about-git-large-file-storage

### アップロードしたファイルを削除するにはリポジトリごと消す必要がある
リポジトリからポインタを削除するとアップロードしたファイルの紐づけを消すことはできますが、サーバにはファイルが残り続けます。削除するには**リポジトリを削除する**か**サポートに連絡する**しか方法がないようです。
誤ってアップロードしないように注意しましょう。

https://docs.github.com/ja/repositories/working-with-files/managing-large-files/removing-files-from-git-large-file-storage

:::note info
Git LFSサーバを自前で用意したという記事もあるので、そうすればこのような問題も解決できるかもしれません。
:::



# 終わりに
今回はGit LFSを用いて巨大ファイルをGitHubにアップロードする方法を解説しました。
今度は自前でLFSサーバを用いる方法も試してみたいところです。

ここまでご覧いただきありがとうございました！
#0087（2024/03/30）ビュー・マテリアライズドビュー・一時テーブル

## データベースにおける「ビュー・マテリアライズドビュー・一時テーブル」の解説

データベースを活用するうえで重要な概念に「ビュー（View）」「マテリアライズドビュー（Materialized View）」「一時テーブル（Temporary Table）」があります。それぞれの特徴や用途を整理します。

---

### 1. ビュー（View）とは？

**ビュー**は、実テーブルのクエリ結果を仮想的にテーブルとして扱える仕組みです。

- **特徴**
  - 実際のデータを格納しない（仮想的なテーブル）。
  - 常に最新のデータを表示（実行時に毎回クエリを実行）。

- **用途**
  - 複雑なクエリを簡単なテーブルのように扱いたいとき。
  - データのアクセス制御（特定のカラムを非表示にする等）。

- **SQL記述例**

```sql
CREATE VIEW view_active_users AS
SELECT id, name, email FROM users WHERE active = true;
```

---

### 2. マテリアライズドビュー（Materialized View）とは？

**マテリアライズドビュー**は、ビューの結果セットを物理的なテーブルとして保存したものです。

- **特徴**
  - 結果を物理的に保存するため高速にアクセス可能。
  - 定期的または手動でデータを更新する必要がある。

- **用途**
  - 大規模なデータを繰り返し高速に検索したいとき。
  - 集計処理やレポート作成など頻繁に使用されるクエリの高速化。

- **SQL記述例（PostgreSQLの場合）**

```sql
CREATE MATERIALIZED VIEW daily_sales_summary AS
SELECT sale_date, SUM(amount) AS total_sales
FROM sales
GROUP BY sale_date;

-- データの更新
REFRESH MATERIALIZED VIEW daily_sales_summary;
```

---

### 3. 一時テーブル（Temporary Table）とは？

**一時テーブル**は、特定のセッションやトランザクション内だけで利用できる一時的なテーブルです。

- **特徴**
  - セッション終了時に自動的に削除される。
  - 一時的な作業領域として使える。

- **用途**
  - 一時的にデータを格納し複雑な処理を分割するとき。
  - 中間集計結果を保存して後続処理を簡略化するとき。

- **SQL記述例**

```sql
CREATE TEMPORARY TABLE temp_active_users AS
SELECT id, name FROM users WHERE active = true;

SELECT * FROM temp_active_users;

-- セッション終了時にtemp_active_usersは削除される。
```

---

### ビュー・マテリアライズドビュー・一時テーブルの比較

| 項目 | ビュー | マテリアライズドビュー | 一時テーブル |
|------|--------|---------------------|--------------|
| データ保存 | しない（仮想） | する（物理） | する（物理・一時的）|
| 更新頻度 | 常に最新 | 定期的または手動 | 必要に応じて随時 |
| 主な用途 | クエリの簡素化、アクセス制御 | 高速検索、レポート | 一時的処理・中間データ保存 |

---