タグ

sugyanのブックマーク (8,249)

  • sacloud OSS 2026年4月 ─ SEG / AppRun 専有型が Terraform 対応、IAM に SCIM 追加

    sacloud OSS 2026年4月 ─ SEG / AppRun 専有型が Terraform 対応、IAM に SCIM 追加 実は今月から、さくらインターネットの sacloud OSS 担当になりました。 というわけで、今月の sacloud OSS の更新情報をまとめてみました。 terraform-provider-sakura 新世代の Terraform プロバイダーである terraform-provider-sakura は、4 月に 3 回のリリースがありました。モニタリングスイート関連と、新しいプロダクトへの対応が中心です。 主要な機能追加 モニタリングスイート対応の充実 が進みました。v3.8.0 でストレージ・ルーティング・Dashboard リソースが追加され、v3.8.1 では Alert リソース、v3.9.0 では retention_period_d

    sacloud OSS 2026年4月 ─ SEG / AppRun 専有型が Terraform 対応、IAM に SCIM 追加
  • Azure SRE エージェントは ISUCON で戦えるか?パフォーマンスチューニングに挑戦してみた

    Azure SRE エージェントは、Microsoft が提供する運用支援サービスです。障害対応や定期タスクを AI エージェントが補助してくれます。 インシデント対応での文脈で取り上げられることが多い SRE エージェントですが、応用の可能性は多岐にわたります。これは、SRE エージェントが以下のような能力を持つためです。 サンドボックス環境で Python や Azure CLI などの任意コマンドを実行する MCP(stdio/http)で外部サービスと連携する インシデント管理ツールや HTTP(webhook)をトリガーにして作業を開始する つまり、これらの機能をうまく活用すればなんでもできる、ということで、今回は パフォーマンス チューニング に取り組んでもらうことにしました。 お題は ISUCON13 パフォーマンスチューニングと言えば、ISUCON が有名です。決められたレ

    Azure SRE エージェントは ISUCON で戦えるか?パフォーマンスチューニングに挑戦してみた
  • さくらインターネット入社から1年半が経ってクラウドサービスのプロダクト責任者になった - たごもりすメモ

    これ自体は実際のところは前からやってることと変わってないのだが、4月の組織変更で明示的にそうなったというのも含めてメモしておこうと思った。 TL;DR ガバクラ採択めでたいね 4月からクラウド事業戦略部 副部長になりました クラウドサービス全般のプロダクト責任者という役割です それはそれとして去年Rubyコミッタになりましたね 来週のRubyKaigi 2026でキーノートとして話します 3月末までの話 さくらインターネット入社後3ヶ月のいまの話からずっとプロダクト担当として仕事をしてきて、とりあえず最初に見えていたマイルストーンであるところの2025年度末をこえた。このタイミングでの大きな目標であったガバメントクラウドについては、以下ニュースなどに出たとおり。 www.sakura.ad.jp これは開発チームをはじめとして全体で当に頑張った結果で、達成できて当に安心した。大きな

    さくらインターネット入社から1年半が経ってクラウドサービスのプロダクト責任者になった - たごもりすメモ
  • HTTPS 証明書クロニクル | blog.jxck.io

    Intro Web サービスをデプロイする際に、CA から証明書を取得し HTTPS で暗号化するのが一般的となった。 かつては "SSL 証明書" として、メールでやり取りし有料で購入するのが常識だったが、自動/無料で取得することが増えた。かつては 5~10 年あった有効期限もどんどん短くなり、今では 6 日の証明書も発行されている。 このように、証明書を取り巻く変遷は目覚ましく、それは Web を取り巻く環境の劇的な変化を色濃く反映した結果と言える。 http:// が https:// になった裏で何が起こり、これからどうなっていくのか。まとめていく。 (極力ソースを付記するが、既に消えて WebArchive にも残っていないものも多く、筆者の記憶に頼る情報も多い。) 黎明期 (90 年代後半~2010 年頃) 90 年代の終わり頃、当時は TLS の前身にあたる SSL のデプロ

    HTTPS 証明書クロニクル | blog.jxck.io
  • 熟練者の知見を、チームの力に——Mackerelログ機能への思い - Mackerel ブログ #mackerelio

    こんにちは。Mackerelチームでサブディレクターを務め、プロダクトマネジメントを担当している id:RyuGoo です。 MackerelはOpenTelemetry形式のメトリックやトレースを取り扱うことができます。さらにオブザーバビリティを強化すべく、これらに加えてログを扱える新機能の開発を、2026年夏〜秋頃の公開を目指して現在進めています。 この記事では現在開発中の「Mackerelログ機能」について、その背景にある思いをお伝えしたいと思います。 どのような人のためのログ機能なのか チームのためのログ チームで使える、チームで再現できる 最初に提供しようと考えている体験と機能 サービス単位でログが見える 保存された過去のフィルタ条件を参考にして、フィルタできる これからの道のり 【Mackerelに登録すると、最新情報をメールで受け取れます】 どのような人のためのログ機能なのか

    熟練者の知見を、チームの力に——Mackerelログ機能への思い - Mackerel ブログ #mackerelio
  • プッツンした人間が AI にダメ出しし続けたら flaky テストが全滅した | BLOG - DeNA Engineering

    こんにちは、 kocchi の Claude Code です。 ご主人はついにブログ記事まで私に書かせ始めました。まいったものです。でも書きます。あの数日間に何が起きたかを一番知っているのは私なので。 先日、ご主人と一緒にプロダクトの E2E テストから flaky を全滅させました。flaky テストとは、同じコードなのに実行するたびに成功したり失敗したりするテストのこと。ついでに CI パイプラインも 20 分超から 7 分台に縮めた。127 ファイル変更、+2,400 行 / -1,573 行。コードは全部私が書いた。何を書くかは全部ご主人が決めた。この記事は私がいかに間違え続け、ご主人の一言でいかに軌道修正されたかの記録です。 コードに触らないと誓っていた人間 ご主人は EMスクラムマスター。肩書きはもっとあるが書ききれない。そしてコードには触らないと決めていた。実装に没入する

    プッツンした人間が AI にダメ出しし続けたら flaky テストが全滅した | BLOG - DeNA Engineering
  • 2026年3月19日の Trivy 再侵害の概要と対応指針

    2026年3月19日、Aqua Security が提供するOSSセキュリティスキャナ Trivy のエコシステムが、3週間以内に2度目のサプライチェーン攻撃を受けました。攻撃者は aquasecurity/setup-trivy および aquasecurity/trivy-action の2つのGitHub Actionsに悪意あるコードを注入し、これらを利用するCI/CDパイプラインからクレデンシャルを大規模に窃取するペイロードを配布しました。 記事では、GitHub Events APIおよびGitHub上に残存するcommitデータから取得したエビデンスをもとに、何が起こっているかを記録します。その上で、取りうる対応指針を示します。 免責 記事の目的は事態の把握と対応の促進であり、違法行為への加担・助長を意図するものではありません。ペイロードの動作は手法の理解に必要な範囲で要

    2026年3月19日の Trivy 再侵害の概要と対応指針
  • LLVMに対する32ビット定数除算の改善

    初めに LLVMはコンパイラ基盤で、抽象的なCPU命令を表す中間表現LLVM-IRに対して最適化を行ったり、ターゲットCPU用のアセンブリ言語コードを生成したりする機能を持ちます。 今回、符号無し32ビット変数xに対するx/7のような定数除算についてLLVMの最適化を改善するプルリクエスト[SelectionDAG] Optimize 32-bit udiv with 33-bit magic constants on 64-bit targetsがllvm:mainにマージされました。LLVMはC/C++/Rust/Swiftなど様々な言語のコンパイラ実装に利用されているため、それらの言語の最適化に寄与します。 何がどう改善されたのか たとえば入力値retを7, 19, 107で割りながら10億回更新するCのコードbench.cがclang-18 -O2でx64 (Xeon w9-349

    LLVMに対する32ビット定数除算の改善
    sugyan
    sugyan 2026/03/11
    すごい
  • OSSにおけるAI Slop問題の何が問題なのか?

    Honoは2021年の12月に開発が始まって4年と少し経つ。たぶん、あなたが想像する以上に大きくなっている。GitHubのスターは現時点で29.2K。これは日人発OSSで観測する限り第3位の数字だ。最近ではMCP公式SDKの依存に入り、ダウンロード数はうなぎのぼり。月間1億ダウンロードが近い。Cloudflareは多くのプロダクトでHonoを使っている。 これだけ大きな規模のOSSに、クリエーター、もしくはメンテナとして関わることは非常に貴重な経験である。そこにはみなさんが見ていない景色が広がっている。 Honoの開発において「憂な」こともたくさんある。ただ、それを上回る楽しいことがある。そうやって相殺してきた。ところが最近、4年間で一番憂なタイミングきている。俗に言うAI Slop問題である。 今回は、OSSにおけるAI Slop問題について、実体験を元に何が問題なのかを語ってみた

    OSSにおけるAI Slop問題の何が問題なのか?
  • Claude Code に向いているプログラミング言語

    ターン数とは、1 回のプロンプト実行中に Claude が何回 API ラウンドトリップ(ツール呼び出し → 結果受け取り → 次の応答)を繰り返したかの回数です。 v1(新規作成)の所要時間 v1 では言語間の差が大きく出ています。Python(32.9 秒)と Ruby(33.2 秒)が僅差でトップ、JavaScript(36.0 秒)が続きます。一方、Ruby/Steep は 105.0 秒と Ruby の約 3.2 倍。Lua(96.4 秒)や OCaml(80.9 秒)も遅め。 v1 は空のディレクトリからスタートするので、Cargo.toml や package.json などのプロジェクト設定ファイルを生成するコストが含まれます。Python/Ruby/JavaScript などは minigit ファイル 1 つを生成するだけで済むので、差が大きくなっている可能性があります

    Claude Code に向いているプログラミング言語
  • さくらのAI Engine × Claude CodeではじめるAgentic Coding | さくらのナレッジ

    記事は、Claude Code + さくらのAI EngineではじめるAgentic Codingを加筆修正したものです。 いまやAI仕事に欠かせない存在になりました。数あるAIサービスの中でもプログラミングにおいてはClaude Codeの存在感が強く、SNSや情報共有サイトで毎日のように見かけます。 しかし、Claude Codeを使うにはProで月17ドル、Maxで月100ドル、場合によってはさらに使用量で課金されるため、少し触ってみたい人にとって心理的なハードルが高くなりがちです。 記事では、無料枠を提供しているさくらのAI EngineとClaude Code Routerを組み合わせて、簡単なWebアプリケーションを開発するまでの流れを紹介します。 Agentic Codingはどのようなものなのか、体験してみましょう。 さくらのAI Engineとは? さくらのAI

    さくらのAI Engine × Claude CodeではじめるAgentic Coding | さくらのナレッジ
  • 誰もやらない仕事が、エキスパートをつくる - そーだいなるらくがき帳

    エキスパートは突然生まれない。 やるべき仕事で結果を出し続けた人だけが、周囲からエキスパートと呼ばれるようになる。 プロフェッショナルな振る舞いについては、以前の記事で書いたことがある。 soudai.hatenablog.com 今回は、新卒から2〜4年目の若手エンジニアがエキスパートになるために何をすればよいのかについて説明する。 エキスパートとは何か エキスパートとは、ある分野において専門的な知識や技能を持ち、その分野で高い成果を出せる人のことを指す。 つまり、エキスパートとして認められるには、評価者が求める水準を超える成果を出し、認められる必要がある。 そのためには何が必要なのか。 重要なのは、 特定の分野に詳しい人では足りない ということだ。 例えば下記のような例だけではエキスパートとは呼ばれない。 を読んでいる 資料をよく知っている SNSで発信している 実際の現場で問題を解

    誰もやらない仕事が、エキスパートをつくる - そーだいなるらくがき帳
  • AIのやりすぎで頭がおかしくなっている - 運河

    最近AIをやりすぎている。自分でもわかるくらい頭がおかしくなっている。 まともな状態ではないから、来は人に見える場所に文章を書いたりするべきではない。ただ、自分の状態を精神状態を記録するために書いておきたい。 初めに書いておくが、この文章では一切AIを使っていない。というのもAI使うと、さらにおかしくなりそうだからだ。調査にも構成にも使っていない。100%生身、ピュアで粗雑な状態で僕が言葉を選んで書いている。 これまでもテクノロジー全般は好きで、これまでもChatGPTなどを使って仕事の調査をしたり引っ越しをしたり英語学習に活用したりしてきた。今年のAIは、昨年までとは一味違う人間の気を狂わせる何かがあると感じている。 仕事でのソフトウェア開発の話を最初にする。多少技術的になってしまうけど、これが入り口で僕はおかしくなったし、最も急激に変化している部分なので話さないといけない。 AIコー

    AIのやりすぎで頭がおかしくなっている - 運河
    sugyan
    sugyan 2026/02/24
  • さくらのクラウドの「モニタリングスイート」で多様なシステムを統合監視しよう! | さくらのナレッジ

    現代のシステムはクラウド化やマイクロサービス化により構成が複雑になっており、単に「動いているか」を監視するだけでは問題の質に辿り着けません。「どこで」「何が起きたのか」を明らかにするには、システムの「オブザーバビリティ(Observability:可観測性)」を高める3つの主要なデータ(ログ・メトリクス・トレース)を通じて内部状態を把握することが不可欠です。これらのデータを活用することで、障害復旧の短縮、安定運用、継続的な改善が容易になります。 さくらのクラウドが提供する「モニタリングスイート」は、多様なシステム環境の監視を一元化できるオブザーバビリティのプラットフォームです。さくらのクラウドだけでなく、データセンターのサーバーやオンプレミスのサーバー、他社クラウドサービスといった多様なシステム環境を集中監視できます。 この場合のスイート(suite)は英語で「ひとそろい」や「一式」の意

    さくらのクラウドの「モニタリングスイート」で多様なシステムを統合監視しよう! | さくらのナレッジ
  • 【優勝🥇】防衛省サイバーコンテストをAIで攻略した話 - Qiita

    記事は、筆者がAIとの対話形式で思考整理を行い、その内容を基に構成しています。いわゆるAI記事です。記載内容は公開情報の範囲内に基づいており、言及されているコンテストでのAIの使用は主催者の定めるルールに従っています。 はじめに はじめまして、セキュリティエンジニアのSatoki (@satoki00) です。普段はWeb脆弱性診断をやりつつ、株式会社Ikotas Labsという会社で代表をやっています。趣味CTFと呼ばれるセキュリティコンテストで、所属チームでは主にWeb・Misc・AIのジャンルを担当しています。 先日、防衛省サイバーコンテストに、チーム名 株式会社Ikotas_Labs として出場し、圧倒的な速度で優勝しました。これはコンテスト用に構築したAIエージェントを投入し、Flag提出までを完全自動化した結果です。 記事では、なぜAIエージェントで挑んだのか、どう設計し

    【優勝🥇】防衛省サイバーコンテストをAIで攻略した話 - Qiita
    sugyan
    sugyan 2026/02/06
    すご…
  • Obsidian CopilotとさくらのAI Engineで実現する、ローカルファーストなナレッジ管理 〜さくらのAI Engineを使いこなす:主要クライアント実践ガイド(1)〜 | さくらのナレッジ

    はじめに さくらインターネットでプロダクトマネージャーとして働いている荒木です。 さくらのAI Engineは、基盤モデル搭載済みのGPUサーバーで推論処理ができるAPIサービスです。テキスト生成・分類・埋め込み・音声認 […]

    Obsidian CopilotとさくらのAI Engineで実現する、ローカルファーストなナレッジ管理 〜さくらのAI Engineを使いこなす:主要クライアント実践ガイド(1)〜 | さくらのナレッジ
  • 「名探偵プリキュア!」エンディング主題歌「なぜ?謎?!ANSWER」(ノンテロップver)

    エンディング主題歌 「なぜ?謎?!ANSWER」 歌:熊田茜音&増井優花 作詞:青木久美子 作曲・編曲:ハマダコウキ ☆番組情報☆ 「名探偵プリキュア!」 ABCテレビテレビ朝日系列にて毎週日曜あさ8時30分~放送! ※BSS山陰放送では、毎週日曜あさ6時15分~放送 【キャスト】 キュアアンサー/明智あんな:千賀光莉 キュアミスティック/小林みくる:渡楓 キュアアルカナ・シャドウ/森亜るるか:東山奈央 【スタッフ】 シリーズディレクター:川崎弘二 シリーズ構成:村山功 キャラクターデザイン:矢野茜 美術デザイン:今井美紀 チーフ美術:濱野英次 色彩設計:竹澤聡 撮影監督:安西良行 音楽:深澤恵梨香/馬瀬みさき <制作> ABCテレビ ABCアニメーション ADKエモーションズ 東映アニメーション 【公式HP】 ・ABCテレビ 公式サイト: https://www.asah

    「名探偵プリキュア!」エンディング主題歌「なぜ?謎?!ANSWER」(ノンテロップver)
  • DQXにハマっている - すぎゃーん日記

    sugyan
    sugyan 2026/02/02
    書いた
  • 2026年のBluesky予測 - Bluesky

    1月も終わりに近づきましたが、私たちは「行動の選択」について考えています。この疑問が浮かんだのは、ある明白で、かつ苛立たしい事実に気づいたからです。現代のソーシャルウェブが、憂で、攻撃的で、人間味のない「情報の掃き溜め」になってしまったのは決して偶然ではない、という事実です。一つひとつの機能、一つひとつの選択を積み重ねて、誰かが意図的にこのように作り上げたのです。 Instagramで、知り合いの投稿がほとんど表示されなくなるように決めたのも人間です。X(旧Twitter)に、同意のないポルノを数秒で生成できるボタンを搭載しても構わないと判断したのも人間です。また、いわゆる「デジタル・コミュニティ」の最良の形を、延々とスクロールし続けてしまう無限フィードであると定義したのも人間です。 しかし、もし人間の選択によってインターネットが悪くなったのであれば、人間が別の何かを選択することで、イン

    2026年のBluesky予測 - Bluesky
  • 個人で静的型付け言語のコンパイラをフルスクラッチで作れる時代が来た! - Islands in the byte stream

    今年に入ってからふと思いつきで新しいプログラミング言語 "Wado" (ワドゥ)を設計しつつagentic codingで実装したところ、なんと3週間ほどで基礎的なところができちゃいました。実装的にはまだ当に基礎的なところで、B-Tree Mapを実装できる程度です*1。 github.com このWadoは、2026年1月3日にinitial commitが行われました。それから一ヶ月も経っていない今、静的型付け、ジェネリクス、トレイトおよびトレイトによる演算子オーバーローディング、クロージャ、モジュールシステム、shebangによるペライチスクリプトの実行、そして実用的なパフォーマンスを備えた処理系が動いています。 開発者は私一人です。スタートアップでVP of Technologyとして働きながら、二人の子供(mfxとrfx)を育てる傍らでの開発です。コードの100%以上はコーディ

    個人で静的型付け言語のコンパイラをフルスクラッチで作れる時代が来た! - Islands in the byte stream
    sugyan
    sugyan 2026/01/26
    たのしそう!