ゲームクリエイターが知るべき 97 のこと 2
【01】ゲーム開発者コミュニティの重要性 by 新 清士 【02】開発を確実に炎上させる 3 つのこと by 中林 寿文 【03】ゲームデザインの向こうを見たくはないか？ by 高橋 勝輝 【04】学問に終わりなし by 山根 信二 【05】「ゲーマー」としてのキャリアパス by 松井 悠 【06】ゲーム開発者のお手並み by 松原 健二 【07】「おもてなし」の心のすすめ by 板垣 貴幸 【08】代替現実感の作り方 by 竹内 ゆうすけ 【09】ゲームは誰のものか by 長久 勝 【10】ロケテストについて深掘りしてみる by motoko128k 【11】オープンハードがもたらすインディーゲーム新時代 by 一條 貴彰 【12】人工知能にたいせつなこと by 三宅 陽一郎 【13】テクニカルサウンドデザイナーという存在 by 稲森 崇史 【14】ゲームサウンドは新しい楽器 by 田中
ゲームクリエイターが知るべき 97 のこと
【01】「勝手にテコ入れゲーム企画」を考えよう！ by 石川 淳一 【02】誰でもできることから始める by 石倉 力 【03】プログラマの「ゲーム作り」への情熱 by 石畑 義文 【04】ゲームクリエイターは何でもできた方がいい by 石原 恒和 【05】君は反省し続ける事ができるか？ by 今給黎 隆 【06】お宝と燃料を同時に手に入れよう！ by 岩出 敬 【07】私たちは誰のためにゲームを作っているか by 宇佐見 公介 【08】ピグライフをつくるときに考えたこと by 浦野 大輔 【09】ムダなムダを徹底的に切り捨てる by 益 弘和 【10】面白さには旬がある by 遠藤 雅伸 【11】理論を軽視しないこと by 大垣 真二 【12】限られたリソースの中で～サーバ運用の現場から～ by 大澤 範之 【13】神は細部に宿りたまう by 大野 功二 【14】面白くならなくてもいいか
プロジェクト・マネジャーが知るべき 97 のこと
【01】できるだけ早期にユーザーを巻き込む by バービー・デイビス（Barbee Davis）MA、PHR、PMP 【02】モグラたたき開発を避けよう by ベンカト・スブラマニアム（Venkat Subramaniam） 【03】ローカライゼーションのせいで締め切りに遅れる by パベル・シムサ（Pavel Simsa）PMP 【04】プロジェクト・オーナーは強力なプロジェクトサポーター by 武谷 美世子（Miyoko Takeya）PMP 【05】複雑よりもシンプルな方がいい by スコット・デイビス（Scott Davis） 【06】負債を支払う by ブライアン・スレッテン（Brian Sletten） 【07】スキルでなく素質のある人を加えよう by リチャード・シェリダン（Richard Sheridan） 【08】シンプルにいこう by クリシュナ・カダリ（Krishna
ソフトウェアアーキテクトが知るべき 97 のこと
【01】システムの要件よりも履歴書の見栄えを優先させてはならない by ニティン・ボーワンカー 【02】本質的な複雑さは単純に、付随的な複雑さは取り除け by ニール・フォード 【03】最大の問題は、たぶん技術的なことではない by マーク・ラム 【04】まずコミュニケーション、そのための明快さとリーダーシップ by マーク・リチャーズ 【05】パフォーマンスの決め手はアーキテクチャー by ランディ・スタッフォード 【06】要求仕様の本当の意味を探れ by アイナー・ランドル 【07】立ち上がろう！ by ウディ・ダーハン 【08】すべてのものは、かならずエラーを起こす by マイケル・ナイガード 【09】それは交渉だということに気付け by マイケル・ナイガード 【10】定量化を求めよ by キース・ブレイウェスト 【11】500 行の仕様書より 1 行のコード by アリソン・ランダ
[WIP] エンジニア向け無料電子書籍 - Qiita
はじめに いろいろな電子書籍の個人的なメモです。 取り留めの無い感じです。 電子書籍といいつつ pdf, epub 以外に html などもあります。 プログラミング言語 無料で（自由に？）プログラミングについて学べるサイトや本をまとめている素晴らしいGitHubリポジトリ「free-programming-books-ja」もあります。大変参考になります。 Python - Python公式サイト 日本語ドキュメント 京都大学 プログラミング演習 Python 2019 東京大学 Pythonプログラミング入門 JavaScript/ECMAScript ECMA-262 JIS X3060 Ruby - オブジェクト指向スクリプト言語 Ruby ISO/IEC 30170 / JIS X3017 実用的 Ruby スクリプティング CC-BY-NC のライセンスで pdf を公開 Ja
![[WIP] エンジニア向け無料電子書籍 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b9c36b70004e038065c16dcb3f603ba73c5193a3/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCV0lQJTVEJTIwJUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgyJUI4JUUzJTgzJThCJUUzJTgyJUEyJUU1JTkwJTkxJUUzJTgxJTkxJUU3JTg0JUExJUU2JTk2JTk5JUU5JTlCJUJCJUU1JUFEJTkwJUU2JTlCJUI4JUU3JUIxJThEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0yMTdlZTFhYWY0OGQwODhkMjkzOGFiMGM3YTBiM2E2OQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5b3NoaTM4OTExMSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NzA1MjM0MWJjY2FiOTA1MmZmM2RhZDA4ZWZjNGVjZWY%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D5db594482d734aa6e9f0015ff9e378a0)
脳に収まるコードの書き方
ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようするには、脳に収まり、人間が理解できるコードを書く必要があります。 本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。最初のコードを書き始めるところから機能を追加していくところまでを解説し、効率的で持続可能なペースを保ちながら、横断的な問題への対処やトラブルシューティング、最適化を行なう方法を説明します。自分のチェックリストからチームワーク、カプセル化から分解、API設計から単体テストまで、ソフトウエア開発の重要な課題に対する考え方やテクニックを紹介します。サンプルプロジェクトで使うコードは、Gitリポジトリの形で入手でき、試しながら学べます。 有効に機能するプロセスを選び、効果のない方法論から脱却する方法。チェックリストを使うこ
『ルールズ・オブ・プログラミング』を読んだ #iknowtherulesjp - Don't Repeat Yourself
Ghost of Tsushimaなどを作った会社の人が書いた本です。ゲーム開発におけるコードを書く際の教訓を整理し、改めて示し直したいい一冊だったと思います。大事なことですが、著者は決して「このルールを絶対使え」と言っているのではなくて、そもそもまず会社の製品の特性上、このようなルールを敷いておくと品質や生産性を高く保てたという前提があり、その前提を元に「ルールを選び取って自分たちのコーディング哲学を構築しよう」と推奨しています。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール 作者:Chris Zimmermanオーム社Amazon この手の本では『リーダブルコード』がよく薦められる傾向にあると思います。私にとってもリーダブルコードは確かに駆け出しの頃すごく役に立った記憶はあるのですが（もう10年くらい前に読んだので正直忘れた）、そこから知識がアップデートされ
【アジャイル】書籍「Clean Agile」より「小規模開発のアジャイル入門」
本書は「小さなことをする、小さなソフトウェアチームがうまくやっていくために!」という副題のとおり、小規模な開発チームにおける様々なプラクティスについてまとめられた本です。 著者のロバート・C・マーティン（アンクル・ボブ）は元プログラマーでありアジャイルの第一人者です。アジャイル開発の誕生の瞬間に立ち会った人物のひとりで、その後は世界中の大企業を対象にコンサルティングやトレーニング、スキル開発を行っています。 著者は、冒頭で本書は分量が少なく、約20年間アジャイルと関わってきた私の個人的な思い出、観察、意見であると述べています。 それだけに少し砕けた表現になっており、本質的なものに要点も絞られているため、シンプルで読みやすい本です。小規模開発に関わっている人がアジャイルを取り入れるために読む本としては最も適しているのではないでしょうか。 あらゆるプロジェクトは、鉄十字と呼ばれるプロジェクトマ
故山崎元氏との共著「ほったらかし投資術」の今後について出版社と意識合わせ
2024年元日に惜しまれつつ亡くなられた山崎元氏との共著「ほったらかし投資術」（山崎元・水瀬ケンイチ著）の今後の取り扱いについて、出版社である朝日新聞出版の書籍編集部さんとミーティングを行いました。 その結果、「ほったらかし投資術」について、以下の3点を意識合わせしました。 ①これからも山崎氏との「共著」として大切にしたいこと ②「ほったらかし投資術」を水瀬に公式継承すると山崎氏から託されたこと ③今後の内容更新は水瀬が行うが、印税のうち半分は今後ご遺族に支払ってほしいこと ①これからも山崎氏との「共著」として大切にしたいこと 今月、山崎さんが亡くなられたあと、奥様と直接お話する機会があったのですが、山崎さんは「ほったらかし投資術」をとても気に入っていて、金融関係者以外のプライベートな知り合いには本書を渡して回っていたと仰っていました。また、編集さんによれば、山崎さんは入院中も本書を医者た
クラウドアプリケーション 10の設計原則 「Azureアプリケーションアーキテクチャガイド」から学ぶ普遍的な原理原則 - インプレスブックス
■真壁 徹（まかべ とおる） 北陸先端科学技術大学院大学 博士前期課程修了 修士（情報科学）。 株式会社大和総研に入社。公共向けパッケージシステムのアプリケーション開発からIT業界でのキャリアを始める。その後日本ヒューレット・パッカード株式会社に籍を移し、主に通信事業者向けアプリケーション、システムインフラストラクチャの開発に従事する。その後、クラウドコンピューティングとオープンソースに可能性を感じ、OpenStack 関連ビジネスでアーキテクトを担当。パブリッククラウドの成長を信じ、日本マイクロソフト株式会社へ。 主な著書に『しくみがわかるKubernetes Azure で動かしながら学ぶコンセプトと実践知識』（翔泳社）、『Microsoft Azure 実践ガイド』（インプレス）、共著に『Azureコンテナアプリケーション開発 ── 開発に注力するための実践手法』（技術評論社）などが
より少なく、しかしより良く - 「エッセンシャル思考」読んだ - $shibayu36->blog;
エッセンシャル思考 最少の時間で成果を最大にする 作者:グレッグ・マキューンかんき出版Amazon 自分がなんでもやりたいタイプなので、この本に書いてあることは中々刺さった。幸福になるには「より少なく、しかしより良く」を追求すべきという本。プライベートや仕事でとにかく忙しく時間がないと思っている人は読んでみると良い。 印象に残ったのは次のことだ。 現代人の最優先課題は、優先順位づけの能力をキープすること 睡眠不足では一番最初にそこが減ってしまうのでダメ 一流のバイオリニストは1日平均8.6時間の睡眠 & 週平均2.8時間の昼寝。睡眠による並外れた集中力で、1時間あたりの練習効果を最大限にする もっとも厳しい基準でやることを決める 「絶対やりたい」「やらない」の2択にする。やろうかな程度なら却下、イエスと言うのは絶対やるしかないと確信した時だけ 自分の中で最重要基準をひとつ用意し、100点満
ソフトウェア設計のトレードオフと誤りを出版しました | フューチャー技術ブログ
すでに多くの方々にお手に取っていただいておりますが、オライリージャパンから「ソフトウェア設計のトレードオフと誤り」の翻訳をフューチャーのメンバーと一緒に出版いたしました。好評なようで、発売一カ月ほどで増刷も決定いたしました。みなさまご購入いただき、ありがとうございます。初版をお買い求めになられたい方は今すぐ書店にダッシュ！ トレードオフこそが設計である良い設計とか読みやすいコードみたいな話題はツイッターではバズりやすい話題です。 読みやすいコードの話題ではいろいろなレイヤーの話が出てくるのですが、因数分解すると、だいたいいくつかのカテゴリーに分かれるように思います。 命名規則とか書き方のルール 従うべきクラス構造、アーキテクチャ構成の導入 サービスの境界をどこに引くか、どのようなときに設計手法を選ぶか、どのアルゴリズムを選ぶか 名前や命名規則の統一とか書き方の統一とかは用語のリストを作って
プログラミング文体練習
レーモン・クノーの『文体練習』から着想を得て執筆された本書は、1つの課題を異なるプログラミングスタイルで実装し、さまざまなスタイルの特性やスタイルが生まれた歴史的経緯などを解説します。本家の『文体練習』は、「バスの中で起きた諍いと、その張本人を後で目撃した」という内容を、公的文書風、宣伝風、業界用語風など、99の異なる文体で表現したものですが、本書は、「単語の出現頻度をカウントして多いものから出力する」という課題を、40のスタイルで実装しています。リソース制約が大きかった時代の方法から、オブジェクト指向、純粋関数型、リフレクション、並行処理、ニューラルネットワークまで幅広いスタイルを扱い、マルチパラダイム言語Pythonの威力と魅力を感じられる構成となっています。 訳者まえがき 第2版 まえがき 第1版 まえがき 序章 第Ⅰ部 歴史的スタイル 1章 古き良き時代：アセンブリ言語 2章 Fo
書籍『インフフラ/ネットワークエンジニアのためのネットワーク「動作試験」入門』がもはや「先輩」だった - てくなべ (tekunabe)
はじめに 『インフフラ/ネットワークエンジニアのためのネットワーク「動作試験」入門』を読みました。とても良い本でした。 www.sbcr.jp Amazon.co.jp はこちら （電子版が試し読みできます） なかなか扱われることの少ない動作試験に絞った書籍であることと、「インフラ／ネットワークエンジニアのためのネットワーク技術＆設計入門 第2版」や「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン」など素晴らしい書籍の著者である、みやたひろしさんの書籍であるという点で、とてもたのしみにしていました。 ポートの状態などを確認する単体試験、機器を接続してルーティングなどを確認する結合試験、冗長機能が正常か確認する障害試験、ほか性能試験や長期安定試験について、考え方や手順などが書かれています。 初学者の頃に、現場の先輩に試験の方法を教えてもらい「こういうのありがたいなぁ。
書籍「評価指標入門」の出版に寄せて 〜監修の想い（O・MO・I） - 株式会社ホクソエムのブログ
監修させていただいている評価指標入門なんですが、株式会社ホクソエムの代表取締役CEOである私、牧山幸史（以下、コージー牧山）、はじめてこの企画を聞いた時は「その特徴は単に評価指標をまとめた辞書やないかい！そういう”売れそうだから書く”みたいな商業的なマインドが学術界の価値を貶め云々」と思ったのですが、上梓された高柳さん（タカヤナギ=サン）の壮大なるお話を聞いているうちに「これはひょっとして数理モデリングとしても奥深い世界が広がっているの？面白いかも！」と思い監修社として名乗りを上げた次第です。 一方、本書の内容と皆様の期待値がややズレているのではないか？と不安には思っておりまして、これは監修社として一肌脱いでおかなければいかんなと、自然界に存在する第５の力「期待値調整力」を見せなければならないなと思い筆を取った次第です。 以下、私、コージー牧山の視点で「書いてあること・書いてないこと・書き
現代のソフトウェア工学を示す「継続的デリバリーのソフトウェア工学」 - Shin x Blog
年末年始に「継続的デリバリーのソフトウェア工学」を読みました。新年を迎えて、気分を一新して開発を始めるのに良い本でした。 ソフトウェア開発に役立つプラクティスを示した本 学びのエキスパート 複雑さ管理のエキスパート 実践的なツール データに基づく指標 ソースコードに限らずに広く適用 ソフトウェア開発者としての矜持 TDD あちら側とこちら側 「継続的デリバリー」は 1 要素 さいごに ソフトウェア開発に役立つプラクティスを示した本 ソフトウェア工学とは、ソフトウェアの実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的アプローチの応用のことである。 1.2 「ソフトウェア工学と何か」 本書では、ソフトウェア開発の現場で役立つプラクティスを、ソフトウェア工学としてまとめています。ここでいう科学的アプローチとは、「特徴づけ」「仮説の定立」「予測」「実験」という形で思考を組み立て
技術書の予習と復習
どうも、株式会社プラハCEO兼エンジニアの松原です 最近若手エンジニアから「技術書や記事からのインプットが遅い、あるいは浅いことに悩んでいる」と相談を受けました。 (自分のインプットの巧拙はひとまず棚に上げて)自分は技術書を読む際は予習と復習を結構するタイプなので、自分なりに工夫していることについて書き残してみようと考えました。超オレオレ理論ですが、悩んでいる方の参考になれば幸いです 本の予習と復習 自分は技術書を読む前後でこんなことをしています: (予習)その本にかける時間を決める (予習)本から学びたいことを書き出す (予習)胡散臭い人に書かれたと考える (復習)仮説を作り、検証する (復習)自分の行動の変化を書き出す (復習)記事を書くか、人に話す 結構面倒だと思いますが、自分にとっては効果的でした 0. その本にかける時間を決める 自分がこれから説明する予習と復習は、めちゃくちゃ時
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
無料で読めるポール・グレアムの「ハッカーと画家」+αの日本語訳のみのまとめ
継続的デリバリーのソフトウェア工学 | Agile Studio
Tech LT #4 人を選ぶ技術
