Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

MySQL の各バージョン間のパラメータの差分を見ることができる MySQL Parametersという便利ページがあるんですよ。 もともと8年前(2018年)に Vue.js の練習として作ったものだったんだけど、JavaScript はあまり触る気になれなくて放置してた。ruby.wasm の登場で Ruby でもブラウザ上でプログラムが動かせるようになったので 3年前(2023年)に ruby.wasm で作り直した。 だけどフルセットの Ruby をブラウザで読み込むんで、起動が重くなったんですよ。まあそれはそう。 モバイルデバイスだと厳しいくらい。そのうちどうにかしたいなーとは思ったんだけど、そのままにしてた。 RubyKaigi 2026 に参加して picoruby.wasm の話を聴いたことで、MySQL Parameters を picoruby.wasm で作り直す気に

CI/CDシリーズ: 1本目: Next.js + NestJSのモノレポでGitHub Actionsのデプロイパイプラインを構築した 2本目: Pull Requestごとにバックエンドも含めたプレビュー環境を自動構築する仕組みを作った 3本目: GitHub ActionsとECS Run TaskでDB操作を自動化する（この記事） CI/CDシリーズの3本目。今回はデプロイ以外の運用自動化、具体的にはDB操作のワークフロー化の話。 背景: なぜ運用タスクをワークフロー化するのか デプロイ以外にも繰り返し発生する運用タスクがある。マイグレーションの適用、マスタデータの投入、テストデータの投入、データパッチの適用など。 これらを手動でSSHやローカルからDB接続して作業する運用はセキュリティ的にちょっと厳しいところ。それにVPC内のリソースへのアクセスにも制約がある。今回はAurora

はじめに 前回の記事で /security-scan を作った後、こんな気持ちになりました。 「これ、デプロイ前の静的解析と、デプロイ後の動的テストが混ざってないか？🤔」 そのとおりで、1スキルに詰め込みすぎていました。 今回は 3スキルに分割してOSSとして公開、さらに テストハーネスで精度を客観測定 するところまでやりました。 まず費用対効果だけ見てください 従来手段 claude-security-scan（3スキル）

📢 アップデート版を公開しました（2026/05/01） この記事のあと、3スキル体制に分割 + テストハーネスで検出率100%を達成 しました。最新の使い方は以下の記事をどうぞ。 👉 claude-security-scanを3スキル体制にアップデートしたら月$1未満で検出率100%を達成した話🎯 はじめに こんにちは、Sabakanです。 今回、Claude Code 用のセキュリティ診断スキル claude-security-scan を作って公開しました。 正直、自分でもびっくりするくらい実用的なものができたので、紹介させてください。 リポジトリはこちら → https://github.com/sabakan0123/claude-security-scan こんな気持ち、ありませんか？ 「セキュリティ診断、ちゃんとやりたいけど Burp Suite の使い方よくわからん」

import * as cdk from 'aws-cdk-lib' import * as ec2 from 'aws-cdk-lib/aws-ec2' import { FckNatInstanceProvider } from 'cdk-fck-nat' import type { Construct } from 'constructs' export interface NetworkStackProps extends cdk.StackProps { environment: string } export class NetworkStack extends cdk.Stack { public readonly vpc: ec2.Vpc constructor(scope: Construct, id: string, props: NetworkStackProps)

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

AI-DLCへの段階的移行の実践 ― AI時代のスクラムイベントを再定義する ― https://levtechlab.connpass.com/event/388937/

はじめに 「どのフレームワークを選ぶべきか？」 これは初学者だけでなく、新規事業の技術選定を任された中級者にとっても常に悩ましいテーマです。 いまフロントエンドの世界は、大きな転換期を迎えています。長年使われてきたReact、Vue、Angularの三大フレームワークが、これまでの古い常識を捨てて新しい次元へとアップデートしているからです。さらに忘れてはいけないのが、私たちのすぐ隣には「Claude Code」や「Cursor」のような、最強のAIアシスタントが当たり前のように存在しているということです。 この記事では、初学者が最初のステップを踏み出すための視点から、中級者がモダンなアーキテクチャをどう捉え、AIとどう協業していくべきかまで、各フレームワークの現在地をまとめました。 1. React：サーバー主導UIへの移行と「AIエコシステムの覇者」 現在もフロントエンド業界で圧倒的なシ

はじめに モチベーション 実装 インフラリポジトリ（Terraform 変更） アプリケーションリポジトリ（ECS タスク定義変更） 横展開：Reusable / Caller 構成への移行 運用風景 コスト影響がない変更の場合 コスト影響がある変更の場合 おわりに はじめに 弊社では AWS 上にマルチテナント構成のインフラを複数の環境にわたって運用しており、その構成管理を Terraform でおこなっています。インフラ側のリソース構成はもちろんのこと、アプリケーション側で管理されている ECS タスク定義の CPU / メモリ割り当てに対しても、折に触れて変更が入ります。 こうしたリソース変更は無論コストに跳ねます。新規コンポーネントの追加やインスタンスサイズの変更が Pull Request（以下 PR、サービスによっては Merge Request 等の呼称もあります）として上が

私の場合、旧検証環境は使い古しているのでアカウント閉鎖、本番環境（旧管理アカウント）は流用するので組織から離脱（組織から除外）することにしました。 アカウント閉鎖 旧管理アカウントのAWS Organizationコンソールから、当該アカウントを選択して閉鎖を指示します。 閉鎖したアカウントは90日間の猶予期間に入り、猶予期間中はサポートに連絡することで復活が可能です。 猶予期間中のアカウントが存在している場合でもOrganizations組織の削除は可能です。 アカウントの離脱（組織から除外） アカウントの離脱（組織から除外）を行う場合、事前に当該アカウントにて以下の条件を満たす必要があります。 ルートユーザの認証設定完了（パスワード・MFA） 支払情報の設定完了 SMS認証の完了 サポートプランの設定完了 新規アカウントは作成後４日経過 1.ルートユーザの認証設定 AWS Organi

クエリが遅くなった。直そう。ここから問題が始まる プロジェクト管理SaaSを1年ほど運用すると、Issueテーブルが200万行、変更ログテーブルが2000万行を超えてくる。ソフトデリートを採用していれば物理削除されないので、行数は増える一方だ。 最初の兆候はユーザーからの報告だった。「Issue一覧の読み込みが遅くて、フィルターを切り替えるたびに5秒くらい待たされるんですが」。スロークエリログを見ると、フィルター付きのIssue一覧クエリがp95で3秒を超えている。インデックスを追加すれば改善する。スキーマ変更も1つ控えていた。どちらもやること自体は明確だった。 問題は「200万行のテーブルにDDLを打つ」という行為そのものにあった。膨れ上がったテーブルに対するスキーマ変更は、パフォーマンスを改善するための作業が、新たな障害を引き起こす可能性を持っている。治療のための手術が患者を殺しかねな

Coding Agent が思わず命令を忘れてしまっても大丈夫。それを機械的にカバーするツールを OSS として作りました。 目次 目次 目次 Coding Agent のド忘れと二重実行 markgate インストール 基本の使い方 1. /check skill 2. hook 終わり 他の hook manager から使う 機械的に二重実行を防止する仕組み マーカーで状態を管理 キャッシュとしての機能 他のユースケース例 ゲートとしての用途 markgate set markgate verify ゲートパターンのユースケース コマンド化できない AI チェックの強制 スコープ付きゲートの活用 実例: 重いチェックを別ゲートに切り出す 最後に Coding Agent のド忘れと二重実行 例えば、実装 skill と、その後に実行するチェック skill (/check)があるとし

はじめに 最近、AI エージェント（GitHub Copilot / Claude Code / Cursor / OpenCode / Codex …）に渡す「指示書」の種類が一気に増えました。 GitHub Copilot → .github/instructions/*.md, .github/prompts/*.md Claude Code → .claude/commands/*.md, .claude/agents/*.md Cursor → .cursor/rules/*.mdc これに加えて MCP サーバー / hooks / skills … チーム内でこれらを 「どこから集めて、どこに配っていますか？」 絵にすると、複数の取得元 × 複数のハーネス という多対多の配線を、各チーム／各リポが自前で組んでいるイメージです。 個々のツールが便利になっても、チーム全体としてこ

Harness Engineering Meetup Tokyo #1、TOPバッターとして、ハーネスエンジニアリングについての導入的説明を行いました。

この雑すぎプロンプトに対して Claude Code は以下を行います。 issue を読んで要件を把握する 自発的に既存のコードベースを調査し、migration ファイル等から既存の table 構造を把握 設計の叩き台の作成・提示 しかし Claude Code の提示する「叩き台」は 情報過多で論点が散漫 になりがちです。 まあ 1 機能全体の要件を把握させて設計をねだっているので当然ですね。次 step で整えます。 2. ユースケースのブラッシュアップと起票 step 1 の出力に対して、人間がつっこみまくるフェーズです。 ここは Agent との二人三脚であり、 人間の判断が設計の方向性を決定する 重要な step になります。 人間が担う役割は主に 2 つあります。 論点の結合・分離 たいてい、 issue やコードベースから読み取れなかった設計の論点を複数個同時に尋ねてき

社内のチームメンバー(クラウド事業本部コンサルティング部)向けに 「 Claude Code を安全に使おう勉強会 」を開催しました。 Claude Code をセキュアに使う上での、 基本的な考え方や権限/サンドボックス機能の紹介、簡単なデモを実施しました。 DevelopersIO向けに調整したスライドを掲載します。 以下勉強会で連携した設定サンプルです。 Claude Code を安全に使おう勉強会: 補足資料 - Gist スライドの内容:テキスト情報を以降に記載します。参考になれば幸いです。 イントロ 勉強会の目的やアジェンダ、スコープについて話します。 勉強会の目的 Claude Code (に限らず、AIエージェント) はとても便利です。 しかしリスクもあり、暴走もします。 この勉強会では、 Claude Codeが適切な範囲で適切に動けるような、 ガードレールの敷き方 を学