デベロッパーの4つ業務

1. サーバ構築
2. DBスキーマ作成、環境設定
3. ミドル環境の設定及びミドルサーバーの構築、開発
4. フロントの環境設定、開発

1. サーバ構築

• サーバーもコンピューターだ。

では、サーバーをなぜ構築しなければならないのか?

• 私はアプリやウェブサイトを作りたい。

• ところであえてサーバーが必要なのか知りたいよ。 という言葉ができます。

  それでは私が比喩を一つやってみます。
  私がコーヒー商売をすると仮定してみました。
  コーヒー商売をするにはどこかでコーヒー豆も積んでおいて機械も入れておかなければならない場所が必要ではないですか。
  このようにコーヒー商売をしても場所(site)が必要です。
  我々はのどの良い商業ビルや露店あるいはトラックのうち、個人の状況に当たる場所を選択することになります。
  コンピュータの世の中も同じです。
  現実で、我々がコーヒー商売をするのと似ていると思ってもいいです。
  仮想の世界でコーヒーを販売するためには、仮想のコーヒーを販売する場所が必要が必要なものです。
  整理すれば、コーヒー商売を行う場所を指してサーバーと思えばいいです。
  サーバーの本質は場所だと思ったらいいと思います。

  Webサーバ、FTPサーバ、DBサーバ、イメージサーバ…
  上記のサーバー名のように、それぞれのサーバーはサーバーの目的から外れません。
  サーバというルーツの上に役割分担するだけです。
  そのため、サービスの性格によって全てのサーバーを備える必要はありません。

本を読んだ後の印象

• この本の一番強いところは、段落分けが明確で、説明がとても易しくて理解しやすい。
  番号を付けてインデックスして整理したり、太字で単語をつなげてくれる部分から著者の配慮が感じられる。(英文基準)

• Phpがサーバーサイドスクリプト言語であることを何度も強調する。
  そしてその簡単な例としてJavaScriptと比較して説明する。

• Phpとウェブサーバーに対する理解を非常に分かりやすく説明してくれる。

• MySQLを活用するデータベースの連動まで詳しく説明してくれている。

少し物足りない点

• Laravelについての本ではない。
• 分かりやすいが、実習が多くはある。
  この本を読んだ後に、Laravelをつなげていければ、なかなかいいと思う。

個人的な感想

• 私にPhpとはPython、Goなどに比べて、古くて使いづらいランゲージという先入観があった。

• LaravelのようなPhpフレームワークで、簡単にECサイトなどを作ることは今でも難しくないが、
  今回の機会を通じてPhpとLAMPのようなサーバーサイド環境について学び直せて良い時間だった。

• 意外とPhpコミュニティがうまく活性化されていて、いろいろ学びやすく、楽しくプログラミングできると感じる。
  https://laracasts.com/
  https://laravel.com/docs/7.x

• かつて主力ランゲージだったJava-Springに比べ、Php-Laravelは、そのハードルがかなり低いので、素早く学べるという感じである。
  Python-Djangoよりも容易に感じられる。
  (現在、Djangoフレームワーク相当重くなった感じがぬぐえない。)

• NodeJSの反対側にある言語という感じがする。(クライアント-サイド、 サーバ-サイド)

なぜDockerを使うのか?

• 最も簡単に説明すれば、パフォーマンスが良いからですね。

  

• 簡単に言えば、途中で不必要なレイヤーをなくしたと思いましょう。

  

Dockerの特徴

• LXC(リナックスコンテナズ)というカーネルコンテナ技術を利用して作ったコンテナ技術のひとつ。もちろん、今はLXCに全面的に依存してはいないが、LXCオプションなどが使えることを勘案すれば、最初から分離された別個の技術とは言えない。
• 運営体制を仮想化しないコンテナ技術だけに、仮想マシンに比べて軽く、VMを含めて1台のサーバーに複数のサービスを駆動しやすい。
• セキュリティ上、サービスがハッキングされても元のサーバに影響を与えにくい隔離された構造であるため、仮想化のメリットをかなり活用できる。
• 仮想マシン(VM)とは異なり、既存のリナックスリソース(ディスク、ネットワークなど)をそのまま活用できるため、複数のサービスを一つのサーバーにすべて運用するにも便利である。
• Linuxカーネル2.6.32-431以上でサポートする。 CentOS 基準では、CentOS 6.5 以上を要求する。
  (バックエンドデベロッパーなら、基本的にインフラ運用も可能になるべきだと思うので、CentOS6の勉強や運用をしていて、6.5以上バージョンを使っています！)

まずは、言葉の整理していきましょう！

仮想化(Virtualization)

• コンピューティングにおいて、仮想化とは、仮想コンピュータハードウェアプラットフォーム、ストレージデバイス、およびコンピュータネットワークリソースを含む、何かの仮想バージョンを作成する行為を指します。
• In computing, virtualisation refers to the act of creating a virtual (rather than actual) version of something, including virtual computer hardware platforms, storage devices, and computer network resources.
  (ps.2015年1月25日、TOEIC870点、もう5年前なので英語の実力が減少した可能性が高いです。(笑))

仮想マシン(Virtual Machine、VM)

• 物理的ハードウェアシステムに構築され、独自のCPU、メモリ、ネットワークインターフェース、およびストレージを備え、仮想コンピュータシステム機能をする仮想環境です。

ハイパーバイザー(Hypervisor)

• ホストシステムで多数のゲストOSを駆動できるようにするソフトウェア。
• ハードウェアを仮想化しながらハードウェアとそれぞれのVMをモニタリングする中間管理者。 VMM(Virtual Machine Monitor)とも呼ばれる。

VM VS Docker

• VM VS Docker(Container)関連論文 : https://arxiv.org/pdf/1807.01842.pdf

AmazonとNetflixで見るDocker(Container)

• あの小さな緑、青の点が1つのコンテナ(pc)だ。
  数多くのコンテナが集まって、一つのサービスを提供しています。

• このようなサービスを実現するのに、非常に多くの時間がかかる。
  このようなサービスがDependencyなく、1つのサービスとして実装、運営されているということはかなり難しいことである。

• しかし、このようなことができる理由は、マイクロサービスを使用するために、
  コンテナの使用にこのようなサービスが実現、運営可能となった。

• コンテナ技術を導入することにより、複雑度の削減、ビルドタイムの削減などが可能となり、
  運営チームは運営に集中でき、開発チームは開発に集中できるようになった。

Containerを活用したMicroservices

• かつてはMONOLITHだったので、すべてのサービスが一つにまとまっていた。
• そのおかげで開発、運営にかなり不便な点が多かったが、マイクロサービスに変わってからはそのような不便が消えつつある。

個人的な感想

• 軽くはLinux、Docker、AWSの活用だけど、もう少し進むなら、Kubernetesの活用だと思います。
• 従来はセキュリティ上の問題で、クラウドやDocker などの使用ができなかった。 (正確にはかなり制限的だった。)
  そのため、私が魅力的に感じる技術を活用できない喉の渇きがあった。
  早くこのような技術を活用できるところで働けたらと思う。それは極めて切実だ。
• 大学研究所で研究していた時代、私の研究室の隣の部屋はクラウドコンピューティング研究室だった。
  たまにコーヒーがない時、隣の部屋の研究員先輩とコーヒータイムをしながら興味深く感じた。
  現在ソフトウェアエンジニアとして働きながら、最も興味を感じることは何かと私に聞かれたら、当然のことながら仮想化技術だと答えるだろう。
  (当時私は人工知能の研究をしていた。 惜しくも経済的な事情でアメリカの大学院に行けなかった。)

仮想化(Virtualization) VS クラウド(Cloud)

• 仮想化は、単一の物理ハードウェアシステムで複数のシミュレーション環境や専用リソースを生成できる技術であり、
• クラウドはネットワーク全体で拡張可能なリソースを抽象化し、フルリングするIT環境です。
• つまり、仮想化は技術で、
• クラウドは環境であることが著しい違いです。

7日間、プログラミングの勉強時間をチェックしてみた。

概要

• 果たして自分がどれだけ熱意を持って、能力のあるプログラマーになるために
  頑張っているのかを自ら評価したいと思いました。

• 純粋に集中した状態だけをスマートフォンのストップウォッチ機能でチェックしました。

• 少しでも他の雑念が入ったり、電話がかかってきたり、ネットで講義を聞いたり、
  休憩時間は徹底して除きました。

結論

• 集中時間の総合 : 37時間 49分 (秒単位を除く)
• 集中時間の1日平均 : 5時間 7分 (秒単位を除く)

反省

• たとえ急に他のイベントが起きたとしても、自分で決めた1日最小の勉強時間5時間を守れなかった日が
  7日中に2日も発生したという点で、タイムマネジメントに対する不足さがうかがわれている。
• 午前中なるべく早く大事な部分に対する概念を勉強して、
  初夏の気候の午後からは、休み時間をよく守りながら体力管理を通じて集中力を上げなければならない。
• 実際、ノートパソコンを使う時間は1日に11時間程度だが、集中する時間は5時間7分だった。
  ノートパソコンの使用時間を10時間と決めておいて、1時間は有酸素運動などをして集中力向上を図らなければならない。

時間記録

Framework VS Library

• 結論 : 誰が誰を呼び出すかの違い(who calls who)

• Frameworkではフレームワークコードが我がコードを呼び出し、

• Libraryでは我がコードがライブラリを呼び出す。

  Inversion of Control (IOC)

  • JavaScriptフレームワークであるQueryを例に、
    Documentが準備状態(document on ready)の時に我々が定義したコールバックを
    呼び出すのはフレームワークである。
    これはフレームワークが担うフレームワークの統制部分の流れである。

  • Framework Code : 統制の流れを定義

  • My Code : 行動を定義

  • Library Code : 行動を定義

  FrameworkとLibraryの違いはControlに関すること。

  • 統制の流れ(flow of control)がその違いだ。
    • FrameworkはApplicationの流れをコントロールし、
    • Libraryはそうではない。

API (Application Programming Interface)

• 開発者が公に露出したメンバーを使って機能にアクセスし、
  当該機能を具現するのに使われたコードを隠せるインターフェース。

Library vs API

• Libraryはコンポーネントそのもの。
• APIはコンポーネントを活用する規約。

ETC

SDK(System Development Kit)

• ソフトウェア開発ツール集
• SDKの中には開発に役立つ開発ツールプログラム、デバッグプログラム、
  文書、APIなどがある。

Software Framework

• 定義されたAPIを提供するSoftware libraryの母音
• ライブラリと違い、アプリケーションの枠組みと構造を決定するだけでなく、
  その上に開発された開発者のコードを制御する。

Software Library

• コンピュータープログラムでよく使われる部分プログラムを集めたもの。
• 静的、動的(リンク、ロード)ライブラリに分けられる。

Directoryとは？

• Directory：Linuxで、ファイルを入れておくことができるオブジェクト。
• Linuxでは、ディレクトリ構造が木を逆さに立てた逆ツリー構造である。
  そして、最上位のディレクトリは 「/」 である。 これrootと呼ぶ。
  「/root」 はrootアカウントのホームディレクトリであり、異なることを示す。
• Linux ディレクトリ 区切り文字は 「/」
  Windows フォルダ 区切り文字は 「¥」
  (Windowsは、ドライブにフォルダ構造を持つ。)

Path

• . : current directory

• .. : parents directory

• / : root directory

• ~ : home directory

• echo $PATH

Handling Files

• CREATE : mkdir,
  vi(:w filename),
  cat(ex. cat > filename) ^D(ctrl + D),
  touch(ex. touch filename)
• COPY : cp
• REMOVE : rmdir, rm -r
• MOVE : mv
• RENAME : rename (ex. rename OldName NewName OldName),
  (ex. mv OldName NewName)

  Option

  • -r : recusive(; include child dir)
  • -i : interactive (ex. rm -i filename) (ex. cp -i SameName SameName)
  • -f : force

Commandとは？

1

[root@centos ~]# コマンド [-option] [argument1] [argument2] ... [argument n]

man(manual page)とは？

• man : コマンドの使い方、またはファイルの説明を確認する。
• 通常200〜300個のコマンドを持ってLinuxを管理する。

1
2
3
4

[root@centos ~]# man [-option] command or filename
[root@centos ~]# man ls
[root@centos ~]# man --help
[root@centos ~]# info commmand (:q)

ls

• ls [-option] …
  (ex. ls -a
  ex. ls -a -l
  ex. ls -al /etc)