明日、2025/7/31付で株式会社はてなを退職します。本日が最終出社でした。社内に向けたご挨拶は社内エントリとして残したので、この記事はここ最近対面することがなかった仲の良い方向け、あるいは個人の日記です。間の悪いことに先週末ごろ新型コロナウイルスの症状が顕在化したので、最終出社といいつつ自宅から各種手続きを終え、このエントリを書いています。 2014年のはてなサマーインターンに参加し、2015年からアルバイト、2016年に新卒入社したので正社員としては9年強、バイトを含めると10年強と長い間働いていました。 バイトを含めた最初の5年はブログのユーザさん向け機能開発やビジネス向けの改修を担当し、残りの5年はマンガビューワの開発・運用をやっていました。某サービスのユーザデータを他社システムからすべて移行してくるチームのリード*1が一番の大仕事で、終盤はサービスの基盤部分の運用・改善を担当す
Keycloak が ver17 より WildFly から Quarkus へ移行しているが、 Quarkus ベースのバージョンでクラスタ構成を検証している情報が少ないため、 今回 Keycloak を AWS のコンテナ環境でクラスタ構成で動作させてみる。 ※本記事は、Keycloakのバージョンアップに伴い、「Keycloakを冗長構成で動かしてみる」と「インフラ管理不要なコンテナ環境のAWS FargateでKeycloakを動かしてみる」の記事を最新化したものです。 本記事でやること Keycloak の AWS 向けカスタム Docker イメージを ECR にプッシュする。 AWS 向けに S3_PING を用いたクラスタ構成設定を追加 コンテナビルド ECR でプライベートリポジトリを作成 コンテナを ECR リポジトリへプッシュ Fatgate を用いた Keycloa
こんにちは！SREグループの桝谷@hnchn87です。 先日7月11-12日に開催された『SRE NEXT 2025』にPlatinumスポンサーとしてブース出展してきました。この記事では、当日ブースで実施した「SREエンジニア実態調査」のアンケート結果と、「あなたが体験した"ヒヤリハット"集」の集計結果を大公開します！ 当日、アンケートやヒヤリハット事例の投稿にご協力いただいた皆様、本当にありがとうございました！！ アンケートの概要 今回のSRE NEXT 2025では、以下の2つの企画を実施しました： SREエンジニア実態調査: SREエンジニアの皆様の技術スタック、組織体制、関心事などを調査 ヒヤリハット集: SRE現場で経験した「ヒヤリハット」な体験談を収集 どちらも多くの方にご参加いただき、SRE業界の現状を把握できる貴重なデータが集まりました！ 1. SREエンジニア実態調査の
日本時間2025年7月18日、ECSのデプロイが大幅に強化されたので、試しつつ情報を整理してみました。単純にBlue/Greenがネイティブで可能になっただけではありませんでした。 先に要点 CodeDeployを使わずとも、ネイティブでBlue/Greenデプロイが可能になった lifecycle hooksによって、様々なタイミングでLambdaによる検証も可能 Test listener/listener ruleによって、エンドユーザ影響ゼロで本番環境での事前検証も可能（Dark Canary） Service ConnectでもB/Gが可能に デプロイコントローラをサービス作成後に変更可能に CodeDeployによるB/Gは今後避けた方がよさそう。移行ガイドもあり アップデートの概要 CodeDeployを用いずともECSの組み込み機能としてBlue/Greenデプロイが可能に
Amazon ECS enables built-in blue/green deployments - AWS
Amazon Elastic Container Service (Amazon ECS) announces new features that make software updates for your containerized applications safer, allowing you to ship software faster and with high confidence, without needing to build custom deployment tooling. Amazon ECS now supports a built-in blue/green deployment strategy and deployment lifecycle hooks that allow you to test new application versions i
こんにちは。ruby-devチームの遠藤（@mametter）です。 次期バージョンのRubyでは、pathnameがRuby本体組み込みとなり、require "pathname"なしで利用可能になる予定です。 Rubyで書き捨てスクリプトを書いてる自分のような人は地味にうれしいかもしれません。 Feature #17473: Make Pathname to embedded class of Ruby - Ruby - Ruby Issue Tracking System さて、pathnameの組み込みがマージされた直後、非常に興味深いバグが発生しました。 今回はそのデバッグの経緯を技術ブログとして共有したいと思います。 問題の発生：特定環境でのみ失敗するテスト コミッタのhsbtさんがpathnameの組み込み化をマージした後、なぜかRubyのCIの一部が落ちるようになりました。
はじめに 背景 エラー情報の管理方法 案1: gRPCメソッドのresponseにエラー用のフィールドを追加する Pros Cons 案2: metadataにエラーを追加する Pros Cons 案3: protoにコメント形式でエラー情報を追加 Pros Cons 選定された方法 チェックツールについて まとめ はじめに こんにちは、ソフトウェアエンジニアの大山です。 enechainでは、複数プロダクトから共通で利用される機能はマイクロサービスとして独立させており、それぞれがgRPC APIを提供しています。 Protocol Buffersの一元管理 ではそれらAPIの定義を一元管理する仕組みについて紹介しました。 共通系のサービスが自由なフォーマットで実装されていくとクライアント側の認知負荷が高まるため、正常系の処理だけでなく異常系の処理に関しても詳細なフォーマットが定められてい
アプリケーションのパフォーマンスを向上：Amazon CloudFront が HTTPS レコードを有効化 | Amazon Web Services
Amazon Web Services ブログ アプリケーションのパフォーマンスを向上：Amazon CloudFront が HTTPS レコードを有効化 本稿は、2025 年 7 月 2 日に公開された “Boost application performance: Amazon CloudFront enables HTTPS record” を翻訳したものです。 Amazon CloudFront は、グローバルネットワーク全体で Amazon Route 53 の HTTPS DNS エイリアスレコードをサポートすることを発表しました。この機能でクライアントは、その後の接続ステップではなく、最初の DNS 解決フェーズで最適な HTTP プロトコルを見つけることができます。これにより、ユーザーはパフォーマンスとセキュリティを向上させると同時に、運用コストを削減できます。 この記事
事前設定されたdevcontainerセットアップは、VS CodeのRemote - Containers拡張機能や類似のツールとシームレスに動作します。 コンテナの強化されたセキュリティ対策（分離とファイアウォールルール）により、claude --dangerously-skip-permissionsを実行して無人操作のための権限プロンプトをバイパスできます。ニーズに合わせてカスタマイズできるリファレンス実装を含めています。 devcontainerは実質的な保護を提供しますが、すべての攻撃に対して完全に免疫のあるシステムはありません。常に適切なセキュリティプラクティスを維持し、Claudeの活動を監視してください。 主な機能 本番対応のNode.js: 必須の開発依存関係を含むNode.js 20上に構築 設計によるセキュリティ: 必要なサービスのみへのネットワークアクセスを制限す
macOS で Touch ID を使った「人間の確認」ができるシンプルな CLI ツール confirm-pam を作りました。 azu/confirm-pam: CLI tool for biometric authentication confirmation prompts このツールを使うことで、AI Agent が任意のコマンドやスクリプトの実行する前に、Touch ID による生体認証を要求できます。 コマンドラインから実行される処理に対して、人間による明示的な確認ステップを追加する仕組みを提供します。 confirm-pam とは confirm-pam は、macOS の Touch ID を使った生体認証による確認プロンプトを提供する CLI ツールです。 主な特徴 Touch ID 認証をサポート 認証ダイアログに任意のメッセージを表示 0（成功）、1（失敗）、2（エ
#共有する 開発生産性カンファレンス https://dev-productivity-con.findy-code.io/2025 2025/07/03 Keynote: 開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった はじめに：25年ぶりの来日と生産性への問題意識 25年ぶりに来日しました。かつて『エクストリーム・プログラミング（XP）』の本が日本の書店に平積みされているのを見て、とても嬉しかったことを覚えています。（サインしようとして店員に怪しまれ、逃げたという面白いエピソードもありましたが。） 今日は「開発生産性」について話します。より多く、より早く作れば生産性は向上するのでしょうか？ドイツには「物事を良くしようとして、かえって悪化する」という趣旨の言葉がありますが、まさにそれが生産性の議論で起きています。特にAIの登場は、この問題をさらに悪化
STORES でエンジニアをしている片桐です。 STORES では店舗運営に関するさまざまなプロダクトを提供しています。これらのプロダクトは元々別の会社で運営されてきた完全に異なるプロダクト群で、アカウント体系から全く異なるシステムになっていました。近年はこれらのシステムを本格的に統合する取り組みを進めてきており、その中で統合のためにいくつかのシステムが新たに作成されてきました。 ある程度統合が進み、うまくいったところ・いかなかったところが見えてきた中で、これまでに作ったシステムの技術選定・システムの役割に対する課題感が見えてきました。 現在弊社ではこの課題を解決していくプロジェクトを進めています。その中の1つで、Goで作られたシステムをRuby on Railsで作られたシステムに移植する作業を行なっているので、今回はそれについて紹介させていただきます。 移植元のシステムの課題 今回別シ
こんにちは。Mackerelチームに所属しているエンジニアの id:lufiabb です。 Webアプリケーションが意図しない挙動をしたとき、ログを使って調査される方は少なくないと思います。お使いになっているログサービスの仕様にも依りますが、伝統的にはログは時間の経過に沿って並ぶので、特定のリクエストだけ調べたい場合やサービスの境界を超える場合には、調べる側で大量のログから必要な情報を抽出するためになんらかの工夫が必要になるでしょう。また、複数のサービスが協調して稼働している場合には、何がどのように連携しているのかといったシステム構成も、読む側で把握しておく必要があります。ログの1行がどこで出力されたものなのかを知るには、該当バージョンのソースコードを追う必要さえあるかもしれません。 このように、ログを出力するのは簡単だけれども、読むためには意外と多くの背景知識が必要です。なので個人的には
こんにちは。@makicamel（川原万季）と@coe401_（塩井美咲）です。 2025年4月16〜18日の3日間、愛媛県は松山市に1,500人を超えるRubyistが集い、RubyKaigi 2025が開催されました。本当に楽しかったですね。 そんなKaigiの興奮覚めやらぬ翌日翌々日、つまりDay 4 & 5にわたしたちは愛媛のお隣、高知県内にある沢田マンションへ行ってきました。貴重な経験だったので、SmartHR Tech Blogのスペースをお借りして、沢田マンションツアーをレポートしたいと思います。 目次 目次 沢田マンションとは？ RubyKaigi 2023で出会った「無名の質」 コラム：空間の継承とRubyKaigiの原点、沢田マンションの今をめぐって〜その①（@eto） TRICK RubyKaigiの原点 プログラム委員長と運営委員長の分離 全員招待講演の第1回 Ru
支出管理開発本部で事業部横断テックリードをしている @ogugu です。 広く複雑で大規模になりつつある支出管理のアーキテクチャについて、以下の連載形式でご紹介していきます。 OpenAPI ではなく TypeSpec を読み書きするスキーマ駆動開発 (本記事) ソフトウェアアーキテクチャに基づいた自動テスト戦略と実装ガイドライン 支出管理におけるマイクロサービスアーキテクチャの知見 今回は、自動テストの戦略をご紹介します。 社内展開した内容を可能な限りそのままご紹介しますので、文体についてはご了承ください。 目的 概略図 テストレイヤー毎の使い分け Unit Test Integration Test Backend E2E Browser E2E アプリケーションレイヤー毎の戦略 フロントエンド Page Component (画面レベルのコンポーネント) Page 以外の Compo
A fully-managed, auto-scaling cloud service designed for your dynamic workloads.
はじめに こんにちは、ニコニコ生放送 バックエンド開発マネージャーの yanagi です。 2024 年 6 月 8 日、ドワンゴはランサムウェアを含む大規模なサイバー攻撃を受け、「ニコニコ」全サービスの停止を余儀なくされました。もちろんニコニコ生放送も例外ではなく、2024 年 8 月 5 日にサービスを再開するまでの約 2 ヶ月もの間、その影響を受ける形となりました。 この記事は、サイバー攻撃を受けたニコニコ生放送がサービスを再開するまでの道のりを記録したものです。 今回の復旧作業から学んだ教訓は、「日頃の実践・鍛錬が重要」ということです。今回のような状況においても、物事への取り組み方は日頃からニコニコ生放送内で実践されているものと大きく変わりありませんでした。 ありのままに言えば、ニコニコ生放送には今回のようなできごとを想定した訓練や対応体制は備わっていませんでした。今までに経験した
忙しい人向けの情報 ecspresso 2.5 から ecspresso deploy --wait-until=deployed オプションを使うとデプロイ短縮できるようになったよ！！ 自分たちの環境では最大で 3 分程度短くなる DRAINING 完了を待つか否かの差か。サービスの安定したリリースに問題なし estie では ecspresso を使っています こんにちは、 sugitak です。 estie で SRE をしております。 estie では ECS + Aurora RDS を基本の環境としていまして、その ECS の deploy にあたっては kayac/ecspresso を使用しています。 ECS のデプロイ時間 私、デプロイを短縮するのが好きです。趣味といえるかもしれません。 私たちのデプロイ時間の大部分は Next や Rust の build, npm i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
