1. 実践：足し算・引き算による入れ替え

【 動作確認 】 以下のコードは、`a` と `b` の差を計算し、その結果を中継地点とすることで値を交換しています。`calc_swap.c` として保存して実行してみてください。

2. アルゴリズムが適用できる型と注意点

【 技術的解説 】 この手法は数値計算に基づくため、適用できる型や制約に注意が必要です。

3. 技術的背景：なぜこのコードが生まれたのか

現代のコンピュータではメモリも豊富にあり、作業用変数を使う `tmp = a; a = b; b = tmp;` の方が可読性も高く安全です。しかし、メモリが極めて限られていた時代や、特殊なCPU命令を最適化したい場面などでは、このような「メモリを節約する工夫」が重宝されてきました。

4. 理解度チェック！練習問題

【 復習問題 】 今回紹介したアルゴリズムで、int型の変数 `a` と `b` の値を交換する際に発生しうる最も深刻なリスクはどれでしょうか？

選択肢：
A. 計算に時間がかかりすぎる。
B. 計算の途中で数値が型の最大範囲を超え、オーバーフローが発生する。
C. printf関数で表示できなくなる。
D. C言語の最新規格（C17）では禁止されている。

5. まとめ

「差分を利用して値を入れ替える」という発想は、変数の値を単なるデータではなく「状態の差」として捉える面白いアルゴリズムです。実務での利用には注意が必要ですが、こうした低レイヤのテクニックを知ることで、メモリと演算の仕組みに対する理解がより深まります。

1. 実践：int型の宣言と初期化

【 動作確認 】 以下のコードを `var.c` として保存して実行します。変数 `a` に値を格納し、表示する基本的な構造です。

2. 規格による宣言位置の制限と緩和

【 仕組みの解説 】 C言語の規格によって、変数を宣言できる場所のルールが異なります。現代のMac環境（C11/C17）では、C99以降の緩和されたルールが適用されています。

3. 未初期化変数のリスク

【 技術的注意点 】 `int a;` のように初期化を行わずに宣言した場合、その変数にはメモリ上に残っていた以前のデータ（不定値）が保持されます。これをそのまま使用すると意図しない挙動やバグの原因となるため、宣言時に明示的に初期化を行うことが推奨されます。

4. 変数の性質に応じた宣言位置の選択

現代の規格では自由な位置で宣言が可能ですが、コードの可読性を保つためには変数の役割に応じた整理が有効です。

5. 理解度チェック！練習問題

【 復習問題 】 現代のC言語（C99以降）における変数の宣言について、**正しい説明**はどれでしょうか？

選択肢：
A. 変数の宣言は必ず関数の1行目に書かなければならない。
B. `int a = 10;` のように、宣言と同時に値を代入（初期化）することができる。
C. 初期化していない変数には、自動的に「0」が代入される。
D. `int` 型の変数には、後から文字列を代入できる。

6. まとめ

C99規格による制約の緩和は、C言語の記述効率を大きく向上させました。MacのClang環境では、これらのモダンな仕様をデフォルトで利用できます。変数の性質を見極め、適切な位置で宣言・初期化を行うことで、堅牢なプログラムの構築が可能になります。

1. 実践：2種類のコメントを書いてみる

【 手を動かして確認 】 新しく `comment.c` を作成し、以下のコードをコンパイルしてみてください。コメント部分はコンパイラに無視されるため、実行結果には影響しません。

2. 伝統的な書き方：/* 文字列 */

【 ここがエンジニアの視点 】 最初期のC言語（旧規格）から存在する書き方です。記号で囲った範囲すべてがコメントになるため、長い解説を書くのに適しています。ただし、`/* ... /* ... */ */` のように入れ子（ネスト）にすることはできません。最初の `*/` が現れた時点でコメント終了とみなされ、エラーの原因になります。

3. 現代的な書き方：// 文字列

【 ここが仕組みのキモ 】 行の途中に `//` を書くと、その行の末尾までがコメントになります。実はこれ、もともとはC++という別の言語の機能でしたが、C99規格（1999年）から正式にC言語でも使えるようになりました。今のMac（C17/C11）環境であれば、何の問題もなく使用可能です。

4. 個人的な見解：なぜ「//」を優先して使うのか

【 ここがこだわり 】 2つの書き方がありますが、個人的には「//」をメインで使うようにしています。その理由は、圧倒的に「コードの修正（デバッグ）がしやすいから」です。

5. 理解度チェック！練習問題

【 チャレンジ 】 C言語のコメントに関する説明として、**間違っているもの**はどれでしょうか？

選択肢：
A. `/* */` は複数行を囲むことができる。
B. `//` は行の末尾までをコメントにする。
C. `//` 形式は、最初期のC言語（C89）でも標準で使えた。
D. コメントアウトを活用すると、特定の手続きを一時的に無効化できる。

6. まとめ：やってみて分かったこと

「なぜ2種類あるのか？」という疑問を深掘りすると、C言語が歩んできた進化の歴史に突き当たります。個人的にはメンテナンス性を重視して `//` を推奨しますが、両方の特徴を知っておくことで、他人が書いたコードを読む際にも戸惑わずに済みます。自分なりの「書き方のルール」を持って、楽しくコードを書いていきましょう。

1. 料理人とレシピの関係：ClangとC言語規格

【 ここがポイント 】 C言語の学習において、コンパイラと規格は「料理人とレシピ」の関係に似ています。この違いを理解すると、エラーの原因や書き方のマナーがより鮮明に見えてきます。

2. C言語の主な規格（C99 / C11 / C17）

【 ここがポイント 】 C言語は1970年代に誕生しましたが、今も進化し続けています。特に重要なのが以下の3つです。

3. 実践：自分のMacの「デフォルト規格」を調べる

【 ターミナルの動き 】 自分のMacのコンパイラが、普段どの時代のレシピ（規格）を基準にしているかを確認してみましょう。`--version` よりもさらに深い情報を引き出すコマンドを使います。

【 結果の読み方 】 この数値は、その規格が策定された年月（あるいはバージョン番号）を示しています。

4. 応用：あえて規格を指定してビルドする

【 ターミナルの動き 】 特定のルールで厳格にチェックしたいときは、コンパイル時に `-std` オプションを付けます。

5. 理解度チェック！練習問題

【 チャレンジ 】 今回学んだ内容の復習です。コンパイル時に、特定のC言語規格（例：C11）に準拠させるための正しい指定方法はどれでしょうか？

選択肢：
A. -ver=c11
B. -mode=c11
C. -std=c11
D. -rule=c11

6. まとめ：やってみて分かったこと

単に「プログラムを動かす」だけでなく、背後にある「Clang」というツールの特性や、「C17（201710L）」という準拠規格を知ることで、自分が今どの時代の技術を使っているのかが鮮明になりました。この「環境への理解」こそが、トラブルに強いエンジニアへの第一歩です。

1. 実践：計算結果を表示するプログラム

【 手を動かして確認 】 新しく `calc.c` というファイルを作成し、以下のコードを記述します。ただの文字列ではなく、実行時に計算が行われ、その結果が画面に表示されます。

2. コンパイルと実行結果

【 ターミナルの動き 】 ターミナルでビルドして実行します。プログラムの中に「2」という数字は書いていませんが、実行時に計算された結果が出力されることを確認してください。

3. 【重要解説】printfの「書式指定子」とは？

【 ここが仕組みのキモ 】 printfの「f」は **formatted（書式化された）** の略。単に表示するだけでなく、データをどのような形式で表示するかを指定できるのが最大の特徴です。ここで使った **`%d`** は、その中核となる「データの予約席」の役割を果たします。

4. 応用：書式とデータの対応ルール

【 ミスを防ぐ視点 】 printfの中に複数の `%d` を置くことも可能です。その場合、左から順番にデータが割り当てられます。この「左からの順番」を意識することが、表示バグを防ぐ基本です。

5. 理解度チェック！練習問題

【 チャレンジ 】 今回学んだ内容を復習しましょう。以下のプログラムの【空欄】に入る正しいコードはどれでしょうか？

選択肢：
A. %s
B. %d
C. %f
D. &d

1. 開発環境の確認：Apple Clang (arm64)

【 手を動かして確認 】 まずは、自分のMacに武器が備わっているか確認します。現在のMac（M1/M2/M3/M4チップ）では、アーキテクチャが「arm64」となっているのが特徴です。ターミナルで以下の結果が返ってくれば、準備は万端です。

※ `Target: arm64` は、Apple Siliconに最適化されたバイナリを生成することを示しています。

2. 作業ディレクトリの作成

【 実践のポイント 】 学習用のコードが散らからないよう、専用のディレクトリ（フォルダ）を用意します。こうした小さな整理整頓が、後のデバッグ効率を左右します。

3. ソースコードの記述：hello.c

【 ここがエンジニアの視点 】 テキストエディタを開き、以下のコードを入力して `hello.c` という名前で保存します。C言語の最も基本的な構成要素（標準入出力のインクルードと、main関数）のみを記述します。

4. コンパイルの実行（ビルド）

【 ターミナルの動き 】 書いたばかりのテキスト（ソースコード）を、arm64アーキテクチャが理解できる実行ファイルへ変換します。`-o` オプションで、出力ファイル名を指定するのがMac流のスマートなやり方です。

5. プログラムの実行

【 実行時の注意点 】 いよいよ実行です。カレントディレクトリにあるファイルを明示的に指定するため、頭に `./` を付けて実行ファイルを叩きます。

6. 【重要解説】なぜ `InstalledDir` がそこにあるのか？

【 ここが仕組みのキモ 】 先ほどのバージョン確認で表示された `InstalledDir: /Library/Developer/CommandLineTools/...` というパス。これは、Macが「Xcode本体をインストールしなくても、開発に必要な最小限のツール（Command Line Tools）を個別に管理している場所」を指しています。

7. 理解度チェック！練習問題

【 チャレンジ 】 今回の手順を復習しましょう。Macのターミナルで、カレントディレクトリにある実行ファイル「hello」を起動するための正しいコマンドはどれでしょうか？

選択肢：
A. run hello
B. hello.exe
C. ./hello
D. clang hello

8. まとめ：やってみて分かったこと

「コンパイル」という一見手間のかかるステップを踏むことで、テキストが「動くプログラム」に変わる瞬間を肌で感じることができました。IDE（統合開発環境）のボタン一つで実行するのも便利ですが、ターミナルで `clang` コマンドを直接叩く経験は、パスの概念やコンパイルプロセスの理解を深め、エンジニアとしての基礎体力を確実に底上げしてくれます。

1. 検索アルゴリズムを最適化する

【 現場の感触 】 データベースに「無駄な探索」をさせないのが基本です。特に存在確認などは、最後まで数えるか、見つかった瞬間に止めるかで雲泥の差が出ます。

2. 余計な「ソート」と「スキャン」を削る

【 現場の感触 】 データベースにとって最も重い処理の一つが「重複排除（ソート）」と「全表スキャン」です。これらを回避する選択がパフォーマンスの鍵です。

3. 解析器（オプティマイザ）のクセを掴む

【 現場の感触 】 SQLは「書いた順序」が評価に影響することがあります。データベースの解析エンジンがどう動くかを意識して記述しましょう。

4. まとめ：チューニングは「DBとの対話」

今回紹介した項目は、いずれも「DBの内部リソース（CPU・メモリ・I/O）をいかに節約するか」に直結しています。

一つ一つは小さな工夫ですが、大量データを扱う本番環境ではこの積み重ねが「100倍の速度差」となって現れます。実行計画（EXPLAIN）を確認しながら、最適な一文を追求していきましょう。

1. 開発環境の準備：Xcode Command Line Tools

【 現場の感触 】 MacでC言語をコンパイルするには、Apple純正のコンパイラ（Clang）が必要です。まずはターミナルから、開発の「儀式」とも言えるツールのインストールから始めます。

2. ソースコードの取得とディレクトリ作成

【 現場の感触 】 作業用フォルダを作成し、GitHubから最新の db.c をダウンロードします。curlコマンドを使って、GitHubのマスターリポジトリから直接保存します。

3. コンパイルの実行

【 現場の感触 】 Mac標準のコンパイラ（Clang）を使用して、ソースコードを実行可能なバイナリファイルに変換します。エラーが出なければ、同じフォルダ内に「db」という実行ファイルが作成されます。

4. データベースの起動と操作（実践）

【 現場の感触 】 実際にプログラムを動かし、データを入力してみます。ここで驚くのが、「CREATE TABLE」を一度も叩かずに insert ができてしまうことです。

5. 【重要解説】なぜ「表」を作らなくても入るのか？

【 仕組み 】 通常のDBではありえないこの挙動の理由は、ソースコードの中にあります。この `db.c` は、「ID、Username、Email」という3つの列を持つ1つのテーブルしか扱えないように、最初から「構造」がプログラムに直接書き込まれている（ハードコードされている）からです。

6. 本質的な「検証」：データの永続性確認

【 現場の感触 】 最後に、プロセスを終了してもデータが消えないことを確認します。これこそが「データベースを極める」ための第一歩です。

7. まとめ：やってみて分かったこと

「CREATE TABLEがいらない」のではなく、「最初から1つだけCREATE済みの表がある状態で起動している」という設計。この仕組みを理解することで、DBの心臓部である「ファイルI/O」や「ページ管理」がいかに動いているか、その一端を鮮明に体感することができました。

巨大なRDBMSも、突き詰めればこうした「ファイルの読み書き」の積み重ね。自作してみることで、トラブル時にも「今はディスクと対話中かな？」といった具体的な想像力が働くようになります。

1. 実行効率を高める書き方の基本

【 基本 】 データベースエンジンにとって、無駄なスキャンや重複排除（ソート）は最大の敵です。まずは、より効率的な演算子や関数を選ぶことから始めましょう。

2. インデックスとデータアクセスの最適化

【 ポイント 】 インデックスはただ作るだけでなく、「使われるように書く」のがコツです。また、読み込むデータの範囲をいかに絞り込むかが勝負を分けます。

3. まとめ：チューニングの優先順位

闇雲に修正するのではなく、まずは以下の表を参考に、コストの高い部分から手を入れていきましょう。

パフォーマンスチューニングに「銀の弾丸」はありませんが、これらの定石を組み合わせることで、システムのレスポンスは確実に見違えるはずです。

1. 設定の落とし穴：wal_levelの変更

【 現場の感触 】 最初のハードルは設定変更です。デフォルトでは論理レプリケーション用のログが出ないので、`postgresql.conf` を書き換えます。再起動が必要なので、本番環境なら「ちょっと待って」となるところですね。

2. パブリケーションの作成と権限の「儀式」

【 現場の感触 】 テーブルを作ってデータを放り込みます。ここで大事なのは「主キー（PK）」があること。論理レプリケーションでは「どの行を更新するか」を特定するためにPKが必須です。あとは接続用の専用ユーザーを作って、権限を付与します。この「運び屋」を作る作業がレプリケーションっぽさを感じさせます。

3. 同期開始！サブスクリプションの威力

【 現場の感触 】 サブスクライバー側で接続情報を指定してサブスクリプションを作成。実行した瞬間に、既存のデータが「バッ」と流れてくるのは見ていて気持ちいいものです。試しにデータを1行追加すると、即座に反映されるのが確認できました。まさにリアルタイム！

4. 応用：同期を止めても「裏で溜まっている」

【 現場の感触 】 運用でよくある「一時停止（DISABLE）」も試しました。停止中にパブリッシャー側でガシガシ更新（'ddd'を追加）しても、サブスクライバー側は静かなまま。でも、再度「ENABLE」にした瞬間、溜まっていた更新が追い付いてくる。この確実性が論理レプリの頼もしいところです。

実際にやってみると、コマンド一発で同期が制御できる手軽さと、内部でWALがしっかり管理されている安心感がよく分かりました。バージョン間のデータ移行や、特定のデータ集約には最高に便利そうです。