阿部和也の作品一覧
「阿部和也」の「Webサイトパフォーマンス実践入門 高速なWebページを作りたいあなたに」「Game Programming Patterns ソフトウェア開発の問題解決メニュー」ほか、ユーザーレビューをお届けします！
- 作者をフォローする
- フォローすると、この作者の新刊が配信された際に、お知らせします。
作品一覧
-
Webサイトパフォーマンス実践入門 高速なWebページを作りたいあなたに
ビジネス・実用
-1巻3,300円 (税込)Webパフォーマンスの基礎知識から最適化テクニックまで！ 本書はWebパフォーマンスの実践書『Web Performance in Action』の日本語版です。Webサイトをより速くするためのテクニックを網羅的に、かつ丁寧に解説した一冊です。 Webパフォーマンスの基礎知識から、CSSの最適化、クリティカルCSS、画像のレスポンシブ化・最適化、フォント、JavaScriptの高速化、サービスワーカーを使ったパフォーマンス向上、データ転送の効率化、HTTP/2、gulpを使った自動化まで、Webページ・サイトのスピードをアップするために知っておくべき知識とテクニックを徹底的に解説しています。 【本書の特徴】 ○Webパフォーマンスを向上するためのテクニックやツールを全般的・体系的に学べる ○パフォーマンス向上テクニック、画像・フォントの最適化、HTTP/2と最適化フローを解説 【前提知識】 ○Web開発の基礎知識（HTML/CSS/JavaScript） ※本電子書籍は同名出版物を底本として作成しました。記載内容は印刷出版当時のものです。 ※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。 ※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。 ※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。 -
Game Programming Patterns ソフトウェア開発の問題解決メニュー
ビジネス・実用
4.81巻4,180円 (税込)開発経験に基づくパターン実践の極意! パターン誕生の背景/エッセンス/適用条件/サンプルを解説。 ゲームプログラミングを含むソフトウェア開発の現場で、デザインパターンをより的確に利用するための解説書。著者は、米国大手ゲーム会社エレクトロニック・アーツでゲーム開発に従事。その経験に基づき、GoFや著者独自のパターンについて考察。より容易に変更できる洗練されたアーキテクチャ、ゲームに求められる実行速度といった視点を重視しつつ、幅広く応用できるパターンやゲーム必須のパターンを取り上げています。本書は、『Game Programming Patterns』の翻訳書です。米国アマゾンで60以上のレビューを集め、その9割が星5つと評価されています（2015年8月）。 【以下、本書イントロダクションより抜粋】 私がこの本で提供したいのは、解決策のメニューのようなものです。この本の各々の章では、単独でコードに適応可能なアイデアを解説しています。役立つものをメニューから選んで組み合わせることができます。
ユーザーレビュー
-
-
Posted by ブクログ
ネタバレWebフロントエンドの複雑化に伴い、フロントエンドの設計手法の整備は現代の重要な課題だ。
そんななか、複雑なフロントエンドを何十年も構築してきたのは『ゲーム』の世界だ。
つまり状態をUIに変換していくにあたりどうモデリングするか、ゲームプログラミングからこそ学ぶ点があると思い、本書を手に取った。
この本は、いわゆるデザインパターンをどう道具としてフロントエンドで使っていくかを表したものである。
特定の技術スタックに依存した内容でないため、普遍的な知識を学ぶことができた。
特にコマンドパターンは見方を変えればFluxであり、現代Webフロントエンドにも繋がってくる考え方だ。
やはりこうした自分の領域にとらわれないすぎない知識収集が、最先端を歩んでくためには必要になってくるだろうと再確認した。 -
-
Posted by ブクログ
■ 感想
いい本でした。知っていることもあるものの、知らなくて勉強になったことや、次にコード書くときにもう少しうまく書けそうな気がする本でした。
Unityを使ったことがあれば、すでに利用しているパターンもあるので、Unity使っている人であれば入りのいい本でもあると思います。すでに利用していたパターンでも他との対比もあり理解が深まったり、どういう意図で作っているのかがわかるようになるので、より利用しやすくなります。
難易度的が低い本と言えず、ある程度の期間、ある程度のサイズ感の開発したことがないと理解しきれないと思います。Unity触って3〜5年目ぐらいで、書いてるコードがこんがらがってきて、うまく整理できないみたいな悩みがある人は一度読んでみるのもいいかもなと感じました。
パターンとしてコードの抽象化（分離）の話もありますが、データの最適化の項目もあり、そういう方向が好みの人にも合うと思います。
■ 抜粋
- よいソフトウェアアーキテクチャの本領が発揮されるのは、コードを読んで理解するときだと思っています。コードを脳に読み込むのは非常に時間のかかる処理なので、読み込む量をへらす方策を見つけることに意義があります。（P.12）
- 「分離」の定義はさまざまですが、2つのブログラムが「分離できていない（結合している）」というのは、一方を理解しないと一方も理解できない状態だと私は考えています。（P.12）
- ソフトウェアアーキテクチャを考える主要な目的は、この「次に進む前に頭に入れておかなければならない知識を最小にすること」です。（P.12）
- 面白いゲームを早くすることのほうが、早いゲームを面白くするより簡単です。（P.15）
- 「単純なコードは、書く時間も短くなる」とは言ってはいないことに注意してください。全体のコードの量が減れば、それを書く時間も短くて済むと考えるかもしれませんが、良いコードは蓄積によって得られるのではなく、精製によって得られるのです。（P.17）
- 抽象化と分離により、プログラムの改良は早く簡単にできるようになりますが、取り組んでいるコードがそのような柔軟性を必要としていると確信できるまでは、抽象化と分離に無駄な時間を割くべきではありません。（P.18）
- （メモ）AvatarAdjusterがInputHandlerをCommandとして受け取ることで実行する。この形を取れば、avatarの生成のタイミングか、画面遷移のタイミングだけに絞れる？（P.26）
- 原則は「変数のスコープは、処理に支障のない範囲で可能なかぎり狭くする」です。（P.93）
- 常にバグのないコードを書いているように思える憧れのコーダーたちも、別に超人的なプログラマーなわけではありません。彼らは、どんなコードにバグが入りやすいか本能的に知っているので、そのようなコードを避けているだけなのです。複雑な分岐と、変更可能な状態—時間経過とともに変化するフィールド—はそのようなバグの入りやすいコードのうちの2つです。（P.101）
- 可変更新間隔
私の知っているゲーム開発者のほとんどがこの方式を推奨しないことをわかった上で、ここに挙げています。なぜよくないないのかを知ることも意味があると思うからです。
- 早すぎる場合にも遅すぎる場合にも対応しています—ゲームが実時間に追いつけない場合は、追いつけるまで更新と描画の時間感覚を延長します。
- ゲームは非決定論的になり、不安定になります—先に述べたとおり、これが非常にやっかいな問題なのです。この方式では、物理シミュレーションとネットワーク通信がとりわけ扱いにくくなります。（P.153-154）
- 間違いは誰もが犯すものであり、創造的なプロセスのk塩となるものです。「取り消し（アンドウ）」を可能にするなどしてエラーをさりげなく処理することで、ユーザーの創造性は高まり、より良いものを作れるようになります。（P.192）
- 言語設計者はプロもアマも文法の定義を甘くみすぎています。パーサに楽をさせる文法を定義するのは簡単です。ユーザーに楽をさせる文法を定義するのは難題です。（P.197）
- （P.202）サブクラスサンドボックスパターン（強い継承を使いたい場合）
- パターンの適用条件
- 派生クラスの多い基底クラスがあるとき。
- 派生クラスが必要としている操作や処理を、基底クラスですべて提供できるとき。
- サブクラス間に共通するビヘイビアがあり、同じコードを使ってコードを簡略化したいとき。
- 派生クラスとシステムプログラムの結合を最小化したいとき。
- 派生クラスは、基底クラスを介してコードベースの他の部分にアクセスするのですから、必然的に基底クラスは派生クラスがアクセスする必要のあるシステム内のあらゆる箇所と結合することになります。（P.202）
- 最近ではオブジェクト指向言語の継承に対する批判を目にすることが多くなりました。継承は問題を起こすことが多く、基底クラスと派生クラスの結合ほど強い結びつきはありません。（P.202）
- ゲームのビヘイビアを定義するのに、スクリプト言語やその他の高レベルの手段を利用すると、実行時の効率はいくぶんか低下しますが、生産性はめざましく向上します。ハードウェアは進歩し続けますが、人間の脳のほうはそうはいきませんので、生産性の向上に重きを置くことがますます重要になってきます。（P.220）
- どんなプログラミング言語を使っていても、コツをつかんでしまえば、思いどおりにコードを書くのはそんなに難しいことではありません。難しいのは、実行させたいことが変わったときに簡単にそれに合わせられるコードをあらかじめ書いておくことです。（P.231）
- UnityフレームワークのクラスGameObjectはすべてコンポーネントでデザインされています。（P.254）
- Data-Oriented Design（P.298）
- 最適化を適用する第1の条件は、実行速度に問題があるときというのが普通です。データ局所化パターンも同じです。コードベース内のあまり実行されない部分にこのパターンを適用することで時間を無駄にしてはなりません。最適化すると、コードは複雑になり柔軟性が低くなるので、不必要な最適化を行うと後の作業が面倒になります。（P.299）
- Cachegrind（P.299）
- AngularなどのブラウザサイドのWebフレームワークでよく見られます。ブラウザ内で変更され、サーバに送信する必要が生じたデータを管理するのに、ダーティフラグが使用されます。（P.332）
