Sion908 Blog

Googleカレンダーの招待を自動化したら地味に人生が楽になった話

2026-03-28T00:00:00+00:00

はじめに

ハニーとの予定をGoogleカレンダーで共有することにした。

ただ、予定を入れるときに共有を忘れることが多い。後から「あ、共有してなかった」と気づいて、慌てて招待する。これの繰り返し。というか直前に予定を行って怒られている。

「自動化しなければ」と思い立って、GASで毎日4時に自動でハニーを招待する仕組みを作った。派手な機能じゃないけど、日常のストレスは確実に減った。

何を作ったか

毎日4時に以下の処理を自動実行：

今日以降の予定をチェック
自分が作った予定だけを対象
タイトル末尾に [skip] がついていない予定に限定
指定したメールアドレスをゲストとして追加

実装のポイント

### 1. isOwnedByMe() で自分の予定だけを対象

招待された予定には自動で招待を追加しない。これが重要。

if (!event.isOwnedByMe()) {
  continue;
}

### 2. [skip] で制御

タイトルに [skip] をつけるだけで除外。シンプルな運用ルール。

if (title.endsWith(skipSuffix)) {
  continue;
}

### 3. 既に招待済みならスキップ

同じ人を何度も招待しない。

const guestList = event.getGuestList().map(g => g.getEmail().toLowerCase());
if (guestList.includes(guestEmail.toLowerCase())) {
  continue;
}

### 4. 主催者の参加状態もセット

ゲストを追加する際、主催者（自分）のステータスも「参加（YES）」に変更する。これをしないと、カレンダー上では「未承諾」のままになってしまう。

if (adminEmail) {
  event.addGuest(adminEmail);
  event.setMyStatus(CalendarApp.GuestStatus.YES)
}

実装全体

TypeScriptで書いて、claspでローカル管理。

function setConfig(): void {
  const props = PropertiesService.getScriptProperties();
  props.setProperties({
    ADMIN_EMAIL: "admin@sample.com",
    TARGET_GUEST_EMAIL: "info@sample.com",
    CALENDAR_ID: "primary",
    SKIP_SUFFIX: "[skip]"
  });
}

function inviteGuestToUpcomingEvents(): void {
  const props = PropertiesService.getScriptProperties();
  const guestEmail = props.getProperty("TARGET_GUEST_EMAIL");
  const adminEmail = props.getProperty("ADMIN_EMAIL");
  const calendarId = props.getProperty("CALENDAR_ID") || "primary";
  const skipSuffix = props.getProperty("SKIP_SUFFIX") || "[skip]";

  if (!guestEmail) {
    throw new Error("TARGET_GUEST_EMAIL が未設定です。setConfig() を実行してください。");
  }

  const calendar =
    calendarId === "primary"
      ? CalendarApp.getDefaultCalendar()
      : CalendarApp.getCalendarById(calendarId);

  if (!calendar) {
    throw new Error(`カレンダーが見つかりません: ${calendarId}`);
  }

  const now = new Date();
  const oneYearLater = new Date(now);
  oneYearLater.setFullYear(oneYearLater.getFullYear() + 1);

  const events = calendar.getEvents(now, oneYearLater);

  for (const event of events) {
    const title = (event.getTitle() || "").trim();

    if (title.endsWith(skipSuffix) || !event.isOwnedByMe()) {
      continue;
    }

    const guestList = event.getGuestList().map(g => g.getEmail().toLowerCase());
    if (guestList.includes(guestEmail.toLowerCase())) {
      continue;
    }

    try {
      if (adminEmail) {
        event.addGuest(adminEmail);
        event.setMyStatus(CalendarApp.GuestStatus.YES)
      }
      event.addGuest(guestEmail);
      console.log(`追加: ${title} -> ${guestEmail}`);
    } catch (e) {
      console.error(`追加失敗: ${title} / ${e}`);
    }
  }
}

function createDailyTrigger(): void {
  const functionName = "inviteGuestToUpcomingEvents";

  const triggers = ScriptApp.getProjectTriggers();
  for (const trigger of triggers) {
    if (trigger.getHandlerFunction() === functionName) {
      console.log("既存トリガーあり");
      return;
    }
  }

  ScriptApp.newTrigger(functionName)
    .timeBased()
    .everyDays(1)
    .atHour(4)
    .create();

  console.log("毎日4時のトリガーを作成しました");
}

function updateGuestEmail(newEmail: string): void {
  PropertiesService.getScriptProperties().setProperty("TARGET_GUEST_EMAIL", newEmail);
}

function updateAdminEmail(newEmail: string): void {
  PropertiesService.getScriptProperties().setProperty("ADMIN_EMAIL", newEmail);
}

セットアップ手順

### 1. clasp をインストール

npm install -g @google/clasp

### 2. ログイン

clasp login

### 3. 既存GASをpull（またはclone）

スクリプトIDはURLから取得：

clasp clone <SCRIPT_ID>

### 4. 初期設定を実行

Google Apps Script エディタで以下を実行：

setConfig()

### 5. トリガーを作成

createDailyTrigger()

失敗談

最初は全予定に招待を飛ばしていて、招待されたミーティングにも勝手に人が追加されるという事故が発生。

isOwnedByMe() チェックを入れてからは安定した。

運用ルール

タイトル末尾に [skip] をつけると除外される (家賃の支払い予定など)
自分が作った予定だけが対象
既に招待済みなら何もしない
メールアドレスは updateGuestEmail() で変更可能

ちょっとした工夫で生活が楽になる

こういう「ちょっとした面倒」を仕組みで消していくのは結構好きで、派手な機能じゃないけど、日常のストレスは確実に減る。

こういうのを積み上げると、生活の解像度が少し上がる気がする。

次のステップ

Slackへの通知追加
複数メールアドレスへの対応
カレンダーごとの設定分岐

参考リンク

FlaskでSQLSpecを使ったCRUDアプリ実装 - ORMを使わずに型安全なDB操作

2026-03-16T00:00:00+00:00

はじめに

FlaskでのDB操作といえばSQLAlchemyが定番ですが、生SQLを書きつつ型安全性も保ちたい場面があります。そんな時に出会ったのがSQLSpecです。

警告

注意: SQLSpecは現在実験的なライブラリです。本番環境での使用前に十分な検証を行ってください。

SQLSpecとは

SQLSpec は生SQLを書きながら型安全なDB操作を可能にするライブラリ。ORM特有の記法を覚える必要がなく、SQL知識があればすぐに使えるのが特徴です。Flaskプラグインも提供されており、SQLite・PostgreSQL・MySQLなど複数のDBに対応しています。

プロジェクト構成

flask-sqlspec-demo/
├── app/
│   ├── __init__.py         # Flaskアプリファクトリ
│   ├── database.py         # DB初期化
│   └── routes.py           # CRUDエンドポイント
├── data/                   # SQLite DBファイル用ディレクトリ
├── pyproject.toml
├── docker-compose.yml
└── Dockerfile

サンプルレポジトリ

https://github.com/sion908/sqlspec_flask

セットアップ

### 1. 依存関係

# pyproject.toml
[project]
name = "flask-sqlspec-demo"
version = "0.1.0"
description = "Flask + SQLSpec CRUD demo with SQLite"
requires-python = ">=3.12"
dependencies = [
    "flask>=3.0.0",
    "sqlspec[sqlite]>=0.1.0",
]

### 2. Docker環境

# Dockerfile
FROM python:3.12-slim

WORKDIR /app
COPY pyproject.toml ./
RUN pip install -e .

COPY app/ ./app/

EXPOSE 5000
CMD ["python", "-m", "flask", "--app", "app", "run", "--host=0.0.0.0"]

# docker-compose.yml
services:
  app:
    build: .
    ports:
      - "5001:5000"
    volumes:
      - ./data:/data
    environment:
      - PYTHONDONTWRITEBYTECODE=1
      - PYTHONUNBUFFERED=1

実装

### 1. Flaskアプリファクトリ

# app/__init__.py
from flask import Flask
from sqlspec import SQLSpec
from sqlspec.adapters.sqlite import SqliteConfig
from sqlspec.extensions.flask import SQLSpecPlugin

DB_PATH = "/data/app.db"

sqlalchemy_spec: SQLSpec = SQLSpec()
plugin: SQLSpecPlugin
db_config: SqliteConfig

def create_app() -> Flask:
    """Flask アプリを生成し、SQLSpec と CRUD Blueprintを登録する。"""
    global plugin, db_config

    app = Flask(__name__)

    # SQLSpec設定
    db_config = SqliteConfig(
        connection_config={"database": DB_PATH},
        extension_config={
            "flask": {
                "commit_mode": "autocommit",
                "session_key": "db",
            }
        },
    )
    sqlalchemy_spec.add_config(db_config)

    # Flaskプラグイン登録
    plugin = SQLSpecPlugin(sqlalchemy_spec, app)

    from app.database import init_db
    from app.routes import items_bp

    init_db(DB_PATH)
    app.register_blueprint(items_bp)

    return app

### 2. データベース初期化

# app/database.py
import sqlite3

CREATE_ITEMS_TABLE = """
CREATE TABLE IF NOT EXISTS items (
    id          INTEGER PRIMARY KEY AUTOINCREMENT,
    name        TEXT    NOT NULL,
    description TEXT,
    created_at  TEXT    DEFAULT (datetime('now', 'localtime'))
)
"""

def init_db(db_path: str) -> None:
    """アプリ起動時に items テーブルを作成する。"""
    with sqlite3.connect(db_path) as conn:
        conn.execute(CREATE_ITEMS_TABLE)
        conn.commit()

### 3. CRUDエンドポイント

# app/routes.py
from flask import Blueprint, jsonify, request
from app import plugin

items_bp = Blueprint("items", __name__, url_prefix="/items")

@items_bp.get("/")
def list_items():
    """全アイテムを取得する。"""
    db = plugin.get_session()
    rows = db.execute("SELECT id, name, description, created_at FROM items ORDER BY id")
    items = list(rows.all() if rows else [])
    return jsonify(items), 200

@items_bp.post("/")
def create_item():
    """新規アイテムを作成する。"""
    data = request.get_json(silent=True) or {}
    name = data.get("name", "").strip()
    if not name:
        return jsonify({"error": "nameは必須です"}), 400

    description = data.get("description")
    db = plugin.get_session()
    db.execute(
        "INSERT INTO items (name, description) VALUES (?, ?)",
        (name, description),
    )

    row = db.execute(
        "SELECT id, name, description, created_at FROM items WHERE rowid = last_insert_rowid()"
    )
    created = row.one()
    return jsonify(created), 201

@items_bp.get("/<int:item_id>")
def get_item(item_id: int):
    """指定IDのアイテムを取得する。"""
    db = plugin.get_session()
    row = db.execute(
        "SELECT id, name, description, created_at FROM items WHERE id = ?",
        (item_id,),
    )
    result = row.one_or_none()
    if result is None:
        return jsonify({"error": "アイテムが見つかりません"}), 404
    return jsonify(result), 200

@items_bp.put("/<int:item_id>")
def update_item(item_id: int):
    """指定IDのアイテムを更新する。"""
    db = plugin.get_session()

    existing = db.execute(
        "SELECT id FROM items WHERE id = ?", (item_id,)
    ).one_or_none()
    if existing is None:
        return jsonify({"error": "アイテムが見つかりません"}), 404

    data = request.get_json(silent=True) or {}
    name = data.get("name", "").strip()
    if not name:
        return jsonify({"error": "nameは必須です"}), 400

    description = data.get("description")
    db.execute(
        "UPDATE items SET name = ?, description = ? WHERE id = ?",
        (name, description, item_id),
    )

    row = db.execute(
        "SELECT id, name, description, created_at FROM items WHERE id = ?",
        (item_id,),
    )
    return jsonify(row.one()), 200

@items_bp.delete("/<int:item_id>")
def delete_item(item_id: int):
    """指定IDのアイテムを削除する。"""
    db = plugin.get_session()

    existing = db.execute(
        "SELECT id FROM items WHERE id = ?", (item_id,)
    ).one_or_none()
    if existing is None:
        return jsonify({"error": "アイテムが見つかりません"}), 404

    db.execute("DELETE FROM items WHERE id = ?", (item_id,))
    return jsonify({"message": f"アイテム {item_id} を削除しました"}), 200

SQLSpecの特徴的なポイント

### 1. Flask拡張の統合

SQLSpecのFlaskプラグインを使うことで、簡単にFlaskアプリに統合できます：

from sqlspec.extensions.flask import SQLSpecPlugin

plugin = SQLSpecPlugin(sqlalchemy_spec, app)

# エンドポイント内でセッション取得
db = plugin.get_session()

### 2. 結果の操作

SQLSpecは SQLResult オブジェクトを返し、便利なメソッドを提供します：

# 全件取得
rows = db.execute("SELECT * FROM items")
items = list(rows.all() if rows else [])

# 1件取得（必ず1件ある場合）
item = row.one()

# 1件取得（0件の場合はNone）
item = row.one_or_none()

# 影響を受けた行数
affected = result.rows_affected

### 3. パラメータバインディング

SQLインジェクション対策のため、パラメータは必ずプレースホルダーを使用：

# ✅ 安全
db.execute("SELECT * FROM items WHERE id = ?", (item_id,))

# ❌ 危険
db.execute(f"SELECT * FROM items WHERE id = {item_id}")

### 4. 自動コミットモード

Flask拡張の設定で autocommit モードを有効にできます：

extension_config={
    "flask": {
        "commit_mode": "autocommit",
        "session_key": "db",
    }
}

これにより、明示的なコミットが不要になります。

動作確認

### 1. アプリケーション起動

# Dockerで起動
docker-compose up --build

# またはローカルで起動
pip install -e .
python -m flask --app app run --debug

### 2. APIテスト

# アイテム作成
curl -X POST http://localhost:5001/items \
  -H "Content-Type: application/json" \
  -d '{"name": "テストアイテム", "description": "これはテストです"}'

# 全アイテム取得
curl http://localhost:5001/items/

# 特定アイテム取得
curl http://localhost:5001/items/1

# アイテム更新
curl -X PUT http://localhost:5001/items/1 \
  -H "Content-Type: application/json" \
  -d '{"name": "更新されたアイテム", "description": "更新されました"}'

# アイテム削除
curl -X DELETE http://localhost:5001/items/1

Flask + SQLSpecの利点

### 1. シンプルさ

学習コストが低い - SQL知識があればすぐに使える
コードが直感的 - ORM特有の記法を覚える必要がない
デバッグが容易 - 実行されるSQLが明確

### 2. 柔軟性

複雑なクエリも対応 - JOIN、サブクエリなどもそのまま書ける
DBに依存しない - SQLite、PostgreSQL、MySQLで同じ書き方
パフォーマンス最適化 - SQLを直接制御できる

### 3. 型安全性

結果の型変換 - 自動で適切なPython型に変換
エラーハンドリング - SQL実行時のエラーを適切に処理
IDEサポート - SQLシンタックスハイライトが効く

注意点と制限

### 1. 実験的なライブラリ

安定性 - API変更の可能性あり
ドキュメント - まだ整備されていない部分あり
コミュニティ - 小規模なため、情報が少ない

### 2. マイグレーション

自動生成なし - マイグレーションファイルは手動作成
バージョン管理 - 別途管理が必要

### 3. Flask統合

プラグイン依存 - Flask拡張に依存する部分あり
セッション管理 - 複雑なトランザクションには工夫が必要

まとめ

Flask + SQLSpecで試してみた感想としては、ORMの学習コストをかけずに型安全なDB操作ができるのは魅力的でした。特にSQLを直接書ける点は、複雑なクエリが必要な場面で重宝しそうです。

ただし実験的なライブラリなので、本番利用は慎重に。マイグレーションも手動になるため、小規模なプロジェクトや個人開発向けかもしれません。

「ORMは便利だけど、もっとシンプルにSQLを書きたい」という場合は試す価値ありそうです。

コードは GitHubリポジトリに置いています。

参考リンク

サーバを持たないSSR入門：Litestar + Jinja2 + MangumでLambdaに載せる

2025-12-18T00:00:00+00:00

TL;DR

SSRは古いんじゃなくて、設計の節度を取り戻す技術だと思ってる
Litestar + Jinja2 はSSRの"素直さ"が出る（テンプレ設定がまっすぐ）
Lambda上では Mangum でASGIアプリをイベントに繋ぐのが手堅い
htmxは"簡単に動く"けど、綺麗に育てる設計が意外と難しい（AIはそこに効く）

SSRが"当たり前じゃなくなった"今、なぜやるのか（思想）

ここ数年、Webは「まずSPA」がデフォになりました。体験は強い。けど個人開発だと、いつの間にか JSの依存・分業前提の設計・初期表示・SEOあたりがじわじわ重くなることがあります。

SSRは "最新トレンド" ではないかもしれない。でも僕はSSRを、懐古ではなく「責務の境界を戻す」ための楔として見ています。

まずHTMLが届く（＝まず見える）
画面の初期状態はサーバで決まる（＝状態の出どころが一つ）
JSは必要な分だけ（＝保守が軽くなる）

SSRは「フロントの都合で世界を作る」より、「サーバが世界の骨格を握る」感じがして、精神衛生に良い。（※もちろんサーバ側の負荷や複雑さが増えるトレードオフはある）

"Lambdaだけ"で済むのが正義（個人開発の速度感）

SSRって「サーバを立てる」印象が強いけど、個人開発だとそこが心理的コストになります。

そこで AWS Lambda + API Gateway（または Function URL）。サーバを持たずにSSRができると、体感として "始める重さ" が一段下がります。

LitestarはASGIアプリなので、Lambdaのイベント形式に橋渡しする必要があり、ここで Mangum が効きます。Mangumは ASGIアプリを Lambda 上で動かすためのアダプタで、API Gateway / Function URL などに対応しています。

Litestar + Jinja2：SSRの"素直さ"がある

Litestarはテンプレート機構を公式にサポートしていて、Jinja2も「普通に」組み込めます。

最小の雰囲気（超短縮）：

from pathlib import Path
from litestar import Litestar, get
from litestar.response import Template
from litestar.contrib.jinja import JinjaTemplateEngine
from litestar.template.config import TemplateConfig
from mangum import Mangum

@get("/")
def index() -> Template:
    return Template("index.html.jinja2", {"msg": "SSR on Lambda"})

app = Litestar(
    route_handlers=[index],
    template_config=TemplateConfig(
        directory=Path(__file__).parent / "templates",
        engine=JinjaTemplateEngine,
    ),
)

handler = Mangum(app)  # Lambda handler

ここまでで「LambdaのURLを叩いたらHTMLが返る」になります。 ※静的ファイル配信は、S3+CloudFrontへ逃がすのが無難

htmxは"簡単に動く"けど"設計が効いてくる"

SSRで十分に気持ちよくなるんですが、人間の欲望は尽きないので、次に欲しくなるのが部分更新。

htmxは hx-get でHTMLを取りにいって、DOMに差し替えられる。ここが軽い。でも「運用できる設計」にする瞬間、急に難しくなります。

難しくなるポイント（体感） - 境界問題：「どこを"部品"として返すか」が設計になる - URL問題：フルページと部分HTMLのURLが増えがち - 状態問題：サーバが持つ状態 / DOMの持つ状態がズレやすい - 重複問題：全体テンプレと部分テンプレが二重管理になりやすい

htmxは"JSが減る"代わりに、テンプレ設計の精度が要求される感じがします。

じゃあAIは使えるのか？

使えます。ただし「設計が未確定な状態」ではAIも迷子になることが多いです。逆に、こちらが"型"を渡すと安定します。

AIが効く「型」

命名規約を決めてから渡す

例： - templates/pages/.jinja2（フルページ） - templates/partials/.jinja2（差し替え用）

この規約があるだけで、AIに「partialはこれに従って」と言えます。

「返していいHTMLの形」を決めてから渡す

例えば「/todos/partial は <li>...</li> の集合だけ返す。<html> は返さない」みたいに契約化。 hx-target で差し替え先が明確になるので、AIも実装しやすいです。

"部分レンダリング"の仕組みを用意しておく

Jinja2は普通に書くと「テンプレ丸ごと」レンダリングになりがちです。ここで、テンプレのブロック単位をレンダリングできる jinja2-fragments みたいな道具があると、設計が少し楽になります（htmx文脈で「一部だけ返したい」に寄せられる）。

AIに「このブロックだけ返す設計で」と指定できるようになるのが大きい。

まとめ：SSRは"古い"んじゃなくて"節度"の技術

LambdaだけでSSRを回せると、サーバ管理の気配が消えて、HTMLの素直さが前に出ます。一方でhtmxは「簡単に動く」けど「綺麗に育つ」には設計がいる。だからこそAIは、コード生成より境界・契約・命名規約を固める用途で効く…というのが現時点の結論です。

SPAが当たり前になった今だからこそ、SSRは回帰じゃなく、現代への楔として書く価値があると思っています。

参考文献

PythonでORMを使わずSQL文で快適開発 - SQLSpecによるマイグレーション&CRUD実装

2025-11-12T00:00:00+00:00

はじめに - ORMの課題とSQLSpecとの出会い

Webアプリケーション開発において、ORMは便利なツールですが、以下のような課題に直面することがあります：

複雑なクエリが書きにくい - JOINや集計処理が多いと、ORM特有の記法が煩雑に
生SQLを結局書く - パフォーマンスチューニングで生SQLに戻ることが多い
学習コストが高い - SQLは知っているのに、ORM特有の記法を覚える必要がある

「SQLをそのまま書きたいけど、型安全性やマイグレーション管理は欲しい」

そんな中で見つけたのが SQLSpec というライブラリです。

警告

注意: SQLSpecは現在実験的なライブラリです。本番環境での使用前に十分な検証を行ってください。

SQLSpecとは

SQLSpec は、SQL文をそのまま書きながら、以下の機能を提供するライブラリです：

✅ Raw SQLをそのまま記述 - 学習コストが低い
✅ 型安全な結果マッピング - Pydanticモデルへの自動変換
✅ マイグレーション管理 - CLIでマイグレーション実行可能
✅ 複数DBサポート - SQLite, PostgreSQL, MySQL等に対応
✅ 非同期対応 - aiosqlite, asyncpgなどをサポート

今回は Litestar (FastAPI類似のWebフレームワーク) + SQLite + SQLSpec でTODOアプリのCRUDとマイグレーションを実装してみます。

サンプルリポジトリ

完成したコードはこちら：

https://github.com/sion908/litestar-sqlspec-app

プロジェクト構成

litestar-sqlspec-app/
├── app/
│   ├── __init__.py
│   ├── main.py           # Litestarアプリのエントリーポイント
│   ├── db.py             # DB設定
│   ├── models.py         # Pydanticモデル
│   ├── routes.py         # APIルート
│   └── migrations/       # マイグレーションファイル（手動作成）
│       ├── 20251111125634_init.sql
│       └── ...
├── pyproject.toml
└── README.md

セットアップ

### 1. 依存関係のインストール

# pyproject.toml
[tool.poetry.dependencies]
python = "^3.12"
litestar = {extras = ["standard"], version = "^2.14.0"}
sqlspec = {path = "sqlspec", develop = true, extras = ["aiosqlite"]}
aiosqlite = "^0.20.0"
pydantic = "^2.10.3"

poetry install

### 2. データベース設定

# app/db.py
from pathlib import Path
from sqlspec.adapters.aiosqlite import AiosqliteConfig

def get_aiosqlite_config() -> AiosqliteConfig:
    db_path = Path("./data/app.db")
    db_path.parent.mkdir(parents=True, exist_ok=True)

    return AiosqliteConfig(
        pool_config={"database": str(db_path)},
        migration_config={
            "script_location": str(Path(__file__).parent / "migrations"),
            "version_table_name": "sqlspec_version",
        }
    )

### 3. Pydanticモデル定義

# app/models.py
from datetime import datetime
from enum import Enum
from typing import Optional
from pydantic import BaseModel, Field, ConfigDict

class Priority(str, Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"

class TaskBase(BaseModel):
    title: str = Field(..., min_length=1, max_length=200)
    description: Optional[str] = None
    completed: bool = False
    priority: Priority = Priority.MEDIUM
    due_date: Optional[datetime] = None

class TaskCreate(TaskBase):
    pass

class TaskUpdate(BaseModel):
    title: Optional[str] = Field(None, min_length=1, max_length=200)
    description: Optional[str] = None
    completed: Optional[bool] = None
    priority: Optional[Priority] = None
    due_date: Optional[datetime] = None

class Task(TaskBase):
    model_config = ConfigDict(from_attributes=True)

    id: int
    created_at: datetime
    updated_at: datetime

マイグレーション管理

### マイグレーションファイルの作成

警告

重要: SQLSpecではマイグレーションファイルは**自動生成されません**。手動でSQLファイルを作成する必要があります。

# pyproject.tomlに設定を記述
[tool.sqlspec]
config = "app.db.get_aiosqlite_config"

# マイグレーション用のディレクトリとファイルを手動作成
mkdir -p app/migrations
touch app/migrations/20251111125634_init.sql

マイグレーションファイルの構造：

-- app/migrations/20251111125634_init.sql

-- name: migrate-20251111125634-up
CREATE TABLE IF NOT EXISTS tasks (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    title TEXT NOT NULL,
    description TEXT,
    completed BOOLEAN NOT NULL DEFAULT 0,
    priority TEXT NOT NULL DEFAULT 'medium',
    due_date TIMESTAMP,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER IF NOT EXISTS update_tasks_updated_at
AFTER UPDATE ON tasks
FOR EACH ROW
BEGIN
    UPDATE tasks SET updated_at = CURRENT_TIMESTAMP WHERE id = NEW.id;
END;

-- name: migrate-20251111125634-down
DROP TRIGGER IF EXISTS update_tasks_updated_at;
DROP TABLE IF EXISTS tasks;

### マイグレーションの実行

# 最新バージョンまで適用
sqlspec upgrade

# 1つ戻す
sqlspec downgrade -1

# 特定バージョンまで適用
sqlspec upgrade 20251111125634

# 現在のバージョン確認
sqlspec current

CRUD実装

### Litestarアプリケーションのセットアップ

# app/main.py
from litestar import Litestar
from sqlspec import SQLSpec
from sqlspec.extensions.litestar import SQLSpecPlugin

from app.db import get_aiosqlite_config
from app.routes import TaskController

# SQLSpec設定を登録
sqlspec_registry = SQLSpec()
sqlspec_registry.register_config(get_aiosqlite_config())

app = Litestar(
    route_handlers=[TaskController],
    plugins=[SQLSpecPlugin(sqlspec_registry=sqlspec_registry)],
)

### CRUD エンドポイント実装

# app/routes.py
from typing import List, Optional
from litestar import Controller, get, post, put, delete
from litestar.exceptions import NotFoundException
from sqlspec.adapters.aiosqlite import AiosqliteDriver

from models import Task, TaskCreate, TaskUpdate

class TaskController(Controller):
    path = "/tasks"

    @get()
    async def list_tasks(
        self,
        db_session: "AiosqliteDriver",
        completed: Optional[bool] = None,
        limit: int = 10,
        offset: int = 0
    ) -> List[Task]:
        """タスク一覧取得（フィルタ・ページネーション対応）"""
        query = """
            SELECT id, title, description, completed, priority,
                   due_date, created_at, updated_at
            FROM tasks
        """
        params = []

        if completed is not None:
            query += " WHERE completed = ?"
            params.append(completed)

        query += " ORDER BY created_at DESC LIMIT ? OFFSET ?"
        params.extend([limit, offset])

        # パラメータは *params で展開して渡す
        result = await db_session.execute(query, *params)
        # schema_typeはexecuteではなく、結果オブジェクトのメソッドで指定
        return result.get_data(schema_type=Task)

    @post()
    async def create_task(
        self,
        data: TaskCreate,
        db_session: "AiosqliteDriver",
    ) -> Task:
        """タスク作成"""
        task = await db_session.select_one(
            """
            INSERT INTO tasks (title, description, completed, priority, due_date)
            VALUES (?, ?, ?, ?, ?)
            RETURNING id, title, description, completed, priority,
                      due_date, created_at, updated_at
            """,
            data.title,
            data.description or "",
            data.completed,
            data.priority,
            data.due_date,
            schema_type=Task
        )
        await db_session.commit()
        return task

    @get("/{task_id:int}")
    async def get_task(
        self,
        task_id: int,
        db_session: "AiosqliteDriver",
    ) -> Task:
        """タスク詳細取得"""
        task = await db_session.select_one_or_none(
            """
            SELECT id, title, description, completed, priority,
                   due_date, created_at, updated_at
            FROM tasks
            WHERE id = ?
            """,
            task_id,
            schema_type=Task
        )
        if task is None:
            raise NotFoundException(f"Task with ID {task_id} not found")
        return task

    @put("/{task_id:int}")
    async def update_task(
        self,
        task_id: int,
        data: TaskUpdate,
        db_session: "AiosqliteDriver",
    ) -> Task:
        """タスク更新（部分更新対応）"""
        update_fields = []
        params = []

        if data.title is not None:
            update_fields.append("title = ?")
            params.append(data.title)
        if data.description is not None:
            update_fields.append("description = ?")
            params.append(data.description)
        if data.completed is not None:
            update_fields.append("completed = ?")
            params.append(data.completed)
        if data.priority is not None:
            update_fields.append("priority = ?")
            params.append(data.priority)
        if data.due_date is not None:
            update_fields.append("due_date = ?")
            params.append(data.due_date)

        if not update_fields:
            return await self.get_task(task_id, db_session)

        update_fields.append("updated_at = CURRENT_TIMESTAMP")
        params.append(task_id)

        query = f"""
            UPDATE tasks
            SET {', '.join(update_fields)}
            WHERE id = ?
            RETURNING id, title, description, completed, priority,
                      due_date, created_at, updated_at
        """

        result = await db_session.execute(query, *params)
        task = result.one(schema_type=Task)
        await db_session.commit()
        return task

    @delete("/{task_id:int}", status_code=204)
    async def delete_task(
        self,
        task_id: int,
        db_session: "AiosqliteDriver",
    ) -> None:
        """タスク削除"""
        result = await db_session.execute(
            "DELETE FROM tasks WHERE id = ?",
            task_id
        )
        if result.rows_affected == 0:
            raise NotFoundException(f"Task with ID {task_id} not found")
        await db_session.commit()

SQLSpecの特徴的なポイント

### 1. パラメータの渡し方

# ✅ execute()の場合: *params で展開して渡す
result = await db_session.execute(query, *params)
# schema_typeは結果オブジェクトで指定
tasks = result.get_data(schema_type=Task)

# ✅ select_one()やselect_one_or_none()の場合: schema_typeを直接指定可能
task = await db_session.select_one(query, param1, param2, schema_type=Task)

# 📝 Note: paramsはlistでもtupleでも問題なく動作します
params = [10, 0]  # または params = (10, 0)
result = await db_session.execute(query, *params)

### 2. 結果の型変換

SQLSpecは SQLResult オブジェクトを返し、以下のメソッドで型変換できます：

# 全件取得
tasks = result.all(schema_type=Task)
tasks = result.get_data(schema_type=Task)

# 1件取得（0件または2件以上の場合はエラー）
task = result.one(schema_type=Task)

# 1件取得（0件の場合はNone）
task = result.one_or_none(schema_type=Task)

# 最初の1件（0件の場合はNone）
task = result.get_first(schema_type=Task)

# スカラー値（SELECT COUNT(*) などで使用）
count = result.scalar()

# 影響を受けた行数
affected = result.rows_affected

### 3. トランザクション管理

Litestarの依存性注入により、db_session が自動的にトランザクション管理されます：

# 変更を確定する場合は明示的にコミット
await db_session.commit()

# エラー時は自動的にロールバック
# try-except不要（Litestarプラグインが自動処理）

動作確認

# マイグレーション実行
sqlspec upgrade

# サーバー起動
litestar run --reload

# APIテスト
# タスク作成
curl -X POST http://localhost:8000/tasks \
  -H "Content-Type: application/json" \
  -d '{"title": "買い物に行く", "priority": "high"}'

# タスク一覧取得
curl http://localhost:8000/tasks

# 完了済みタスクのみ取得
curl http://localhost:8000/tasks?completed=true

# ページネーション
curl http://localhost:8000/tasks?limit=5&offset=0

SQLSpec使用時の注意点

### マイグレーション

❌ モデルからの自動生成は**サポートされていません**
✅ SQLファイルを手動で作成する必要があります
✅ タイムスタンプベースのファイル名を推奨（例: 20251111125634_init.sql）
✅ -- migrate-{version}-up と -- migrate-{version}-down セクションの両方を記述

### パラメータ処理

✅ execute() では *params で展開
✅ select_one() では個別の引数として渡す
✅ listでもtupleでも動作します
⚠️ execute() にパラメータと共に`schema_type` を渡すとエラーになります

### トランザクション

✅ 変更系操作（INSERT/UPDATE/DELETE）後は commit() を呼ぶ
✅ SELECT のみの場合はcommit不要
✅ エラー時のロールバックは自動

まとめ

SQLSpecを使うことで、以下のメリットが得られました：

✅ SQLをそのまま書ける - ORMの学習コスト不要 ✅ 型安全 - Pydanticモデルへの自動マッピング ✅ マイグレーション管理 - CLIで簡単に実行 ✅ 柔軟性 - 複雑なクエリもそのまま記述可能

一方で以下の点には注意が必要です：

⚠️ 実験的なライブラリ - 本番環境では慎重に ⚠️ マイグレーションは手動 - SQLファイルを自分で書く必要がある ⚠️ ドキュメント不足 - 試行錯誤が必要な部分もある

「ORMは便利だけど、結局SQL書くことが多い」という方で、実験的なツールを試してみたい方には、SQLSpecは興味深い選択肢になると思います。

完全なコードは GitHubリポジトリで公開していますので、ぜひ試してみてください！

参考リンク

AIペアプログラミングで体感する未来の開発：Lambda + HTMX で30分ゲーム開発の全記録

2025-06-29T00:00:00+00:00

はじめに：開発革命の実体験

### 衝撃の30分間

「AWSでゲームを作りたい」と入力してから、完全に動作するタイミングベースクリッカーゲームが完成するまで、わずか30分。これは誇張ではなく、実際に体験した開発速度です。

### 従来開発との比較

従来の個人開発: 企画(1日) → 技術調査(2日) → 環境構築(半日) → 実装(1週間) → デバッグ(2日) → デプロイ(半日) 合計: 約2週間

AI支援開発: 企画・実装・デプロイ: 30分

この圧倒的な差は何から生まれるのか？実際の開発プロセスを詳細に記録しました。

AI支援開発の実際：対話ログから見る開発プロセス

### Phase 1: 技術スタック選定（5分）

私: 「awsに置くことを念頭に置いたゲームを作りたい」

AI: 即座に複数の選択肢を提示 - Webブラウザゲーム（S3 + CloudFront + Lambda） - リアルタイム対戦（GameLift + WebSocket） - モバイルゲーム（Amplify + Cognito）

私: 「lambda+jinja2+htmxである」

AI: 瞬時に最適化された構成を提案

Lambda Function URLs + Jinja2 + HTMX ↓ サーバーレス + テンプレート + ハイパーメディア = 最小構成で最大効果

### Phase 2: 基本実装（10分）

AIが生成した初期コードの品質に驚愕： - Litestarの適切な使用法 - Jinja2テンプレートのインライン実装 - HTMXの効果的な活用 - エラーハンドリングまで完備

### Phase 3: 機能拡張（10分）

私: 「litestarも使って欲しい」 → 即座にMangumを使ったLambda統合

私: 「localStorageに保存するようにして欲しい」 → クライアント・サーバー間の状態同期システムを実装

### Phase 4: UX改善（5分）

私: 「htmxの機能を何か使いたい」 → プログレスバー、アニメーション、リアルタイム更新を提案・実装

Lambda + HTMX: 新時代のWeb開発パラダイム

### 従来のSPA開発の課題

// React/Vueの典型的な複雑さ
const [gameState, setGameState] = useState({});
const [loading, setLoading] = useState(false);

useEffect(() => {
 // 複雑な状態管理
 // API呼び出し
 // エラーハンドリング
}, [dependencies]);

// ビルド設定、バンドル最適化、デプロイ設定...

### HTMX + Lambdaのシンプルさ

<!-- たった1行でリアルタイム更新 -->
<button hx-post="/api/action"
       hx-target="#game-content">
   Click Me!
</button>

### 技術的優位性の詳細分析

#### 1. 開発効率 - フロントエンド・バックエンド境界の消失

HTMLテンプレート内でサーバーロジックを直接呼び出し

状態管理の複雑さを排除

APIの設計・実装コストを削減

#### 2. 想定運用コスト

従来構成の月額コスト: • EC2 t3.micro: $8.5 • RDS t3.micro: $15 • CloudFront: $1 • 合計: $24.5/月

Lambda + HTMX構成: • Lambda実行時間: $0.20 • API Gateway: $1 • 合計: $1.20/月 (95%削減)

#### 3. パフォーマンス - 初期ロード: HTMLテンプレート直接配信 - 更新処理: 必要な部分のみDOM更新 - ネットワーク: JSONではなくHTML断片で通信効率化

実装の技術的深掘り

### HTMXの真の威力

#### 1. 宣言的UI更新

<!-- 従来のJavaScript -->
<script>
fetch('/api/action', {method: 'POST'})
 .then(response => response.json())
 .then(data => {
   document.getElementById('score').textContent = data.score;
   document.getElementById('level').textContent = data.level;
   // 複雑なDOM操作...
 });
</script>

<!-- HTMXの宣言的アプローチ -->
<button hx-post="/api/action"
       hx-target="#game-content"
       hx-swap="innerHTML">
   Click Me!
</button>

#### 2. 高度な機能の簡単実装

<!-- プログレスインジケーター -->
<div hx-indicator="#loading">Processing...</div>

<!-- 条件付きリクエスト -->
<div hx-get="/api/special"
    hx-trigger="load"
    hx-include="[name='level']">
</div>

<!-- リアルタイム更新 -->
<div hx-get="/api/status"
    hx-trigger="every 2s">
</div>

### Lambdaでのゲーム状態管理

#### 1. localStorageとの連携パターン

def get_game_data_from_request(request: Request) -> Dict[str, int]:
   """HTTPヘッダーからクライアント状態を取得"""
   game_data_header = request.headers.get('X-Game-Data')
   if game_data_header:
       return json.loads(game_data_header)
   return {'score': 0, 'clicks': 0, 'level': 1}

def create_response_with_game_data(template_name: str, game_data: Dict[str, int], context):
   """更新された状態をヘッダーで返却"""
   headers = {'X-Updated-Game-Data': json.dumps(game_data)}
   return LitestarResponse(content=html, headers=headers)

#### 2. タイミングシステムの実装

function attemptItemGet(event) {
   // リアルタイム位置計算
   const position = calculateIndicatorPosition(event);

   // タイミング品質判定
   const quality = determineTimingQuality(position);

   // HTMXでサーバーに送信
   htmx.ajax('POST', '/api/get-item', {
       headers: {'X-Timing-Quality': quality}
   });
}

AI支援開発の深層分析

### AIが優秀だった点

#### 1. 技術選択の最適化 - 問題: 「AWSでゲーム」という曖昧な要求 - AI判断: 用途に応じた複数選択肢の提示 - 結果: 最小構成で最大効果の実現

#### 2. 実装パターンの知識

# AIが自然に適用したベストプラクティス
• Mangumを使ったLambda統合
• Jinja2のStringLoaderパターン
• HTMXイベントハンドリング
• エラーハンドリングの網羅

#### 3. デバッグ能力

エラー: ImportError: cannot import name 'FormData' AI対応: 即座に不要なインポートを特定・削除

エラー: AttributeError: 'StringTemplateEngine' object has no attribute 'engine' AI対応: テンプレートエンジンの実装方式を変更

### 人間が重要だった点

#### 1. 要求の具体化 - 「プログレスバーを表示し、特定の場所をクリックするとアイテムがもらえるように」 - 「スコアはlocalStorageに保存するようにして欲しい」

#### 2. UX判断 - タイミングゲームの面白さ - 視覚効果の豪華さ - ユーザビリティの向上

#### 3. 技術選択の最終判断 - Lambda + HTMXの組み合わせ採用 - localStorageでの永続化選択

開発体験の革新

### 従来の個人開発

アイデア発想
技術調査・学習
環境構築
設計・実装
テスト・デバッグ
デプロイ設定
運用準備

各段階で挫折リスク

### AI支援開発

アイデア発想
AIとの対話で即座に実装
リアルタイムでの改善・拡張

挫折リスクの大幅削減

### 学習効果の変化 - 従来: 理論学習 → 実践適用 - AI支援: 実践 → 理解深化 - 結果: より深い技術理解

まとめ：開発パラダイムの転換点

### AI支援開発の本質 - 速度: アイデア→実装の時間短縮 - 品質: ベストプラクティスの自動適用 - 学習: 実践を通じた深い理解

### Lambda + HTMX の意義 - シンプルさ: 複雑さを排除した開発体験 - 効率性: 最小コストでの最大効果 - 拡張性: 必要に応じた機能追加の容易さ

### 個人開発者への提言 1. AIを恐れず活用: 協働パートナーとしての位置づけ 2. 技術選択の再考: 複雑さより実用性を重視 3. 学習方法の変化: 理論より実践を先行

### 最後に

この30分間の開発体験は、単なる技術的成功以上の意味を持ちます。それは、個人開発者が世界レベルの開発速度と品質を手に入れられる時代の到来を示しています。

技術の民主化が進む今、重要なのは最新フレームワークの習得ではなく、**問題解決能力**と**創造性**です。AIが技術的な実装を支援してくれる今こそ、私たちは本来注力すべき「何を作るか」「なぜ作るか」に集中できるのです。

参考リンク・リソース

---

この記事は実際のAI支援開発体験を基に執筆されました。開発時間30分は実測値です。

AWS Lambdaとローカルで非同期処理をシームレスに実行するユーティリティを作った話

2025-05-03T00:00:00+00:00

はじめに

AWS Lambdaの非同期実行とローカル開発の両立って意外と面倒ですよね。本記事では、asyncioによるローカル非同期処理と、Lambdaの非同期実行を同じAPIで扱えるユーティリティを作成し、LitestarでAPI化、CDKでデプロイまで自動化した構成を紹介します。

目的・背景

ローカルではasyncioで高速に非同期処理を試したい
本番はAWS Lambdaでスケールしたい
API設計はモダンなPythonフレームワーク（Litestar）で
デプロイ・管理はCDKで自動化したい

アーキテクチャ概要

+-------------+       +----------------+       +--------------------+
| API Gateway |  -->  | API Lambda     |  -->  | Worker Lambda      |
+-------------+       +----------------+       +--------------------+
         ↑                   |                        |
         |   (Litestar)      |   (async invoke)       | (async job)
         +-------------------+------------------------+

API Gateway経由でリクエストを受け、API Lambda（Litestarアプリ）で処理
非同期ジョブはWorker Lambdaへinvoke
ローカルではasyncioで同等の非同期実行

ソースコード

https://github.com/sion908/async_lambda_local

ローカル＆Lambda両対応の非同期処理

`async_lambda_invoker`デコレータで、ローカル時はasyncio、Lambda時はboto3でinvoke

System Message: WARNING/2 (/home/runner/work/master_web/master_web/source/blog/2025/lambda-async-utility.rst, line 48); backlink

Inline interpreted text or phrase reference start-string without end-string.
共通APIでどちらでも非同期ジョブをキックできる

from main import async_lambda_invoker

@async_lambda_invoker
async def process_job(data):
    # 非同期ジョブ本体

LitestarによるAPI実装

/ でサービスのステータス確認
/process で非同期ジョブをPOST
VS Code REST Client用の api_test.http で簡単にAPIテスト

AWS CDKによるデプロイ自動化

Lambda関数、IAMロール、API Gatewayなど全てCDKで定義
manage.sh で ./manage.sh deploy するだけで一発デプロイ
`.env`でAWSプロファイルやリージョンを安全に管理

System Message: WARNING/2 (/home/runner/work/master_web/master_web/source/blog/2025/lambda-async-utility.rst, line 71); backlink

Inline interpreted text or phrase reference start-string without end-string.

./manage.sh deploy

プロジェクト構成と管理

main.py: 非同期処理ロジックとAPI
infra/cdk/: CDKスタック定義
src/lambda/: Lambdaハンドラー
manage.sh: 統合管理スクリプト
.env & .env.sample: 設定ファイル
requirements.txt, requirements-dev.txt: 依存関係管理

まとめ

ローカルとLambdaの両方で同じAPIで非同期処理ができる
LitestarでモダンなAPI開発
CDKと管理スクリプトでデプロイも超簡単
AWSプロファイルも安全に切り替え可能

---

litestarのpolyfactoryでGeometryを扱う

2025-03-23T00:00:00+00:00

はじめに

litestar+sqlalchemyを用いてアプリの開発をしており、テストコードを書く際に、モックデータということで、litestarの派生ライブラリ？であるpolyfactoryを使った。この時、geoalchemy2を使っているのだが、簡単には生成してくれなかったので、記事として残しておく。

スクリプト

import random
from typing import Any, Callable
from advanced_alchemy.base import UUIDBase
from sqlalchemy import Column, Integer, String
from geoalchemy2 import Geometry
from geoalchemy2.functions import ST_X, ST_Y
from polyfactory.factories.sqlalchemy_factory import SQLAlchemyFactory
from sqlalchemy.orm import Mapped, mapped_column


# Geometry型を含むSQLAlchemyモデル
import random
from typing import Any, Callable
from advanced_alchemy.base import UUIDBase
from sqlalchemy import Column, Integer, String
from geoalchemy2 import Geometry
from geoalchemy2.functions import ST_X, ST_Y
from polyfactory.factories.sqlalchemy_factory import SQLAlchemyFactory
from sqlalchemy.orm import Mapped, mapped_column


# Geometry型を含むSQLAlchemyモデル
class Location(UUIDBase):
    __tablename__ = "locations"

    id = Column(Integer, primary_key=True)
    name = Column(String(100), nullable=False)
    location: Mapped[str] = mapped_column(Geometry("POINT", srid=4326), nullable=True)

    def __repr__(self):
        return f"<Location(id={self.id}, name={self.name}, location=(<{ST_Y(self.location)}> <{ST_X(self.location)}>)))>"


class LocationFactory(SQLAlchemyFactory[Location]):
    __model__ = Location

    @classmethod
    def get_sqlalchemy_types(cls) -> dict[Any, Callable[[], Any]]:
        types = super().get_sqlalchemy_types()
        types[Geometry] = lambda: f'POINT({random.uniform(-180, 180)} {random.uniform(-90, 90)})'
        return types

    @classmethod
    def location(cls) -> str:
        return cls.get_sqlalchemy_types()[Geometry]()

# 使用例
def demo_mock_creation():
    loc = [LocationFactory().build() for _ in range(10)]
    for l in loc:
        assert type(l) == Location
        assert l.location is not None

# デモ実行
if __name__ == "__main__":
    demo_mock_creation()

何をやったのか

追加したのは、`LocationFactory`における, `get_sqlalchemy_types`の

types[Geometry] = lambda: f'POINT({random.uniform(-180, 180)} {random.uniform(-90, 90)})'

の部分。ついでに、null許容だったのですが、モックでは値を必ず入れて欲しかったので

@classmethod
def location(cls) -> str:
    return cls.get_sqlalchemy_types()[Geometry]()

を追記しています。

litestarのコミュニティにきいたところ

SQLA factory is a bit different to others in the sense there's an extra translation layer from column type to python type that needs to be done in factory.
-- SQLA（SQLAlchemy）のファクトリーは他のものとは少し異なっていて、カラムの型をPythonの型に変換するための追加の変換レイヤーがファクトリー内に必要になるんだ。

Can you try overriding https://polyfactory.litestar.dev/reference/factories/sqlalchemy_factory.html#polyfactory.factories.sqlalchemy_factory.SQLAlchemyFactory.get_sqlalchemy_types to map this type to callable that returns a random value for this column type?

とのこと。そりゃ生成されないわけです。

元々のエラー

AttributeError: 'Geometry' object has no attribute 'impl'
It looks like this stems from polyfactory trying to infer a python_type from the Geometry column, which isn't supported by GeoAlchemy2's Geometry type.

implがないとのことですね。 AIに聞いても全然解決策の提示はしてもらえませんでした。

参考

https://polyfactory.litestar.dev/reference/factories/sqlalchemy_factory.html#polyfactory.factories.sqlalchemy_factory.SQLAlchemyFactory.get_sqlalchemy_types

追記

ドキュメント更新していただけましたありがとうございます https://github.com/litestar-org/polyfactory/pull/671

python+sqlalchemy+lambdaで管理者画面を作る

2024-12-20T00:00:00+00:00

背景

バックエンドエンジニアをやっています。litestar+sqlalchemy+lambdaの構成でAPIをつくったのですが、フロントの方から管理者画面を作った方がいいよの声が... 普通みんな持ってるでしょって言われましたあるあるなんでしょうか？みなさん教えてください

というわけで、管理者画面を拵えることになったのですが、工数はないので、適当なライブラリを使うことに。Djangoみたいに簡単にできればいいなというところで、`sqladmin <https://github.com/aminalaee/sqladmin>`_を見つけました。簡単な管理者画面にはとてもいいのですが、jinja2で毎レスポンスごとに、全てのhtmlを送ってくる仕様でした。ちょっと困るのでlambda+cognitoで使えるようにhtmxを使って書き換えることにしました。

TL;DR

sqladminでcrudできるの楽しい
htmxおもしろい
`sqladminlambda <https://github.com/sion908/sqladminlambda>`_作ってみたので、みてみてください

System Message: WARNING/2 (/home/runner/work/master_web/master_web/source/blog/2024/python-sqlalchemy-lambda-admin.rst, line 27); backlink

Inline interpreted text or phrase reference start-string without end-string.

そもそも

## sqladminについて

sqlalchemyのモデル定義をもとに、starlette系のASGIライブラリで管理者画面を作ることができる。 starletteでasgiを作り、sqlalchemyのモデルをwtformsでフォーム化、jinja2でhtmlをレンダリングする。

## 利点 - 少しの変更で、crudができるようになる - モデルのcrudの前に処理を挟むことができるので、必要な独自処理を追加できる - 拡張性が高い

## 個人的に足りなかったこと - 毎回全てのhtmlをレンダリングして返してくるので、効率が悪い

せめて、最小限のDOMを返すようにしたい

cognitoに対応したい

開発

色々やってみたかったのですが、第一弾として、htmxに対応してもらって、id_tokenを渡すことで、apigatewayの認証にも対応できるようにしました。

やったこと

htmxによる擬似的なページ遷移の実現
htmxによるDOM操作
htmxでid_tokenを渡せるように修正

## htmxについて

<button hx-get="/api/user-info"
  hx-trigger="load"
  hx-headers='{"Authorization": "Bearer ${localStorage.getItem("id_token")}"}'
  hx-target="this"
  hx-push-url="true">
</button>

このbutton操作によってできること

DOM操作 - `hx-target`属性を使用して、更新する要素を指定 - `hx-trigger`で、いつHTMXのリクエストを実行するかを制御

System Message: WARNING/2 (/home/runner/work/master_web/master_web/source/blog/2024/python-sqlalchemy-lambda-admin.rst, line 78); backlink

Inline interpreted text or phrase reference start-string without end-string.

System Message: WARNING/2 (/home/runner/work/master_web/master_web/source/blog/2024/python-sqlalchemy-lambda-admin.rst, line 78); backlink

Inline interpreted text or phrase reference start-string without end-string.

認証トークンの設定 - 個別のリクエストで`hx-headers`属性を使用してヘッダーを設定

ルーティングの仮想遷移 - `hx-push-url="true"`属性により、ブラウザの履歴にURLを追加

System Message: WARNING/2 (/home/runner/work/master_web/master_web/source/blog/2024/python-sqlalchemy-lambda-admin.rst, line 85); backlink

Inline interpreted text or phrase reference start-string without end-string.

System Message: WARNING/2 (/home/runner/work/master_web/master_web/source/blog/2024/python-sqlalchemy-lambda-admin.rst, line 85); backlink

Inline interpreted text or phrase reference start-string without end-string.

終わりに

あくまでも個人的見解です。夢はあるなと cognitoの対応もしたのですが、sqladminの外側で定義したので、ライブラリに含めることはできなかったです。 lambdaとsession周りをどう適応させるかわからず今回はこのような方式にしましたが、ちょくちょく認証が切れて、ログアウトさせられるのをどうにかしたいところです。最近litestarにハマっているので、starlette系だけではなく、litestarにも対応させたいです。litestarの方にも`piccolo admin`がありましたが、こちらの方が使いやすそうな印象でした。文章力がほしい...

参考

https://aminalaee.dev/sqladmin/

gitのブランチ移動を簡単にする

2023-11-15T00:00:00+00:00

はじめに

gitでバージョン管理をしている GUIの操作を覚えたくないのでCLIでやろうとするが長くなりがちなブランチ名をいちいちコピペするのもめんどくさいというところで、ブランチの移動とやりたいときはマージまでコマンドで簡単にできないかとシェルスクリプトを作成した。これでブランチの移動にストレスがなくなりました `./bashrc`への追加でさらに使いやすくなります何か意見改善点あればぜひ教えてください！！

制作品

### 完成品

#!/usr/bin/env bash

set -u

show_help() {
  cat <<'EOF'
usage: gcn [options] [branch_number]

options:
  -h  show help
  -p  pull the target branch after switch
  -m  merge previous branch into target branch after switch
  -d  delete previous branch after switch (confirmation required)

examples:
  gcn 3
  gcn -p 2
  gcn -md 5
  gcn -mpd 1
EOF
  exit 0
}

confirm_delete() {
  local branch_name="$1"

  echo
  echo "Delete previous branch: ${branch_name}"
  read -r -p "Type 'yes' to delete this branch: " answer

  [ "$answer" = "yes" ]
}

is_protected_branch() {
  local branch_name="$1"

  case "$branch_name" in
    main|master|develop|development)
      return 0
      ;;
    *)
      return 1
      ;;
  esac
}

sort_branches() {
  local prioritized=(
    main
    master
    develop
    test
    staging
    clientdemo1
  )

  local sorted=()
  local branch
  local p
  local found

  for p in "${prioritized[@]}"; do
    for branch in "${branches[@]}"; do
      if [ "$branch" = "$p" ]; then
        sorted+=("$branch")
        break
      fi
    done
  done

  for branch in "${branches[@]}"; do
    found=0
    for p in "${prioritized[@]}"; do
      if [ "$branch" = "$p" ]; then
        found=1
        break
      fi
    done

    if [ "$found" -eq 0 ]; then
      sorted+=("$branch")
    fi
  done

  branches=("${sorted[@]}")
}

switch_branch() {
  local target_branch="$1"

  echo ">> git switch $target_branch"
  git switch "$target_branch"
}

pull_branch() {
  local target_branch="$1"

  echo ">> git pull origin $target_branch"
  git pull origin "$target_branch"
}

merge_previous_branch() {
  local previous_branch="$1"

  echo ">> git merge $previous_branch"
  git merge "$previous_branch"
}

delete_previous_branch() {
  local previous_branch="$1"

  if is_protected_branch "$previous_branch"; then
    echo "Refusing to delete protected branch: $previous_branch"
    return 1
  fi

  if confirm_delete "$previous_branch"; then
    echo ">> git branch -d $previous_branch"
    git branch -d "$previous_branch"
  else
    echo "Canceled branch deletion."
  fi
}

# option flags
do_pull=0
do_merge=0
do_delete=0

while getopts ":hpmd" opt; do
  case "$opt" in
    h)
      show_help
      ;;
    p)
      do_pull=1
      ;;
    m)
      do_merge=1
      ;;
    d)
      do_delete=1
      ;;
    \?)
      echo "Invalid option: -$OPTARG"
      echo
      show_help
      ;;
  esac
done

shift $((OPTIND - 1))

mapfile -t branches < <(git for-each-ref --format='%(refname:short)' refs/heads/)
if [ "${#branches[@]}" -eq 0 ]; then
  echo "No local branches found."
  exit 1
fi

sort_branches

before_branch="$(git rev-parse --abbrev-ref HEAD)"

echo "Available branches:"
for i in "${!branches[@]}"; do
  printf "%3d: %s\n" "$i" "${branches[$i]}"
done

if [ $# -ge 1 ]; then
  branch_number="$1"
else
  read -r -p "Enter branch number to switch: " branch_number
fi

if [ -z "${branch_number:-}" ] || [ "$branch_number" = "q" ]; then
  echo "Canceled."
  exit 1
fi

if ! [[ "$branch_number" =~ ^[0-9]+$ ]]; then
  echo "Invalid branch number: $branch_number"
  exit 1
fi

target_branch="${branches[$branch_number]:-}"

if [ -z "$target_branch" ]; then
  echo "Invalid branch number: $branch_number"
  exit 1
fi

echo "chosen branch: <$target_branch>"

if [ "$before_branch" = "$target_branch" ]; then
  echo "You are already on '$target_branch'."
  exit 1
fi

if ! switch_branch "$target_branch"; then
  echo "Failed to switch branch."
  exit 1
fi

if [ "$do_pull" -eq 1 ]; then
  if ! pull_branch "$target_branch"; then
    echo "Failed to pull branch: $target_branch"
    exit 1
  fi
fi

if [ "$do_merge" -eq 1 ]; then
  if ! merge_previous_branch "$before_branch"; then
    echo "Failed to merge branch: $before_branch"
    exit 1
  fi
fi

if [ "$do_delete" -eq 1 ]; then
  delete_previous_branch "$before_branch"
fi

### 使い方

シェルスクリプトを実行するとブランチの一覧が表示され、数字を指定することで、そのブランチに移動することができる。

$ ./git_checkout_by_number.sh
　　Available branches:
   0: main
   1: develop
   2: feature/branch1
   3: feature/branch2
 Enter branch number to switch:      １
 >> git switch develop
 Switched to branch 'develop'

オプションを指定することで、移動後に追加の操作が可能です：

-p: 移動後に git pull を実行
-m: 移動前にいたブランチを移動先ブランチにマージ
-d: 移動前にいたブランチを削除（確認あり）

$ ./git_checkout_by_number.sh -p 2
$ ./git_checkout_by_number.sh -md 3
$ ./git_checkout_by_number.sh -mpd 1

スクリプトの説明

## オプション解析

getopts を使用してオプションを正しく解析します。

while getopts ":hpmd" opt; do
  case "$opt" in
    h) show_help ;;
    p) do_pull=1 ;;
    m) do_merge=1 ;;
    d) do_delete=1 ;;
    \?) echo "Invalid option: -$OPTARG"; show_help ;;
  esac
done

## ブランチの取得とソート

ローカルブランチを取得し、優先ブランチ（main, master, develop等）を先頭にソートします。

mapfile -t branches < <(git for-each-ref --format='%(refname:short)' refs/heads/)
sort_branches

## 入力の取得と例外処理

引数でブランチ番号が指定されない場合は対話的に入力を求めます。入力なしまたは q を入力するとキャンセルされます。

if [ $# -ge 1 ]; then
  branch_number="$1"
else
  read -r -p "Enter branch number to switch: " branch_number
fi

if [ -z "${branch_number:-}" ] || [ "$branch_number" = "q" ]; then
  echo "Canceled."
  exit 1
fi

## ブランチの移動

git switch を使用してブランチを移動します。同一ブランチへの移動は防止します。

if [ "$before_branch" = "$target_branch" ]; then
  echo "You are already on '$target_branch'."
  exit 1
fi

switch_branch "$target_branch"

## 保護されたブランチの削除防止

main, master, develop, development ブランチは削除対象から除外します。

is_protected_branch() {
  case "$branch_name" in
    main|master|develop|development)
      return 0
      ;;
    *)
      return 1
      ;;
  esac
}

`.bashrc`への登録

gitは比較的どこでも使うので`./bashrc`に登録したほうが使いやすいですいちいちプロジェクトごとに置いとくのもignoreするのもめんどいですしね自分の場合は`git_checkout_by_number.sh`を`/usr/local/bin/mine/`において、 .bashrcに下記を追記しました。

export PATH=/usr/local/bin/mine/:$PATH
alias gcn='git_checkout_by_number'

$ gcn

で利用できます

参考文献

ごめんなさいあったかもしれませんが忘れました参考にした方ありがとうございました