OmniAICreator/Qiita-1.07M huggingface dataset:
【React】react-router-dom にて画面を更新・リセットする方法

# 問題
`react-router-dom`の navigate の画面遷移を用いて、今開いている画面を更新したい。

# 方法
navigate の引数を"0"にする。

```Page.tsx
import { useNavigate } from "react-router-dom";

const Page = () => {
  const navigate = useNavigate();

  const refreshPage = () => {
    navigate(0);// 画面更新
  };

  // 省略
};
```
これで、画面更新をすることができます。

また、"1" を指定すると、一つ先に進み、"-1"を指定すると、一つ前に戻すこともできます。

```Page.tsx
import { useNavigate } from "react-router-dom";

const Page = () => {
  const navigate = useNavigate();

  const goBack = () => {
    navigate(-1);// 一つ前に戻る
  };

  // 省略
};
```

以上です。
【LPIC】LPICレベル1 - 共有ライブラリ管理 > リンカーについて

# 初めに
この記事ではリンカーについて、調べたことをここに記載します。

## コンパイルとは
簡単に言うと
「ソースコード」から「バイナリコード」に変換することをコンパイルといいます。

以下の記事を見ると、イメージを掴みやすいと思います。
[C言語で使うファイルの拡張子と役目を知る（.c .out/.exe .o .h）](https://qiita.com/4sterisk/items/839c0cdea17bfcb83887 "C言語で使うファイルの拡張子と役目を知る（.c .out/.exe .o .h）")

[C言語のコンパイル処理過程について](https://qiita.com/Mikeinu/items/45c63ba4e801e3f9599a "C言語のコンパイル処理過程について")


## リンカーとは
コンパイラで生成されたオブジェクトファイルを結合し、実行可能なプログラム（バイナリファイル）を作るツールのこと。
![リンカー_イメージ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3509425/cfb7aedf-5701-4444-80d4-dd9314945f59.png)

## スタティックリンクとダイナミックリンク
* スタティックリンク
実行ファイルに、使うライブラリのコードをまるごと取り込む方法。
* ダイナミックリンク
ライブラリを実行時に読み込む方法。ライブラリは参照するだけ。
##### イメージとしてはこんな感じ
* スタティックリンク
![スタティックリンク.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3509425/4cf58dd3-f997-42ac-aeb3-f01526b822c8.png)

* ダイナミックリンク
![ダイナミックリンク.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3509425/9069d68b-c5e7-4b41-b589-4d8addc0ca56.png)
ラズパイ初期設定 Zero 2W(メモ)

# IPアドレス固定化
- 接続名確認
 nmcli connection show
- コマンドで設定
sudo nmcli connection modify "接続名" \\
  ipv4.method manual \\
  ipv4.addresses "固定IPアドレス/24" \\
  ipv4.gateway "デフォルトゲートウェイ" \\
  ipv4.dns "DNS" \\
- sudo nmcli connection reload
- sudo nmcli connection up "接続名"
windows11で、sketchup6 その96

# 概要
windows11に、sketchup6を入れてみた。
rubyで、3Dを書く。
練習問題やってみた。

# 練習問題
webdialogで、プログラムランチャーを書け。

# 写真

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/18104/dd0907eb-e907-4522-8ad1-4e54160cd494.png)


# サンプルコード

```

def testweb2
	wd = UI::WebDialog.new("Ruby ", true, 'Runcher', 500, 200)
	wd.set_html <<-EOS
		<html>
		<head>
		</head>
		<body>
		<div><label><input type="radio" name="fruit" value="run0">サイコロ</label></div>
		<div><label><input type="radio" name="fruit" value="run1">時計</label></div>
		<div><label><input type="radio" name="fruit" value="run2">ブロック崩し</label></div>
		<br>
		<button onclick="run()">run</button>
		<script>
		function run() {
			var elements = document.getElementsByName('fruit');
			for (var i = 0; i < elements.length; i++)
			{
				if (elements.item(i).checked)
				{
					window.location = 'skp:' + elements.item(i).value;
				}
			}
		}
		</script>
		</body>
		</html>
	EOS
	wd.add_action_callback('run0') do |d, a|
		create_dice
	end
	wd.add_action_callback('run1') do |d, a|
		Tokei.new
	end
	wd.add_action_callback('run2') do |d, a|
		Block.new
	end
	wd.show
end




```

以上。
Postmanを使ってみた

# １．概要
API (Application Programming Interface)を呼び出すツール・実行サービスの1つで有名なPostmanを使ってみた。今回はAPIキーが不要かつ面白そうなAPIである[PokéAPI](https://pokeapi.co/)を利用してみる。

# ２．手順
### PokeAPIの確認
トップページにサンプルとして、APIエンドポイント（グレーの部分）とそれを含めたURL（グレー＋白の部分）が生成されている。これをそのまま使う。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877782/724568c9-e24d-4ed3-84e9-faf892ae235a.png)

### Postmanの準備
まずは[Postman](https://www.postman.com/)に登録し、トップ画面にアクセス
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877782/d5a9f234-d962-48fe-805e-eba64450f934.png)

今回はテンプレを活用するので、REST API Basicsを選択し、GETメソッドでディグダ(英語圏ではdittoって言うらしいw)のデータ取得する。
BaseURLをPokeAPIでしたグレーの内容に修正し、後続のURLパラメータ（/pokemon/ditto）と入力する。
最後に右にあるSendボタンでGo！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877782/45f6d77f-0ff8-4bb3-91c1-95408faa0544.png)

JSON形式で様々なディグダの情報が取得される。じめん属性からどのポケモンシリーズで登場したかも事細かに取得できた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3877782/3bef4fc1-c965-4a7f-91ba-d83dffdee6a6.png)

# ３．まとめ
今回は、APIを簡単に呼び出すPostmanを使う方法を解説した。
IT初心者でも使いやすいので、APIとはなんだろう？という方はこれを使って実際の動作を見てみるとよいかと思う。
APIの幅広い分野で活用され奥も深いので、ぜひ世界中のありとあらゆるAPIサービスをPostmanで呼び出してみてほしい。
OpenVPN・Tailscaleを併用した自宅ネットワーク構成

```markdown
# OpenVPNとTailscaleを併用した自宅ネットワーク構成とリモート接続トラブル対応

## はじめに
本記事では、学生である私が、自宅ネットワークに構築したOpenVPNとTailscaleを用いたネットワーク構成について説明します。この構成を利用して、iPad ProからWindows 11 Pro PCへのリモート接続を実現し、RDPやSunshine＋Moonlightを用いた映像操作を可能にしました。この記事では、その設定経緯、発生した問題、最終的な構成方針（ハイブリッド構成）について初心者向けに解説します。

## 1. 構成概要と目的
このネットワーク構成の目的は、iPad ProからWindows PCへのリモート接続を安全かつ効率的に実現することです。以下の構成を採用しています：

- **メインルーター**：TP-Link ER605
- **VPNサーバー**：OpenVPN（UDP/1195）
- **ローカルネットワーク**:******
- **VPNクライアント用IPプール**：*********
- **モバイル端末**：iPad Pro（OpenVPNクライアント、Tailscale）
- **リモート操作用アプリ**：Microsoft Remote Desktop, Moonlight（Sunshine稼働）
- **開発系サービス**：Nextcloud, OpenProject, SSH（VPN経由でアクセス）

## 2. 発生した問題と対処法

### （1）OpenVPN経由でRDPが接続できない問題
- **問題点**：Windowsのリモートデスクトップ設定やファイアウォール許可は適切だったが、VPNクライアントからの通信が許可されていなかった。
- **対処法**：VPNユーザーに対しRemote SubnetとIP Poolを設定し、ポート競合・アドレス競合を回避しました。

### （2）OpenVPN経由でSunshineに接続できない問題
- **問題点**：VPN接続は成功しているが、Moonlightが接続できない。
- **対処法**：WindowsファイアウォールがVPN経由の通信をブロックしていたため、Tailscaleでは問題なく接続できました。Tailscaleは自動的に信頼されるネットワークとして認識されるため、制限を受けませんでした。

## 3. 最終方針：ハイブリッド構成の採用
安定性と安全性を両立させるため、以下のように役割を分担しました：

### Tailscale（P2P通信可能なmesh型VPN）
- **用途**：Sunshine＋Moonlightによる低遅延リモートデスクトップ
- **理由**：ポート開放・ファイアウォール調整不要で接続が安定

### OpenVPN（ルーター中心のL3 VPN）
- **用途**：Nextcloud, OpenProject, SSH等のWeb/開発系サービスアクセス
- **理由**：ドメイン連携、固定IP制御、管理性に優れている

## 4. 今後の課題と展望
- OpenVPN通信にもSunshineポートを開放することで、完全移行も視野に入ります。
- ProxmoxやWireGuardを用いたさらなる高速VPN構成の検討も行っています。
- 学内アクセスや将来的な遠隔授業連携を見据えたSAML/OAuth2対応についても検討中です。

この記事が、初心者の方が自宅ネットワークを構築する際の参考になれば幸いです。
```
WordからQiitaへ：GPT-4o×CLIで自動記事生成・投稿システム構築

```markdown
# 自動Qiita記事生成・投稿CLIツールの紹介

この記事では、WordファイルからMarkdown形式の技術記事を自動生成し、Qiitaへ投稿するCUIベースのCLIツールについて紹介します。このツールの開発経緯や機能概要を、初心者にもわかりやすく説明します。

## 背景と目的

従来、Qiitaに記事を投稿するには、構成の検討、Markdown記述、手動投稿という複数の工程が必要でした。本プロジェクトは、これらのプロセスを自動化し、効率的なナレッジ共有と発信を支援することを目的としています。

## システム構成

本システムは、以下の主要コンポーネントにより構成されています：

- **Python 3.11+**
- **OpenAI（GPT-4o API）**
- **python-docx（Word読み込み）**
- **python-dotenv（APIキー管理）**
- **requests（Qiita API通信）**

## 処理フロー

以下の手順で処理を進めます：

1. Word（.docx）ファイルをCLIで指定
2. GPT-4oでQiita記事構成を自動生成（Markdown形式）
3. 生成結果をMarkdownファイルとして保存
4. CLIから投稿タイトル・公開設定を入力
5. Qiita APIを使って記事を非公開または公開で投稿

## 実装コード概要

### 1. Wordファイルの読み込み

```python
from docx import Document

def read_docx(path):
    doc = Document(path)
    return "\n".join([para.text for para in doc.paragraphs if para.text.strip()])
```
指定したWordファイル（.docx）を開き、空行を除いて本文を結合して返します。

### 2. GPT-4oによるMarkdown生成

```python
from openai import OpenAI

client = OpenAI(api_key=openai_api_key)

def generate_qiita_structure(docx_text, style_hint="Beginner-friendly technical article"):
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "You are an assistant that structures and edits articles for Qiita."},
            {"role": "user", "content": f"Generate a Qiita-style Markdown article:\n{docx_text}"}
        ],
        temperature=0.7,
    )
    return response.choices[0].message.content
```
Wordから取得した本文をもとに、GPT-4oにより技術記事の構成をMarkdown形式で自動生成します。

### 3. Qiitaへの投稿処理

```python
import requests

def post_to_qiita(title, body, token, tags=["Python", "GPT-4", "Qiita"], private=True):
    headers = {"Authorization": f"Bearer {token}"}
    data = {
        "title": title,
        "body": body,
        "private": private,
        "tags": [{"name": tag} for tag in tags]
    }
    response = requests.post("https://qiita.com/api/v2/items", json=data, headers=headers)
    return response.status_code, response.json()
```
タイトル・本文・タグを指定して、Qiita APIを使い自動的に記事を投稿します。

## 実行例

CLI実行時の標準的な出力例です：

```
Enter the .docx filename: example.docx
[INFO] Markdown saved to: example_qiita.md
Enter Qiita post title: test02
Make it private? (y/n): y
[✅] Successfully posted to Qiita!
URL: https://qiita.com/ramalong/private/xxxxxxxxxxxxxxxxxx
```

## おわりに

本CLIツールにより、文章作成からQiita投稿までの流れが一貫して自動化されました。今後は、タグ自動提案、記事の一括投稿、既存記事の更新、記事ID管理などの機能拡張も検討しています。

このツールを活用して、より効率的な情報共有を実現しましょう。
```
いろんなアルゴリズムのテンプレ

\[知恵の館の目次](https://qiita.com/rionQ/items/0ba7a700620a1d617bc6)
\# 立ち位置・仕様
\* いろんなアルゴリズムをコピペできるように記録するのみ
\* 最適化が目的でない
\* たまにメモとして解説を残す
\* 最低限でまとめる
\* データを抽出しやすいように個別のIDを付与
\* あるアルゴリズムにおいて、他のアルゴリズムが登場する際にはそのIDを付与
\* IDは16進数表記
\* なるべく最低限なパッケージで実装
\* なるべく特殊なオブジェクト型は使用しない

\# TargetID
xx.xx.xx.xx

\# ReferenceID
xx.xx.xx.xx [bar] https:
xx.xx.xx.xx [bar] https:


\# ニュートン・ラフソン法
\* 微分可能関数 $f$ が $f(x)=0$の解、つまり根を求めるための反復的手法
\* 一元n次方程式で実行可能
\```python:
def foo(x):
	return x
\```

\# 使用方法
\```python:
x = foo(1)
print(x) # 1
\```
AI society change prediction 01

```markdown
# AIを前提とした社会の変化予測

AIの進化に伴い、社会制度や人々の生活様式が大きく変わることが予測されています。本稿では、その変化を初心者にもわかりやすく解説します。

## 1. 社会制度の「個体」から「連続体」への転換

これまでの人間社会は、国家や企業、個人といった「個体」ベースで制度設計されてきました。これは認知負荷を軽減し、責任や権利を明確にするための手段でした。しかし、AIの登場はこの前提を覆します。AIは現実を連続的で流動的なものとして処理できるため、既存の組織や個人という枠組みを超えた制度設計が可能です。

### 具体例
- **税制**: 個人単位ではなく、リアルタイムの経済活動に基づく動的課税が可能となる。
- **組織**: 固定の企業形態ではなく、プロジェクトベースで最適編成される流動的な組織（DAO的存在）へのシフト。

### 予測される変化
- 固定された「国」「会社」「所有者」概念が弱まり、流動的・分散的な主体による意思決定が中心となる。
- リアルタイムで更新される法律や制度。
- 責任帰属のあり方も連続的・共同体的に変化する。

## 2. AIは「新しい自然」として受容される

AIは単なるツールではなく、自然法則に類似する存在となりつつあります。AIは予測困難な「環境」として存在し、人間はこれに適応していく必要があります。

### 具体例
- **金融市場**: AIトレーディングアルゴリズムが、人間の理解を超えた市場変動を引き起こしています。
- **インフラ管理**: 都市交通やエネルギー配分をAIが最適化し、人間の手を離れた制御が進んでいます。

### 予測される変化
- AIを理解するよりも、AIを前提にした適応型社会への移行。
- AIとの共進化的ガバナンス。
- 人間中心主義の相対化。

## 3. 変わらない領域と変わる領域の峻別

### 変わらない領域
- 最終的責任の所在問題。
- 人間の倫理的・情緒的価値観。

### 変わる領域
- 知的財産権の再定義。
- 富の再分配モデル。

## 4. 社会変革の最大ボトルネック：人間の「社会的保守性」

AIが技術的に公平な富の再分配や最適な公共資源配分を可能にしても、人間社会は伝統的枠組みを簡単には手放せません。この「社会的合意の遅延」が、技術進化と制度変革の間に深刻なギャップを生み出します。

### 具体例
- 自動運転技術が完全に実用化しても、法律整備や社会の受容が遅れる。
- グローバルな富の再分配提案があっても、ナショナリズムに阻まれる。

## 5. 新しい人文社会学の必要性

これからの社会には、AIリテラシーを備えた哲学者、制度設計ができる政治家、技術と倫理を橋渡しする研究者が求められます。彼らは「このAIシステムにどんな倫理的枠組みを与えるべきか？」「連続的社会における正義とは何か？」などを実践的に扱うことが必要とされます。

## まとめ：AI前提社会の方向性

AIが前提となる社会においては、従来の制度や価値観が見直され、新たなルールや倫理が形成されていくでしょう。人々はこの変化に適応し、AIと共進化するガバナンスを考える必要があります。
```
よく使う「問題ない」「大丈夫」の罠

#
## 「問題ない」「大丈夫」というキーワード
### 特に新人エンジニアと会話すると飛び交うキーワードではないかなと最近感じます。
#
## 「問題ない」「大丈夫」の会話を紐解くと・・・
#### 意見の尊重と自走を目的として、課題・進捗は一任しますが確認のため「いざレビュー！！」すると
### 例えば・・・
##### ・期日対し「問題ない」「大丈夫」とは異なり期日枠から漏れ出している
##### ・課題に対し「問題ない」「大丈夫」の結論付けが「根拠なき空想」「願わくば」と紐づいている
##### ・段取りに対し「問題ない」「大丈夫」と異なりフロー図で例えると「スタート」→「エンド」に近い無策な段取り
##### ・コードやコンフィグに対し「問題ない」「大丈夫」以前にググった内容に疑問も感じずにコピペする

#
## 「問題ない」「大丈夫」が湧いてくる根源は一体！？
#### 客観的に知りたいのでGeminiさんに尋ねてみました。
#### 1.楽観主義
#### 2.認知バイアス
#### 3.感情的要因
#### 4.状況的要因
#### 5.生理的要因
#### だそうです。
<br>

### 他にも原因がありそう。
#
## 「ググってコピペ」思考グセも混じってそう
[この記事](https://qiita.com/kitty-cat/items/49086b6ba134856248ee)を掲載していますが、「ググってコピペ」も一役買ってそうな気がします。
#### 何か一つ課題を任せ、飛び交った会話の中に含む解らないキーワード、課題を片っ端から「ググって」るようです。
#### しかもコードやコンフィグは英単語なのに「検索ワード」はカタカナ😱
#### 新人君のディスプレイを覗くとブラウザータブと単一のカタカナキーワードが無数に存在してます。
#### つまり、「ググって」追い求めてきた答えらしき答え、しかも「ググる」で検索ヒットした1番目を拾って**Mission Complete!!🎉**

#### 「ググる」事に対し否定はしてませんが、追い求めていた答えがヒットすると「他人の答え」を養分にしてしまう習性があるようです。

### フローで示すと
##### 脳内処理「スタート」→「ググる」→「答えゲット」→「エンド」
##### そして「問題ない」「大丈夫」と紐づく
### 何も自分自身の推論・論理立てて検証してない😱

### AI時代に突入した今、「ググる」ことも時代遅れですが・・・・・・・・
### 一番罪なのは、「貴重な時間を費やしてグルりまくって、自責を問わない答え」を養分にする。😖
### 他にもAIを使えば得る答え精度も高いのですが、単に「ググる」は単一・単語だけ。
### 「ググる」好きな方達にとってはAIツールは問題を分解し問う能力が必要なので扱いにくいのかも。

#
## 課題解決方法を考えてみる
#### 私の意見ですが、現代風に一言で言うと「メタ認知能力を向上させる」なのかな？と考えています。
#### もっと簡単に言うと学生時代の「予習」「復習」を繰り返し、予習で課題の解像度を上げて、答えを出した道のりを再度見つめ直すと言う「復習」を繰り返す。

#
## 結論
### 「問題ない」「大丈夫」の根拠は算数の必要条件や絶対条件にも似てますが、「課題の解像度を上げる」「得た答えに疑いを持って検証する・論理立てる」ことで真の「問題ない」「大丈夫」が得られると思います。
Next.js Parsing error: Unterminated regular expression literal.eslint

## 何が起きたか

Next.jsを利用しています。以下のコードでエラーが発生しました。

**エラー内容**
```shell
Parsing error: Unterminated regular expression literal.eslint
```

```ts
import React from "react";

function Navigation() {
  return <div>Navigation</div>;
}

export default Navigation;
```

正規表現に関して言われていますが、divタグを正しく読み込めていない感あります。


## 解決策

ファイル名 `Navigation.ts` を`Navigation.tsx`に変更しました。
寝ぼけてtsで作ってしまったようです。
いろんなアルゴリズムの目次

[ページ作成のテンプレ](https://qiita.com/rionQ/items/89e860d7d386e7896177)

# 目次
00.00.00.01 [バブルソート](https://qiita.com/rionQ/items/b9532b4443231331ebca)
00.00.00.02 [選択ソート](https://qiita.com/rionQ/items/72d1e04fbbbac1244e63)
00.00.00.03 [挿入ソート](https://qiita.com/rionQ/items/2b070daf3e8013671448)
00.00.00.04 [シェルソート](https://qiita.com/rionQ/items/4e9ca46891d925d3c742)
00.00.00.05 [クイックソート](https://qiita.com/rionQ/items/ce9e66d80bc1772a3c4b)
00.00.00.06 [ヒープソート](https://qiita.com/rionQ/items/a923c224c790e24b3291)
00.00.00.07 [マージソート](https://qiita.com/rionQ/items/e15414f8d606d41bb35f)
00.00.00.08 [高速逆平方根計算](https://qiita.com/rionQ/items/1e8c26bed0c07438c694)
00.00.00.09 [数珠順列の候補](https://qiita.com/rionQ/items/e58a8401ee657976dbd3)
00.00.00.0a [円順列の候補](https://qiita.com/rionQ/items/3230eedacb6835e162f9)
00.00.00.0b [最大値](https://qiita.com/rionQ/items/a9b3882f0e46bcbb858f)
00.00.00.0c [ニュートン・ラフソン法](https://qiita.com/rionQ/items/147febd59773c2169486)
00.00.00.0d [深さ優先探索（depth first search）](https://qiita.com/rionQ/items/737c2bd9db9a9f039d28)
00.00.00.0e [幅優先探索（breadth first search）](https://qiita.com/rionQ/items/bc0457f97aec79610134)
00.00.00.0f [線形探索（linear search）](https://qiita.com/rionQ/items/cb2ac6ea40cd80c3d268)
00.00.00.10 [二分探索（binary search）](https://qiita.com/rionQ/items/bad31fb0ea591d5431f2)
00.00.00.11 [センチネルによる線形探索（sentinel linear search）](https://qiita.com/rionQ/items/f1b9fac886a01f9469c5)
00.00.00.12 [深さ優先探索と幅優先探索との差分がわかりやすいアルゴリズム](https://qiita.com/rionQ/items/0b1b0cfc9adbee197aec)
00.00.00.13 [n桁のm進数を全て列挙](https://qiita.com/rionQ/items/df203966a8b93ce6427b)
00.00.00.14 [run length encoding](https://qiita.com/rionQ/items/b6aca53f93f856ca2cb4)
00.00.00.15 [run length decoding](https://qiita.com/rionQ/items/b68521edf55015cbe866)
00.00.00.16 [swiched run length encoding](https://qiita.com/rionQ/items/826dc59d16d5794d30b8)
00.00.00.17 [桁ごとに異なる進数を持つ数値の列挙（i番目からj番目まで）
](https://qiita.com/rionQ/items/85cbd660557bea493040)
【Go】line-bot-sdk-goのv8でwebhookを実装する

## 概要
`line-bot-sdk-go`は[[API構築5] line-bot-sdk-goとngrokでchatbotを作る](https://zenn.dev/tofucode/articles/504bfdd232a0d2)の記事で紹介されている通り、lineからのwebhookを受けて処理をするライブラリです。この記事で紹介されている実装はv7のものですが、v8になって若干実装のやり方が変わっていたのでメモ書きです。

## 前提
* 使用したline-bot-sdk-goは`v8.13.1`です。


## 変更点の概要
[こちら](https://github.com/line/line-bot-sdk-go/blob/master/examples/kitchensink/server.go)の公式のサンプルにある通り、リクエストのParseやイベントの種別の判定にwebhookのパッケージを使用する必要があります。また、イベントの種別の判定はswitch文で行う実装となります。

## 実装サンプル
LINEで友達登録をされた時の実装サンプルを以下に記載します。APIのフレームワークはechoを使用してる前提で、Handler部分の実装になります。

```go
import (
	"os"

	"github.com/jackc/pgx/v5"
	"github.com/labstack/echo/v4"
	"github.com/line/line-bot-sdk-go/v8/linebot"
	"github.com/line/line-bot-sdk-go/v8/linebot/webhook"
)

func LineCallBackHandlerSample(c echo.Context) error {
	// bot作成
	bot, err := linebot.New(
		os.Getenv("LINE_MESSAGE_SECRET"),
		os.Getenv("LINE_MESSAGE_CHANNEL_ACCESS_TOKEN"),
	)
	if err != nil {
		return err
	}
	// webhookのParseを使用してコールバックのリクエストを取得
	callbackRequest, err := webhook.ParseRequest(os.Getenv("LINE_MESSAGE_SECRET"), c.Request())
	if err != nil {
		return err
	}

	for _, event := range callbackRequest.Events {
		// イベントの種類をswitch文で判定
		switch e := event.(type) {
        // webhookの型を使用
		case webhook.FollowEvent:
			source := e.Source
			// ソースタイプがユーザーの場合のみ
			switch s := source.(type) {
            // webhookの型を使用
			case webhook.UserSource:
				// LINEのユーザIDですでに通知登録済みかDBで判定（処理の詳細は記載割愛）
				_, err := GetUserByLineId(c.Request().Context, s.UserId)
				if err != nil {
					if err != pgx.ErrNoRows {
						return err
					} else {
						// LINEのユーザIDでDBのレコード追加（処理の詳細は記載割愛）
						_, err := CreateLineUser(c.Request().Context, s.UserId)
						if err != nil {
							return err
						}

						_, err = bot.ReplyMessage(
							e.ReplyToken,
							linebot.NewTextMessage("友達登録しました"),
						).Do()
					}

				} else {
					_, err = bot.ReplyMessage(
						e.ReplyToken,
						linebot.NewTextMessage("すでに友達登録済みです"),
					).Do()
				}
			}
	}

    return err
}
```
いろんなアルゴリズム"00.00.00.0c"

[知恵の館の目次](https://qiita.com/rionQ/items/0ba7a700620a1d617bc6)
# 立ち位置・仕様
* いろんなアルゴリズムをコピペできるように記録するのみ
* 最適化が目的でない
* たまにメモとして解説を残す
* 最低限でまとめる
* データを抽出しやすいように個別のIDを付与
* あるアルゴリズムにおいて、他のアルゴリズムが登場する際にはそのIDを付与
* IDは16進数表記
* なるべく最低限なパッケージで実装
* なるべく特殊なオブジェクト型は使用しない

# TargetID
00.00.00.0c

# ReferenceID

# ニュートン・ラフソン法
* 微分可能関数 $f$ が $f(x)=0$の解、つまり根を求めるための反復的手法
* 一元n次方程式で実行可能
```python:
def NewtonRaphsonMethod(func, derivative, x1, step):
	# func : 元の関数
	# derivative : 導関数
	# args : 初期値
	# step : 反復回数
	xn = x1
	for _ in range(step):
		xn = xn - func(xn)/derivative(xn)
	return xn
```

# 使用方法
```python:
def func(x):
	return (x-3)**2 - 1

def derivative(x): #　事前に導関数を計算する必要
	return 2*(x-3)

if __name__ == '__main__':
	x = NewtonRaphsonMethod(func, derivative, 8, 10)
	print('y=0となるとき、xは{}'.format(x)) # 4 (初期値によっては2)
```
Rails:form_withのmodelオプションで正しいURLヘルパーが見つからない(NoMethodError undefined method `xx_path' )

環境
Ruby:3.2.2
Rails:7.1.5

期待していた動作
```
form_with model: [:admin,user]
```
・modelオプションによるリソース識別で最終的なフォーム送信先がadmin/users(POST)になっていてほしい。

症状
・admin_pathを探してNoMethodエラーが出ている。
・エラーメッセージは以下の通りだった
```
NoMethodError in Admin::Users#new
undefined method `admin_path' for #<ActionView::Base:0x000000000529e0>
```
推察
・modelオプションでは生成するHTMLのaction属性のURL(フォームの送信先パス)に変換する前にURLヘルパーを探している？
・そして今回探されるべきURLヘルパーはadmin_pathではなくadmin_user_pathなのではないか？

調査
・modelオプションの挙動。内部の仕組みが記述されている記事は見つけられなかったが、結果から見るとmodel:xxと指定したとき⇒xx_path/model:[A,B]と指定したとき⇒A_B_pathというURLヘルパーを探すようである。
・またmodelオプションでのリソース識別を行う前提条件としてresources/resource+αでルーティングを行っていることを確認する必要がある

https://railsguides.jp/form_helpers.html#%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E3%82%92%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AB%E7%B5%90%E3%81%B3%E4%BB%98%E3%81%91%E3%82%8B

・前提条件となるresourcesでのルーティングは確認できた。
・またrails　routesでパスとurlヘルパーの対応関係を確認したところ、期待するパスに対応するURLヘルパーはやはりadmin_user_pathであることが確認できた。
⇒modelオプションの@userにuserオブジェクトが代入されていないのではないか？
解決策
・やはりコントローラーでのビューに渡すインスタンス変数名がタイポ(正:@user)していたため正しいURLヘルパーを探していないことが原因だった。
```ruby
  def new
    @users = User.new
  end
```

抽象化・一般化・重要なポイント
・model:xxと指定したとき⇒xx_path/model:[A,B]と指定したとき⇒A_B_pathというURLヘルパーを探す
・modelオプションでのリソース識別を行う前提条件としてresources/resource+αでルーティングを行っていることを確認する必要がある
【Spring】REST APIの作成①GET


### ■ リクエストの送信
GETリクエストで、データを取得するリクエストを送る。

![rest-get.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4050514/462d747e-9f8d-46f1-b5c3-ba30cb970f91.png)
↑Acceptヘッダで 取得するデータの形式をJSON形式に指定している。
デフォルト設定は「* / *」(=なんでも受け付ける)であり、SpringBootは自動で適切な形式(ほぼJSON)を選んで返すので、特に何も指定しなくてもJSONで返ってくる。
```JavaScript
const id = 1
const res = await fetch(`/api/words/${id}`, {
    method: "GET", //GETの場合は省略可
    headers: {  //省略可
        "Accept": "application/json"
    }
});		
```

### ■ コントローラでハンドリング

```java
@Controller
public class WordApiController {

    @GetMapping("/api/words/{id}")
    @ResponseBody
    public WordDto getWordsById(@PathVariable("id") Integer id){
        return wordService.findById(id);
    }
}
```
メソッドに@ResponseBody を付けることで、戻り値の WordDto オブジェクトが JSON形式に変換されてレスポンスされるようになる（Springの HTTPMessageConverter が自動で処理）

毎回メソッドごとに @ResponseBody を書くのは面倒なので、クラスに @RestController を付けることで次のように書ける。
```java
@RestController
public class WordApiController {

    @GetMapping("/api/words/{id}")
    public WordDto getWordsById(@PathVariable("id") Integer id){
        return wordService.findById(id);
    }
}
```
### ■ HTTPMessageConverterがJavaオブジェクトをJSONに変換

![rest-get-res.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4050514/0c988bc8-6ef2-4aab-bdc3-b1897e7bf27a.png)

### ■ クライアント側(JS)でJSONを取得する
```JavaScript
if(res.ok){
const word = await res.json();
//wordのプロパティから値を参照できる
}
```
いろんなアルゴリズム"00.00.00.0b"

[知恵の館の目次](https://qiita.com/rionQ/items/0ba7a700620a1d617bc6)
# 立ち位置・仕様
* いろんなアルゴリズムをコピペできるように記録するのみ
* 最適化が目的でない
* たまにメモとして解説を残す
* 最低限でまとめる
* データを抽出しやすいように個別のIDを付与
* あるアルゴリズムにおいて、他のアルゴリズムが登場する際にはそのIDを付与
* IDは16進数表記
* なるべく最低限なパッケージで実装
* なるべく特殊なオブジェクト型は使用しない

# TargetID
00.00.00.0b

# ReferenceID

# 最大値
```python:
def _max(l):
	v = l[0]  
	for n in l[1:]:
		if n > v:
			v = n
	return v
```

# 使用方法
```python:
l = [2,6,3,1,6,8,29,2,4,5,8]
v = _max(l)
print(v) # 29
```
統計検定2級 F検定

## はじめに
[前回](https://qiita.com/koji0705/items/b1f899e302e3f2cab8fb)までに水準間平方和と残差平方和を学びました。ただ、水準間平方和と残差平方和を算出したけど、これって結局どうやって扱えばいいの？って疑問が。よく見ると、F検定をやって初めて価値のあるものらしいです。そのため、今回はF検定を学んでいきます！！

## ✅ F検定とは？グループ間に差があるかを検定する方法

水準間平方和（SSB）や残差平方和（SSE）を計算しただけでは、「差があるかどうか」は判断できません。  
**F検定**を使うことで、グループ間に統計的に有意な差があるかを評価できます。

---

### ✅ F値とは？

F検定では、以下のように**「グループ間のばらつき」と「グループ内のばらつき」**を比べます。

$$
F = \frac{\text{水準間分散（MSB）}}{\text{残差分散（MSE）}}
$$

---

### ✅ 分散の求め方

- グループ数：$k$、データ総数：$N$
- $\text{MSB} = \dfrac{SSB}{k - 1}$（水準間平方和 ÷ 自由度）
- $\text{MSE} = \dfrac{SSE}{N - k}$（残差平方和 ÷ 自由度）

---

### ✅ P値で判断する

- F値が大きい → グループ間に差がある可能性が高い
- F値をもとに**F分布**からP値を求める
- <strong>P値 < 0.05（有意水準）</strong>なら、「有意な差がある」と判断


## ✅ 問題設定

ある学校で、A組・B組・C組の3クラスについて、テストの点数を調査しました。

| クラス | 点数         |
|--------|--------------|
| A組    | 60, 65, 70   |
| B組    | 80, 75       |
| C組    | 50, 55, 60   |

この3つのクラスに、**平均点に有意な差があるか**を**F検定**で確認します。

---

## ✅ ステップ1：平方和の計算

### ▶ 各クラスの平均と全体平均

- A組の平均：65  
- B組の平均：77.5  
- C組の平均：55  
- 全体の平均：64.375

---

### ▶ 水準間平方和（SSB）

$$
SSB = \sum n_j(\bar{y}_j - \bar{y})^2 = 609.375
$$

- A組: $3 \times (65 - 64.375)^2 = 1.1719$
- B組: $2 \times (77.5 - 64.375)^2 = 344.531$
- C組: $3 \times (55 - 64.375)^2 = 263.672$

---

### ▶ 残差平方和（SSE）

$$
SSE = \sum (y_{ij} - \bar{y}_j)^2 = 112.5
$$

- A組: $(60-65)^2 + (65-65)^2 + (70-65)^2 = 50$  
- B組: $(80-77.5)^2 + (75-77.5)^2 = 12.5$  
- C組: $(50-55)^2 + (55-55)^2 + (60-55)^2 = 50$

---

## ✅ ステップ2：F値の計算

| 項目       | 計算内容                         | 値        |
|------------|----------------------------------|-----------|
| グループ数 | $k = 3$                          |           |
| 全データ数 | $N = 8$                          |           |
| 自由度     | $df_1 = k - 1 = 2$、$df_2 = N - k = 5$ |     |
| $MSB$      | $SSB / df_1 = 609.375 / 2$       | 304.688   |
| $MSE$      | $SSE / df_2 = 112.5 / 5$         | 22.5      |
| **F値**    | $F = MSB / MSE = 304.688 / 22.5$ | **13.53** |

ここから、P値を算出する。

```python:
# 📌 ライブラリのインポート（scipyからf分布を使う）
from scipy.stats import f

# ✅ 入力値（F値と自由度）
F_value = 13.53  # 計算済みのF値
df1 = 2          # 自由度（グループ間）
df2 = 5          # 自由度（グループ内）

# ✅ P値の計算（右側の確率）
p_value = 1 - f.cdf(F_value, dfn=df1, dfd=df2)

# ✅ 出力
print(f"F値: {F_value}")
print(f"自由度 (df1, df2): ({df1}, {df2})")
print(f"P値: {p_value:.5f}")

# ✅ 判定
if p_value < 0.05:
    print("→ 有意差あり（P < 0.05）")
else:
    print("→ 有意差なし（P ≥ 0.05）")
```



```shell:
F値: 13.53
自由度 (df1, df2): (2, 5)
P値: 0.00961
→ 有意差あり（P < 0.05）
```
SREノススメ　其の６

# SRE本 第9章「シンプルさ」詳細まとめ【複雑さとの闘い・設計原則・実例付き】

---

## 🔰 はじめに

SRE本 第9章「シンプルさ」では、Googleがインフラや運用において**「複雑さ」こそが最大の信頼性低下要因**であると認識し、**シンプルな設計を重視する文化と哲学**を解説しています。

信頼性・運用性・拡張性をすべて維持し続けるために、なぜシンプルさが重要なのか？どうすればシンプルに設計できるのか？この章ではその問いに向き合います。

---

## 🧱 複雑さの本質とは

### ✅ 定義

複雑さ（Complexity）とは、「**あるシステムの振る舞いを予測しづらくする要因の総体**」です。

### 🔥 複雑なシステムの弊害

- **トラブルシュートが難しい**
- **変更の影響範囲が読みづらい**
- **障害が連鎖しやすい**
- **人による運用・保守が困難になる**

> 複雑さは技術的負債であり、障害の温床です。

---

## 🧠 なぜエンジニアは複雑にしてしまうのか？

| 誘因 | 説明 |
|------|------|
| 機能追加 | ユーザー要求を満たそうとして仕組みが増える |
| スケーリング対応 | トラフィック増加でインフラ構成が多層化 |
| チーム交代 | 歴史的経緯の理解不足で設計が継ぎ接ぎになる |
| コンウェイの法則 | 組織構造がシステムに投影されてしまう |

---

## 📌 シンプルさを設計に組み込む方法

### ✅ 設計時の原則

1. **理解しやすいこと**
2. **変更しやすいこと**
3. **予測可能であること**
4. **不要な依存を避けること**

### 🔧 シンプルにするための具体策

- 機能を分離してモジュール化
- 可視性・監視性を意識した構成にする
- 明示的なエラー処理とタイムアウトを設計に含める
- 単一責任の原則（SRP）を守る

---

## 🧭 システム設計の複雑化を防ぐフロー（図解）

```mermaid
graph TD
    A[要件定義] --> B[最小実装の選定]
    B --> C[運用時の想定]
    C --> D[障害時の簡素さを確認]
    D --> E[スケーラビリティの検証]
    E --> F[拡張計画とドキュメント整備]
```

---

## 📊 例：複雑 vs シンプルな設計比較

| 観点 | 複雑な設計 | シンプルな設計 |
|------|-------------|----------------|
| デプロイ方法 | 5段階の手動スクリプト | CI/CDで自動化 |
| ログ構成 | ローカル保存＋FTP＋手動圧縮 | Cloud Logging一元管理 |
| エラー処理 | 例外が沈黙し原因不明 | ログ＋アラート＋メトリクス連携 |

---

## 🧠 Googleの事例と学び

- Googleでは「スケーラブルだが複雑な設計」をシンプルにリファクタリングした事例が多数ある
- 複雑な依存関係は、新人オンボーディングの障壁になる
- 「**このシステムを1週間で再構築できるか？**」という問いが設計の健全性を測る指標になっている

---

## ✅ SRE的シンプル設計の鉄則

- **理解できないシステムは運用できない**
- **SLOやエラーバジェットの可視性がある構造を選ぶ**
- **SREはシステムの「なぜそうなっているか」を説明できるようにしておく**
- **シンプルであることはセキュリティにも寄与する**

---

## 📌 まとめ

- 複雑さはあらゆる障害の母体
- シンプルな設計は、**信頼性・変更容易性・学習コスト削減**につながる
- シンプルを保つには、**設計段階から運用まで一貫した意識づけ**が必要

---

## 🚀 次にやること

1. 自システムにおける「複雑な箇所」を3つ書き出す
2. その構成・依存関係・手順を図解する
3. 「1週間で作り直せるか？」を自問してリファクタリング計画を立てる

---
SREノススメ　其の５

# SRE本 第7章・第8章 詳細まとめ【自動化の進化とリリースエンジニアリング】

---

## 🔰 はじめに

SRE（Site Reliability Engineering）において、トイル削減と信頼性確保は最重要課題です。本記事では、第7章「Googleにおける自動化の進化」と第8章「リリースエンジニアリング」の内容を詳細に解説し、Googleがどのように「効率」と「信頼性」を両立してきたかを学びます。

現場で自動化に悩む方、リリースの安定性に課題を感じている方に向けて、Googleの実例に基づいた実践的なヒントを提供します。

---

# 第7章：Googleにおける自動化の進化

## 🏗️ 自動化が求められる背景

Googleのように何百万台ものマシン、数千のサービスが稼働する環境では、人手による対応には限界があります。

- 運用チームが成長するサービスに追いつけない
- 手動操作は時間がかかり、ヒューマンエラーの原因となる
- 運用が属人化し、新人のオンボーディングも困難になる

そのため、SREは運用をスケーラブルに保つために「自動化」を推進します。

---

## 🧭 自動化の進化ステージ（図解）

```mermaid
graph TD
    A[Stage 0: 手動操作] --> B[Stage 1: スクリプト化]
    B --> C[Stage 2: 半自動]
    C --> D[Stage 3: フル自動]
    D --> E[Stage 4: 自律型システム]
```

| ステージ | 特徴 | メリット | 主な課題 |
|----------|------|----------|----------|
| 0. 手動 | Runbookに従って人が対応 | 柔軟に判断できる | 人的コスト・エラー多発 |
| 1. スクリプト化 | 操作をbash/python等で簡略化 | 再現性、スピード向上 | 管理が属人化 |
| 2. 半自動 | トリガーは人間、処理は機械 | 手動より速く安全 | 監視との統合が不十分 |
| 3. フル自動 | 条件により自動実行 | スケーラブル、高信頼性 | テスト・監視設計が必須 |
| 4. 自律型 | 判断と復旧を自動で行う | 真の「セルフヒーリング」 | 複雑、設計難易度が高い |

---

## 🧠 Googleが得た教訓

- **初期の自動化は属人化しやすく壊れやすい**
- **安定した手動運用のパターンをまず確立することが先**
- **観測 → 実行 → 記録（ログ） → フォールバック（ロールバック）の4点セットが重要**

> 自動化とは「人間の置き換え」ではなく「人間の判断力を補助・強化する」ための手段です。

---

# 第8章：リリースエンジニアリング

## 🚀 リリースの意義

「ソフトウェアをデプロイする」ことがリリースの全てではありません。  
**ユーザーに安全かつ安定して機能を届けること**がリリースの本質です。

信頼性を最優先とするSREにとって、リリースはただの「開発後作業」ではなく、**信頼性を崩さずに価値を届ける最後の関門**です。

---

## 🔧 安全なリリースの4大要素

| 要素 | 説明 |
|------|------|
| 再現性 | 同じプロセスで何度でも同じ成果を出せること |
| テスト性 | あらかじめ品質とSLOを保証する検証を行うこと |
| ロールバック性 | 問題発生時にすぐに元に戻せる体制 |
| 段階的リリース | 一部ユーザーから試し、徐々に全体展開 |

---

## 🧭 リリースフロー例（図解）

```mermaid
flowchart LR
    C1[コードマージ] --> C2[CIビルド & テスト]
    C2 --> C3[ステージング環境への自動デプロイ]
    C3 --> C4[SLO監視・自動検証]
    C4 -->|OK| C5[段階的に本番展開]
    C4 -->|NG| C6[ロールバック処理・アラート通知]
```

---

## 🧪 CI/CDとリリース品質の関係

- CI/CDはスピードを提供する一方で、品質を守る仕組みが必要です
- 信頼性を守るには、**以下の3本柱が欠かせない**：

1. **自動テスト**（ユニット/統合/負荷）
2. **自動監視**（SLO/SLIでの異常検知）
3. **自動ロールバック**（問題発生時の即時復旧）

---

## 🧠 Googleの事例から

- 初期はチームごとに手法がバラバラだった
- 中央集権的なリリース基盤（Borg + Blaze）に移行し、品質が安定
- 機能フラグ・カナリアリリースを駆使する文化が根付いている
- 「リリース頻度を高めること」＝「信頼性が高い証拠」

---

## ✅ SRE的リリース原則

- **信頼性が最優先**：速度よりも安定性を重視
- **失敗を前提に設計**：必ずロールバック手段を用意
- **一気に出さない**：段階的リリース＋機能フラグが基本
- **トイルの排除**：手動リリースは即、自動化の対象

---

## 📌 まとめ

- **第7章：自動化は段階的に進め、信頼性を損なわないように慎重に行うこと**
- **第8章：リリースは開発のゴールではなく、SREが品質を守りながら価値を届ける最終ステップ**
- 共通して重要なのは「**人手でしかできない部分をどうやって仕組みに変えるか**」

---

## 🚀 次にやること

1. 自動化していない手動作業を洗い出し、リスクと時間コストを評価
2. 現在のリリースフローを図解して課題を洗い出す
3. 小さな部分から「安定したプロセス」を自動化し、繰り返せるように改善サイクルを回す

---
脱課金！自宅LLMサーバでサクッとAIコーディングを始める方法

# GPU非搭載のWindows/MacからローカルLLMコーディングする手順まとめ

今回は、UbuntuマシンでLM Studioを利用してOpenAI互換のAPIを立ち上げ、WindowsマシンのVSCodeから利用できるようにするまでの手順をまとめます。


## 🌟 ゴール

GPU非搭載端末のVSCodeでローカルAIコーディングする

## ✅ 検証環境

### LLMサーバ（Ubuntu側）

* OS: Ubuntu 24.04 
* GPU: GeForce RTX 5060 Ti（VRAM 16GB）
* ソフトウェア: LM Studio 0.3.15-11 x64
* モデル: Qwen3-30B-A3B-GGUF Q3\_K\_L

---

### 検証端末（Windows側）

* OS: Windows 11
* ソフトウェア: VSCode 1.99.3
* VSCode拡張機能: Continue


## ✅ 前提条件

* UbuntuでLM Studioをインストール済み
* WindowsとUbuntuは同一ネットワーク（同じWi-FiやLAN）上に接続されている

## 🛠️ 作業手順

### 1. Ubuntu側のLM Studio設定を確認

LM Studioを起動し、下タブでUser以外が選択されている事を確認
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3123299/11d2dfd2-8de1-43a2-a5c9-e1ff929ea1c7.png)

左タブ開発者から以下を有効化：

* **Server Port** → 1234（デフォルト）
* **ローカルネットワークでサービング（Serve on local network）** → ✅ チェック
* **CORSを有効にする** → ✅ チェック（ブラウザやアプリからの接続用）
* **Status: Stopped** → Runningに変更
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3123299/4d8c520d-5f7c-4e68-ac16-0b3c4a65a6d8.png)

これにより、Ubuntuは `0.0.0.0` でバインドしLANに公開されます。

---

### 2. UbuntuのIPアドレスを確認

ifconfigコマンド等で確認。Wi-Fiなら `wlp5s0`、有線なら `enp4s0` を確認。例：

```
inet 192.168.x.x  netmask 255.255.255.0
```

この場合、Windowsからアクセス出来るエンドポイントURLは：

```
http://192.168.x.x:1234/v1/chat/completions
```

---

### 3. Ubuntuのファイアウォール（ufw）を設定

Ubuntuでは外部接続がブロックされていることが多いので、以下でポート1234を開放：

```bash
sudo ufw allow 1234
sudo ufw reload
```

ステータス確認：

```bash
sudo ufw status
```

---

### 4. Ubuntu側でローカル確認

Ubuntu上で一度接続確認：

```bash
curl http://192.168.x.x:1234/v1/models
```

モデル一覧が返ればOK。

---

### 5. Windows側から接続確認

Windowsのブラウザで：

```
http://192.168.x.x:1234/v1/models
```

同様にモデル一覧が返ればOK。

---

### 6. VSCodeのContinue設定例

`C:\Users\ユーザー名\.continue\config.yaml` のmodelsに以下を追加：

```yaml
models:
  - name: LM Studio Local
    provider: openai
    model: qwen3-30b-a3b
    apiBase: http://192.168.x.x:1234/v1
    apiKey: EMPTY
    roles:
      - chat
      - edit
```

---

### 7. VSCodeのContinueでLM Studio Localを選択

LM Studio Localを選択し、ChatやEditで会話が返ればOK。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3123299/2a233c4b-e191-4ab9-8506-1641f1c3a3fd.png)


## ⚠️ よくあるハマりポイント

* 「ローカルネットワークでサービング」を有効化していない
* `ufw` がポートを閉じている
* Wi-Fiルーターがクライアント間通信をブロックしている（ゲストWi-Fiでは特に要注意）
* 設定ファイルのproviderにopenai以外を指定している


## 🔚 まとめ

* LM Studioのネットワーク公開設定を有効化する
* Ubuntuのファイアウォールを解放する
* 正しいIPでWindowsから接続する
* Continueの接続設定をする
GitHub Actions で reviewdog バイナリを直接インストールして使用する

#

## 背景

GitHub Actions で reviewdog を使いたい場合、[reviewdog/action-setup](https://github.com/reviewdog/action-setup) を使用するのが一般的ですが、先日サプライチェーン攻撃の被害に遭ったようです。

[[Security Advisory] Supply Chain Attack on reviewdog GitHub Actions during a specific time period #2079](https://github.com/reviewdog/reviewdog/issues/2079)

2025/5/4 時点で緊急対応はされているようですが、事案としては進行中となっており reviewdog/action-setup を使用するのはセキュリティ的にリスクがあります。

そのため、上記 issue でも述べられているように、reviewdog バイナリを直接インストールして使用する方法を共有します。

> Consider directly installing and using the reviewdog binary instead of reviewdog/action-* if you want to completely eliminate the risk of GitHub Action-based supply chain attacks.

## 方法

[reviewdog/action-setup の install.sh](https://github.com/reviewdog/action-setup/blob/master/install.sh) より、最低限必要な部分を抽出することで対応しました。

```yml
      - name: Setup reviewdog
        shell: bash
        env:
          REVIEWDOG_TEMPDIR: ${{ runner.temp }}
        run: |
          curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/fd59714416d6d9a1c0692d872e38e7f8448df4fc/install.sh | sh -s -- -b "${REVIEWDOG_TEMPDIR}/reviewdog/bin" latest
          echo "${REVIEWDOG_TEMPDIR}/reviewdog/bin" >> "$GITHUB_PATH"
```

最新版以外を使用したい場合は、curl コマンドの latest を変更してください。

```shell
curl -sfL https://raw.githubusercontent.com/reviewdog/reviewdog/fd59714416d6d9a1c0692d872e38e7f8448df4fc/install.sh | sh -s -- -b "${REVIEWDOG_TEMPDIR}/reviewdog/bin" [vX.Y.Z]
```

上記をワークフローに記載することで、GitHub Actions で reviewdog を使えるようになりました。
いろんなアルゴリズム"00.00.00.0a"

[知恵の館の目次](https://qiita.com/rionQ/items/0ba7a700620a1d617bc6)
# 立ち位置・仕様
* いろんなアルゴリズムをコピペできるように記録するのみ
* 最適化が目的でない
* たまにメモとして解説を残す
* 最低限でまとめる
* データを抽出しやすいように個別のIDを付与
* あるアルゴリズムにおいて、他のアルゴリズムが登場する際にはそのIDを付与
* IDは16進数表記
* なるべく最低限なパッケージで実装
* なるべく特殊なオブジェクト型は使用しない

# TargetID
00.00.00.0a

# ReferenceID

# 円順列の候補
```python:
import itertools
def circularPermutation(nodes):
	l_list = []
	per = []
	for l in itertools.permutations(nodes, len(nodes)):
		if l not in l_list:
			per.append(l)
			extend_l = l+l
			l_list.extend([extend_l[i:i+len(nodes)] for i in range(len(nodes))])
	
	return per
```

# 使用方法
```python:
nodes = ['A','B','C','D']
cp = circularPermutation(nodes)
print(cp)
[('A', 'B', 'C', 'D'),
 ('A', 'B', 'D', 'C'),
 ('A', 'C', 'B', 'D'),
 ('A', 'C', 'D', 'B'),
 ('A', 'D', 'B', 'C'),
 ('A', 'D', 'C', 'B')]
```
【Vitis】Standaloneアプリでprintfを使う

# はじめに

Vitisでスタンドアロンアプリを作成する際、printfが使えるとDebugに便利です。
本記事では、Vitisでスタンドアロンアプリを作成する際にprintfを使う方法について説明します。

# 環境

- Vivado/Vitis 2024.2
- Zynq7010
- PLのUARTが接続されていること

# 設定

VivadoでZynq Block DesignでUARTを有効します。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/532235/4e1493eb-60ce-495a-8a5c-8b48b23c0102.png)

私の場合は、MIO24、25をUART1が接続されているのでこのような設定となっています。

Vitisでプラットフォームを作成した後、Settingsを開きます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/532235/80b2b69a-6885-429b-b36a-da402b3ccdfa.png)

Boar Support Packageのstandaloneを選択すると、standalone_stdin, standalone_stdoutの設定があるので、使用するUARTを選択します。
UARTが１つしか無い場合は、デフォルトの状態で問題ないとおもいます。

# 使い方

xil_printfを使うことで、UARTに出力することができます。

```C
#include "xil_printf.h"

int main() {
    xil_printf("Hello from UART!\r\n");
    return 0;
}
```

実行すると、シリアルコンソールに出力されます。
デフォルトの通信速度は、115200bpsなので、この速度でシリアルコンソールを設定しておいて下さい。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/532235/f522ec75-5e56-4eb5-9158-5f0dc9ce41d2.png)
いろんなアルゴリズム"00.00.00.09"

[知恵の館の目次](https://qiita.com/rionQ/items/0ba7a700620a1d617bc6)
# 立ち位置・仕様
* いろんなアルゴリズムをコピペできるように記録するのみ
* 最適化が目的でない
* たまにメモとして解説を残す
* 最低限でまとめる
* データを抽出しやすいように個別のIDを付与
* あるアルゴリズムにおいて、他のアルゴリズムが登場する際にはそのIDを付与
* IDは16進数表記
* なるべく最低限なパッケージで実装
* なるべく特殊なオブジェクト型は使用しない

# TargetID
00.00.00.09

# ReferenceID

# 数珠順列の候補
```python:
import itertools

def necklacePermutation(nodes):
	l_list = []
	per = []
	for l in itertools.permutations(nodes, len(nodes)):
		if l not in l_list:
			per.append(l)
			extend_l = l+l
			reverse_extend_l = tuple(reversed(extend_l))
			l_list.extend([extend_l[i:i+len(nodes)] for i in range(len(nodes))])
			l_list.extend([reverse_extend_l[i:i+len(nodes)] for i in range(len(nodes))])
```

# 使用方法
```python:
nodes = ['A','B','C','D']
np = necklacePermutation(nodes)
print(np)
"""
[('A', 'B', 'C', 'D'), 
 ('A', 'B', 'D', 'C'), 
 ('A', 'C', 'B', 'D')
]
"""
```
SREノススメ　其の４

# SRE本 第6章「分散システムのモニタリング」詳細まとめ【図解・用語・実例付き】

## 🔰 はじめに

本記事では、SRE本（Site Reliability Engineering）第6章「分散システムのモニタリング」について、SRE未経験者や実務者にも理解しやすいよう要約・解説します。

モニタリングは、SREの基本中の基本。異常の検知・原因の特定・パフォーマンスの分析・容量管理など、あらゆるSRE活動の出発点になります。

---

## 📡 モニタリングの目的と役割

| 目的 | 説明 |
|------|------|
| 障害の検知 | サービスの異常をリアルタイムで察知する |
| トラブルシュート | 原因の絞り込みと復旧対応 |
| パフォーマンス管理 | 応答速度やスループットの把握 |
| キャパシティプランニング | リソース使用率を把握して将来の需要に備える |

---

## 🧠 SREが考える「良いモニタリング」とは？

### ✅ 原則

- **ユーザー視点であること**：ユーザー体験に直結するメトリクスを重視
- **自動でアラートを出せること**：人手で気づくのでは遅い
- **無駄なアラートを出さないこと**：ノイズ削減が運用の鍵
- **可観測性（Observability）を意識すること**

---

## 🔍 重要用語の整理

| 用語 | 説明 | 例 |
|------|------|-----|
| メトリクス (Metrics) | 数値化された状態情報 | CPU使用率、リクエスト数 |
| ログ (Logs) | イベントや状態の履歴 | エラーログ、アクセスログ |
| トレース (Traces) | リクエストの経路・処理時間を追跡 | 分散トレースツール |
| イベント (Events) | 特定の出来事を表す通知 | Podの再起動など |
| アラート (Alerts) | 事前定義した条件に基づく警告 | SLO違反、5xx増加 |

---

## 🧭 モニタリング設計の指針（図解）


```mermaid
graph TD
    A[ユーザー体験の把握] --> B[SLIの特定]
    B --> C[可視化：ダッシュボード]
    C --> D[アラートルールの設計]
    D --> E[ノイズ削減と自動化]
    E --> F[障害対応と改善サイクル]
    
```


---

## 📌 ブラックボックス vs ホワイトボックス監視

| 観点 | ブラックボックス | ホワイトボックス |
|------|------------------|-------------------|
| 概要 | 外部からの観測 | 内部構造も把握 |
| 例 | curlでの死活確認 | アプリ内部のメトリクス確認 |
| メリット | ユーザー体験に近い | 詳細な状態が把握できる |
| デメリット | 原因特定が困難 | 実装依存で壊れやすい |
| ベストプラクティス | **両方組み合わせるのが理想** |

---

## 🧰 実務で使えるモニタリングツール一覧

| カテゴリ | ツール名 | 用途 |
|----------|----------|------|
| メトリクス収集 | Prometheus / Datadog / Cloud Monitoring | サービス状態を可視化 |
| ログ分析 | Cloud Logging / Fluentd / Logstash | エラー・リクエスト内容の追跡 |
| トレース | OpenTelemetry / Jaeger / X-Ray | APIや内部処理の可視化 |
| 可視化 | Grafana / Kibana / Looker Studio | ダッシュボード作成 |
| アラート管理 | PagerDuty / Opsgenie / VictorOps | 通知とオンコール対応連携 |

---

## 🛠 アラート運用のベストプラクティス

- **SLOベースのアラート**：SLO違反の兆候に基づいて通知
- **段階的な通知**：Warning → Critical とレベル分け
- **ノイズ除去**：同一原因による多重通知はサプレッション設定
- **緊急度に応じたルーティング**：重要度で通知先や手段を分岐

---

## ✅ モニタリングの失敗あるある

| 誤り | 解説 |
|------|------|
| なんでもかんでも監視対象にする | ノイズ過多・保守不能に |
| アラートを通知するだけ | 自動対応やRunbookがなければ意味なし |
| ダッシュボードが多すぎる | 見る人が迷い、使われなくなる |

---

## 📌 まとめ

- モニタリングは「**検出・分析・改善**」の出発点
- ブラックボックスとホワイトボックスの組み合わせが鍵
- 「SLI→SLO→アラート」の構成がSRE的王道
- ノイズ削減と自動化で運用負荷を抑える

---

## 🚀 次にやること

1. 監視対象の一覧を整理して、ユーザー体験に直結するSLIを選定
2. ダッシュボードとアラートを見直してノイズを削減
3. 自動化できるアラート対応フローを検討・構築する

---
Systembarの大きさを取得したい



# statusBar
```
context.resources.getDimensionPixelSize(
  context.resources.getIdentifier("status_bar_height", "dimen", "android")
)
```

# NavigationBar
```
context.resources.getDimensionPixelSize(
  context.resources.getIdentifier("navigation_bar_height", "dimen", "android")
)
```
Arduino × AWSサーバーレスで作るIoT温度モニタリングシステム（仮）【第6回】


# 🚀 クラウド連携でDynamoDBへのPOST＆完結編！

## はじめに

「Arduino × AWSサーバーレスで作るIoT温度モニタリングシステム（仮）」も、ついに最終回です！

今回は自作したAndroidアプリにHTTP通信機能を実装し、Arduinoに繋げた温湿度センサー（DHT22）の値をBluetooth経由で受信。
そして、AWS API GatewayとLambdaで構築したREST APIを呼び出し、DynamoDBにデータを書き込むところまでやってみました！

:::note info
この記事は「Arduino × AWSサーバーレスで作るIoT温度モニタリングシステム」シリーズの一部です。シリーズの全体リンクは記事の末尾にまとめてあります！
:::

---

## やったこと

- 自作AndroidアプリにHTTP通信（POST）機能を実装
- 受信したセンサーデータ（温湿度＋タイムスタンプ）をクラウドへ送信
- Lambda(Python)でデータ検証＆DynamoDBへ保存
- 実際にDynamoDBにデータ登録される様子を確認
- Bluetooth切断後の再接続テストもOK！

---

## システム全体イメージ

![システム全体図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/21269/bfe7f9ac-c4f7-4763-99b6-11eee8a1c6a6.jpeg)

---

## 実機接続

![実際の接続](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/21269/8b26c429-87c5-446a-9126-5d8e6ff1cf3b.jpeg)

---

## 📱 アプリ動作・AWS連携の様子

### 📷 Bluetooth経由で温湿度データ受信中！

![アプリ画面キャプチャ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/21269/284640ba-d40a-40a4-adb2-b53f516465f8.jpeg)

---

### 📷 DynamoDBへのデータ登録確認！

![DynamoDB登録確認](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/21269/db342fd5-9635-4db9-845b-72e434279029.jpeg)

---

### 🎥 動作動画（Bluetooth受信→クラウド連携）

🎥 動画はこちら：
<iframe width="560" height="315" src="https://www.youtube.com/embed/2WgmWQjtEDA" frameborder="0" allowfullscreen></iframe>

👉 [YouTubeで直接見る場合はこちら](https://youtu.be/2WgmWQjtEDA)

---

# 📖 技術要素

- Arduino + DHT22温湿度センサー
- HC-06 Bluetoothシリアルモジュール
- Androidアプリ（Java）
- AWS API Gateway（REST API）
- AWS Lambda（Python 3.12）
- AWS DynamoDB（NoSQLデータベース）

💡 **今回作成したコードは、すべてGitHubで公開しています！**  
👉 [GitHubリポジトリはこちら](https://github.com/takataka5845/iot-temperature-monitoring)

---

## 感想・まとめ

昨年末から思い立ったこの実験的プロジェクト、  
作業期間約1ヶ月・作業時間も約20時間ほどで、ここまで作り上げることができました！
（Qiita記事をまとめる方に時間がかかってしまった💦）

- ハードウェア初心者でも
- サーバーレス初体験でも
- Androidアプリの作り込みが粗くても（笑）

とにかく「動くものを作りきる」って、本当に楽しい。

---

さて次は何を作ろうかな。  
ネットの世界は広大だわ…（By 草薙素子）

If you can dream it, you can make it happen.  
If you can think it, you can bring it to life.

---

## 🌟 Special Thanks

- ここまで頑張った過去の自分へ
- 未来でこの経験を活かす自分へ

---

## シリーズ記事一覧

- 【第1回】[AWSでクラウド側の受け口を作ってみる](https://qiita.com/takataka5845/items/b7d129a738b7365cc602)
- 【第2回】[光センサーでArduinoからMacにシリアル通信](https://qiita.com/takataka5845/items/ea7999588c7c9957acd7)
- 【第3回】[DHT22で温湿度を取得してシリアル送信](https://qiita.com/takataka5845/items/3aff19c560c1457829a5)
- 【第4回】[Bluetooth通信でセンサーデータをAndroidに送信](https://qiita.com/takataka5845/items/53f2d29991f7b1023949)
- 【第5回】[自作アプリでBluetooth接続＆温湿度データ受信できてるかな？](https://qiita.com/takataka5845/items/dc4753bc410dd0daa0d4)
- 【第6回】クラウド連携でDynamoDBへのPOST＆完結編（このページ）

---

つづく！（また新しいチャレンジでお会いしましょう！）🚀
Webコンテンツ制作の課題を解決する「Wプロマッチ」について

Webコンテンツ制作に課題を感じている方に向けて、トップクラスの人材とのマッチングサービス[「Wプロマッチ」](https://w-promatch.com/)の活用を提案します。

「優秀なライターが見つからない」「仲介手数料が高すぎる」「インボイス対応の人材を探すのが大変」──そんな悩み、実は「Wプロマッチ」でかなり改善できるかもしれません。
## Wプロマッチとは
「Wプロマッチ」は、審査を通過したトップ10％のWebライター・編集者・SEOコンサルタントを手数料0円で採用できるマッチングサービスです。

月額19,800円の定額料金で、優秀なクリエイティブ人材を何人でも直接採用することができます。
### 期待できる効果
具体的には、以下のような効果が期待できます。

・コスト削減：一般的なマッチングサービスでは発注ごとに報酬の20-30%が手数料として発生しますが、Wプロマッチでは企業側は月額料金のみで手数料は完全に0円です。
・品質向上：厳格な審査制度を設けており、審査を通過した優秀な人材のみが在籍しています。優秀なライターが見つからない、記事の質が安定しないといった問題に対応できます。
・運用効率化：契約や支払いの管理が煩雑、ライターの教育に時間がかかるといった課題を解決します。即戦力となる人材のみを採用しているため教育不要で、直接契約によって柔軟な運用が可能です。
### サービスの特長
Wプロマッチの主な特長は以下の通りです。

・厳正な審査制度：業界で実績を積んだ上位10％の人材のみが登録可能なため、優秀なライターを確実に採用できます。
・手数料0円の採用：月額19,800円で、厳選されたプロライターを何人でも採用可能です。さらに、ライターとは直接契約できるため、仲介コストを抑えられます。
・全員インボイス登録済み：登録されている人材は全員がインボイス登録済みです。インボイス未対応のライターへの発注による税制面のデメリットを心配する必要がありません。
### 対応可能な業務範囲
Wプロマッチに登録されている人材は、以下のような業務に対応可能です。

・記事制作：SEO記事や取材記事、コラム記事など、各ライターが得意とする記事制作
・記事編集/ディレクション：ライターが執筆した記事の編集やディレクションを「ディレクター」レベルの人材に依頼可能
・SEOコンサルティング：「SEOコンサルタント」として登録されている人材に、自社サイトのSEO戦略設計/コンサルティングを依頼可能
・その他のライティング：LPのセールスライティングや紙媒体の執筆など、その他ライティングに関する業務
## 利用の流れ
Wプロマッチの利用方法は以下の通りです。

新規会員登録：まずは無料で会員登録
ログイン：会員登録後、ログインして機能を確認
無料で登録人材をチェック：機能が制限された無料版を体験できます
クレジットカード登録：有料版へ申し込み（月額19,800円）
案件募集/スカウトにて採用：マイページより「案件募集」や「スカウト機能」を使って人材を直接採用

## 導入時のポイント
Webコンテンツ制作のためにWプロマッチを活用する際には、以下のポイントを押さえておくことが重要です。

・具体的な要件の明確化：どのようなコンテンツを、どのような目的で、どのくらいの量と頻度で制作したいのかを明確にしておきましょう
・予算計画の立案：月額料金に加えて、ライターへの報酬も考慮した予算計画を立てておきましょう
・コミュニケーション方法の確立：直接契約となるため、効率的なコミュニケーション方法を確立しておくことが大切です

Wプロマッチを活用することで、Webコンテンツ制作の質を向上させながら、コストを抑え、効率的な運用を実現することができます。優秀なクリエイティブ人材との直接契約によって、自社のWebコンテンツ戦略を強化したい企業にとって、有効な選択肢となるでしょう。

詳細な情報や無料会員登録については、以下のWプロマッチ公式サイトをご確認ください。
https://w-promatch.com/
【備忘録】VScodeでESLintの設定ファイルエラーが出たので解決してみた

# エラーが発生
フロントエンド開発を思い立ちVue.js＋viteで色々遊んでいたところ、run dev時にVueファイルで大量のエラーが発生。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/4014590/8e0a4c04-dfb0-41f4-9f09-ce652819b2d6.png)

全コンポーネントで発生している様子。設定ファイルに問題がありそうなエラーなので、備忘録ついでに解決方法をまとめておきました。

# 解決方法
エラーログ周りを眺めていると、こんなエラーが出ていました。
```
Parsing error: 
You appear to be using a native ECMAScript module 
configuration file, which is only supported when
running Babel asynchronously or when using the Node.js
`--experimental-require-module` flag.
```
どうやら、Node.jsの`--experimental-require-moduleフラグ`
を使用してくださいと言われているようですね。

より調べてみると、どうやらVscodeの拡張機能ESLintの**ECMAScriptモジュール（ESM）の設定ファイルを適切に処理できていないことが原因**のようですね。

原因も分かったので、さっそく対応してみましょう。

- ESLint設定ファイルを追加
```.eslintrc.js```を直下ディレクトリに追加して、以下の内容を追加します。

```
module.exports = {
  // root: true
  // ESLintが親ディレクトリの設定ファイルを探すのを停止する
  // これを設定することで、プロジェクト固有の設定のみが適用される
  root: true,
  
  // env: 環境変数を設定
  env: {
    node: true,      // Node.js のグローバル変数（require, process など）を有効化
    browser: true,   // ブラウザのグローバル変数（window, document など）を有効化
    es2021: true     // ES2021の文法を有効化（最新のJavaScript機能が使える）
  },
  
  // extends: 既存の設定を継承
  extends: [
    'plugin:vue/vue3-essential',  // Vue.js 3の必須ルールセット
    'eslint:recommended'          // ESLintの推奨ルールセット
  ],
  
  // parserOptions: パーサーの設定
  parserOptions: {
    ecmaVersion: 'latest',   // 最新のECMAScriptバージョンを使用
    sourceType: 'module'     // ESモジュール（import/export）を使用可能に
  },
  
  // rules: 個別のルール設定
  rules: {
    // Vueコンポーネント名を複数単語にする必要があるルールを無効化
    // (例: 'MyComponent' は OK だが、'Button' は NG というルール)
    'vue/multi-word-component-names': 'off'
  }
}
```
設定ファイルの詳細はClaudeに教えてもらいました（笑）。

さて、このファイルを追加すると、、、

**エラーが消えていました！！**

Vueプロジェクトをviteで立ち上げると、ESLint設定は含まれないそうです。

ですが、VScode側ではあらかじめESLint拡張機能をインストールしていたので、VScode側が自動的にESLintを探して見当たらないのでエラーが出ていたようですね。

なるほど、勉強になりますね！
いろんなアルゴリズム"00.00.00.08"

[知恵の館の目次](https://qiita.com/rionQ/items/0ba7a700620a1d617bc6)
# 立ち位置・仕様
* いろんなアルゴリズムをコピペできるように記録するのみ
* 最適化が目的でない
* たまにメモとして解説を残す
* 最低限でまとめる
* データを抽出しやすいように個別のIDを付与
* あるアルゴリズムにおいて、他のアルゴリズムが登場する際にはそのIDを付与
* IDは16進数表記
* なるべく最低限なパッケージで実装
* なるべく特殊なオブジェクト型は使用しない

# TargetID
00.00.00.08

# ReferenceID

# 高速逆平方根計算
```c:
float Q_rsqrt(float number){
	long i;
	float x2, y;
	const float threehalfs = 1.5F;

	x2 = number * 0.5F;
	y = number;
	i = * ( long * ) &y;
	i = 0x5f3759df - ( i >> 1 );
	y = * ( float * ) &i;
	y = y * ( threehalfs - ( x2 * y * y ) ); // ニュートン法1回目
    //y = y * ( threehalfs - ( x2 * y * y ) ); // //ニュートン法2回目

	return y;
}
```

# 使用方法
```python:
int main(void){
	float y = Q_rsqrt(2);
	printf("%f\r\n", y); // 0.706930

	return 0;
}
```
初心者向けSQL学習サービス・書籍の紹介

# 目次

- はじめに
- DBとは
- SQLとは
- 無料の学習環境
- おすすめの書籍
- まとめ

# はじめに

この記事をご覧になってくださった皆様、ありがとうございます。

石川 聖(ヒジリ)と申します。

本記事では、これからSQLを学びたいと考えている方に向けて、おすすめのサービスや書籍を紹介します。
SQL（エスキューエル）は、データベースを扱うための言語です。

IT業界ではもちろん、データを使って仕事をするあらゆる場面で役立つ知識です。

開発・データベースエンジニア、データサイエンティストや一部のマーケターなどデータ系の職種であれば必須のスキルになります。

でも、「なんだか難しそう」「どうやって学べばいいのかわからない」と感じる人も多いと思います。
そのような初心者の方が安心してSQLの勉強を始められるように、無料で使える学習サービスや、わかりやすい入門的な書籍を紹介します。

# DBとは

DB（データベース）は、たくさんの情報をまとめて保存しておく場所のことです。

たとえば、お店の「商品一覧」や「お客さんの情報」、アプリの「ユーザーの投稿」などを、わかりやすく整理して保管するのに使われます。

ノートに表を書いてデータを整理するのに似ていますが、コンピュータではもっと速く正確に扱うことができます。

# SQLとは

SQL（エスキューエル）は、データベースに対して「データを取り出す」「追加する」「変更する」「消す」などの操作をするための言語です。

たとえば、「名前が〇〇さんのデータを見せて」といった指示を、SQLで書くことができます。

プログラミング言語のように見えますが、構文はシンプルなので初心者でも学びやすいのが特徴です。

# 無料の学習環境

SQLを学ぶには、実際に手を動かして練習するのがとても大切です。

ここでは、初心者でもすぐに使える無料の学習サイト「SQLab（エスキューラボ）」を紹介します。

### SQLab（SQLラボ）

- 公式サイト：https://sqlab.net/
- 公式X（旧Twitter）：https://x.com/sqlab_app

### 主な特徴

- **練習問題が豊富**
    
    初級・中級・トライアル・チャレンジ編など、さまざまなレベルの問題が用意されています。
    
    難易度別に分かれているので、初心者でも安心して取り組めます。
    
    ※「上級」は現在準備中です。
    
- **すべてブラウザ上で完結**
    
    SQLのコードをブラウザ上で書いて、その場で実行結果を確認できます。インストールなどの面倒な準備は不要です。
    
- **完全無料で利用可能**
    
    ログインすれば、すべての問題にチャレンジできます。
    
    費用をかけずに学習を進めたい方にもぴったりです。
    
- **PCからの利用がおすすめ**
    
    推奨ブラウザはGoogle Chromeです。
    
- **使用されているデータベース**
    
    PostgreSQL バージョン14.4が使われており、実務でもよく使われる環境で学習できます。
    

- SQLab
    
    ブラウザ上で、SQLの記述, 実行結果の確認ができます。また、ER図(データベースの構造を図にしたもの)や、問題の解答例も見れます。

![D2F3B7B0-73C2-4CD4-838A-0A6C64E3C78B.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289989/28703e56-facc-4e33-b9e4-13e466639a75.jpeg)


# おすすめの書籍

無料の学習サイトとあわせて、本でじっくり学ぶのもおすすめです。

特に、SQL初心者にとって読みやすく、内容もしっかりしている書籍を1冊ご紹介します。

### スッキリわかるSQL入門（第4版）

- https://www.amazon.co.jp/dp/4295018465/ref=sspa_dk_hqp_detail_aax_0?psc=1&sp_csd=d2lkZ2V0TmFtZT1zcF9ocXBfc2hhcmVk

### この本の特徴

- **初心者に人気のロングセラー**
    
    SQLを初めて学ぶ人向けに書かれた定番の入門書です。やさしく丁寧に説明で、初心者がつまずきがちなサブクエリ, 結合, 正規化も楽しく理解できるようになっています。
    
- **豊富な図解とやさしい文章**
    
    イラストや図が多く使われており、内容がイメージしやすくなっています。文章も親しみやすく、スラスラ読み進められます。
    
- **データベース設計の基礎も学べる**
    
    SQLの書き方だけでなく、「インデックス」や「正規化」など、データベースの設計に関する基本的な考え方にも触れています。
    
- **オンラインでSQLを試せる「dokoQL」付き**
    
    新書を購入すると、オンラインでSQLを実行できる「dokoQL（ドコキューエル）」が使えます。
    
    インストール不要で、文中のSQL例や256問もの練習問題の解答をそのまま試すことができます。
    
- 統計分析
    
    第4版では、新付録として「SQLによるデータ分析入門」が追加されました。RDBやSQLが、近年注目を集めるデータ活用とAIの世界にも繋がっていることを実感できます。
    

- dokoQL
    
    ブラウザ上で、SQLの記述, 実行結果の確認を行うことができます。

![8A30C2CE-D582-45B0-BA69-2F798F95ABDD.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3289989/cfebc75d-076b-450e-ab42-46f3fe14bc67.jpeg)

# まとめ

最後までご覧いただき、ありがとうございました。

SQLは最初はとっつきにくく感じるかもしれませんが、実際に手を動かして練習していくことで、少しずつ理解できるようになります。

今回紹介した「SQLab」や「スッキリわかるSQL入門」は、どちらも初心者にやさしく、すぐに学習を始められます。

まずは一歩踏み出して、自分のペースで学んでみてください。

コツコツ学べば、きっとデータベースやSQLの知識があなたの強みになります。

内容の誤りや質問などございましたら、コメントにて申し付けください。

このアカウントでは、週に一本のペースで投稿しております。

来週は「令和時代にJava, Springに入門してみた」的な記事にする予定です。(会社の新入社員研修でjava, springを初めて触りました。そこでの発見を共有したいと思っております。)
それでは皆様、また来週。
バイブコーディングでLaravelをNextJSにリプレイスしてみた

以前に[AWS資格試験問題集サイト](https://www.aws-qualification.link/)をLaravelで作成したのですが、それをNextJSへのリプレイスをgithub copilotのagentモードとcursorを利用して行いました。

laravelのアプリケーションディレクトリの場所とリプレイスして欲しいnestJSディレクトリの場所を指定して。
後は、「appディレクトリはLaravel のフレームワークで問題出題のWEBアプリケーションが実装されています。これをnestJSディレクトリ内にNextJSへリプレイスをしてください。」と指示すると、叩き台程度のリプレイスを行ってくれました。

後は、各ページでエラーが出ていたのを、エラーメッセージを投げて修正して欲しいとか、デザインを見やすくして欲しいとか思ったことを特にプロンプトエンジニアリングとかを意識せずに適当に依頼しても、大体は期待通りに修正してくれました。
自分でコードを修正したのは数行程度です。

[リプレイス前後のサイトの様子](https://hoyoyo543.github.io/2025/05/04/%E3%83%90%E3%82%A4%E3%83%96%E3%82%B3%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%A7Laravel%E3%82%92NextJS%E3%81%AB%E3%83%AA%E3%83%97%E3%83%AC%E3%82%A4%E3%82%B9%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/)