KubernetesでMinecraftサーバーを運用すると何が難しいのか Minecraftサーバーは、Dockerを使えば比較的簡単に動かせます。 Docker Composeで環境変数を指定し、ボリュームをマウントして起動すれば、個人サーバーとしては十分に便利です。 しかし、これをKubernetes上で「運用」しようとすると、見える問題が変わります。 Podは再作成されます。Deploymentは再デプロイされます。world dataはPVCに残ります。設定やpluginsは更新されます。終了時に保存処理が失敗すると、worldやpluginsの状態に影響することもあります。 この記事では、MinecraftサーバーをKubernetes/GitOps前提で扱うときに難しくなる点と、その問題意識から作っているDocker imageについて整理します。 Docker Compos

Total: 94% reduction. Roughly 15× smaller. What this actually buys you Disk and registry costs are the obvious win, but they are usually not the biggest one. Faster cold starts on Kubernetes and serverless platforms. Pulling 78MB instead of 1.2GB on a node that does not have the layer cached is the difference between a pod ready in 4 seconds and one that takes 40. Smaller attack surface. The CVE c

タスクのアサイン、プロジェクトのリード、チームのマネジメントなど、『今の自分の実力でできるかわからない役割』を任されることがある。いわゆるストレッチアサインメントである。程度の差はあれ、こういう任され方の方が多いんじゃなかろうか。 言うのは簡単だが、やってみるとたいていつらい。焦りや不安でしんどくなったりする。まあ自分の実力を超えた役割なんだから当たり前なのだけれど、 "型" として抑えておくとよさそうなポイントもある気がするので雑に書き出してみる。 1. 期待と理由を明確にする 『なぜ』『何を』『どこまで』やるべきなのかと、『なぜ』『今』自分が担うのかを明確にすること 期待を明確にしないとずっと何もできていないような気持ちになるし、自分がやる理由を明確にしないと自信を持ちにくくなってしまう 抜擢など誰かにお願いされた場合には、その相手と直接話すのが一番よい 2. 役割を宣言する 自分が担

by Tanner Linsley on May 11, 2026. Status (2026-05-15): All clear ✅ After a three-day full security sweep and hardening pass, we're issuing an official all-clear on TanStack repo and package security. Only the Router/Start repo was affected — 42 monorepo packages, 2 versions each. All were deprecated within the hour and removed by npm shortly after. All other TanStack repos and packages were unaff

前回、GitHub Actionsを使ったCI/CDパイプラインの仕組みを作ったという話を書いたが、今回はPull Request（PR）ごとのプレビュー環境を構築したのでそれについて。 課題 フロントエンドのプレビュー環境はVercelが勝手にやってくれるので何も困らない。PRを作ればプレビューURLが払い出されてそこで確認できる。問題はバックエンドだ。 今回のプロジェクトの場合、PRは機能単位で作成されるのでフロントエンドとバックエンドの両方に修正が入ることが普通にある。フロントだけプレビューできてもバックエンドがdev環境のままだと、API側の変更を含む修正の確認ができない。 しかも同時に複数のPRが開かれてそれぞれレビューされるのもよくある。生成AIを大活用するようにした結果10とか20のタスクを並列で実行させるので、それらがPRとしても同時に並ぶ。このPRたちをそれぞれの変更内容

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? お前がコードを書き始める前に 言っておきたい事がある かなりきびしい話もするが 俺の本音を聞いておけ はじめに これから少しの間、不器用で、偉そうで、厳しいことを言う。けれど最後まで聞いてくれれば、その裏側にあるものもわかってもらえると思う。だから先に謝っておく。生意気な口を、許してほしい。 まず、お前に話す前に、業界を取り巻く空気の話をさせてくれ。ソフトウェア業界には、昔から消えない風潮がある。 「売れたプロダクトはすべて正しい」 「品質? 障害が起きなければそれでいい」 「細かいことはベンダーに丸投げで構わない」 ビジネスの現場で生

アメリカ東部時間の10日午後8時07分（日本は11日午前9時過ぎ）、NASAの有人月探査プロジェクト「アルテミスII」の宇宙船「オリオン」が、月周回ミッションを終えて地球に帰還した。その模様は、NetflixやHBO Maxなど多くのプラットフォームでライブ配信され、NASA公式のYouTubeライブ「NASA’s Artemis II Crew Comes Home」は、一時320万人以上の同時接続を記録した。

HTML in Canvas API は WICG の提案段階にある実験的な API です。現時点では Chrome Canary の chrome://flags/#canvas-draw-element フラグを有効にすることで利用できます。 HTML in Canvas API の使用方法 HTML in Canvas API は以下の 3 つの要素で構成されています。 layoutsubtree 属性 drawElementImage() メソッド paint イベント canvas 要素に layoutsubtree 属性を追加することで、canvas 内に描画したい HTML を定義できます。この段階ではまだ canvas 内には描画されません。 <canvas id="canvas" width="400" height="300" layoutsubtree> <div i

酒井です。ハローでは、プロダクトのローンチ前からAutoReserveの開発に関わっています。 この記事では、Next.jsアプリケーションであるautoreserve.comをVercelからCloudflareに移行し、月額コストを約90%削減した背景と実装の詳細を共有します。 Next.jsは比較的セルフホスティングが難しいフレームワークとして知られており、Vercelへのベンダーロックインが懸念されることがあります。Next.js 16でBuild Adapters APIが導入されるなど、セルフホスティングのハードルは徐々に下がっていますが、実運用では課題が多いのが現状です。 VercelからOpenNext + Cloudflare Workersの構成に本番環境を移行したため、現場でのNext.jsのセルフホスティングの実際について紹介できればと思います。 背景 AutoRe

テックリード @ 株式会社カケハシ 医療SaaSの共通基盤を開発。TypeScriptと関数型プログラミングで堅牢なシステム設計を実践。 はじめに TypeScriptで型を定義する際、interface と type のどちらを使うべきか。これは、多くの開発現場で一度は議論になるテーマではないかと思います。 世の中の多くのドキュメントや記事では、クラスへの implements のしやすさや、interface が持つ「宣言のマージ（Declaration Merging）」の利便性が紹介されることもあり、interface の利用が推奨されるケースもよく見かけます。 しかし、特にサーバサイドアプリケーションや、ある程度規模のあるシステムを開発する上で、私はこの「宣言のマージ」機能が、時として予期せぬ挙動や、場合によってはセキュリティ上のリスクを静かにもたらす要因になると感じています。