プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
表 1: 完全情報ゲームの状態空間複雑性とゲーム木複雑性 従来の「完全情報ゲーム」の中では、囲碁は、状態空間複雑性もゲーム木複雑性もほかのゲームより、はるかに高いことがわかります。2017 年、AlphaZero が MCTS と深層強化学習を利用して囲碁を含めた複数の完全情報ゲームを解いたことをきっかけに、学術研究では「不完全情報ゲーム」と「リアルタイムストラテジーゲーム」などがより注目されるようになっています。 不完全情報ゲーム: 情報集合数と平均的な大きさ 「不完全情報ゲーム」の場合も、「完全情報ゲーム」と同様にその状態空間複雑性とゲーム木複雑性を計算することができますが、情報が不完全で非対称的なため(たとえば、ポーカーと麻雀では相手の手札と伏せたままの残り札は把握できません)、参加者はゲームの実際の状態を分別することができません。たとえば、ポーカーでは自分が K を 2 枚持ってい
Rouan is a software engineer and technical leader, who helps build outstanding teams and high-quality software. He's worked in a variety of technology stacks for companies in the financial services, education, leisure and energy sectors (including as a consultant at Thoughtworks). He cares about keeping things simple, building inclusive teams, and writing about what he learns. Gathering operationa
CPU, GPU, Memory, and multi-process architecture In this 4-part blog series, we'll look inside the Chrome browser from high-level architecture to the specifics of the rendering pipeline. If you ever wondered how the browser turns your code into a functional website, or you are unsure why a specific technique is suggested for performance improvements, this series is for you. As part 1 of this serie
技術部のフルタイムRubyコミッタの遠藤(@mametter)です。昨日の Hackarade #04 の開催報告に続き、2日連続で記事を投稿します。 今回は、ある条件下でのRubyの実行速度を高速化した話を紹介します。この改善はすでにMRIの先端にコミットされていて*1、年末リリース予定のRuby 2.6に含まれる予定です。 ひとことで言うと、「簡潔ビットベクトルを索引に使うことで、プログラムカウンタから行番号を計算するアルゴリズムをO(log N)からO(1)に改善した。これにより、TracePoint有効時やコードカバレッジ測定下で、長さ N のメソッドの実行が O(N log N) から O(N) に高速化される」ということです。順に説明します。 背景:Rubyのバイトコードの構造 この最適化を理解するにはまず、Rubyのバイトコードのある特徴を知る必要があります。 たとえば x
ブログを書くのは久々です。 京都で小さな会社をやっていて、自社開発でClojureとClojureScriptを使用し続けて、概ね3年くらい使い続けています。その過程で、Clojure自体にも小さいながらソースレベルの貢献ができたりして、オープンソースプロジェクトとしても面白かったのですが、もともとオブジェクト指向言語ばかりやってきたところから、Clojureという、まったくオブジェクト指向言語ではない言語に飛び込んだ経験や考えたことなんかを、ブログにストックすると、何か他の人にも役立つこともあるかと思って、ブログに書くことにしました。 このところずっと、自社の仕事とは別に、恵比寿にある 株式会社ユーザベース さんのお仕事に参加しています(私が法人を作る前からなので、もう5、6年くらいになります)。そちらの方でもClojureやシステム設計の話(プレゼンなど)などを何度かさせてもらったり、
この記事は Ruby on Rails Advent Calendar 2015 15日目の記事です。 これまで携わってきたソーシャルゲームのサーバーサイド開発では、1タイトルに対して主に3つの機能を作成することが多かった。 API スマートフォンのネイティブアプリケーションから呼ばれるJSON(あるいはJSONフォーマット互換)API 管理用画面 ユーザー情報管理、その他各種制御処理を行う(BANとか補填とかマスタデータキャッシュ管理とか)。エンジニアとカスタマーサポートチームが使用する デバッグ用画面 開発用のWebUI、単純なAPIを呼ぶフォームではなく「カードのレベルをMAXにするボタン」みたいなものが機能ごとに沢山ある 開発を行う場合、大体はAPI用の機能がメインになる。ただ、デバック用画面に関しては完全に社内開発用なので適当で構わないけど、管理用画面に関してはそれなりの作りこみ
Covers how to use the proto3 revision of the Protocol Buffers language in your project. This guide describes how to use the protocol buffer language to structure your protocol buffer data, including .proto file syntax and how to generate data access classes from your .proto files. It covers the proto3 revision of the protocol buffers language. For information on editions syntax, see the Protobuf E
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0063 号 バックナンバー Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist
FiNC Developer Advent Calendar 2016の19日目の記事です。 要約 リクエスト・レスポンス形式のドキュメントはメンテが大変 メンテされていなくても気がつかないため放置され気味 committeeでJSON Schemaに実装が沿っているかを確認可能 prmdでJSON Schemaを楽に書ける+人が読めるドキュメントが生成できる メンテされていない事が検出できるので続く(はず API作成時のリクエスト・レスポンス形式問題 サーバとクライアントで並行開発しながらAPIを作成する場合、以下のようにリクエスト・レスポンス形式を整えにくいという問題があります。 リクエストの形式が想定と違う 想定外のキーを送ってくる 構造が想定していない構造 レスポンスに知らないキーが含まれている 同じデータなのにエンドポイントによって形式が違う enumの数値だったり、対応する文字
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く