はじめに Windows 11上のWSL2にUbuntuなどのLinuxをインストールして開発環境を構築している方は多いと思います(便利ですよね)。 その際、ブラウザの運用方針は人によって分かれるかと思います。 WSL2上のLinux側にブラウザをインストールして完結させる(ただ、日本語という観点だと、Linux側にIMEをインストールするなど、ブラウザインストール以外の手間がかかります) WSL2上のLinux側にはブラウザをインストールせず、Windows側のブラウザをそのまま使う(今回はこちら) 特に後者の場合、CLIツールを使った認証などで少しつまずくポイントがあります。本記事ではその解決策と、さらに便利なWindows連携ツールへの応用を紹介します。 【2026/04/28】追記・大幅修正: いただいたフィードバックを反映しました 本記事の公開後、はてなブックマークにてフィードバ

はじめに マンガアプリチームでAndroidエンジニアをしている id:matsudamper です。この記事ではSelf-hosted runnerにおけるAndroidのキャッシュの設定/運用方法を共有します。 はてなでは以前よりSelf-hosted runnerを運用しています。 developer.hatenastaff.com 2025年からはAndroidアプリ開発においても試験導入を開始しました。運用が安定してきたため、今回はSelf-hosted runnerにおけるGradleキャッシュの知見についてまとめます。 GitHub Actionsキャッシュの課題 GitHub Actions標準のキャッシュは、リポジトリあたり10GBという制限があります。これまでは削除のライフサイクルが遅かったため、Android開発のようなキャッシュサイズが大きいプロジェクトでもなんとか

画像説明, 2026年1月3日にヘリコプターで、ニューヨーク・マンハッタンへ移送されたニコラス・マドゥロ大統領（当時）。現在は市内の拘置所に収監されている

Rate limiting is one of those topics that looks simple until you’re actually doing it in production. Implement a counter with the INCR command and a TTL and away you go. But when you ask questions like “what happens at the boundary?”, “should I use a Valkey/Redis cluster?”, or “why are we getting twice the traffic we expected?”. In this post we’ll go beyond the basic tutorial and cover the five al

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

はじめに Claude Code のプラグインエコシステムが急速に拡大しています。2026 年 4 月時点で、公式マーケットプレイス（claude-plugins-official）には 160 個のプラグインが登録されています。うち 32 個が Anthropic 製、残りはサードパーティ製です。 しかし、数が多すぎて「結局どれを入れればいいの？」と迷う方も多いのではないでしょうか。 この記事では、公式マーケットプレイスの中身を実際に確認した上で、おすすめのプラグインと MCP サーバー系プラグインを紹介します。 プラグインの基本 プラグインとは Claude Code プラグインは、スキル・フック・MCP サーバー・エージェントをパッケージ化して配布する仕組みです。プラグインをインストールするだけで、新しいスラッシュコマンドやツールが使えるようになります。 インストール方法 # 公式マ

はじめに 最近、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 … チーム内でこれらを 「どこから集めて、どこに配っていますか？」 絵にすると、複数の取得元 × 複数のハーネス という多対多の配線を、各チーム／各リポが自前で組んでいるイメージです。 個々のツールが便利になっても、チーム全体としてこ

最新バージョンに合わせ、「install_beforeの話」を、「minimum_release_age(旧: install_before)の話」に修正しました (2026/04/27) データ事業本部の大谷(おおや)です。 以前、下記記事を書きましたが、あれからもmiseを使い続け、気がつけばロックファイルやdepsといったイチオシ機能も増えてきたので、改めてまとめてみました。 miseをまだ使ったことがない方はもちろん、使っているけど基本的な機能しか使えていないという方にも読んでいただければと思います。 miseとは miseは、複数の開発ツールのバージョンを一元管理できるツールです。 Node.js、Python、Terraformなど、プロジェクトやディレクトリごとに異なるバージョンを自動で切り替えてくれます。 pyenv、nodenv、tfenvのような言語・ツールごとのバージ

「歴史もの」の面白さとはなんだろうか？ このジャンルには一つの「逆説」がある。 秦の始皇帝が中華を統一することも、織田信長が本能寺で倒れることも、我々は作品に触れる前から知っている。それでも、歴史上の人物の物語に夢中になり続けるのはなぜなのだろうか？ その答えを探るため、電ファミでは、『信長の野望』シブサワ・コウ氏と『キングダム』原泰久氏に話を聞いてみた。 2026年はシブサワ・コウ氏の活動45周年、原泰久氏の『キングダム』連載20周年というアニバーサリーイヤーを迎える。今回は、その節目を記念した特別企画として、この両者に「歴史」について語っていただく対談が実現した。 おふたりは歴史の面白さは“余白”にあると語る。 歴史の“結果”は決まっていても、その“過程”に無限の可能性を見出せるからだというのだ。 1981年の『川中島の合戦』以来、「能力値」という概念を歴史シミュレーションに持ち込み、

はじめに Claude Code を長く使っていると、CLAUDE.md が太ります。過去の失敗パターン、ワークフロー、ツールの使い方を書き足すたびに、ファイルが肥大化していきます。 気づいたら 2000 行近くまで育ち、どんな小さな作業でも毎セッションで全文を読み込ませていました。タスクに取りかかる前から、過去の注意書きだけでコンテキストの大部分を使っている状態でした。 この記事では、そこから 起動時のコンテキスト消費を約 83% 削減 するまでの試行錯誤を書きます。結論だけなら「rules/ と skills/ に切り分けた」ですが、2 ヶ月かけて行きつ戻りつしながら削った記録の方が実用的なので、そちらを中心に書きます（実測値は後半）。 最初はこうだった（失敗の出発点） 過去の commit ログを掘り返すと、2 月時点で以下のような状態でした。 SuperClaude Framewo

はじめに なぜ内製化を選んだのか プラットフォーマーとしての説明責任 制約の解消とコスト削減 認証基盤を内製で持つリスク 移行の設計 並行稼働による段階的移行 使用するデータソースの統一（SSoT） 認証基盤の内製化、並行稼働をしてみて 認証基盤全体がコントローラブルになった 内製化で得られた価値 並行稼働について 発生した課題 まとめ はじめに こんにちは、ソフトウェアエンジニアの大山です。 enechainではこれまでユーザー認証基盤としてAuth0を利用してきましたが、事業の成長に伴い自社開発の認証基盤（eAuth）へ移行しました。 本記事では、Auth0から内製へ移行する意思決定の背景、移行の設計について紹介します。 なぜ内製化を選んだのか enechainでは元々Auth0を認証基盤として採用していました。 少人数のチームでサービスを立ち上げるフェーズでは認証認可の開発運用コスト

最近のWebサービスでは、画像配信の設計を昔のままにしておくのは難しくなっています。 以前は、画像をアップロードした時に固定サイズのサムネイルをいくつか生成し、それをそのまま配信する形でも大きな問題はありませんでした。しかし今は、高精細なディスプレイを持つスマートフォンが一般的になり、同じ画像でも表示環境に応じて適切なサイズやフォーマットを選ぶ必要があります。さらに、CDNや画像最適化サービスを使えば、元画像から必要な派生画像を動的に生成してキャッシュできるようになりました。こうなると、画像配信は単なるフロントエンドの都合ではなく、サービス全体の設計の一部として考える必要があります。 私が重要だと考えているのは、次の4点です。 画像の綺麗さにおいては、qualityよりも画像サイズの方が重要であること 画像URLの設計はフロントエンドではなくバックエンドが握るべきであること 同じ画像に対し

この独特な国についてつらつら考えてみるとひょっとしてこの何年かで初めてかもしれない．先日，X で間違いなく興味深いことが起きた．X で日本語ツイートが英語に自動翻訳されて，英語圏ユーザーのおすすめに表示されはじめたんだ．他国に比べて，日本の人たちの X 利用率はずっと高い．その理由の大半は，X では本名を明かさずに投稿できるおかげで素性を知られないまま私的な生活について公開で発言できることにある．たいていの人は私生活でこのプラットフォームを利用しているので，もっぱら政治論議に利用されている英語圏の X に比べて，日本語の X はずっと毒性が低い． だから，〔日本語ツイートの〕正気と健全性が流れ込んできて英語圏の X ユーザーが歓喜したのも，ムリはなかった．風変わりな日本のネット文化のいろんな楽しみに喜んだのは，言うまでもない．ぼくの予想では，このハネムーン期は短期しか続かず，やがて英語圏の

Japan is the land of the train. 28 percent of passenger kilometers in Japan are travelled by rail, more than anywhere else in the developed world. France achieves 10 percent, Germany 6.4 percent, and the United States just 0.25 percent. Travel in Japan is over a hundred times more likely to be by rail than travel in the United States. Japan’s vast railway network is divided between dozens of compa

2026年3月に Reporting API というWeb標準 API が Baseline に到達し主要ブラウザで利用可能になりました。 今回はこの便利な Reporting APIを実際に使ってみて、できることやユースケースについて考えてみます。 Reporting API とは Webアプリケーションを運用していると、こんな問題に遭遇したことはないでしょうか。 本番環境でだけ CSP 違反が起きているが、ユーザーからの報告がない限り気づけない 使っている API がいつの間にか非推奨になっていて、将来のブラウザアップデートで壊れるかもしれない ブラウザが勝手に動画の自動再生をブロックしたが、ログに残っていない これらはすべて ブラウザ側で発生するイベント であり、従来のサーバーサイドの監視では捕捉できないものです。 このような場面で役に立つのが、Reporting API です。 R

English description below. 実装することで実際にドローンとして飛行できる，ドローン名刺を作ってみました． 長い間，バグっててあんまりきれいに飛ばなかったのですが息抜きに飛ぶように修正してみました． ESP32をコアとしており，6軸IMUのセンシングとモーターのPID制御します．スマホをプロポとするためにESP32上でWebサーバーを立て，Joystickを動かすとWebSocket通信で入力値をドローンに送信します．また，ドローンのRoll pitch yawの角度値や電圧といったテレメトリをスマホ側で見れるようにしています． イメージとしてはCrazyfileのようなフライトコントローラとフレーム兼用の基板を目指して作っています．リアルで私に会うことがあればお渡しします！ 名刺完成しました！(形だけ) pic.twitter.com/beSWObaRMu— fu

古典的なDDD/クリーンアーキテクチャを採用したJava Webアプリケーションで生じる「モデル増殖」「詰め替え過剰」「ドメインモデルの肥大化」という問題を診断し、Always-Valid LayerとRaohによるデコーダ合成で解消する設計を解説する。本書は無料です。内容が役に立ったと感じたら、本書で使用しているライブラリ Raoh（https://github.com/kawasima/raoh）にスターを付けたり、実際のプロジェクトで試してみたりしていただけると励みになります。