良いゲームを作るためのディレクターの戦い。面白さの探索と不安のトレードオフ｜かえるD
最近新卒２～３年目くらいの子が新しくディレクターに任されたけど、どうすればうまくできるのかと悩んでいたので、ディレクターとはこういうものだよという説明をした。本人はとても納得したようで良かったと思ったが、考えてみれば私も最初はすごく苦労したし、今でも仕事をするたびに「本当にこれで良いのか」と悩み続けている。 今回この記事を書こうと思ったのは、困っている人にこれ読むと良いよというようなリファレンスがなく、新卒に「ディレクターとは何か」を説明するにしても必要となるタイミングがみんなずれるため全員に説明するとすごいコストがかかる（現実的ではない）からだ。 そして、本題の結論を先に書いておく。 ・ディレクターは、不確実性と戦う職業だ ・面白いゲームを作るためには「面白さの探索と不安のトレードオフ」に向き合う必要がある これは私の解釈であり、絶対の正解ではない。ただこういうものは、違う表現で違う人か
マイクロサービスチーム編成のベストプラクティスとメルカリでの構想 - Mercari Engineering Blog
今年もMercari Advent Calendar 2018 が始まりました。初日は @stanaka がお送りします。 メルカリでは創業以来開発してきたPHPのアプリケーションから(主に)Goで実装されたマイクロサービスアーキテクチャへの移行を進めています。これまでにMercari Tech Conferenceやその他のカンファレンスでMicroservice化の意義、移行の方法、基盤となるMicroservice Platformの概要などについて様々な発表をしてきました。 現在、来年からの本格的なマイクロサービスアーキテクチャでの開発に向けて、これまでのサービスの施策ドリブンのチーム編成から、マイクロサービスを軸としたチーム編成に移行しようとしています。 しかし、マイクロサービスアーキテクチャを成功させるためには、各種プラットフォームの機能を揃え、それらを利用したマイクロサービス
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
Kyashに入社して半年くらい経ちました - Konifar's WIP
早いもので、2017年12月にKyashに入社してから半年が経ちました。 最近は 「勢いある」「Kyashよさそう」と言っていただくことも増えてありがたいなぁと思うと同時に、中にいるとちょっと過大評価されているなと感じることもあります。 自分自身も後で見返せるように、実際どうなの？という話を自分の視点から書いておこうと思います。Kyash実際はこんな感じなんだーというのがなんとなく伝われば嬉しいかぎりです。 ちなみにこういう話は思いもしないところ思いもしないツッコミを受けるものなので結構緊張しています。何か気になる表現があれば@konifarまで直接連絡をもらえるとありがたいです。 入社直後の感想 2017年12月に入社した時、Kyash社内はめちゃくちゃ忙しい時期でした。開発もマーケも全員修羅場で、「オッやっとるな」という感じでした。 自分が入った時にすでに佳境だったので、そのプロジェク
デスマーチが起きる理由 - ３つの指標
デスマーチが起きる理由 - ３つの指標 著者： 青い鴉（ぶるくろ）さん @bluecrow2 これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。 今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。 昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。 お願い もしオリジナルの図を保存されていた方いら
技術選定の審美眼。時代を超えて生き続ける技術と、破壊的な変化をもたらす技術を見極める（前編）。デブサミ2018 － Publickey
最近の立ち位置としてはライオンと一緒にされていまして、テストを書いていないプルリクエストとかに対して、却下の代わりにこの画像が張られるみたいな形で、一種の恫喝の代わりに使われています。 が、本人はきわめてジェントルな人で、いましゃべってるところを見て、このライオンとはキャラが違うなとお感じになっていただければ嬉しいです。 ついて行くべき変化とスルーしていい変化 昨今の技術の現場でよくあるのは、フロントエンド疲れ。JavaScriptの新しいフレームワークや、開発方法論とか、そういうのがどんどん登場して、また新しいものが出てきたと。 2年前に標準とされていたものがすっかり過去のものになってしまっていて、Gruntはどこに行ってしまったんだとか、Backbone.jsはどこに行ってしまったんだとか。 そうした変化に追いつけずに、疲れてしまうわけです。 かと思えば、一種の限界集落。よく言えば安定
［CEDEC 2017］「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた
［CEDEC 2017］「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた ライター：西川善司 CEDEC 2017は，任天堂からの登壇者が例年に比べて非常に多い。数えてみると8件あった。「海外のカンファレンスでは登壇する一方，日本国内のカンファレンスにはあまり出てこない」という，これまでの傾向からは一転した新しい動向と言える。「ゲーム開発シーンにおける知見の共有」において，これまであまり積極的でなかった任天堂だが，意識を変えてきたのだろうか。 いずれにせよ，CEDEC 2017で任天堂は，「ゼルダの伝説 ブレス オブ ザ ワイルド」（Nintendo Switch / Wii U，以下，ゼルダの伝説BotW）関連セッションを4本も持った。今回はその中から，開発者でない一般のゲーマーにも分かりやすかったと思われる「『ゼルダの伝説 ブレス オブ ザ
広告プラットフォーム立ち上げ百鬼夜行
立ち上げにまつわるあれやこれやをプレゼンした内容です。 特に、事業スケールにともなってテーマ性が変わりますので、 そちらをいかに乗り越えていくのか？というお話が中心です。
Hex-Rays Decompiler
The Hex-Rays Decompiler brings binary software analysis within reach of millions of programmers. It converts native processor code into a readable C-like pseudocode text. Advantages of the Decompiler In comparison to low level assembly language, high level language representation in the Decompiler has several advantages: concise: requires less time to read it; structured: program logic is more obv
Amazon.co.jp: Amazonのクラウドエンジニアが選ぶ技術書: 本
本 の優れたセレクションからオンラインショッピング。
Docker を利用した Web アプリケーションのデプロイ - クックパッド開発者ブログ
技術部の鈴木 (id:eagletmt) です。 クックパッドでは一部の Web アプリケーションサーバで Docker が使われており、今回はそのデプロイ方法について紹介します。 Docker で Web アプリケーションをデプロイするときには、まだまだベストプラクティスがある状況ではありません。 たとえば、どのように無停止でデプロイするか、どのようにコンテナと通信するかといった問題があります。 最初に Apache Mesos と Marathon などのツールを検証しましたが、クックパッドの環境において使いやすそうなものはなく、最終的に自前でデプロイのしくみを作ることにしました。 しかし Docker 周辺のツールは様々な新しいものが出てきている最中です。 今はまだベストなものが無いけれども、近いうちによりよいものが出てくるかもしれません。 そのため、できるだけ単純なしくみにしておく
android Git repositories - Git at Google
Git repositories on androidNameDescriptionaccessories/manifestassets/android-studio-ux-assetsBug: 32992167brillo/manifestcts_drno_filterParent project for CTS projects that requires Dr.No +2's.device/aaeon/upboarddevice/amlogic/yukawaBug: 122486287device/amlogic/yukawa-kernelBug: 122486287device/asus/debdevice/asus/flodevice/asus/flo-kerneldevice/asus/fugudevice/asus/fugu-kerneldevice/asus/grouper
Google のバグ予測アルゴリズムと bugspots の導入
概要 はじめまして、開発の土田です。 Google のバグ予測アルゴリズム、というものがあります。 詳細は、「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している - Publickey」や、Google 本家の記事「Bug Prediction at Google - Google Engineering Tools」をご参照いただければ、と思いますが、基本的には「よくバグフィックスで更新されるファイルは危ない、最近のファイルほど危ない」という考え方です。バグフィックスのコミットに対して、古いものほど点数が低く、最近更新されたものほど点数が高くなるような計算式になっています。 また、このアルゴリズムを実装したオープンソースのツールである bugspotsというものもあります。こちらの詳細も Publickey の記事「グーグルのバグ予測アルゴリズムを実装したツール「bu
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
APIドキュメントを書くのが楽になるツールまとめ - Qiita
さいきんREST APIのドキュメントを書いていて、wiki使うのだるいし他に良い方法ないかな〜と調べてた時に見つけたツール群をまとめてみます。 追記: こちらも便利そうなので参考にどうぞ。 REST APIドキュメント作成ツールはapiary.ioが決定版かもしれない - Qiita swagger Swagger: A simple, open standard for describing REST APIs with JSON | Reverb for Developers デモ: Swagger UI ソースコード中にAPIの概要を書いておくと、それを元にドキュメントを自動生成してくれる。wikiやmarkdownで書くのと決定的な違いは、↓のようにドキュメント上のformからAPIコールを試すことができる点。 様々な言語のWAFに対応したライブラリも開発されてる。 Home ·
GitLab | FAIRWAY Engineer {Blog}
こんにちは。 最近はもっぱらチーム開発を効率よくできる仕組みを考える事に必死なベッチです。 そんな時に電車でいろいろ調べていたら以下のスライドをみつけました。 少人数チームにおけるプロジェクト管理のベストプラクティス このスライドでは以下の２つの事を実践する事で品質が向上すると提唱しています。 コードの強制自動テスト プログラマ同士のコードレビュー 最近開発チーム内でもコードレビューの必要性について議論されてきているのでこのタイミングで開発フローにのせれるように検証してみようと考えました。 ただし「１．コードの強制自動テスト」を強制するのは現場が混乱するのでとりあえずは保留にしておきます。 スライドではRedmine、GitLab、Jenkinsを使った開発フローが紹介されていますが、いきなり全てを連携してというのは無理なので、まずは「２．プログラマ同士のコードレビュー」を実現する為にGi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
読み物投稿サイト scraiv(スクライブ)
開発組織マネジメントのコツ - Speaker Deck
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
Armadillo-IoTゲートウェイの概要
