  |
はてなキーワード: アーキテクチャとは
さて、いよいよ新年である。ただでさえ新年というものは未来展望的気分が高まる時期なのであるが、それに加えて「平成最後の」という扇情的枕詞が付くのだからなおさらである。という訳で、俺様も自分の所属する業界ーAI業界ーについての予言をやらかしてみることにする。題して「AIブームその後」。このお題通り、AIブームはもう終わる。以下は、「終わり」と「その後」についての妄想的予言である。
今世間で大流行りのAI、いつから始まったのかは諸説あろうが、今「ブーム」の真っ只中であることは間違いない。そしてもちろんブームはいつか終わる。だから「今のAIブームは終わる」という予言は、「大地震はいつか来る」レベルの実のない予言でしかない。地震予知同様、肝心なのは「いつ終わるのか？」である。ズバリ、それは「今年のどこか」であると予言する。もちろん、この予言の成否は「終わり」をどう定義するかにかかっている訳だが、それはブームのピークであるとしておく。そして、いつがピークだったのかは、下降トレンドに入って相当経った後からでしか分からないものである。だから、予言の当たり外れが判明するのはずっと後になるかもしれないが、今のAIブームのピークは今年（の後半）のどこかであり、その後ブーム比較的急速に衰退するであろうと予言する。それではなぜAIブームが終わるかというと、それはブームに終了を強いる出来事が発生するからである。それは世界的リセッションである。戦後の世界的リセッションは8〜10年周期で生じているが、今年は前回の2008年のリーマンショックから11年目である。さらに、昨年末から世界中で株価の変調が見られている上に、米国の長短金利差逆転などの様々な有名な指標も軒並み危険信号を発している。（今回は、日本近隣の地政学的リスクの恐怖も大きいことも見逃せない。）ブームにとどめを刺すのは不況の到来である。
では、なぜ不況が来ればAI業界は衰退するのか。AI業界の現場にいるものなら誰でも知っていることだが、今のAIブームを支えている一大勢力は、「ヨソもやってるからウチも」という特オチ恐怖に取り憑かれた奴らか「俺の手柄にするんでアイデア挙げろ！」という出世欲に駆り立てられた連中である。（俺はこういう需要を「虚需」と呼んでいる。）こういう状況でもし不況の嵐が吹き荒れたらどうなるか。「ヨソ」は一斉に止めるし、不況期にAIなどで手柄が上げられるはずもない。大体不況下では、AIどころかIT系全般の出費が広範囲にカットの対象となるのが普通である。「やらなくてもすむ」はもちろん、「やったほうがよい」までカットされることになる。そんな中、効果の不透明なAIなぞ構われるわけがない。一大勢力は潮が引くように退場する。需要が一斉に収縮した後にブームが維持されるはずがない。ブームの息はこれで止められる。これこそAIブームの終焉である。
ブーム終焉後の業界の状況は一言、「惨状」となるはずである。現在雨後の筍のように湧いて出てきている従業員数名〜2、30名程度の弱小自称AIベンチャーは、元栓の閉鎖によって軒並み一掃されるだろう。（ちなみに俺は、今のブームの走りのビッグデータブームが盛り上がり、世間が機械学習って一体何なんだと騒然となった時、既に10年の機械学習の「実務経験」を持っていた。このチャンスに広く活躍の場を期待したとしても、それは不自然ではないと同意してもらえるだろう。だが、実務経験が長いということは、それだけ年齢を重ねているということでもある。そういう訳で、経験者であったにも関わらず90社以上から書類審査のみで不採用とされている。来るべきブーム後の厳冬期に、もし自分を不採用とした会社が倒産したら、転職用に作った応募企業一覧のその会社の名前の上に髑髏マークをつけてやろうと計画している。）だが、今のAI業界に、不況から生じる惨状への恐怖感を予感し、震えるものは驚くほど少ない。なぜなら、今のAI業界に属するほとんどの会社は、2011年ころのビッグデータブーム以降、雨後の筍のように生えて出た会社がほとんどだからである。不況による惨状はリーマンショックの時にも生じているが、その時の惨状を知っているのは、そのころ既にデータ解析で飯を食っていた会社、例えば「インサイダー」社や「DCCCC」社などごくわずかである。何のことはない、ほとんどの会社は単に無知だから恐れていないというだけである。
それでも「いや、もうこれからの社会はAIなしでやって行けない。不況の影響はあろうが、業界がしぼんでしまうなどあるはずがない。それどころか、不況だからこそAIでの効率化が必要となるだろう。お前は馬鹿か？」と言う人もいるだろう。確かにこれについては、人によってはさらなる説明が必要かもしれない。そういう人向けに日本のAI業界の特徴を解説しておくことにしよう。今のAI業界の大半は、いわゆるベンチャーの体裁を取っている。世間一般では、ベンチャーと言えば、「これ」と頼むトンがった自社プロダクトで世間に勝負をかけ、その質とシェアを上げるために社員は脇目も振らずそれだけに掛かりきりで、社長は青い顔で金策に走り回って投資家との神経戦で消耗し、それでも社長以下社員全員が夢を信じて失意と高揚の間を激しく振幅する、というステレオタイプが広まっているだろう。ところが、事情を知らない人は全く理解できないであろうが、今の虫のように湧いて出ている自称「AIベンチャー」のほとんどは、驚くことにこれらの特徴を全く持っていないのである。全く、である。そういう会社は、なによりも第一に世間に問うべき自社プロダクトを持っていない。（中には「自称自社プロダクト」を持っている会社もあるにはあるが、それは普通のサービスに「AI風味」のふりかけを掛けただけのものだったり、それならまだしも、フリーソフトに皮を被せただけの代物を恥知らずにも「我が社のプロダクト」と言い張っている呆れるしかない会社もかなり多い。）さらに社長は金策に走り回るというわけでもなく、そもそも投資家との接触すらない社長様も多い。このように書けば、自社プロダクトがない（あるいはタダで拾って来たものをケースにいれただけのものしかない）上に投資家とのパイプもないベンチャーって何なんだ？それじゃあ会社はどうやって維持されるのか？社長、社員は何をやっているのか？と疑問を持つ人が出るのは当然だろう。
ここに日本のAI業界の特殊性がある。それは、日本ではAI業界がIT業界の一部をなしていることと、日本のIT業界の特殊性の2点からなる。後者についてさらに言えば、日本のIT業界の特殊な商習慣、「多重下請け」と「人売り人買い」がその二本柱である。日本の下流IT業界のほとんどは、自分では自主的、実質的な仕事をせず、上流の丸投げを右から左に仕事を流すか、最下流で（プライドは一流だが）下流にふさわしいレベルの下層プログラマをブラックな環境で労働させ、中間搾取を貪るのを「商売」としている。あるいは「とにかく人手が欲しい」という現場に人夫（ほぼ完全に素人という場合すらある）を送り込み、その上前で暮らしている。そのようなIT業界の一部として発生した日本のAI業界も、その悪弊を完全に引き継いでいる。大半の自称AIベンチャーも、自分では自主的、実質的な仕事をせず、上流の丸投げを右から左に仕事を流すか、最下流で（プライドは一流だが）それにふさわしいレベルの「大学で統計学の単位を取りました」レベルの「自称データサイエンチスト」や行き場を失った理系の成れの果てにそれらしいプログラムを組み立てさせる、あるいは「とにかくAIやれる人手が欲しい」という現場に自称や成れの果てを送り込み、上前で暮らしているのである。結局、収益構造的にはよくあるニッポンのIT企業そのものでしかなく、最も大切な技術力は極めて貧弱なのである。この状況は、日本におけるAI業界の悲劇性そのものである。確かにAI業界はIT業界との相性が良いのは確かではあるが、だからと言ってAI業界がIT業界の一部である必然性はない。また日本のIT業界の非人間的労働環境もIT業界にとって必然でないのも当然である。であるのに、日本ではAI業界がIT業界の一部として発展し、そのIT業界は技術水準も低く、労働環境的にも非人間的でブラックな環境なのである。その結果、AI業界も低技術悪労働環境となってしまっている。本来技術で勝負するべき日本のAI業界は、そもそもとても技術力では勝負できない見せかけだけの自称AI屋の集団でしかない。もちろんすべてがそうであるとまで主張するつもりはない。ほんのわずか（多分、多めに見て日本全国で十社ちょっと位だろうか）ではあるが、理論、実用面共に本格的にAI屋を名乗る資格がある会社が存在するのは事実である。だが大半の残りは自称AIベンチャーのただのIT派遣業に過ぎない。開発技術力もない企業がAIの看板を挙げて一体どうやって生き残れるのか。その方法があるなら是非教えて欲しいくらいである。
この状況を認識するなら、ブームが去った後の日本のAI業界の将来を予想することができる。簡単に言うと、それは二極化である。世間一般で妄想される「何か分からないが魔法のようにすごいことができるAI」を追求する（そして本当に実現できる）極少数の企業と、ルーチンワークで済む仕事を大量こなすこれまた少数の企業のどちらかに分類されることになるだろう。前者は既に述べた通りだが、後者については説明が必要だろう。まず、ルーチンワーク的AI業務の需要は、不況下であっても確かに必ず存在する。商売としてAIを応用するのなら、過不足なしの最適なレベルでの適用が当然であるが、世間には単純な技術の単純な応用で十分に効果が上がる企業も数多くあるからだ。こういう企業に対しては、いわゆるビジネスデータ解析と呼ばれる単純な技術（今はこれも立派なAI扱いであるが、そもそもこれがAIと呼ばれること自体どうかしているとしか思えない）のルーチン的な適用（に加えてコンサルティング業務、実はこちらの方がずっと大切で、金になる部分）で必要かつ十分である。そして、そういう仕事なら、わざわざ弱小ベンチャーに依頼するよりも現在既に実績を積み上げている「インサイダー」社とか「頭が悪い」社とか「蜂の巣」社とかの大手ビジネス解析屋に丸投げするのが確実である。さらに、そうなるとこんどは少数の大手がダンピング競争で仕事を取りに来るだろうから、スケールの小さな自称ベンチャー達の出る幕はますます無くなる。ということで、日本のAI業界は、高水準な少数の企業と、広く薄くビジネスアナリシスを引き受けるこれまた少数の大手の二極へと分裂してゆくだろう。そうなると、現在ルーチンワークやせいぜい中間レベル程度の仕事内容でどうにかやっているボリュームゾーンに属する弱小企業がどうなるかは明らかだろう。まずこの手の企業が本当の意味でのAIに対応できるレベルでないことは既に述べた通りだ。だからそういう内容で生き残ることはできない。それではルーチンワークの方はどうかというと、大手に対抗するのも難しい。結果は言うまでもない。
AIビジネスの未来に関して、もう一つ指摘しておきたいことがある。それは、前に挙げた「虚儒」に対する「実需」と呼ぶべき一群の需要は、不況下でも無くならないということである。一番大きいのは画像解析関連分野であろう。これは、今まるでAIと同義語のように使われている深層学習が、素晴らしいフリーソフトのおかげでどんな素人でも簡単に扱えるようになったせいである。（俺は、2012年の深層学習ブレークの5、6年前に自作の3層ニューラルネットで高次元の医療画像の解析の仕事をしたことがあるが、収束に至らずひどく苦労をしたという経験がある。それだけに、優秀なソフトとGPGPUのおかげで、たとえ大規模データであってもあまりにも簡単に収束するのを目の当たりにしたときには呆然としたものである。）このように画像認識についてもコモディティ化が起きていることから、簡単に深層学習が適用できそうな「実需」は、不況下でも、一渡り需給が一巡するまで無くなりはしないだろう。俺様アーキテクチャーを注入して黒魔術化することも容易で、そういう意味でも長らく使われることが予想される。ただし、コモディティ化のおかげで優位性を維持することもまた難しくなるだろう。（ちなみに、ブーム後に今回のブームの功罪を評価することがあるなら、深層学習のコモディティ化は間違いなくその「功」の筆頭に挙げられるだろうと考えている。このような技術が一気に誰でも使えるようになったのは、自分の長年にわたる趣味、そして仕事としてのAI人生においても最大の驚きであり、これを超える驚きはもうないだろうと思う。）一方、自然言語解析応用分野も「実需」としての潜在的需要は大きいが、この分野では画像解析のようなコモディティ化はまだ起きていない。従って、今の所画像解析と比べて参入が難しい。だが（他の予言と違ってあまり自信はないが）こちらの「実需」も密かに続くと踏んでいる。さらに音や感性などの特定分野に特化した「実需」もあるだろうが、このような「狭いが深い」ニーズに対してはそれ専門に特化したごく少数の会社が対応することになるだろう。こういう需要も確かに続くと思われる。
業界の未来の予言はこれでくらいにして、それでは不足が叫ばれている人材の採用、育成はどうであろうか。猫も杓子も「これからはAIだ」「グローバルな競争に遅れるな」と騒いでいるのに、これを担う人材をどうすれば確保し、育てられるのか。これを考える前に、まず世間はもとより、業界関係者の多くも、AI人材について全く理解していないということを強調したい。世間ではいわゆるデータサイエンチストとは「何やら難しい数学を使っている頭の良い理系の人」というイメージがほとんであろう。ブームが盛り上がった初期の業界は特にそうだった。だがこのステレオタイプこそ、AI人材に対する世間の誤解の源泉なのだと俺は考えている。例えば、ブームが炎上し始めた頃、理系の難しそうなことやっている人じゃないとダメなんじゃないか、という誤解が広まり（今ですらそう信じている人も大勢いる）、そのイメージにぴったりな理論物理を専攻していた人が引っ張りだこになったことがある。だが彼らがやっていることはデータサイエンスとは根本的に異なる。引っ張ってきて机に座らせればたちまち超一流のデータサイエンチストとして活躍する、というのではない。（門外漢にはわからないだろうが、意外に理学と工学の違いというのも大きい。様々な点で「必要なセンス」が非常に大きく異なるのである。これは自分も理学出身だから分かる。）自分の知り合いでアメリカの大学院で素粒子の質量がどうだ（何のことだか自分にはよくわからない）とかやっていた物凄い数理センスのある頭の良い人がいたが、彼も最初にデータサイエンスに向き合った時は何が何だか分からなかったと正直に言っていた。もちろんこういう人は地ができているのでキャッチアップは早いが、率直に言ってデータサイエンチストとしては数理的にはオーバースペックである。
その一方で、このステレオタイプには正しい面もある。それは、AI（とか機械学習とか勝手気ままに呼ばれるもの）は、あくまで数学的理論の基礎の上に乗っている、という点である。その数学を知らないものがAI（とか機械学習とか勝手気まま以下略）が理解できるはずがない。自分にとって非常に不思議なのは、ものすごく大量の「普通の」プログラマが「俺はもう一人前のプログラマ 
ツイートシェア
今スパコンと呼ばれているものがなんであるかは取り敢えず無視していいし、ラズパイ並べたものがスパコンであるように感じたとしても取り敢えず別の何かとした上で
一応レギュレーションは想定するなり増田の方で決めてもよかったんだが、
この問題は「ラズパイの群れとスパコンを比較して、ラズパイの群れにだけある弱点を指摘しましょう」
ってつもりで答えてみて。
条件は以下。
■ラズパイ側
無限の速度のWi-fiで繋がれている。(ありえない仮定とか言うな。この条件でもちゃんと答えを出せるはずだ)
CPU周波数は仮に1GHzとでもしておこうか。メモリ1GB。コア数は1。
これが、世界各地に1000あるとしよう。
■スパコン側
1000コアの各コア1GHz動作のCPU（CPUアーキテクチャはラズパイと同じ）
この条件で、「スパコンで実行すると割とすぐ計算できるけどラズパイで計算すると果てしなく時間かかるだろ」ってプログラム例を挙げてみてくれ。
Green500と経済性は何の関係もないし、なんでそこで経済性を持ち出すのが訳がわからない。
ケーザイセーなるものは今のどの指標でも測ることはできないし、それを問題視するならケーザイセーとやらを評価するランキングを作れ。
アーキテクチャを変更したらソフトウェア更新コストがかかるなんてのは当たり前のことだし、そもそもお前の大好きなx86ですら世代を経るごとにコードを書き換えないと性能が出ない。
いい加減見苦しいぞ乞食。そろそろ黙れ。
そもそもパソコンの世界がx86による統一が図られたあとだから、ほぼすべての端末で艦これが動くのであって、HPCの世界にあっては、なにかを動かすためにはアーキテクチャごとに書き換える必要があるというのは、少し考えれば分かることだろうに…
おっと、いちいち書き換えるなんてコストが高すぎるとかその手の批判は過去数十年繰り返されてきたし、今更そんなものに答えたくないからやめてくれ。
Pezy以外がGreen500狙ってなくね？ って指摘
計算機が大型化するにあたって、電力が問題となりがちという話はおｋ？ 京が専用の建物を前提としてもの凄い空調費を毎年使っていたのがそのいい例。パソコンが好きそうなので、Pentium 4 の例とか。
どんどん計算機を大きくすること自体はお金をかければある程度実現できるけど、効率向上を目指さないといずれ電力問題で破綻するよねというのがここ10年ちょっとぐらいの流れ。PVCやTPUなんかみたいなドメイン特化プロセッサもその一環。初代GRAPEからだともう30年近いか。
Top500とか今動いているの大規模計算機だけど、Green500今後大規模計算機を作るにあたってのネックをいかに解消するかという点についてのチャレンジなので別の意義がある。Green500の上位に来るアーキテクチャならそのまま大規模化すればTop500の上位を狙えるはずだし。
そもそもGreen500は別にPEZYのために作られた指標でもないし、なんの意図もなく作られたと思ってるの？「普通に」考えれば団体がそこに研究意義を見出して集計していると考える。その程度のことすら思い至らないのが反知性主義的(誤用)だと言っている。
一応断っとくと、わしは学生のころに半分ぐらいHPCに片足を突っ込んでいただけの単なる牧野先生ファンのワナビーで、研究者でも何でも無いで。PEZYには若干のロマンを感じつつもおや？と思うことも多数ある。世の中のPEZY批判の9割が的外れなのが許せないだけ
うーん、あんまりその原点くらいに立ち戻るのは嫌なんだけど、Pezy以外がGreen500狙ってなくね？ って指摘はどうなん。ランクにはTop500だかの併記もあるし、他のチームがGreen500にあえてエントリしたとは言いづらいようにも見えるわけだが。
最初の方に言った通り、アーキテクチャ的には汎用なブツを利用してるしな。
それ自体は間違いではないけれど、それ金メッキじゃね？ って指摘はあるじゃろ。
そもそもお前の最初の論点は「Green500は意味なんかないランキングじゃん」だったはずだが、なに論点逸らしてんだテメー
せっかくだから真面目に答えてやろう。
まずHPLなりTop500なりでググれ。
四則演算レベルのベンチマークとか意味不明。そんなんあらゆる計算は四則演算で表せるに決まってんだろ。舐めてんのか
あとな、そもそも今日においてRISCだのCISCだのの分類に意味はない。CISCの代表格のx86が命令をマイクロオペレーションに分解して実行している以上、x86だってRISCだ。
それにな、アーキテクチャが混ざった環境下であっても、その性能を一定の指標のもと、正しく測ることが可能と大多数の人間に考えられているから、HPLは問題があると言われつつも40年間ベンチマークとして成立してんだよ。お前のようなニワカがギャーギャー言ってるようなことはとうの昔に語り尽くされているわけ。
もちろん、HPLに問題がないかといえばそういうわけでもない。様々な批判はある。代替するためにHPCGをはじめとしたベンチマークが提案されている。
一石さんゆうてたやろ。「意外と同時多発的に物が動いたりすることってないみたいよ？」って。
一石さんというのがどなたか存じませんが。
コンピュータゲーム中での「それらしい動き」を再現することと、研究で必要な未知の現象を明らかにするための再現が同列で語れると思っているのが凄いですね。
では、疎結合計算機で計算した大規模計算の例を具体的にどうぞ。
疎結合の計算機で多くの問題が解けるなら、90年代のBeowulfからの安価な計算機を安価なネットワークだけで構成するというアーキテクチャで良いわけです。
どうして、スーパーコンピュータでインターコネクトやトポロジが設計上の今日的なテーマになっているのか。
PEZYを否定したい気持ちは分からないでもないけど、それでHPC業界について全体を否定しようとするのは単なる非知性主義。
んじゃ結構真面目な話すると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 データベースを使ってみよう
：
前回はオブジェクト指向プログラミング（OOP）で使う様々な仕組みについて学びました。
OOPの文法を学んだ後、OOPの長所が発揮される場面をどうやって説明したらいいのか？を考えてみた。
横田の意見を参考にして、「フレームワーク」を使って、OOPの使い方を見てみよう。
framework →「枠組み」「骨組み」「構造」などという意味の英語。
システム開発で使われる「フレームワーク」とは、よく使われる機能のパーツを用意して、まとめて１つのパッケージにしたプログラム群のことだ。
イメージとしては、いろんなおかずが入ってる豪華な幕の内弁当のようなものだ。
ただし、ご飯のマスだけが空になっていて、プログラマーが自分でご飯を用意しないと、弁当としては完成していない形になってる。
普通の白いご飯を作って追加しても良いし、好みや必要に応じて、炊き込みご飯やまぜご飯を作って追加しても良い。
ゼロから豪華な幕の内弁当を作るのは大変だけど、ご飯だけ用意すれば完成するので楽ができる。
プログラムの開発でフレームワークを使うと、プログラマーは必要最小限のコードを書くだけでアプリを完成させられるので楽ができる。
「フレームワーク」と似た用語で「ライブラリー」という用語がある。
弁当を作るときに使いたいおかず（ライブラリー）を自分で考えて探し出し、選ばないといけない。
（フレームワークは最初からおかずが全部用意されているので、自分でわざわざ選ばなくてもOK）
プログラムの動作で見た場合、フレームワークとライブラリーでは決定的な違いがある。
↑このページの「図1●フレームワークにおける制御の反転」という図解を見てみよう。
「制御の反転」（Inversion of Control、IoC）といって、自分の書いたコードが主役から脇役になってる点が違う。
（主役と脇役という説明は適切ではないかもしれないけど、イメージとしてはそんなかんじ？）
フレームワークはいろんな機能が全部入りで、こいつを使えば、ちょっとコードを書くだけで、高機能なアプリがすぐに作れる。
ここでは「MVCパターン」という仕組みで作られた「MVCフレームワーク」を使ってみよう。
MVCは「Model」「View」「Controller」の略で、MとVとCの３つを自分で用意すれば、アプリが作れちゃう仕組みだ。
MVCの歴史は古くて、GUI（Graphical User Interface、グラフィカルユーザインタフェース）を作る方法の定番だ。
→「MVC 仕組み」でGoogle画像検索すると、分かりやすい図解がいろいろ出てくる。
（参考）
Wikipediaの説明は、文章が学術的で難しいけど、正確な説明になってると思う。
↑このページの「MVCの概要」という図が、MVCの仕組み＝動作の流れを分かりやすく説明してる。
こういうプログラムの設計に関するノウハウは、「アーキテクチャー・パターン」という分野に蓄積されている。詳細はGoogle検索してみよう。
Webアプリを作るときに使われるMVCフレームワークには、いろいろある。
有名なものとして、
などが挙げられる。
PHPでOOPを学習しているので、ここではPHPのWAFの１つである「CodeIgniter」を使ってみよう。
CodeIgniterは使い方がシンプルで、覚えるルールが少ないので教材に向いているだろう。
それでは、CodeIgniterを使ってみよう。
↑このページの「Download」から「3.1.9.zip」という圧縮ファイルをダウンロードする。（2018年10月現在はバージョン3.1.9でした）
ダウンロードしたファイルを解凍して、「CodeIgniter-3.1.9」というフォルダが出てきたら、「waf」という名前に変えよう。（「waf」はWeb Application Frameworkの略。）
今「waf」フォルダの中には、「index.php」というファイルや、「application」「system」などフォルダがあるね？
この「waf」フォルダを以前用意したXAMPPの中にコピーする。（参照：anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備）
＝「C:\xampp\htdocs」（Cドライブの中の「xampp」の中の「htdocs」というフォルダ）の中に「waf」をコピーして下さい。
＝「C:\xampp\htdocs\waf」という位置にコピーできたらOK。
これで「Welcome to CodeIgniter!」というWebページが表示されたら、CodeIgniterの動作確認はOKです。
$config['base_url'] = 'http://localhost/waf/';
それでは「Hello, world!」と表示させるシンプルなWebアプリを作ってみよう。
<?php
defined('BASEPATH') OR exit('No direct script access allowed');
class Hello extends CI_Controller {
public function index()
{
$this->load->view('hello_index');
}
}
ここで注目して欲しいのは、「class Hello extends CI_Controller」という部分です。
フレームワークが用意している「CI_Controller」というクラスを継承して、自分で「Hello」というクラス（オブジェクトの設計図）を作っている、という点です。
次に、
<?php defined('BASEPATH') OR exit('No direct script access allowed'); ?>
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<p>Hello, world!</p>
</body>
</html>
今回は簡単なので、MVCの「M」は用意しませんでした。（CとVだけで完成）
Webブラウザーで「http://localhost/waf/index.php/hello」というURLにアクセスして下さい。
画面に「Hello, world!」と表示されたら、Webアプリの作成が成功です！
「Hello, world!」の表示だけではショボ過ぎるけど、Webフレームワークを使えばもっといろいろな機能が作れます。
詳細は、CodeIgniterのマニュアルを参照して下さい。
↑このページで「ユーザーガイド(日本語)」を読んでみて下さい。
Webアプリを作るときデータベースがないと不便なので、次の次ぐらいにSQLを学ぼう。
MySQL（データベース）を使えば、掲示板などのWebアプリも作れるようになります。
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の参考書
：
少し前になるが、転職活動の一環で難易度が高いと言われているニュースの会社をリクルーターを通して受けてみた。
SNSや勉強会を通じて、優秀な人材がいることは事前に分かっていたし、勉強会で実際に話してみるとただ有名なだけのエンジニアとは違い、技術にもビジネスにも明るく仕事が出来る事が直ぐに感じ取れたからだ。相手は自分のことなど覚えてはいないと思うが。
時を同じくして同僚も受けていた事が分かり、同僚も辞退をしていたのでどんな感じだったか情報交換を行った。
面接を通してミスマッチが発生しなくて良かったと思っているので、その記録を残してみる。
私のキャリアは、ソフトウェアエンジニアを約10年ほどサーバーサイドのプログラムを多く書いており、十数名規模のマネジメント経験がある。
応募ページを見ると、大量にポジションが無尽蔵に羅列してあり、何が何なのか正直よくわからなかったのでポジションサーチというやつに申し込んだ。
まずここでミスマッチが発生した。先方からはフロントエンド関連のエンジニアのポジションを提案され、戸惑いながらも面接に進んだ。経歴書にはフロントエンドも業務で取り組んでいたと書いたためであろう。なお、面接の前にオンラインで簡単なコーディングテストが行われた。
面接は1日に連続して数人と行うスタイルで、このやり方は初めての体験だった。
最初の人は現場の人だったのであろう。非常に初歩的な事を聞かれた。技術的に深いコミュニケーションが出来ず、少し深ぼった話をすると逆になんですかそれはという反応をされたので、レベルが高くない人なのかと察し適当に流すことにした。
なお、コーディングテストの結果はどうだったのか評価を教えてほしいと伝えると、自分もこの問題はよく分からないからと言われた。一体何のために行っているのかテンションが下がる話である。
次はマネージャーとの面接だった。どういうチームがあるのか組織的な事を説明され、相手の会社のアーキテクチャを説明された。その上でどう改善するかという問題を出された。
こういう面接の方法もあるのかと思いつつ、もし前提がこうであればこう改善したほうが良いという提案を何個かしたが、それはこういう理由で出来ないや、今は忙しくて取り組めないという事を返された。隠れた条件を後付けで出されるので、なんかズレてるなと感じ、組織的な課題を聞いてみたところはぐらかされた。
面接によくある、最後に何か質問はありますか？と問われたときに、面接の中で聞かれたことを逆質問し、その課題にどう取り組むかの意見を聞いたところ、適当な感じに返された。
この時点で微妙な人たちが連続して続いたので、私の中では辞退をしようと決めていたのだが、是非2次面接に進んでほしいという案内を受けた。
てっきり1次と2次を連続してやったと思っていたが、この日に受けたのはどちらも1次面接らしい。
リクルーターには別のポジションで受けたいこと、可能であればもっと優秀な人か勉強会で登壇した人と面接をしたい事を伝えたが後者は叶わなかったので辞退を申し入れた。辞退の理由は、面接した人と一緒に仕事をする事になると心労が絶えない事を直感的に感じ取ってしまったからだ。
同僚はバックエンドというポジションで直接応募しており、情報交換した感じでは面接官は別の人のようだった。
聞いた話なので詳細を書くことは出来ないが、Kubernetesの本に関わっている有名な人が出てきたようだったが、そのプロダクトの話をしても全然詳しくなく、実際にサービスで使っている自分の方が詳しくてがっかりしたそうだ。今取り組んでいるプロダクトの課題や目的、背景を聞いても、よく分からないと返されてしまい、萎えてしまったために辞退した模様。その同僚はフリマの会社も受けており、きちんと分かっている人が出てきたのでそちらに行くらしい。
（この増田は意図的に炎上を起こすことを目的として無断転載を行うものです）
（無断転載元：https://komeda.hatenadiary.jp/entry/2018/10/09/150830）
前置き - 実験IIIについて -
今までにも辛いものがあったでしょうが、今期のそれは今までをはるかに上回るそうです。
「それ」とは、もう皆さんお分かりでしょう。
「 情 報 科 学 実 験 III」 です。
情報科学科の授業の中で、最も辛く過酷な授業と言われています。
実験内容は、静岡大学情報科学科の計算機教育用に開発されたマイクロプロセッサであるSEP-3アーキテクチャの実装、つまりCPUの作成を行うことです。
確かに、実験内容だけを見れば、コンピュータサイエンスが好きな人にとっては、とても楽しそうな授業でしょう。
それは「 レ ポ ー ト 、 教 員 」です。
実験IIIでは某教員による、かなりシビアな指導が行われているらしいです。
深夜２時まで続く発表
地獄の再発表
学生の首根っこを掴んで怒鳴る
学生が一度も習ったことのないことを口頭試問で質問し、答えられないことを立ちっぱなしで1時間以上追求する
私がこれまでに聞いて来た愚痴や某教員の暴挙とも言える行いの数々です。
いやぁ、恐ろしいです。
さながらブラック企業のドス黒業務のようですね。耐えられる気がしません。
ズンドコキャベツ太郎
@toradora_haken
somの口頭試問を受けてないくせにsom3は厳しいけど正論しか言ってないだとか正しい事しか言ってない とか言ってる偽善者が嫌いすぎる
somの口頭試問を受けた上でまだそんなことが言えるならへ〜そういう人がいるんだなで済ませられるけど
https://twitter.com/toradora_haken/status/1010069961295839232
れたすのー
@retasnow_tt
僕だったらいいけど、もう1人の泣き出してしまった女子に「何で泣いてるの?」とか聞いてしまうのは本当にデリカシーがないし早くセクハラで訴えられて欲しい
https://twitter.com/retasnow_tt/status/958024564864270336
これから実験IIIを受ける皆さんは、耐えられると思いますか？我慢できますか？
先輩方は乗り越えてきました。
恐らく、私も、あなたたちも、乗り越えられるでしょう。
乗り越えた先には何が待っているのでしょうか？私たちは何を得られるのでしょうか？
実験IIIを乗り越えたという大きな達成感は得られるでしょう。
実験により培った実装力、仲間と共に切磋琢磨したことによる協調性なども得られるはずです。
膨大な量のレポートを書いたことで得られる文章力は、社会に出てからも活きてくるでしょう。
このようなものが得られるという点では、実験IIIの授業はとても身になるものと言えます。
しかし、です。
某教員がやっていること、アカデミックハラスメントに当たりませんか？？
深夜２時までの発表や、反論を許さない体制、アカハラに刻当するのではと思います。
アカデミックハラスメント（和製英語: academic harassment）とは、大学などの学術機関において、教職員が教育・研究上の権力を濫用し、ほかの構成員に対して不適切で不当な言動を行うことにより、その者に対して修学・教育・研究ないし職務遂行上の不利益を与え、あるいはその修学・教育・研究ないし職務遂行に差し支えるような精神的・身体的損害を与えることを内容とする人格権侵害のことである。
アカデミックハラスメント - Wikipedia より
先ほど箇条書きした項目の中に、アカハラに当たるだろうものがありませんか？
ありますよね...。
（ 教育も度が過ぎればなんとやらってやつですね...）
さあ、このような実験IIIの体制を許しておいて良いのでしょうか？
実験IIIのような強いられた環境の中で学習を行うことは悪影響（私の場合）
コンピュータサイエンスを好きでいたい（実験IIIを受けたら嫌いになりそう）
実験III受講中にアカハラが発生した場合、私は必ずハラスメント報告をしたいと考えています。 (打ち消し線の意図は後ほどほど述べます）
このような考えをお持ちの方が、私以外にもいるはずです。
ですが、ハラスメントの報告はどこに？誰に？いつ？すればいいの？と、報告する気持ちはあっても、どう行動して良いのか、誰に相談して良いのかわからない方もいるでしょう。
そこで、今回は静岡大学におけるハラスメント対策の方法をご紹介します。
ハラスメントとは？
先ほどはアカデミックハラスメントについてのみ紹介をしましたが、複雑な社会が展開される昨今、ハラスメントには様々なものがあります。
その他のハラスメント
それは、「嫌がらせ」です。
ハラスメントは、英語では "harassment "と表記し、人を困らせること、嫌がらせなどと訳します。
嫌がらせとは、
他者に対する発言・行動等が本人の意図には関係なく、相手を不快にさせたり、尊厳を傷つけたり、不利益を与えたり、脅威を与えること
https://www.osaka-med.ac.jp/deps/jinji/harassment/definition.htm
です。
ハラスメント（嫌がらせ）の定義からも某教員がしてきたことはハラスメントに刻当することがわかります。
このようなハラスメントに対して、どのような対策をすることができるでしょうか。
ハラスメント問題は、加害者が無意識に行なっている場合もあり、関係者同士で解決を行うのは難しいと言われています。
ですから、内外部の組織に相談をし、解決を行なってもらうことが一般的です。
静岡大学の学生であれば、まずはその窓口に相談を行うのが正解でしょう。
静岡大学におけるハラスメントの相談窓口は、大きく分けて二つあります。
学内相談窓口は、学内の相談員によるハラスメントの相談を行います。
相談員はプライバシーを固く守り、相談内容の秘密を厳守します。
相談箱を各部局に設置してあり、週一回、相談員が内容の確認をしています。
学外相談窓口は、静岡大学から委託を受けた事業者が、無料で、相談者からの相談を行います。
相談はWeb、電話にて行うことができ、学内相談窓口同様にプライバシーを厳守します。
特に問題がないのであれば、学内相談窓口に相談を行うのが正解でしょう。
学内相談を行う方法は、ハラスメント相談箱にハラスメント申立書を入れるか、相談員に相談を行うかの二つです。
ハラスメント相談を担当する相談員への連絡先は、このページに載っています。
相談員の選び方ですが、馴染みのある先生、学部の先生、事務部の方から選ぶと良いでしょう。
相談箱にはハラスメント申立書を入れる必要がありますが、ハラスメント申立書はこのページからダウンロードすることができます。
おわりに
ハラスメント問題は、自分で解決ができない場合、他人に相談しないと、解決することはできません。
（実験IIIの）ハラスメント問題を解決するために、まずは相談員への連絡、相談箱への投稿をしてみましょう。
（実験IIIで深い傷を負わないためにも、後輩たちに同じような思いをさせないためにも、ハラスメント報告はするべきだと考えます。楽しい実験IIIを、みんなで作っていきましょう！！）
ハラスメント報告をしたいと考えていたのですが...
私は先ほど、ハラスメント報告をするつもりです、と言いました。
しかし、今は静岡大学のハラスメント報告のシステム、と言うよりも、ハラスメント委員会（というよりかは静岡大学）に懐疑の目を持っています。
それは、
「某教員はハラスメント委員会の頭だ。だからハラスメント報告をいくらしても無駄。」という噂を複数確認したからです。
あくまで、噂です。ですから、某教員がハラスメント委員会の頭だということに確証はありません。しかし、報告が意味をなさないというのは強ち間違っていないだろうと考えています。
静岡大学では半期の授業が終わるたびに、授業評価アンケートを実施します。
そのアンケート内では、任意のコメントをすることができ、そのコメント欄を使い実験IIIの体制を変えようと訴えた先輩方が複数いることを確認しました。
ですが、現状はどうでしょう。何も変わっていません。
また、2018/10/10当日、このようなツイートを確認しました。
すが藁
@sgwrch105
· Oct 10, 2018
Replying to @hanko96
柚子ノ樹
@hanko96
研究室変更の時に色々担当者と話したけど、学務教務カウンセラー辺りは理解したうえで手を出せない状況だったから、学内で何とかするの無理っぽい。糞オブ糞
https://twitter.com/hanko96/status/1049991508227584000
やはり、静大内部から実験IIIを変えていくのは無理があるようですね...。
元々は、「静大生にハラスメント報告の仕方を周知し、ハラスメントを受けた人がハラスメント報告をすることで、実験III（その他辛いだけの授業）の体制を変えることができないだろうか」という意図を強く持った文章を書くつもりでした。
しかし、静大当局が動いてくれないのであれば、この文章は意味がありません。
ですから、静大のCS実験IIIの現状が世間に浸透し、静大内部を変えるような強い社会潮流を持ってくれないだろうか...という淡い期待も兼ねてこの文章を書きました。
長くなりましたが、私の根底にある願いは一つです。
コンピュータのマシン語は命令文もデータも数値で表す。これは今も昔も同じ。
数値だけでは人間が管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ。
複数の処理をひとまとめで扱うサブルーチン・関数・プロシージャ・ファンクションと
いったものができた。
（カプセル化）
アプリケーションからOSの機能を呼ぶシステムコール・APIが生まれた
（ブラックボックス化）
複数のクラスやコード、データをひとまとめにするにモジュールができた。
（カプセル化）
プログラムを外部から操作するRPC、CORBA、SOAP、RMIができた。
IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。
（ブラックボックス化）
（操作の簡略化）
Docker でWEB/DB/KVSなどをまとめてコマンド１つで扱えるようになった。