update server overvew (#200)

Author: ryoya-fujimoto

src/server-app/overview/README.md

@@ -61,20 +61,20 @@ print "</html>";
 ```
 
 - Common Gateway Interface の略
-- The Apache HTTP Server ("httpd") などのWebサーバでHTTPリクエストを受けて、外部プログラムにHTTPリクエストを渡し、出力をHTTPレスポンスとして返すしくみ
+- The Apache HTTP Server ("httpd") などのWebサーバでHTTPリクエストを受けて、外部プログラムにHTTPリクエストを渡し、出力をHTTPレスポンスとして返す仕組み
 - Perlが大流行するきっかけとなった
-  - 当時の主流であるC言語の文字列処理が貧弱だったのに対し、Perlは文字列処理が強力だった
-  - PerlからMySQL/PostgreSQLに接続してHTTPレスポンスを生成するスタイル
+  - 当時の主流であるC言語の文字列処理が貧弱だったのに対し、Perlは文字列処理が強力
+  - PerlからMySQL/PostgreSQLに接続してHTTPレスポンスを生成することができた
 - 少し前まではPerlで実装されたプロダクトが存続していたが、最近は流石滅多にないかも
   - MovableTypeとか、mixiとか。CookPadもPerlでスタートしたはず
 - CGIの仕組み自体はPerl以外でもRubyやPython、シェルスクリプトなど文字列を出力できるプログラムであれば利用できる
 
-CGIはHTTPリクエストを受けるごとに、新しいプロセスをforkする必要があり、Webサーバにとって負荷が高い特徴がありました。
+初期のCGIはHTTPリクエストを受けるごとに、新しいプロセスをforkする必要があり、Webサーバにとって比較的負荷が高い特徴がありました。
 
 ![perl_cgi](./perl_cgi.drawio.png "perl_cgi")
 
-そこで1998年頃にはWebサーバのモジュールとしてPerlを動作させる「mod_perl」という方法が考案されています。
-これによりプロセス管理をapache側で効率的に行えるようになりました。
+そこで1998年頃にはPerl等のインタプリタをWebサーバのモジュールとして動作させる「mod_perl」が使われるようになりました。
+これによりプロセス管理をapache側で効率的に行えるようになります。
 
 ![mod_perl](./mod_perl.drawio.png "mod_perl")
 
@@ -91,21 +91,21 @@ CGIはHTTPリクエストを受けるごとに、新しいプロセスをforkす
 </html>
 ```
 
-（開発開始は1994年 実質的に最初の公開版PHP 3が1997年 本格普及はPHP 4で2000年)
+（開発開始は1994年 実質的に最初の公開版PHP 3が1997年 本格普及はPHP 4で2000年）
 
 1. CGIはHTTPリクエストを受けるごとに、新しいプロセスをforkする必要があり、Webサーバにとって負荷が高かった
 1. 前述の通りmod_perlという形でPerlを動作させる手法が流行っていた
 1. しかし当然ながらPerlはWebサーバのモジュールとして動作させる前提で設計・実装されたものではなく、使い勝手が悪かった
 1. 類似の技術としてFastCGIというものもあったが、やはり癖があり使いにくかった
-1. そこで最初からWebサーバのモジュールとして実行することを念頭に置いた、Webプログラミングに特化した処理系としてPHPが登場、大流行してPerlを駆逐する
+1. そこで最初からWebサーバのモジュールとして実行することを念頭に置き、Webプログラミングに特化した処理系としてPHPが登場、大流行してPerlを駆逐する
    1. Facebookも長い間PHPで書かれていた
 1. 元々はWebページを動的に生成するためのテンプレート的な言語であったが、機能が追加された結果スクリプト言語としての機能も持つ
 1. 動かし方はCGI, mod_php（モジュール形式）などがあり、Perlの項目とほぼ同様の形式で動作する
 1. 現在でも広く利用されており、[CakePHP](https://cakephp.org/jp) など今風のフレームワークも存在する
 
 ### Java Servlet (サーブレット)
 
-（1996年に初期バージョンが公開 1998年に最初の公式API仕様が確立 2001年にStrutsが登場)
+（1996年に初期バージョンが公開 1998年に最初の公式API仕様が確立 2001年にStrutsが登場）
 
 Java Servletの例
 
@@ -155,13 +155,16 @@ JavaのテンプレートエンジンであるJSP(JavaServer Pages)の例
 ```
 
 1. 1995年Sun Microsystems社がJava言語を売り出した
-   - 最初にアピールした`Applet`は、Webページの中にJavaのサンドボックス環境を埋め込んでアプリケーションを実行するというものだった。しかし制約が大きいうえにマシンパワーを要求するので、実用的なアプリケーションを作る環境としては、流行らなかった
-2. しかしサーバサイドの技術として発表されたサーブレットは2000年ごろから流行し始め、2001年にStrutsが登場するとその人気が決定的になった
-    1. サーブレットはHTTPリクエストを（CGIのようにプロセスをforkするのではなく)スレッドで処理するので性能が高い
+   - 昔は`Applet`と呼ばれる、Webページの中にブラウザ上で動作するJavaのサンドボックス環境がそこそこ使われ、アピールもされていた
+   - しかし制約が大きくマシンパワーを要求するのと、セキュリティ的な問題からあまり流行らなかった
+2. 一方でサーバサイドの技術として発表されたサーブレットは2000年ごろから流行し始め、2001年にStrutsが登場するとその人気が決定的になった
+    1. サーブレットはHTTPリクエストを（CGIのようにプロセスをforkするのではなく）スレッドで処理するので性能が高い
     2. Javaは静的に型付けされた言語であるため、Javaで書かれたアプリケーションはPHPよりも品質を確保しやすいかった
     3. WebアプリケーションフレームワークであるStrutsによって大人数による開発が効率的に行えるようになり、規模の大きなエンタープライズシステムの実装が可能になった
-    4. Javaで書かれたコードはポータビリティがあり、サーバのOSやCPUが変わっても、そのまま実行できた。（まだx86系のCPUが市場を独占しておらず、SPARCやAlphaなどのCPUもある程度のシェアを持っていた。)
+    4. Javaで書かれたコードはポータビリティがあり、サーバのOSやCPUが変わっても、そのまま実行できた。（まだx86系のCPUが市場を独占しておらず、SPARCやAlphaなどのCPUもある程度のシェアを持っていた。）
 3. カジュアルな（コンシューマ向けの）WebアプリケーションはPHPで、シリアスな（エンタープライズ向けの）WebアプリケーションはJavaサーブレットで書く、という時代が続くことになった
+4. Strutsはその後も進化を続け、Struts2が登場したが、Struts1との互換性がなかったため、Struts1を採用していた開発会社に受け入れられなかった
+   - その後脆弱性問題を連発したため、今日ではまったく人気がない
 
 ### Java EE / Spring
 
@@ -210,11 +213,9 @@ public class HelloController {
 3. だが、実際のJava EEアプリケーションサーバ製品は不安定で性能も悪く、プログラミングも難しいものであった。人々はJava EEを信じて使い続けていたが、疑問も大きく膨らんでいった
 4. そこに登場したのがSpring Framework（2002年頃）
    - 作者のRod JohnsonがExpertt One-on-One J2EE Design and Developmentとともに世に問うたもの。
-   - Java EE（J2EE) の欠点を指摘し、EJB、とりわけ`Entity Beans`を使うことは断念し、POJO（Plain Old Java Object) をベースに開発することを提唱した
-   - DI （Dependency Injecttion) のアイデアを普及させ、大規模なJavaアプリケーションを効率よく分業体制で実装する道を切り開いた。
+   - Java EE（J2EE） の欠点を指摘し、EJB、とりわけ`Entity Beans`を使うことは断念し、POJO（Plain Old Java Object） をベースに開発することを提唱した
+   - DI （Dependency Injecttion） のアイデアを普及させ、大規模なJavaアプリケーションを効率よく分業体制で実装する道を切り開いた。
 5. Spring Frameworkは一世を風靡しただけでなく、今日まで人気を失うことなく、利用されている。
-   - StrutsはStrus1の後継バージョンであるStruts2が、Struts1とまったく互換性がなかったため、Struts1を採用していた開発会社に受け入れられなかった。
-   - その後脆弱性問題を連発したため、今日ではまったく人気がない
 
 ### Ruby on Rails
 
@@ -239,22 +240,22 @@ end
          - ほとんどの設定項目は、自動的なものであり、設定ファイルのメンテナンスは大量の単純作業であった。
       - そこで多くの現場ではExcelなどで主要設定項目を管理し、そのExcelファイルからマクロで個々の設定ファイルを生成するようなことが行われていた。
       - Railsでは、これを「デフォルトで定められているディレクトリ構造や命名規則に沿っている限り、設定ファイルは不要とする（特別な場合だけ、設定ファイルを書く）」という方法で解決した。
-      - たとえばRDBMSのpersonsテーブルに対応するモデルクラスを、ModelsディレクトリにあるPerson.rbファイルとして記述すれば、自動的にDBアクセス可能とするというような具合である。
+      - たとえばRDBMSのpersonsテーブルに対応するモデルクラスを、ModelsディレクトリにあるPerson.rbファイルとして記述すれば、Railsが勝手に解釈してpersonsテーブルを操作するクラスとして扱ってくれる。
       - こうした開発者体験(Developer Experience)の良さは、Rubyが非常にメタプログラミングをしやすい言語であることで成り立っている。
          - Rails 独自の拡張や構文を多数実装することで、上記の哲学を実現している。
    2. コマンドラインユーティリティによる開発のサポート
       - たとえばあるURLに対応するコントローラクラスのスケルトンをコマンドラインユーティリティから生成できる。
       - このようなユーティリティを提供することで、開発者を単純作業から解放し、価値あるコードを書くことへ集中できるようにした。
    3. Ruby on Railsに触発されて、別の言語でも同様のフレームワークが多数開発された。
       - PHP: CakePHP
-      - Java: JBoss Seam, Java EE 6, Grails（Groovyを使う)
+      - Java: JBoss Seam, Java EE 6, Grails（Groovyを使う）
       - Python: Django
 1. 今でも第一線で使われており、githubもRailsで作られ続けている。とはいえ一時期より採用されることは減ってきた。
-  - 「マイクロサービス」が注目され、小さなアプリケーションを多く作るようになった
-    - Railsはどちらかというと大きなアプリを作るためのフレームワークであり、マイクロサービスと対比してモノリスアプリの例として扱われる
-    - とはいえ最近はまた一巡してモジュラーモノリスなど大きなアプリが着目されており、流れが変わりつつあるかもしれない
-  - pythonが言語として人気であり、その流れでDjangoが採用されることが多い（？）
-  - Goなどに比べてパフォーマンス面で不利
+   - 「マイクロサービス」が注目され、小さなアプリケーションを多く作るようになった
+     - Railsはどちらかというと大きなアプリを作るためのフレームワークであり、マイクロサービスと対比してモノリスアプリの例として扱われる
+     - とはいえ最近はまた一巡して「マイクロサービスだるくね？モジュラーモノリスでよくね？」的な空気もあり、流れが変わりつつあるかもしれない
+  - pythonが言語として人気であり、その流れでDjangoが採用されることも多い
+  - Goなどに比べてパフォーマンス面では若干不利
 
 ```bash
 rails generate controller User name:string email:string
@@ -275,12 +276,15 @@ Person.create(email: 'hoge@example.com', username: 'hoge') # データの作成
 ### Ajaxの出現 / フロントエンド+APIサーバの時代
 
 1. Google MapsおよびGmailの出現により、「画面遷移を伴わないWebアプリケーション」というものがユーザーに認知され始めた。2005年ごろのこと
+   - 今では想像もつかないが、この技術が流行るまで画面上のデータ更新は全て画面遷移を伴っていた
+   - 「ユーザの見えないところで非同期にデータを更新する」ことができるようになったのがこの辺
 2. 技術としてはそれ以前から存在していたが誰も注目してこなかったXMLHttpRequestというJavaScriptの機能を初めて本格的に使用するもの
-   1. この技法をAsynchronous JavaScript + XMLの頭文字をとってAjax （エイジャックス) と呼ぶようになった。
-3. StrutsやRuby on Railsはサーバサイド（バックエンド）側でリクエストを処理して画面も生成するというようなスタイルが中心だった。しかしAjaxが人気を集めるようになるとクライアント（フロントエンド）側で画面描画をすべて行い、バックエンドにはAPIサーバのみを置くというスタイルが人気を集めるようになった。
-   1. 画面遷移を伴わないWebアプリケーションのことをSPA （Single Page Application) などと呼ぶ
+   1. この技法をAsynchronous JavaScript + XMLの頭文字をとってAjax （エイジャックス）と呼ぶようになった。
+3. StrutsやRuby on Railsはサーバサイド（バックエンド）側でリクエストを処理して画面も生成するというようなスタイルが中心だった。しかしAjaxが人気を集めるようになるとクライアント（フロントエンド）側で画面描画をすべて行い、バックエンドにはAPIサーバのみを置くというスタイルが主流になっていく
+   1. 画面遷移を伴わないWebアプリケーションのことをSPA （Single Page Application）などと呼ぶ
    2. このスタイルが定着すると、デスクトップアプリケーションと比較しても遜色ないUIのWebアプリケーションが当たり前のように期待されるようになっていった
-   3. 要求の高度化に応えるため、フロントエンド側のフレームワークが非常に速いペースで開発されているのが今日の状況である。人気の出たフロントエンド・フレームワークとしてはReact （Facebook)、Angular （Google)、Vue.js （Evan You)などがある
+   3. 要求の高度化に応えるため、フロントエンド側のフレームワークが非常に速いペースで開発されていった。人気の出たフロントエンド・フレームワークとしてはReact （Facebook）、Angular （Google）、Vue.js （Evan You）などがある
+   4. 最近はフロントエンド・フレームワークの開発も落ち着きつつある
 
 ### Node.js
 
@@ -295,8 +299,8 @@ Perlから始まり、ここまで出てきたJavaやRailsは基本的に同期
 
 ![apache_railes](./apache_rails.drawio.png "apache_railes")
 
-しかしインターネット利用者に増加にともなってWebサービスへのアクセス量も増え、プロセスのforkやスレッドによる処理モデルの限界が表面化してきた。特にプロセスの場合は1サーバあたりで起動できるプロセス数には限界がある他、プロセスを作るコスト（メモリ消費など）が無視できなくなってきたのである。
-(C10K問題と呼ばれる)
+しかしインターネット利用者に増加にともなってWebサービスへのアクセス量も増え、プロセスのforkやスレッドによる処理モデルの限界が表面化してきた。特にプロセスの場合は1サーバあたりで起動できるプロセス数には限界がある他、プロセスを作るコスト（メモリ消費など）が無視できなくなってきた。
+（いわゆるC10K問題）
 
 ::: tip
 たとえば32bit環境のlinuxサーバでは、プロセスの作成上限は管理番号(PID)の上限となる32768になる。
@@ -317,7 +321,7 @@ Node.jsの中でリクエストを並列に捌けるためWebアプリ用にプ
 
 開発スタイルの特徴としては以下が挙げられる。
 
-- フロントエンド開発と同じJavaScriptで書けるので、1サービスを作るのに複数の言語を扱わなくてよくなる
+- フロントエンド開発と同じJavaScriptで書けるので、プロダクトを作るのに複数の言語を扱わなくてよくなる
 - 豊富なライブラリやツールの選択肢がある
 - 反面EventDrivenな実装はコードが複雑になりがちで、どちらかというと小規模な実装向け
   - TypeScriptによる型の導入やasync/await記法の導入などで改善されつつはある
@@ -363,10 +367,11 @@ RubyやPython、Javaなどのように実行環境をインストールする必
 
 ### その他...
 
-- Haskellなどの関数型言語が流行りそう？
 - Rustはいい言語だが書くのが難しく、どちらかというとOSなどのシステムプログラミング向け（と思ってる）
   - Rustのメモリ管理はGC（ガベージコレクト）を起こさないためのもの
   - Webアプリの実行環境はある程度メモリやCPUを富豪的に使えるため、書きやすさを優先してGoやRuby, JavaなどGCのある言語が使われる傾向にある？
+- 昨今はAIプログラミングが大前提の時代に突入しつつある
+  - AIに特化した言語やフレームワークが登場する？
 
 ## アプリケーションプログラミングインタフェース(API) の色々