  |
はてなキーワード: アーキテクチャとは
最近Google japanが採用を強化したことから、Google社員のブログがはてブに上がってくるのをよく見る。
それを見たWebエンジニア界隈のTwitterでは「Googleのおかげで給与水準が高まった」「企業の人事部はGoogle見て焦ってるんだろうな」なんてツイートが受けている。
が、GoogleはWebエンジニアなんてお呼びじゃないことに気づけ。時間の無駄だ。
Webエンジニアみたいな、「高卒だろうが院卒だろうが実力が全て」っていう弱肉強食の世界じゃないってことだ。
学歴重視だ。Googleが言う「実力」っていうのはWeb系とは前提が違う。学歴がないやつは眼中にない。
Webエンジニアの中には、「CS専攻じゃないし、むしろ文系上がり」なのに異様な力を持つやつが居る。
だが、そういう奴らはGoogleの面接は突破できないだろう。
「アルゴリズムを書け」「計算量は？」どれも基礎的な内容を聞いている。
極めて一般的だが「Web業界に入ってプログラミングを覚えた」やつには馴染みの薄い題材だ。
もちろん、Webエンジニアであっても、そんな問題は解ける。解けないやつは実力もないことは確かだ。だが、叩き上げにとっては「知ってはいる」程度だ。体が覚えるほどに練習はしていない。
Webで最も必要になるのは「遅い場所を計測しつつ探し出す」「ネットワークを如何に使わないか」「理解しやすいアーキテクチャは何か」なんて思考だ。
Webで必要なことと、Googleが求めることは乖離している。
Googleが求めているのは、「世界を変えるためのソフトウェア」を作る能力であって、現状に存在しているツールを使いこなすことではない。ツールを改良することでもない。
Web系は他の分野に「Web屋」だと馬鹿にされていることを自覚しろ。「軟弱」、「人が作ったものを組み合わせてるだけ」と馬鹿にされていることを思い出せ。
Turing completeでも聞け。配信者が如何にWeb屋を軽視しているかわかるだろう。
Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事。
---
タイミングの問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleはデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部からの技術的観点からの技術統合を行ってきました。他社でもその視点は存在していますがGoogleにはその点に固有のアドバンテージが存在します。
その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています。開発者は制限の無い計算資源が利用でき、何よりもマルチプレーヤーをサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化が必要でした。我々のプラットフォームではクライアントもサーバも同じアーキテクチャの下にあります。これまではクライアントとサーバの間のpingに支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一のインスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞のヘッドラインを飾ることが可能な技術です。
両方です。
ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中のデータセンタ間を接続しています。米国の西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシが予測可能でそれに従い設計を行うことができます。
StadiaはYoutubeの技術と深く結びついていますが、実際には一歩引いています。今日のゲーム業界を考えてみて下さい。2つの世界が共存しています。1つはゲームをプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeでゲームを毎日見ています。2018年には述べで500億時間がゲームを視聴するのに費されています。時間と人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。
つまり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザが他人を楽しませる場所です。
だから我々のブランドはStadiaといいます。これはスタジアムの複数形です。スタジアムはスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したかを意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。
その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fps、HDRとサラウンドをサポートしました。さらに開発者が必要なインフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDRで画像を送信することが可能です。だからあなたのゲーム体験の思い出は常に最高の状態になります。
プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogleは4Kでストリームします
共有が友達だけか、世界中に公開かも自由に選択可能です。Googleはユーザに制御を明け渡します。もしユーザがYoutubeで公開すれば誰でもリンクをクリックすることでそのゲームを遊ぶことができます。
そう。そしてこれはマルチプレーヤーゲームのロビーの新しい形となります。Youtubeのクリエイターなら誰でもがファンやチャンネルのsubscriberを自分のゲームへと誘うことができます。生主として、Youtubeのクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。
Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初のサービス立ち上げから全ての画面への対応を行います。TV、PC、ラップトップ、タブレットに携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。
我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りからも解放したいのです。パフォーマンスに優れ、リンクをクリックすればゲームは5秒以内に開始されます。ダウンロードもなく、パッチもなく、インストールも必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップでChromeブラウザを使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラが動作します。そして、もちろん、我々自身のコントローラも開発中です。
コントローラを自作する理由にはいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術に採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続でDC内のゲームに直接接続することです。ローカルのデバイスとは接続しません。
その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。
そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術とマイクを用います。ユーザの選択により、ユーザはプラットフォームとゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaがマルチプレーヤーゲームを指定した友人と共に直ぐに開始します。
我々はゲーマーを可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーがゲームを起動したら直ぐに友人とゲームを開始したいと考えています。ゲーマーはUIに時間を費したくは無いのです。
誰かが言ったことですが、現在のコンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム機自体の更新や、ゲームの更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeにシェアできます。
Youtubeが観られるならどこでもStadiaは動きます。
Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます。画像はNetflixやYoutubeから直接受け取ります。Stadiaの場合、StadiaコントローラからChromecastへとこのゲームのインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画のストリームを受け取ります。クライアントはとてもシンプルです。行うのはネットワーク接続、ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力はコントローラが扱います。ビデオと音声とネットワーク接続はChromecastの基本動作で全て既に組込まれています。
そうです。とても良く出来ています。WiFiに繋ぐだけです。コントローラにはWiFiのIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手にChromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができます。デジタルパッドでUIを操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができます。Chromecastは5W位下です。Micro-USBで給電可能です。典型的なコンソールは100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画の再生だけです。従ってAssassin's CreedやDoomや他の重いゲームがあなたのスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホで10時間でも遊べます。
今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からはYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。
サービス開始時から提供されるサードパーティによる解決手段をサポートしています。他にもアイデアがあります。しかし今は話せません。
良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術を提供していました。StadiaはLinuxベースです。グラフィックAPIはVulkanです。開発企業はクラウドにインスタンスを作成しますので、開発キットも今ではクラウドにあります。しかしクラウドだけでなく、開発社のプライベートなDCでも、机上のPCでも可能です。
もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブがゲーム開発での標準となるでしょう。
デベロッパーやパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要なツールや技術について考えていると思います。しかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営に必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています。
米国では全ての必要な場所に展開が終わっています。Project Streamの試験に必要な環境は2018年末には整いました。我々はGoogle社内で、Google社員を対象に2017年の始めから2年間の間、プライベートなテストを行ってきました。2019年には米、加、西欧、英にて 
ツイートシェア
技術責任者だかエンジニアマネージャだかしらんけどおまえクソコードしか書けねーだろ。
つかほぼコード書いてないじゃん。そのくせ基盤部分とかアーキテクチャ設計に入りたがる。
そして飽きたら社員に任せて自分はドロン。基盤の設計がクソだから誰も触りたがらないしメンテコストがヤバいのよ。
自分でコード書けないのは自覚してるらしいけど、そんならそのポジション空けろよ。
おまえがそこにいられる理由はただひとつ。創業メンバーだから。
そのくせ知識だけはいっちょ前にひけらかしてくるからまたウザイ。
おまえネットベンチャーでちょこっとエンジニアやってた経歴しかないじゃん。
勉強会とかセミナーとか起業コンテストとか行きまくってるミーハー野郎じゃん。
技術選定のポリシーも何もなくて流行り物を選ぶだけ。技術力ちゃんと身についてます？
その技術によって採用のやりやすさだったり、外注エンジニアの単価が決まること理解できてる？もっと会社のこと考えろよ。
「この会社でエンジニアとして成長して市場価値を高めよう」とか言っちゃってるのもう笑えない。
何度も言うけどおまえコード書けねーじゃん。なんでそんな上から目線なの？自分のキャリアは自分で決められるから。
いや、別にそういう制度があっても全然いいのよ。会社として用意してるのは素晴らしい。
でもコード書けないやつが考えるキャリアアップなんてクソみたいなもんでしょ。
プログラマとしてクソみたいな実力しか無いのにトップに立ってるつもりなのやめろよ。
テスラの車は、トヨタとメルセデスの古いプラットフォームから派生した純電気自動車だ。まあ、旧型カムリだ。各ECUとインパネ(IC)間がCANバスで結ばれ、ゲートウェイを通して車内インフォテインメント(カーナビ)が接続できる。そして、ゲートウェイにはセンターコンソール(MCU)、自動運転モジュール(APE)が接続されている。まあマツコネみたいなものだ。ただし、通常のカーナビと違い、このMCUはTegra 3(旧世代)または超高速なIntel Atomプロセッサ(現行)が採用されている(マジ)。そして、海賊版のUbuntu GNU/Linuxを実行している(マジ)。そしてLTE回線に直結し、テスラ本社のサーバ(mothership.tesla.com)にOpenVPN接続している。
古いモデルは3G、新しいモデルはLTEモジュールを標準搭載している。明示的に特別注文しない限り無効化や取り外しは行われない。本社Mothershipは各車の動作状況を監視・操作するほか、オートパイロット起動通知を受け取り、またssh接続のためのパスワードを保持する。これによりファームウェアのrootが取られた場合にオーナーを蹴り出したり、あるいは事故発生時に「オートパイロットは(直前でエラーを吐いて運転をぶん投げたため)使用されておりませんでした」と発表するなどいち早くメディア対策を行うことができる。
更新パッケージは前述のOpenVPN経由でダウンロードされ、その中にAPEファームウェアのほかにもドアハンドル、ブレーキ、インバータECUなどのファームウェアが含まれていれば、MCUが更新処理を行う。これまでに配信されたアップデートには、Linux Kernelを含むMCUのOS更新、インバータ出力アップ(設計の三倍程度)、緊急制動距離の延長と短縮、自動緊急ブレーキの追加、自動運転の警告間隔延長・短縮(事故報道の頻度に応じて調整)、自動運転機能そのものの搭載や根本的な入れ替えなどがある。現在の仕様ではファームウェアバージョン表記はYYYY.WW.x.y.zで、GitのコミットIDが末尾に付き、平均して月2回程度のローリングリリースが行われる。つまりリポジトリのheadがざっと社内検証を通るとLTEで降ってくる。非常にまれなケースでは社長(@elonmusk)の「やりましょう」ツイートから数時間でバージョンが上がる。
純電気自動車なので、エンジンは搭載しない。代わりに車体下面にリチウムイオン電池パック(ノミナル電圧480Vまたは400V)を搭載する。パックは火薬式ヒューズを含む高電圧コンタクタ(リレー)を介してモータおよびインバータと接続され、インバータはモータ進角を監視しながらスロットル指示に合わせて三相交流電源を供給する。この辺りはCPUファンと変わりない。
普段AWSならこういうアーキテクチャが良いとか議論しているのを見かけるので、
エンジニアの人から見た、銀行のインターバンクの仕組みとか、ドル本位制の仕組みとか、そのあたりってどう判断してるのか気になった。
インターバンクで複数の銀行間がつながっていて、普段は特に問題ないのだが、1つの銀行が問題を起こすと、インターバンク通じてバタバタ他の銀行も死んでいき、政府の介入が必要な事態になる。
クラウド上のあるサービス間を監視し続けていて、債務不履行が起こってないかチェックしているが、いざ大きなエラーが出ると全部が死ぬ。冗長性担保してないのかよ。
ドル本位制もおかしなもので、アメリカ国内でやばいってなりドルが足りなくなったら、輸出入の取引に使用しているドルが足りなくなり、他の金融での資産があったとしても支払いができなくなるわけで、冗長性が足りない気がする。
Suicaには残高たくさんあるのだけど家に忘れてきてしまって、Edyの残高足りなくて買い物できん、って状況があるのだから、似たようなものかもしれないが。
日本だと国内需要に支えられているにもかかわらず、製品やサービスに問題な無かろうとも、少ない輸出入の割合が全体に影響するわけで。
今スパコンと呼ばれているものがなんであるかは取り敢えず無視していいし、ラズパイ並べたものがスパコンであるように感じたとしても取り敢えず別の何かとした上で
一応レギュレーションは想定するなり増田の方で決めてもよかったんだが、
この問題は「ラズパイの群れとスパコンを比較して、ラズパイの群れにだけある弱点を指摘しましょう」
ってつもりで答えてみて。
条件は以下。
■ラズパイ側
無限の速度のWi-fiで繋がれている。(ありえない仮定とか言うな。この条件でもちゃんと答えを出せるはずだ)
CPU周波数は仮に1GHzとでもしておこうか。メモリ1GB。コア数は1。
これが、世界各地に1000あるとしよう。
■スパコン側
1000コアの各コア1GHz動作のCPU（CPUアーキテクチャはラズパイと同じ）
この条件で、「スパコンで実行すると割とすぐ計算できるけどラズパイで計算すると果てしなく時間かかるだろ」ってプログラム例を挙げてみてくれ。
Green500と経済性は何の関係もないし、なんでそこで経済性を持ち出すのが訳がわからない。
ケーザイセーなるものは今のどの指標でも測ることはできないし、それを問題視するならケーザイセーとやらを評価するランキングを作れ。
アーキテクチャを変更したらソフトウェア更新コストがかかるなんてのは当たり前のことだし、そもそもお前の大好きなx86ですら世代を経るごとにコードを書き換えないと性能が出ない。
いい加減見苦しいぞ乞食。そろそろ黙れ。
そもそもパソコンの世界がx86による統一が図られたあとだから、ほぼすべての端末で艦これが動くのであって、HPCの世界にあっては、なにかを動かすためにはアーキテクチャごとに書き換える必要があるというのは、少し考えれば分かることだろうに…
おっと、いちいち書き換えるなんてコストが高すぎるとかその手の批判は過去数十年繰り返されてきたし、今更そんなものに答えたくないからやめてくれ。
うーん、あんまりその原点くらいに立ち戻るのは嫌なんだけど、Pezy以外がGreen500狙ってなくね？ って指摘はどうなん。ランクにはTop500だかの併記もあるし、他のチームがGreen500にあえてエントリしたとは言いづらいようにも見えるわけだが。
最初の方に言った通り、アーキテクチャ的には汎用なブツを利用してるしな。
それ自体は間違いではないけれど、それ金メッキじゃね？ って指摘はあるじゃろ。
そもそもお前の最初の論点は「Green500は意味なんかないランキングじゃん」だったはずだが、なに論点逸らしてんだテメー
せっかくだから真面目に答えてやろう。
まずHPLなりTop500なりでググれ。
四則演算レベルのベンチマークとか意味不明。そんなんあらゆる計算は四則演算で表せるに決まってんだろ。舐めてんのか
あとな、そもそも今日においてRISCだのCISCだのの分類に意味はない。CISCの代表格のx86が命令をマイクロオペレーションに分解して実行している以上、x86だってRISCだ。
それにな、アーキテクチャが混ざった環境下であっても、その性能を一定の指標のもと、正しく測ることが可能と大多数の人間に考えられているから、HPLは問題があると言われつつも40年間ベンチマークとして成立してんだよ。お前のようなニワカがギャーギャー言ってるようなことはとうの昔に語り尽くされているわけ。
もちろん、HPLに問題がないかといえばそういうわけでもない。様々な批判はある。代替するためにHPCGをはじめとしたベンチマークが提案されている。
んじゃ結構真面目な話するとPezyは周波数低いRISCなんだから消費電力低くて当然じゃね？ とちょっと調べて思ったりした。
んで、そのRISCとCISCとその他混ざったアーキテクチャの中で統一した指標を出すために回してるプログラムってなんだ？ ってことが気になった。
結局MIPSだかFLOPSだかをスコアにしてるんだから、スパコン用のプログラム的なものは回してなくて四則演算レベルのベンチマーク回してるだけなのでは説がある。
もっというと、ワイや増田やぱそこん先生はこのスコア見て何を導きだせばいいんだ？ っていう根源的な問題もある。
Hacker NewsはマイクロソフトのインターンEdge開発者がGoogleがYouTubeで他社製ブラウザの速度を妨害するような細工をしていたと告発。67ブクマを集める。今日GIGAZINEが日本語記事を書いていてそっちも盛況。
https://news.ycombinator.com/item?id=18697824
A Style-Based Generator Architecture for Generative Adversarial Networks に5ブクマ。ブクマした人は興奮していらっしゃる様子。
http://b.hatena.ne.jp/entry/s/arxiv.org/abs/1812.04948
[1812.03651] Serverless Computing: One Step Forward, Two Steps Back に7ブクマ。
PhoronixはLinuxカーネル開発者がインテルの32bitアーキテクチャx32のサポートを止めるか続けるか議論しているという記事に3ブクマ。
NMEはベストアルバムオブザイヤー2018に4ブクマ。100アルバムを紹介。The 1975のアルバムが1位。
https://www.nme.com/blogs/nme-blogs/best-greatest-albums-of-the-year-2018-2419656
WIREDは国際アムネスティにトロール・パトロールというプロジェクトがあって、そこの報告書の紹介に2ブクマ。Twitteは女性を攻撃したり脅したり嫌がらせしたりに我慢を強いられる場所になっていて女性にとっては害毒だという。増田民必読？な記事。
https://www.wired.com/story/amnesty-report-twitter-abuse-women/
PS3は当初独自GPUを予定してたけどうまくいかなくて、nvideaに泣きついて型遅れのGeForce7800GTXを採用することになった
GPU設計が高度化していくなかで5年に一度のばくちをするのは危険な時代になった
そしてPS4はPSの歴史のなかでも異例といえる最初からPCを意識した構成で、PCで良いじゃんみたいなことを言われながらの発売だった
しかし同一品を大量に売るコンシューマーのビジネスモデルはPC的なPS4でも発揮され好調な売れ行きだったわけだ
そんななか、PC界隈が怪しくなっている
ご存知のようにインテルはicelakeの製造に手間取っている
AMDはTMSCに依頼し、7nmのCPUGPUをインテルより先に投入するようだが
7nmの先はあるのか、PCの限界が来るのではないかという意見は多い
一方でシュリンクが限界を迎えようとしている時代に新しい流れが出てきた
この流れに乗ってソニーは自分たちでもう一度CPUGPUを設計段階から開発するなんてことはあり得るんだろうか
まぁありえないだろう
前回はオブジェクト指向プログラミング（OOP）の使いどころを学ぶために、MVCフレームワークを使ってみました。（ほんの触りだけ）
OOPに関する有名な本はたくさんあります。Amazonでレビューの評価が高い本は、定番の本が多いです。
だけど分厚い本は、ある程度プログラミングに慣れてから読んでみないと、最初は意味がチンプンカンプンだと思います。
（最初は意味が分からなくても）なるべく早い時期に1回は読んでみた方が良いと思う本をピックアップしてみます。
この本は、OOPの概要、基礎知識がコンパクトにまとめられています。
この本を１つの目安にして、今後の学習指針を立ててみて下さい。
https://www.shuwasystem.co.jp/products/7980html/4614.html
この本は、OOPも含むプログラム設計のノウハウや原則をまとめて紹介しています。
カタログ的に、各テーマを広く浅く紹介してるだけなので、詳しい内容は個別に掘り下げる必要がありますが、それでも概要を知る上では役立ちます。
今すぐ理解できなくても、「あー、そういえば、そういう話もあったな」と後で思い出せる程度に眺めておくだけでも十分だと思います。
（第3章にある「UNIX哲学」は、初心者にとってプログラミングの良い指針になると思います。）
https://gihyo.jp/book/2016/978-4-7741-8361-9
この本は、上記2冊の内容を具体的な事例で説明しているような本です。
これらの内容はそれぞれが1冊の本になるほどボリュームの多い内容ですが、本書ではそれらのエッセンスをうまくまとめていると思います。
サンプルコードはRubyで説明されていますが、何らかのOOP言語を使ったことがあれば、Rubyの文法を知らなくても、だいたい意味は分かると思います。
プログラミングの入門書を数冊読んだ程度の段階では、上記の本を読んでもいまいちピンと来なくて、意味が理解できないと思われます。
しかし、将来自分がぶち当たるであろう壁、課題を先取りしているつもりになって、「こんなことも考慮してるんだな！」と雰囲気だけでもつかんでもらえればいいんじゃないかと思います。
PHPを使って、OOPの基本的な仕組みを説明をしたので、PHPの入門書を挙げるなら、とりあえずこの１冊。
自分にとっては分かりやすい説明だと思うのですが、類書はたくさんあるので、実際に本屋で確かめてみましょう。
Javaの入門書で文法の基礎を学んだら、次に読んでみたい本。
「デザインパターン」という知識があると、他人が書いたプログラムを読むときに役立つと思います。
（なんでこういう書き方をしてるんだろ？とか、定番の書き方＝パターンがいくつかあるので。）
グチャグチャな汚いコードを綺麗にスッキリさせるノウハウがあります。
リファクタリングに関する知識を学ぶと、プログラムの書き方が改善されて、後で自分がメンテナンスするときに苦労が減ります。
今の段階では、パッと思いついた本はこんなかんじだけど、他にも良い本はいっぱいあります。
自分が分かりやすいと思う説明方法と、他人が分かりやすいと思う説明方法は、必ずしも一致してない場合が多々あります。
図書館や本屋で、実際に本の内容を確かめてみて、自分にとって一番分かりやすいと思える説明の本を探してみてください。
リファレンス（文法の辞書など）は、読む頻度が多ければ、買って損はしない＝元は取れると思うので、自分への投資だと思って、必要な本は買うようにしましょう。
（プログラミングの専門学校とかに行ったら、学費が何十万円もしますね？それを思えば本なら安いものです。）
プログラミングに限らず、他の勉強でも同じだと思いますが、最初は知らないことの連続ですね？
プログラムのサンプルコードを見ても、意味が分からなくて、中身が不明な「ブラックボックス」に見えると思います。
でも、いったん意味が分かるようになると、霧が晴れたように、急激に視界が開けてきます！
学習曲線で言えば、滑らかな右肩上がり（／）ではなく、ある時グイッと変わる階段状（＿l￣）の変化に近いと思います。
なので、最初は分からないことが多く感じても、それが当たり前なので、あまり気にする必要はないです。
理解を早める補助として、上記のような参考書も活用されてみて下さい。
今回までで、手続型言語（構造化プログラミング、オブジェクト指向プログラミング）の基本を知りました。
次回は、問合型言語（SQL）を学び、データベースを使いましょう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書 ←★今ここ★
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
：