この記事では、トーナメント大会を行う形式の一つである｢ダブルエリミネーション方式｣(ダブルイリミネーションとも)が、通常のトーナメント方式に比べて、どの程度適切な順位付けをできるかについて書く。 なお、この記事は寝椅子氏の企画であるスマブラAdventCalendar2020に参加している。リンク先の他のブログ記事も是非読んでみてほしい。また、リーグ戦については以下の過去記事で考察している。 ダブルエリミネーションはシングルエリミネーションの問題を緩和する ダブルエリミネーションによる順位付けを数理的に評価する 大会をシミュレーションし、大会形式の影響を調べる 総評 【追記おまけ】組合せ運だけを評価できないか？ ダブルエリミネーションは シングルエリミネーションの問題を緩和する 多くの競技で採用されている普通のトーナメント戦は、1敗した時点で順位が確定する。この形式をシングルエリミネーショ
※本記事はアフィリエイトプログラムによる収益を得ています セガが6月15日、社内勉強会用の資料をSEGA TECH BLOGで公開しました。ゲームの開発に必要な知識ということなのですが、内容は大学初年度レベルのガチ数学、そしてその内容は150ページ以上！ よ、読んでも全然分からん……！ う、うわぁぁぁ（画像はセガ公式Twitterから） この資料は、セガで2020年に有志で行われていた数学の勉強会で使用されていたもの。内容としては、高校数学を超駆け足で復習し、大学初年度で学ぶ線形代数の基礎の学び直しと応用としての3次元回転の表現の基礎の理解を主目的としています。 勉強会のゴールは、「クォータニオン」（日本語では「四元数」）を数学的に理解すること。クォータニオンは、ゲームではキャラや背景などを3次元回転させるときに応用されるものだそうです。 150ページ以上に及ぶ資料は全ページ公開されている
はじめに はじめまして。 2019年3月に入社した正岡です。 平均週に4回、大分県中津のから揚げ弁当を食べている大の鶏好きです。からあげクンと呼んでください。 主に Rails × Typescript のプロジェクトにフロント／バックエンドエンジニアとして参加しています。今後ともよろしくおねがいします。 本記事の内容 およそ１年前、弊社ではDocBaseのユーザーの皆様により良いユーザー体験をしていただくために何ができるかを検討しました。結果、フロントエンドを改修して SPA（Single Page Application） に移行することで、従来よりも速く、快適にご利用いただけるのではないかという結論に至り、ご存知の通り先日リリースいたしました。 フレームワークどれを使うか問題 既存サービスのSPA化などのフロントエンド改修を検討する際、「フレームワークどれ使う？」問題にぶち当たります
まえがき 案件でサーバーとクライアントがJavaScript/TypeScriptで作られてる場合、サーバーとクライアントでAPIの型定義やバリデーションのユーティリティーなどを共通化したくなります。 共通化する部分だけを別リポジトリに切り出すと、開発中公開しないと使えないので面倒です。今回はサーバー側にYarn Workspaces モノリポ（モノリシックリポジトリ）の共通化部分をNPMで公開します。 また案件で使うときは共通化はしたいけど、パブリックに公開したくはないっという矛盾があります。プライベートNPMとして公開できるにようにします。 要件まとめ サーバーもクライアントもプライベートリポジトリで管理されている サーバー側が共通化ソースを含むモノリポ構成になっている クライアント側はNPMパッケージとして読み込む 非公開のNPMパッケージとして公開したい 今回はGitHub Pac
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady（準備ができている）である必要があります （Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 別のところで依頼を受けて作った文書なのですが、皆様の参考にもなるかと思いますので共有しておきます。 まずはプロダクトゴールを検討するプロダクトバックログは、プロダクトゴールの実現のために存在します。 つまりプロダクトバックログを作るには、プロダクトとして実現したいゴール、顧客に提供したい価値などをあらかじめ検討する必要があります。 リーンキャンバス、エレベーターピッチ、ユーザーインタビュー、エスノグラフィーなどのテクニックを活用しながら、プロダクトとして解決したい課題、実現したい価値やゴールを評価しますプロダクトを実際に開発するのはお金も時間もかかるので、本来この時点で仮説検証を繰り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
