タグ

wata88のブックマーク (11,387)

  • DevOpsとは何だったのか

    SRE NEXT 2026の記事で、maruさん、ゆううきさん、Moriさんとの立ち話から、こんなポストをした、ということを書いた。 https://t.co/mGZbILmQRK にある「開発の時系列上の役割と、技術レイヤーの話が混ざっている」という話、maruさん、yuukiさん、moriさんと立ち話してた時に出た話で、DevOpsもそうだよね、という話になったのだけど、DevOpsも元々は、組織とか部門の話のはずなんだよね — mizzy (@gosukenator) July 13, 2026 整理してブログ記事にしてもいいかもな、たぶん面倒なのでやらない、と書いたけど、songmuさんのこのポストに触発されたこともあって、書くことにした。 小文字のdevopsという考え方、僕は素敵だと思っているのだけど、あまり語られているのを見たことはない — songmu (@songmu)

    DevOpsとは何だったのか
    wata88
    wata88 2026/07/14
  • Vibe Coder vs Software Engineer | Yusuf Aytas

    Java Developer vs. Software Engineer. At the time, I didn’t realize how deeply people had tied their professional identity to Java. My goal was to distinguish between someone defined by a specific language and someone who thinks more broadly about solving problems. The whole discourse started from one premise. Java had become the way. Many developers began thinking from Java outward. The tool beca

    Vibe Coder vs Software Engineer | Yusuf Aytas
    wata88
    wata88 2026/07/14
  • Terraform + Aurora Data APIでDBユーザー作成をIaC化した話 - Timee Product Team Blog

    はじめに こんにちは。プラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 新規プロダクトを立ち上げるとき、インフラ構築って意外とやることが多いですよね。その中でも地味にめんどくさいのがDBユーザーの作成と権限付与。手動でやると「あ、権限つけ忘れた」「このユーザー名スペルミスってない?」みたいなヒヤリハットが発生しがちです。 今回は、この作業をTerraformでIaC化した話を書いていきます。 背景:ボイラープレートでインフラ構築を爆速にしている 弊社ではTerraformのボイラープレートと、それをもとにインフラを構築するためのDevinへの指示プロンプトをセットで管理しているリポジトリがあります。 新規プロダクトのインフラが必要になったら、このリポを使ってDevinにお願いするだけ。数時間もあれば、AWSアカウントの作成、VPC・ECS・Aurora

    Terraform + Aurora Data APIでDBユーザー作成をIaC化した話 - Timee Product Team Blog
    wata88
    wata88 2026/07/14
  • Claude Code on the webを少し使ってわかったこと | DevelopersIO

    クラウド上の隔離環境で Claude Code を実行できる「Claude Code on the web」を試してみたので、セキュリティと開発者体験の観点から気づいたことをまとめます。 ブラウザやモバイルからクラウド上の環境で Claude Code を動かせる Claude Code on the web を少し触ってみたので、そこでわかったことをまとめておきます。ローカルの Claude Code とは前提が違う部分が多く、特にセキュリティ面と開発者体験の面でいくつか気づきがありました。 注記: Claude Code on the web は記事執筆(2026/7/5)時点でリサーチプレビュー段階の機能です。この記事の内容は 2026年6月下旬に試した段階 のものであり、今後の仕様変更で挙動が変わる可能性があります。あらかじめご了承ください。使用したClaude Code のバー

    Claude Code on the webを少し使ってわかったこと | DevelopersIO
    wata88
    wata88 2026/07/13
  • Failure is inevitable: Learning from a large outage, and building for reliability in depth at Datadog | Datadog

    30; }, handleResize() { if (window.innerWidth >= 1024) { this.mobileOpen = false; this.dropdownOpen = 'none'; } }, checkAnnouncementBanner() { const announcementBanner = document.querySelector('.announcement-banner') || document.querySelector('.announcement-banner--large'); if (announcementBanner) { this.hasAnnouncementBanner = true; } else { this.hasAnnouncementBanner = false; } } }" x-init="chec

    Failure is inevitable: Learning from a large outage, and building for reliability in depth at Datadog | Datadog
    wata88
    wata88 2026/07/13
  • 開発者が攻撃対象になった時代に、開発環境とCI/CDについて考えていること

    最近のサプライチェーンアタックを見ていると、これまでとは明らかにフェーズが変わったと感じています。 この記事は、具体的な解決策を提示するというより、最近のサプライチェーン攻撃を見て、自分が開発環境やCI/CDについて考えていることを整理したものです。 以前の攻撃は、どちらかというとコンピュータリテラシーがそこまで高くない人を狙うものが多かったと思います。怪しいメールを開かせる、怪しい添付ファイルを実行させる、偽サイトに認証情報を入力させる、というようなものです。もちろんそれらも深刻ではありますが、少なくとも「気をつける」という個人の努力である程度防げる余地がありました。 しかし最近の攻撃は、明確に開発者を狙っています。 開発者は、一般的な業務利用者よりも強い権限を持っていることが多いです。GitHub token、npm token、SSH key、cloud credentialなどを持

    開発者が攻撃対象になった時代に、開発環境とCI/CDについて考えていること
    wata88
    wata88 2026/07/13
  • 依頼文化をやめる日 EM視点で語るPlatform EngineeringとInclusive SRE / Discussing Platform Engineering and Inclusive SRE from an EM's Perspective

    Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on. →

    依頼文化をやめる日 EM視点で語るPlatform EngineeringとInclusive SRE / Discussing Platform Engineering and Inclusive SRE from an EM's Perspective
    wata88
    wata88 2026/07/12
  • EKS × ARCでつくるGitHub Actions Self-hosted Runner基盤 - Timee Product Team Blog

    こんにちは、タイミーでエンジニアをしている徳富です。 今回は、EKS上にGitHub Actions Self-hosted Runner基盤を構築した話をお届けします。 背景:GitHub Actionsへの移行と、新たに見えてきた課題 2024年10月に公開したCI基盤をGitHub Actionsへ移行した記事で紹介したとおり、 CircleCIからGitHub Actionsへの移行によって、私たちのCI体験は大きく改善しました。 しかし、開発者やテストケースが増え、時間が経つにつれて新たな課題も見えてきました。 実行回数の急増によるコスト高騰 2025年2月頃からDevinをはじめとしたAIエージェントの利用が進み、PRやpushの回数が一気に増加 開発者数の増加も重なり、ワークフロー実行回数が比例して伸びていった GitHub-hosted Runnerは料金や安定性の面である

    EKS × ARCでつくるGitHub Actions Self-hosted Runner基盤 - Timee Product Team Blog
    wata88
    wata88 2026/07/11
  • A return to two-pizza culture

    A return to two-pizza cultureJune 30, 2026 • 1830 words When I joined Amazon, Jeff had an idea: no team should be so large that it couldn’t be fed by two pizzas. In those early days, some teams were so small that one pizza would’ve been enough to get the job done. But it was never really about feeding hungry engineers. We could’ve just as easily said a “six sandwich team”, but sandwiches don’t evo

    A return to two-pizza culture
    wata88
    wata88 2026/07/10
  • https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/

    Here are five levels of increasing autonomy: L0: Manual Execution: All activities are human-driven. Humans must Investigate alerts, Approve any course of action, Actuate the changes, and handle any Multi-Step Resolution required. L1: Assisted: Automation extends to Monitoring and Investigation. The AI agent can analyze data and provide insights or suggestions (AI driven Incident Hypothesis), but a

    wata88
    wata88 2026/07/09
  • Drunk Post: Things I’ve Learned as a Senior Engineer

    A few years ago, a data engineer on r/ExperiencedDevs got drunk and wrote down everything he learned in 10 years of engineering. The original account is deleted, but the post captures something real — the kind of honesty you only get after a few glasses of wine. Preserving it here, typos and all. Contains the language you’d expect from someone who opened with ‘I’m drunk’. I’m drunk and I’ll probab

    Drunk Post: Things I’ve Learned as a Senior Engineer
    wata88
    wata88 2026/07/08
  • ソフトウェア設計における抽象とメタの違い - kawasima

    ソフトウェアは、現実世界をそのまま扱えない。 たとえば、ある町の地図を描くとする。同じ町でも、目的が違えば描き方はまるで変わる。 路線図は、駅と乗り換えさえ分かればよい。だから、実際の線路の曲がりも、駅どうしの距離のばらつきも捨てて、等間隔に並んだ駅とまっすぐな線だけを残す。 道路地図は逆で、道の形や交差点が命になり、電車の路線はいらない。 どちらも、目的に必要なものだけを取り出し、それ以外を捨てている。これが抽象化である。 抽象化とは、難しい言葉に言い換えることではない。現実のものを、目的に合わせて扱いやすい形に切り出すことである。 抽象化は、いきなり型になるわけではない 路線図をソフトウェアにするとする。 最初に書くべきなのは Station という型ではない。まず考えるのは、経路案内から見たときに、鉄道について何が必要かである。 code: (text) 経路案内から見た鉄道 - ど

    ソフトウェア設計における抽象とメタの違い - kawasima
    wata88
    wata88 2026/07/08
  • Software, from First Principles · Faza

    When you use your smartphone or laptop, it is easy to forget the sheer absurdity of the physical reality underneath. Behind that seamless experience lies centuries of effort from physicists, chemists, mathematicians, engineers, programmers, and designers. Inside your device is a slice of literal rock, purified to near perfection and carved with microscopic circuits. By just controlling the flow of

    Software, from First Principles · Faza
    wata88
    wata88 2026/07/08
  • The Engineer in the Half-Space | Yusuf Aytas

    You are reading interview loop feedback. You are going through the notes and it looks like neither a no-go nor a go. You are divided in your head too. Mitch does not seem to score high in system design, algorithms, or anything obvious for that matter. The general consensus is that Mitch does not cut it. Your gut says interview him yourself. So you do. In the end, you call it a hire. Mitch starts t

    The Engineer in the Half-Space | Yusuf Aytas
    wata88
    wata88 2026/07/07
  • Fable時代のAI活用法を、Anthropicの開発者が公開

    記事では、最新のAIエージェントを使いこなすためのテクニックについて、ざっくり理解します。 株式会社ナレッジセンスは、生成AIやRAGを使ったプロダクトを、エンタープライズ企業向けに開発しているスタートアップです。 この記事は何 この記事は、「FableレベルのAIを使いこなすため」のガイド記事[1]について、日語で簡単にまとめたものです。 題 ざっくりサマリー 『A Field Guide to Fable』は、「Fable 5」レベルのAIを使いこなすための、新しいテクニック集です。 「Claude Code」の開発者であるThariq氏によって、2026年7月に公開されました。 Thariq氏によると、「Fable」世代は非常に賢いので、「人間側の指示の品質」がボトルネックになる「初めてのモデル」とのことです。 そしてこの記事では、 「地図は現地ではない」(The map is

    Fable時代のAI活用法を、Anthropicの開発者が公開
    wata88
    wata88 2026/07/07
  • ソフトウェアの見積もり - kawasima

    ソフトウェアの工数見積もりは40年以上にわたって研究されてきた古いテーマで、入門書も実践書も数多い。だが現場で広く流布する「常識」の多くは、一次資料まで遡ると実証根拠が確認できない。確率分布が書ける前提で精度を磨いてきた見積もり研究は、確率分布が原理的に書けない領域から来る大幅超過には対応していない。見積もりが大幅に外れる事例の多くは、見積もり研究が前提としてきた範囲の外側で起きている。 ソフトウェア見積もりの手法はどこに分布しているか 見積もり手法は5系統に分かれる。それぞれの内部にも世代差や流派がある。 エキスパート判断系: 経験者の直感と類推で値を出す手法群。現場で最も多く使われており、Jørgensenの系統的レビューでは形式モデルと精度差が系統的に出ない比較対象として位置づけられる 直感見積もり(gut feel): 単独の経験者が一人で値を出す。最古かつ最普及だが個人バイアスの

    ソフトウェアの見積もり - kawasima
    wata88
    wata88 2026/07/07
  • スタートアップをとりまく思想 - 🐴 (馬)

    追記:よく読まれたので Substack のほうで音声版も公開しました。 [音声版] スタートアップをとりまく思想 - 第1部 シリコンバレー思想史 なぜいま、スタートアップと思想なのか 日で「シリコンバレー」と聞いて思い浮かぶのは、GAFAのような巨大テック企業か、「失敗を恐れず挑戦する起業家精神」といったビジネス書的なイメージではないでしょうか。 しかし、いまアメリカのテック業界で起きていること、そしてシリコンバレーが世界から注目されている理由は、そうしたビジネスの枠を超えて、政治や思想の領域にまで及んでいます。 たとえば、いまシリコンバレーの周辺では、次のようなことが起きています。 データ分析企業が、軍や諜報機関の中枢に入り込む 著名な投資家たちが「民主主義よりCEOモデルによる統治のほうが優れている」と公然と語る AI企業の経営者たちが「人類絶滅のリスク」と「人類史上最大の豊かさ

    スタートアップをとりまく思想 - 🐴 (馬)
    wata88
    wata88 2026/07/06
  • TerraformでGitHubを管理する - 10X Product Blog

    こんにちは、SREの@babarotです。 10Xでは GitHub Organization のリソースを Terraform で管理しています。メンバーの追加・削除、チーム構成、78リポジトリの設定(Repository Ruleset、アクセス権、GitHub Environments)など、可能な限りすべてコードで定義してPull Requestベースで変更・運用しています。 この仕組みで目指しているのは「SREだけが管理する」のではなく「誰でも安全に変更できるセルフサービス」です。メンバーの追加はtfvarsに1行足してPRを出すだけ、リポジトリの設定変更は各チームが自分でPRを出せる、新規リポジトリの作成はGitHub Actionsでリポジトリ名を入力するだけ、といったようなイメージです。ガバナンスとセルフサービスを両立する仕組みを、約2年かけて段階的に構築してきました。 こ

    TerraformでGitHubを管理する - 10X Product Blog
    wata88
    wata88 2026/07/06
  • Claude Code (Opus 4.8) が数分固まる問題、188セッション実測したら原因はAPIでもネットワークでもなかった

    はじめに Claude Code を使っていると、応答が数分間「無音」になる停滞に遭遇することがあります。特にOpus 4.8で頻発していたため、体感や推測ではなくセッションログの実測で原因を特定しました。 この記事で分かること Claude Code の停滞を定量調査する方法(ログの場所と集計の考え方) 「固まって見える」現象の意外な正体 停滞を減らすための、標準機能ベースの実装(コード付き) 対象読者: Claude Code を日常的に使うエンジニア、subagent / hooks をまだ活用していない人。 TL;DR 60秒超の停滞 376件のうち、当の「API待ち」は1件だけ。残り375件は、止まっていたのではなくモデルがトークンを出し続けている「生成中」だった(分類の定義は後述) 正体は、重いturnでthinking + 出力を数千〜数万トークン一気に生成する長考。完了ま

    Claude Code (Opus 4.8) が数分固まる問題、188セッション実測したら原因はAPIでもネットワークでもなかった
    wata88
    wata88 2026/07/06
  • etcd を奇数台にする理由は「スプリットブレイン対策」なのか - 理念と共に、最も困難で狂気の選択を考え続けて諦めない

    etcd の構成について調べると、「スプリットブレインを防ぐために奇数台にする」と説明されることがあります。 この説明は、運用上の結論だけを短く言うなら理解できます。 etcd では奇数台構成が推奨されます。 また、etcd が使う Raft は、矛盾する状態が複数の分断側でコミットされることを避けるように設計されています。 そのため、入門記事や運用記事で「スプリットブレインを避けるために奇数台にする」と短く説明されること自体は自然です。 ただし、この説明をそのまま Raft の仕組みとして読むと、奇数台構成と quorum の役割を取り違えやすくなります。 この記事は、既存の記事を否定するためのものではありません。 むしろ、既存の記事が伝えている「etcd では quorum が重要であり、奇数台構成が推奨される」という実用上の結論を前提に、その理由を Raft の動作に沿って少し精密化

    etcd を奇数台にする理由は「スプリットブレイン対策」なのか - 理念と共に、最も困難で狂気の選択を考え続けて諦めない
    wata88
    wata88 2026/07/06