タグ

razokuloverのブックマーク (34,605)

  • 役割と責任の区別をつける

    みなさんこんにちは。@ryuzeeです。 2026年3月4日に新刊の訳書『Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方』がオライリー・ジャパンから発売になりましたのでよろしくお願いします。 記事は、先日Xに書いた記事の転載です。 先日Xで「スクラムマスターが何もしない。ふざけんな(意訳)」という話を見かけました。 確かに、何もしていないのであれば不要なんじゃないか、という気もします。 ただ、この話はいくつか論点が混ざっていそうなので、分けて見ていきましょう。 役割と責任は違うスクラムマスターの話なので、見るべきはスクラムガイドです。とりあえず擦り切れるくらい読んでください。 スクラムガイド2020年版では、今回の話に関係がある大きな改訂が行われました。 それが「責任(Accountability)」です。 スクラムガイド2017まではプロダクトオーナー、開発

    役割と責任の区別をつける
  • Tailscaleやめたい - まいの雑記帳

    # はじめにTailscaleはネットワークの知識がない人が使うものだと思っていて、内心ずっと冷笑しているのですが、悪い噂をあまり聞かないので当に悲しいです。用途に応じて使い分けろという話なんだろうとは思います。思いますが、他人の環境にアクセスしたいときに「まずTailscaleを入れて〜」みたいなことを言われると当に嫌な気持ちになります。 ちなみに私も使っているので、あまり人のことを言えた義理ではありません。 便利なのは認めます。tailscale up一発で直接インターネットへの疎通性を持たないホストに外から入れるのは素直に便利ですし、ちょっとしたマネジメント用途にはすごく使えるものだと思います。ただ、この便利は、OSのリゾルバ, netfilter, routing table他諸々に対する全力の侵襲と引き換えに成立しています。問題は、その侵襲の質が悪いことで、当にストレスが溜

  • Build Your Own Redis with C/C++ | Build Your Own Redis with C/C++

    Introduction Build real-world software by coding from scratch. If you can build a Redis server, you can build almost any software beyond CRUD! Because it teaches you 3 fundamental skills: Network programming. The next level of programming is programming for multiple machines. Think HTTP servers, RPCs, databases, distributed systems. Data structures. Redis is the best example of applying data struc

    Build Your Own Redis with C/C++ | Build Your Own Redis with C/C++
  • Ruby採用の2Dゲームエンジン「DragonRuby GTK」が無償提供中。4/28(火)まで期間限定で入手可能|ゲームメーカーズ

    Rubyで記述する2Dゲームエンジン「DragonRuby Game Toolkit」、期間限定で無償提供中 クロスプラットフォームに対応した軽量なゲームエンジンで、ホットリロードが可能な点などを特徴とする 無償提供期間は、2026年4月28日(火)午前8時13分(日時間)まで 2026年4月23日(木)より、2Dゲームエンジン「DragonRuby Game Toolkit」(以下、DragonRuby GTK)が期間限定で無償提供されています。 配布期間は2026年4月28日(火)午前8時13分(日時間)まで。itch.ioの特設ページからダウンロードできます。 「DragonRuby GTK」は、オープンソースのプログラミング言語「Ruby」で2Dゲームを開発できる、クロスプラットフォーム対応のゲームエンジン。軽量な設計であることや、ホットリロードが可能であることなどを特徴として

    Ruby採用の2Dゲームエンジン「DragonRuby GTK」が無償提供中。4/28(火)まで期間限定で入手可能|ゲームメーカーズ
  • AIのお世話が辛いのでUsecase Design Docを書く - CADDi Tech Blog

    はじめに 何が辛かったのか 毎回詳細なプロンプトを書くのが辛い AIエージェントのタスク完了まで面倒を見るのが辛い これらを並列で実行しているのが辛い 解決方針 詳細な設計ドキュメントの作り込み Usecase Design Doc 細かい実装指示・計画・実行をAIエージェントに委譲 タスクの分割方針 AIエージェントへの実装委譲 AIのお世話からの解放 - 得られた成果 開発速度の向上 PRレビュー自体の認知負荷の軽減 現在直面している課題 設計書の細かい誤りの増幅 設計とPRレビューのボトルネック化 まとめ はじめに こんにちは。CADDi Quoteのサーバーサイドの開発を担当しています、majimacchoです。私たちのチームでは全員がAIエージェントを活用して実装しPR作成まで行なっています。 私自身を含め、全く自分でコードを書かなくなったメンバーもいます。AIエージェントを使っ

    AIのお世話が辛いのでUsecase Design Docを書く - CADDi Tech Blog
  • 次世代信号情報処理シリーズ 2 音声音響信号処理の基礎と実践 - フィルタ,ノイズ除去,音響エフェクトの原理 - | コロナ社

    次世代信号情報処理シリーズ 2 音声音響信号処理の基礎と実践 - フィルタ,ノイズ除去,音響エフェクトの原理 - 田中 聡久 東京農工大教授 博士(工学) 監修川村 新 京都産業大教授 博士(工学) 著 音声・音響に関する信号処理技術を,現場ですぐに活用できる形で,かつ平易に解説する。 ジャンル マルチメディア 音声・音楽 電気・電子工学 音響 音声 電気・電子工学 信号処理 ディジタル信号処理 信号処理の講義は,座学が中心であることに加え,信号処理の応用範囲が,音声,画像,電波など多岐にわたるため,信号処理の基礎理論と応用技術の関連性を受講者がイメージしにくい面がある。このような背景から,応用をイメージした信号処理の学習ができれば効果的であるという考えのもと,書では音声・音響に焦点を絞り,信号処理の基礎理論と応用技術について,読者ができるだけ現場ですぐに活用できる形で,かつ平易に解説す

    次世代信号情報処理シリーズ 2 音声音響信号処理の基礎と実践 - フィルタ,ノイズ除去,音響エフェクトの原理 - | コロナ社
  • Programming with a DJ Controller — not vibe coding

    RubyKaigi 2026

    Programming with a DJ Controller — not vibe coding
  • Decision Quality と設計判断失敗パターン - kawasima

    Decision Quality (DQ) は SDG が体系化した意思決定の質の枠組みで、良い意思決定の条件を6つに分解する。 Frame(解くべき問題の枠組み) Alternatives(選択肢) Information(情報) Values(評価基準) Sound Reasoning(論理的推論) Commitment to Action(実行へのコミット) 全体の質は一番弱い要素で決まる、というのがDQの中心的な主張である。意思決定そのものと、その結果は区別する。良い意思決定でも結果が悪いことはあるし、その逆もある。 設計判断の現場で繰り返し観測される失敗の多くは、6要素のうち Frame と Values の2つの取り違えで説明できる。Valuesを 評価軸 として8つに整理し、Frame の取り違えは 支配軸の取り違え として捉える。残りの4要素も副次的に絡む。早合点 は In

    Decision Quality と設計判断失敗パターン - kawasima
  • Juice=Juice NEW EP 2026年6月24日(水) 発売決定!! - ハロー!プロジェクト公式サイト

    SNS関連動画総再生回数が約6億回再生!「盛れミ旋風」ともいわれるヒット曲「盛れ!ミ・アモーレ」がバズり中のJuice=Juiceが新作EPをリリース。 「盛れ!ミ・アモーレ」他、にLIVEで大人気の「BLOODY BULLET」 「甘えんな」を初音源化。 さらに広瀬香美プロデュースの新録曲を含む、Juice=Juiceの現在形を詰め込んだ全6曲を収録!! ボーナストラックとして、現メンバー11人の紹介ソング『GIRLS BE AMBITIOUS! 2026』のライブテイクも収録。 Juice=Juice 『MORE! MORE! EP』 2026.6.24 ON SALE!! 【CD収録内容】 01.クラクラ・クライマックス (新録曲:広瀬香美プロデュース) 02.盛れ!ミ・アモーレ 03.結論から言ってちょうだい (新録曲:中島卓偉提供) 04.甘えんな(初音源化曲) 05.BLOOD

    Juice=Juice NEW EP 2026年6月24日(水) 発売決定!! - ハロー!プロジェクト公式サイト
  • RubyKaigi 2026 - @ledsun blog

    0日目 移動トラブル 今回のRubyKaigiは、かなり印象的なスタートになりました。 もともとは羽田空港から函館空港へ飛行機で移動する予定でした。 管制機器のトラブルによって、飛行機の出発が危ぶまれる状況になったのです。 飛行機は諦めて新幹線で移動することにしました。 移動には4時間ほどかかり、函館駅に到着したのは10時過ぎでした。 ただ、このトラブルのおかげで良い体験もありました。 同じように移動トラブルに巻き込まれていた rhiroe さんが、Slackで「ご飯行く人いませんか?」と募集していたのを見かけて、それに乗っかる形で一緒にジンギスカンをべに行きました。 Slack上ではIDを見かけていて認識はしていたのですが、実際にお会いするのは初めてでした。 ジンギスカン 移動トラブルが良い思い出になりました。 1日目 キーノート The Journey of Box Building

    RubyKaigi 2026 - @ledsun blog
    razokulover
    razokulover 2026/05/01
    函館山寒かった…
  • ゼロからのOS自作入門を563日で完走した感想 - sasurau4のブログ

    TL; DR ゼロからのOS自作入門をやって、君も自分だけのOSを作ろう! ちょっとずつ作っていく過程で、歴史の追体験と機能ができたときの感動を体験しよう! 最高なので、今すぐ購入しよう!(ダイレクトマーケティング) はじめに 「ゼロからのOSを自作入門」、通称mikanをやっとこ完走したので、その感想 当に最高だったので、その感動を共有したくて、ブログを書いている 成果物 repoはこちら GitHub - sasurau4/mikan-os · GitHub 上記のrepoは llvm-18, WSL2, Ubuntu24.04 で動作確認して、tagも家に倣って打ったので参考にしたい方がいればどうぞ Ubuntu18.04環境を用意するのが大変だったのと、llvmも新しいversionで始めてどうしようもなくなったら下げるかという考えで進めた 家はbuild scriptが別

    ゼロからのOS自作入門を563日で完走した感想 - sasurau4のブログ
  • Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo

    Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo

    Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo
  • 「三文オペラ」公演中止後の対応についてのご報告 - メディキット県民文化センター 公益財団法人 宮崎県立芸術劇場

    第31回宮崎国際音楽祭 サテライト・コンサート in 西都「NADESHIKO弦楽八重奏団」 2026年05月04日(月・祝) 西都市民会館(〒881-0012 宮崎県西都市小野崎2丁目49番地) 詳しく見る

  • RubyKaigi 2026 参加記 | うなすけとあれこれ

    函館に辿り着く方法 大型自動二輪免許を取得したうえに、全然そのつもりはなかったけどバイクを購入したので、せっかくなら函館にもバイクで向かおうと考えてはいました。ただ、4月の函館、というよりはフェリーを利用した場合の苫小牧から函館までの経路において雪の可能性を捨てきれないという助言を頂き、リスク回避のため飛行機で向かうことにしました。結果としては桜の開花も早まるくらいには暖かく、雪の心配はなかったわけなのでちょっと悔しい思いはしています。 #RubyKaigiNOC 今年もNOC memberの一員として関わらせていただきました。また、昨年からサブスクリーンやサイネージのオペレーションも一部担当しています。朝に “good morning!” とか言ってるのはサブスクリーンのテストだったりして。ちなみにこの運用経験はKaigi on Railsに輸入されており、大変ありがたく思っています。

    RubyKaigi 2026 参加記 | うなすけとあれこれ
    razokulover
    razokulover 2026/04/29
    クロスピック大変だ
  • なぜ、「プログラマーの三大美徳」は日本でばかり有名なのか?

    はじめに プログラマーの三大美徳は、ラリー・ウォールが Perl文化とともに提示した有名な言い回しですが、日ではそれが単なる Perl の格言にとどまらず、広くエンジニア一般の心得として知られるようになりました。現在の Perl 公式文書でも、この三つは「Laziness, Impatience, and Hubris」として明記され、由来はラクダの通称で知られる『Programming Perl』にあると案内されています。出発点は明確に Perl 文化の内部にあります。 ところが日語圏では、この言葉が Perl を知らない初学者や転職希望者にまで届いています。技術系媒体や転職媒体、学習媒体に至るまで、三大美徳は「プログラマーに向いている人の特徴」や職業理解の一部として紹介されています。一般化の度合いが、日ではかなり高いのです。 ここで問いの立て方を少し正確にしておきます。英語

    なぜ、「プログラマーの三大美徳」は日本でばかり有名なのか?
  • はてな株に売り殺到、終日値付かず “11億円流出”ショックで

    ブログサービスなどを運営するはてな(京都市中京区/東証グロース)の株価が4月27日、値幅制限の下限(ストップ安)水準の881円で売り気配のまま推移し、終日値が付かなかった。同社が前週末に発表した、不正な送金指示による最大約11億円の資金流出事案が嫌気された。 前週末24日の終値は1181円で、27日のストップ安水準は300円安の881円。同日は寄り付きから売り注文が積み上がり、買いが追いつかなかった。 売り材料となったのは、24日に開示した資金流出事案だ。4月20日と21日、悪意ある第三者から虚偽の送金指示に従い、従業員のアカウントから銀行預金を外部の口座に送金していた。 同社の2026年7月期通期業績予想は、売上高38億5900万円、営業利益1億3600万円。最大被害額は、通期営業利益予想の約8倍に相当する規模だ。 同社は手元の運転資金について「十分な流動性を確保しており、事業運営や資金

    はてな株に売り殺到、終日値付かず “11億円流出”ショックで
    razokulover
    razokulover 2026/04/28
    セキュリティというよりガバナンスの方が問題なのはそう…
  • 【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 - レバテックLAB

    プログラマ、テスト駆動開発者 和田 卓人 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。『プログラマが知るべき97のこと』(オライリージャパン、2010)監修。『SQLアンチパターン』(オライリージャパン、2013)監訳。『テスト駆動開発』(オーム社、2017)翻訳。『事業をエンジニアリングする技術者たち』(ラムダノート、2022)編者。テストライブラリ power-assert-js 作者。 日CTO協会が主催する、開発者体験をテーマとしたイベント「Developer eXperience Day 2024」が、7月16日、17日に開催されました。 レポートでは、7月16日に行われたt-wadaこと和田卓人氏のセッション「望ましい自動テストとは:どのようなテストが開発生産性と開

    【t-wada】自動テストの「嘘」をなくし、望ましい比率に近づける方法【Developer eXperience Day 2024 レポート】 - レバテックLAB
  • コンウェイの法則 - Martin Fowler's Bliki (ja)

    私が敬愛するソフトウェアアーキテクチャの専門家たちは、この分野のあらゆる一般法則に対して懐疑的です。 優れたソフトウェアアーキテクチャはコンテキストに固有であり、さまざまな環境下で異なる解決をしなければならないトレードオフを分析するものだからです。 とはいえ、彼ら全員が同意するものがひとつだけあります。 それは、コンウェイの法則の重要性とパワーです。 私がこれまでに経験したすべてのシステムに影響を与えるほど重要であり、抗えないほどのパワーがあります。 この法則を説明するには、作者の言葉がいちばんでしょう1。 システム(広義に定義)を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。 ―メルヴィン・コンウェイ コンウェイの法則とは、ソフトウェアシステムのアーキテクチャは開発チームの組織とよく似る、というものです。 元々は、1つのチームでコンパイラーを作

  • 要件定義書の成果物を1枚ずつ解説する記事がなかったので、架空のプロジェクトで自分でつくって解説します

    この表の左から右へ読むと「何を→誰が作り→誰が決め→何が決まるか」がわかります。上から下へ読むとプロジェクトの意思決定の流れがわかります。以降の解説は、この流れに沿って進みます。 ビジネスコンセプト:プロジェクトの「存在理由」を経営層と合意する BR.1のステークホルダー整理と並行して最初に固めるのが、プロジェクト全体の「存在理由書」です。外部環境(EDI標準化・インボイス制度・競合のデジタル化)と内部課題(手入力ミス年間60件・月次集計3日)を整理し、ビジネスゴール(KGI:業務コスト年間1,500万円削減・受注ミス年間5件以下・受注確認書5分以内発行)を経営層と合意します。以降のすべての要件はこのKGIに紐づく形で正当化されます。ここでKGIへの合意が得られなければ、どれほど精緻な課題分析や施策設計も「何のためにやるのか」が曖昧なまま進んでしまいます。 BR.1 ステークホルダー把握:

    要件定義書の成果物を1枚ずつ解説する記事がなかったので、架空のプロジェクトで自分でつくって解説します
  • GitHub - TrisH0x2A/project-box: C projects: algorithms, games, and networking

    razokulover
    razokulover 2026/04/27
    いいね