CI（継続的インテグレーション）を勉強した

CI(continuous integration:継続的インテグレーション)について勉強した。
CIとは、
プログラムの動作を毎日毎晩確認してバグを洗い出しながら開発を進める手法のこと。確認のために日々プログラムのコミット、コンパイル、テストを自動化する。その為ツールを用いて人がいない夜間にそれら確認を実行する。

そのメリットは

1. 日々少しづつ確認を行うことにより手戻りを最小限にする。（最悪でも1日分の手戻り）
2. それにより品質を高めることができる。
3. 自動化により作業工数の削減が可能。
4. 自動化により作業ミスを減らすことが可能。

となる。これは短期間でプロダクトのデリバリを行うアジャイル開発手法ともよくマッチする。

この考え方をさらに推し進めると継続的デリバリ≒DevOps、つまり本番環境へのプロダクトの投入まで自動化することも目指すことができる。

ちなみにスマホゲームなどは、毎日のようにイベントを行ってゲームを盛り上げようとしており、そのために毎日のようにプログラムの修正が発生していると思う。その場合にはこの継続的デリバリの考え方で開発を行わないとやっていけないはずだ。
一方自分が関わることが多いいわゆる「お堅い企業」においてもビジネスにおいて新しいサービスの早期投入を求められるようになってきており、この考え方の導入がだんだん進みつつある。

NoSQLを勉強した

ちょっとかじった程度で曖昧にNoSQLを理解していたので勉強した。
SQL（というかRDBMS）については、これまでそれなりに実務でもやっていたので理解しているつもりではあった。

これまでのイメージでは、NoSQLとは、

1. ACIDを保証しない。
2. リレーショナルな関連付けとデータの最適な保持（正規化）ができない。
3. 便利なSQLを使えない。
4. ただし高速らしい。

とわりとマイナスのイメージから理解していた。当初は、Hadoopあたりから発展した技術と勝手に考えていた。すなわち巨大データを（ペタバイトとか）をつかって分析を行うためによみ出しを重視して、ACIDを保証しないという理解をしていた。

今回勉強してもその理解は、あまり変わっていなくて「本当ならRDBMS(SQL)で間に合わせたいが、データが巨大すぎ、そのうえで高速な処理を求められるため泣く泣くRDBMSの利点をすてて、要件を満たす技術を作り出した。」

という理解です。

近年、クラウド技術が発展して、かつRDBMSもインメモリで動くようになっています。1クライアント（トランザクションといったほうがいいのかな）が1データ（ROW）を読み書きするだけならば、そして、蓄積された巨大データは別途分析するという要件ならば、

NoSQLという選択になるのかもしれませんが、上記のようなクラウドやRDBMS自体の発展に伴い、使用する局面は少なくなってくるのではないかと考えました。（複雑に絡み合うデータを取り扱うケースのほうが圧倒的に多いと考える）

ちなみにポケモンGoはGoogle Cloud Platformで動いているとので、選択したデータベースは、MySQLの派生DB(Google Cloud SQL)かなあと想像する（カスタムで全然別のデータベースも導入できるとは思うがスケールさせるのが大変そう）

NoSQLも大別すると４種類くらいのタイプがありそれぞれ得意不得意がある。

1. キーバリュー型：とにかく早い
2. カラム型：列単位でのデータ操作が得意
3. グラフ型：グラフというのは、関係性の意味で、複雑な関係性の検索・分析などリレーショナルデータベースで表現できないぐらいの関連付けをデータに紐づけられる（例としては道路網における最短ルート探索とか）
4. ドキュメント型：定型的な構造を持たないデータベース（Row毎にデータ構造を変えることができる）

なので要件によってNoSQLを使用していくことも十分考えられるが、既存のRDBMSがNoSQLの機能をどんどん取り込んでいっているので、先行き不透明という印象を持った。

しかしながら、調べていくうちに例えば、Radis（キーバリュー型にちょっとドキュメント型風味）、Cassandra（カラム型）、CouchDB（ドキュメント型）とかに興味を持った。

あとMongoDB（ドキュメント型）も人気があるようだ。

自分は元々オラクルやサイベース（懐かしい）を使ってたのでやはりSQLに親しみがあるが、上記のDBたちも少しづつ触ってみて評価できるようになりたいと思う。

IoTについて勉強した

IoT(Internet on Thing)とは何か？を勉強した。
文字通り、あらゆるものがインターネットに接続されること（冷蔵庫とか家電）と最初は理解していた。で接続して情報を収集して何になるの？と考えていた。

IoTとは、以下のように定義されるらしい。

1. モノからセンサーによっていろいろな情報をインターネット経由で収集する。
2. 収集したデータを蓄積する。
3. 蓄積されたデータを分析する。
4. 分析に従って、必要に応じてモノにフィードバックする。（センサーついているモノに直接フィードバックすることもあれば、分析結果を社会や企業、の今後に生かすことも指すらしい）

センサーから収集し、蓄積したデータは膨大なものになるので、その分析には人工知能も関連してくる。（人知では分析しきれないほどのデータ量になりがちのため）

とすると応用領域は、例えば電力のスマートメーターによって電力の使用量の傾向の蓄積であるとか、自動車からの交通量の状況蓄積と対策とか、自動車事故を起こしやすい状況の分析とか。また医療分野についてもいろいろな応用が考えられる。介護分野についても同様。（しかし金融の投資動向とか分析されると一般人は、大手金融機関の思いのままになるんだろうなあ）

とするとその情報の管理が大変重要になる。各々のデータが個人情報と結びついた時、その個人の生活が赤裸々になってしまう可能性がある。（もうAmazonやGoogle、Appleにはかなりの個人情報を握られてしまっているが）

2016年9月現在、政府から情報銀行なる構想が提言されたが、個人の購買行動や医療情報などは国に握られたくはないとの思いがある。年金の管理のずさんさ、住基カードの有様をみるととても役所に自分の情報を預けたくはないと考える。（マイナンバーを利用したいのだろうけど、ビッグブラザーの影がチラチラ見えて来る）

DevOpsについて勉強した。

DevOpsといえば高速な開発と本番環境へのプロダクトの投入と思い込んでいた。まちがっていないが、もっと広く深い概念と理解した。

2016年現在確立した定義はないが、自分の理解を列挙してみる。

1. Dev（開発）とOps（運用）の協力体制をより密にすること。
2. これまでは、開発の立場としては、開発したプロダクトをより早く本番環境に載せたい。
3. 一方運用側は、安定稼働を望むため変化を好まない。
4. そのような利害関係があるので、企業体として求められる「早くサービスを提供すること」に対応しきれない部分があった。※上記の書き方だと運用側が抵抗勢力のように読めてしまうが、低品質のプロダクトをもってくる開発側にも問題がある。あと本番環境と開発環境の差異などで障害は発生しがちである。なのでコンテナ技術が発達してきたのかな？
5. そのための考え方がDevOpsという言葉に集約される。
6. より密に協力していこうという考え方の背景は、ITをコストカットのためのツールとしてではなく、ITを使って競争に打ち勝つという考え方がある。そのためより便利で安定性のあるソフトウエアプロダクトが求められている。
7. また協力の考え方だけでなく、それを実現するためのツール群も近年現れてきた。
• ツール群によるプロダクト開発（と投入）のレベルに段階があるので少し解説する。さっき覚えた（笑
1. 第1段階　バージョン管理（本番のソースコードと開発中のソースコードの差異管理。）
2. 第2段階　継続的インテグレーション（テストとOKであれば開発系ソースコードへのコミットの自動化）
3. 第3段階　継続的デプロイ（第２段階の結果、問題がなければプロダクトのビルドと本番環境への適用の自動化）
4. 第4段階　継続的デリバリ（本番環境へのデプロイタイミングをビジネス要求に沿って決定する。※第3段階までくるといつでも本番環境にプロダクトを投入できる状態になる）
• 上記の段階を実現するための便利なツール群が近年登場してきた。
8. 欧米ではここ7,8年前ぐらいからこの考え方はあって、日本では自分の見聞きする限りせいぜい第2段階どまり。（スマホゲームだと第4段階まで行っていないとだめだろうけども、毎日のように何かイベントがあるから）

一番重要なのは6.の考え方だと思う、その方法としてDevOpsという考え方が生まれてきたのだと考える。

ubuntuへのnode.js、npm、expressのインストール手順（2016/08）

node.jsの練習のために多少調べたりして時間を食ったので、手順を記録として残す。
練習のためなので最新版は必要がないのでインストールの簡便さを優先した。

1.node,jsのインストール

sudo apt-get install nodejs

2.おまじない（nodejsをnodeにリンク）

sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10

3.npm（パッケージマネージャ）のインストール

sudo apt-get install npm

4.express（フレームワーク本体）のインストール

sudo npm install express -g

5.express-generator（スケルトンの自動生成機能と思う）

sudo npm install express-generator -g

以上で準備は整ったはず。

ITプロジェクトにおけるカンバン方式について勉強した。

「カンバン」というと「トヨタ」しか連想されなくて、生産管理の手法と思いこんていたので改めて勉強した。

カンバンのポイントは以下のとおり
※ちなみにWikipediaは、難しすぎてよくわからなかった。

1. この方式の導入の大きな目的は、プロジェクトの見える化。
2. 何（タスク）を、いつまでに、誰が、今どこまで、を見える化する手法。
3. 最低限、ホワイトボードと付箋紙があれば実行できる。
4. （おそらく一番単純な書き方では）ホワイトボードに縦に３本線を引く。
5. 左の列は「ToDo」何をするのかを付箋紙で貼っていく。
6. 真ん中の列は「Doing」仕掛り中の付箋紙を「ToDo」から移動させる。
7. 右の列は「Done」終わったタスクを「Doing」から移動させる。
8. 付箋紙にはだれが、いつまでに、どんなことをするのかを書く。（はず）
9. ホワイトボードではなく、コンピューターのツールを使ってももちろんいい。
• チームの人数がすこし多くなるとその方が良いのだろうと思う。

上記は、単純なパターンだが列を増やしプロセスを細かくすることも可能。

上記をみて巷でいうチケット駆動では？と思ったがそちらも詳しくないので後日調べてみる。

しかしこれは自分が関わったような大規模プロジェクトでは、導入しにくいのではと思った。やり方に問題があるのではなく「見える化」を良しとしない人がいるためだ。表向きは、「プロジェクトなので見える化は推進されるべき」となるが、実際は見えると困る人達がいる。プロジェクトの進捗状況は、その人自身の評判や人事考課に関わってきたりする。なにしろ一目で「できない人」がわかってしまうので、日本人の性質なのか赤裸々にそれを明確にすることは難色を示されることがあるのではと感じた。

個人的には、ITプロジェクトにおける「できる」「できない」は、向き不向きの問題なので、赤裸々になっても恥じることはないと考えているが。

JSONを勉強した

Web越しのデータの受け渡しにJSON(JavaScript Object Notation)という形式が使われると聞いたので勉強してみた。かつてはXMLが主流とおもっていたのが、必ずしもそうではなくなったらしいので勉強しておかねばと思った。（特にJavasScriptを勉強するにあたって）

XMLは構造をあらわすのに便利な形式ではあるが、ちょっと冗長なところがあるとは思っていた。入れ子構造をあらわすには便利だと思う。しかし可読性はそれほど良くないところもあり、単純なデータ構造をあらわすためにJSONという形式ができたのではないかと思う。単純な設定ファイルなどのためには、XMLは大仰なのかもしれない。

JSONの簡単な記載例を以下に示す。

{
    "年齢":50,
    "住所":"東京都杉並区",
    "ペット":["犬","猫","猿","雉"],
    "既婚":false
}

左側にデータ名、コロンで挟んで右側にデータ値。超簡単ですね。
ペットの記載例のように配列も取り扱い可能。記載例には書かなかったが入れ子構造も可能な様子。（オブジェクトというものを使うのかな？今回は割愛）

確かにXMLよりは可読性に優れているように思います。
RDBMSでJSONをサポートしたというニュースを聞くのもなんだかわかる気がします。

SOAについて考えてみた

これまで関わった２つのプロジェクトで基本的なアーキテクチャにSOA(Service Oriented Architecture)を採用していた（とされていた）。

まずSOAとは、概念であり、技術や製品ではないと記述をあるところで読んで、ひっくり返りそうになった。

SOAの概念、利点は以下とおり。

• 業務（領収書を発行する等）単位でプログラムを部品化し再利用できるようにして、システム単位のみならず企業単位で最適化を図る。（例えば組織変更によるワークフロー変更への柔軟な対応とか）もうすこし詳しく書くと、
1. 業務の部品化する。
2. 部品を組み合わせてアプリケーションを構成する。
3. オープンな技術による（SOAP等）標準的なインターフェースを備える。

と理解した。

とすると、関わった２つのプロジェクトは、いずれも（かなり有名な）パッケージ製品を利用することが決まっており、外部からアクセスする為のAPIも当然備わっていた。それぞれのプロジェクトは、別途アプリケーションサーバーを立て、APIにかぶせる形でSOAサーバーを立てていた。（SOAは概念であるとするとSOAサーバーって変な感じ）

パッケージ製品のAPIは、部品化され標準にのっとったインターフェースを備えており、さらにSOAサーバーが必要な理由がよくわからなくなってくる。

真に企業においてSOAの概念が必要なケースは、全く新規にシステムを一から再構築する場合のように感じる。

つまりバズワードであるSOAを営業的に使って、SIerから余計にサーバーを買わされただけなのが真実なのだろうか？

Visual Studio Codeを使ってみた。

node.jsを練習するために、入力補完のあるEditorを使いたいと思った。
クラウド開発環境のCloud9は、結局インストールがめんどくさく諦めて、練習のための環境整備の為に労力を割くのもバカバカしいと思い、割り切ってローカルでIDE(Integrated Development Environment))を使うことにした。いろいろなIDEがあるが今回は新進気鋭のVisual Studio Code(2016/08/15 v1.4 Microsoft製OSS)を使ってみようとインストールしてみた。インストールは凄く簡単でだった。

余談だが商用のIDEも検討してみたが、だいたい300、400ドルもするので断念した。これだけの価格差の価値のある機能なのかわからずチュートリアルのためにそれだけの出費をすることは納得できなかったので諦めた。（グループワーク機能や各種フレームワークへの対応が充実しているように感じたが、チュートリアルそこまでの機能は必要としていない）

node.jsの入門本のチュートリアルをやってみるだけなので、とりあえず20行〜30行ぐらい編集できれば良い。なのでエクステンションはまったくインストールせずにそのままとりあえず使ってみた。４、５年前にはEclipceをPythonの為につかったことがあるが、そのときよりもかなり進化しているように感じた。（Pydevってエクステンションをインストールした記憶がある）

まずチュートリアルの為の簡単なhtmlを作成しておおっと思ったことは。

1. 入力補完がずっと進化しているような気がする。
1. カッコ(){}の補完が便利。
2. タグの候補が2,3文字入力するだけで表示される。（タグ以外の文字列も補完してくれるのかな）
3. Tabの段落下げをかなり自動でやってくれる。
2. Terminalが内蔵されているので、エディタ内で完結できるので良い。
3. ファイルブラウザ（エクスプローラー）がデフォルトで内蔵されている。
4. 思ったよりずっと軽かった（Eclipceはかなり重かった気がする。昔いた現場では現場ではプログラマーは、ロースペックのPCでEclipceでJava開発をしていた。機能はともかく重くてしんどかっただろうなあ。）

まだまだ使いこなしていないが、いろいろ便利なんだろうな。手慣れたプログラマーにとっては基本的な機能でも、おじさんの手習いとして使うには凄く感動した。

Macにおける仮想化環境（VirtualBoxとParallels Desktopの簡単な比較）

最近Macを買い換えたので、移行アシスタントを使わずに新しいMacに一からソフトウェアをインストールすることにした。

旧Macでは、ちょこっとした仕事にOfficeを使う為、Parallels Desktopを買ってその仮想環境にWindowsをインストールして使っていた。ソフトウェアの見直しに当たってParallels Desktopを使い続けて課金するのもなあと思い始めた。よってかつて使い慣れたVirtualBoxに戻ることにした。そこでとことん使い倒しているとはいえないものの、両者を簡単に比較してみる。

Parallels Desktopの良いところ。

1. （おそらく）パフォーマンスが良い。Macbook Airの1.7GHzで32bitWindows7および10がキビキビ動いていた。バリバリ3Dとかでなければ上記スペックでもゲームで遊べていた。Officeももちろん普通に動く。
2. Guest OS（特にWindows）への対応が早い。
3. 設定とか全然考えずにファイル共有とかクリップボード共有とかが出来ていた。

Parallels Desktopの良くないところ。

1. メジャーバージョンアップ（MacOSのメジャーバージョンアップとタイミングはほぼ同じ。）ごとにバージョンアップの費用が五千円くらいいる。（バージョンアップをしないという選択肢もあるが、最新OSにだんだん対応しなくなっていく）
2. なんか自社製品の広告が時々出てうざったい。（たまにだが）
3. 設定は至れり尽くせりなのだが不要なエイリアスとか勝手に作ってくれたりする。
4. クロスプラットフォームじゃない。（これは結構大きいかも）

VirtualBoxの良いところ

1. ただ（USBまわりの機能拡張を入れると完全OSSではないが無料）
2. クロスプラットフォーム（作った仮想環境を別のPCに持っていける）

VirtualBoxの良くないところ

1. 新しいMacbook Proでは試していないが、過去の記憶ではゲームとか描画系が厳しかったのでゲームとか無理（と思う）
2. 一時期オラクルがサボっていてアップデートが滞っていた気がするので、将来的に不安。
3. 細かいところまでの設定が厳しい（Xubuntu16.04のインストールでは結局サウンドドライバ周りは切った）。HOSTとの共有フォルダとかは自分で設定が必要（その方が良いケースもあるが）

よって今回は、お金とクロスプラットフォームを取ってVirtualBoxにした。

あとOffice365を使っているので、Mac版の最新Officeをインストールできたのも大きい。

余談だがOffice365マジおすすめ。昔は互換性が悪いという話も聞いたが、今のところ問題ない。

node.js練習用開発環境を作成した

目的：できるだけ早く、お試しで単純なwebサービスを作ること。（内容はまだ秘密）

手段：開発言語は、node.js+express+HTML+javascriptでやりたい。

方針：なるべく手間をかけずに早くサービスを立ち上げる。

環境作成

1. クラウドを使いそこにWebサービスを置く
2. 開発は、ローカルでやるが仮想環境上に構築したい
3. プログラムは、クラウドにファイル転送（SFTP）する。（ゆくゆくはrktとか使うか）

手順

1. MacにVirtualBox（仮想化ソフト）をインストール。（手順は省略。）
2. VirtualBoxにXubuntu（ubuntuの派生ディストリビューション。ISOが1G超えてる。。もうCDROMには収まらないのか。）をインストール。（手順は省略。理由は慣れているから。）
3. Xubuntuにnode.jsをインストール（練習なので最新版でなくお手軽インストールを重視）
1. sudo apt-get install nodejs
2. sudo apt-get install npm 
3. sudo update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10
4. node -v　（v4.2.6　20160809現在。練習なので最新でなくて良い）
5. sudo npm install express
4. XubuntuにVisual Studio Codeをインストール（新進気鋭のMicrosoft製エディタでコード補完機能も充実してそうだから）
5. 続いてクラウドの設定、Vultrを選択（お手軽、東京リージョンがあるから。こちらからサインインしてもらえると。とてもとてもありがたいです。）
6. クラウドにubuntu serverをインストール（慣れているから、インスタンスの維持は最低価格で月5ドル。インスタンスを破棄すれば課金されません。）
7. rootしかないので、useradd -m hogehoge
8. 上記の3.の手順でnode.jsをインストール
9. XubuntuからSSHでクラウドに接続。

一応一通り環境ができたので、練習開始。

自動運転の自動車がする判断について

近年の技術の発展はめざましく、自動車の自動運転技術が競って開発されて実用化間近で、本当の路上での実証実験や運転者のアシスト機能として自動車にその機能が搭載されたりしている。最近、自動車の自動運転での死亡事故（テスラ）が海外であり、ちょっと思うところがあるので書いてみる。

自分も昔、自動車を運転していたためわかるのだが、自動車を運転していると色々な場面で色々な判断、選択をせまられることがある。前に割と早い速度でカーブを曲がるときに、急な土砂降りでできた水たまりの上に乗って制御不能になりそうな場面があったりした。

上の例は、単に自分のドライブテクニックの問題かもしれないが、自動車運転においてどうしようもない場面（急な飛び出しとか）は起こりうると思う。どうしようもない場面でそのときにとる行動は、人間の場合それぞれだ。

子供が急に飛び出してきた。そのときに取りうる選択肢の例としては、

1. そのままブレーキは最大限かけるだろうが、まっすぐ進む
2. 自分を犠牲にして横の壁に向かって激突しに行く
3. 逆方向にハンドルを切る（ただしそっち側には老人がいる）

人間で自分のようにドライブテクニックもない場合は、だいたい1.しかできないのではないかと思う。テクニックのある人は2.を選択するかもしれない。さらにテクニックのある人は、1.2.3.のうち最大限人命を損なわない可能性にかけるかもしれない。（1.の場合は前方不注意になるんだろうなあ）

自動運転にすると、人身事故はすごく減るんでないかという話をきいた。スピードは必要以上に出さないし、パニックにならないし、蓄積された膨大なデータから最善の運転方法をとるだろうし。（ここで思いついたのが、自動運転ばかりだと、自動運転プログラムは自然と連携して動けるが、人間の運転者が一人でもいるとそれがノイズとなって、事故の確率が上がるというジレンマが。。）

しかし自動運転でもどうしようもないケースはあるだろうし、その場合上記も1.2.3.のどの選択肢をどのようにとるか、どうゆう風にプログラムされているのかは気になった。

確率で一番安全策をとるのだろうか？完全に同確率の場合、命の選択をせまられるが、命の重み付けをしたりしているのだろうか？老人は轢いてもよしとか。。道交法上は、運転者の命が一番軽い設定のような気がするが、そういうプログラムになっているのだろうか？

仮に誰が亡くなったとしてもその責任は運転者に帰すのだろうか？（テスラの事例は、自損で運転者の死亡だった）プログラムの判断ミスに対する責任は問われないだろうか？とすると自分でハンドルを握りたいなあと思った。

まあ飛行機はすでに離陸はほぼ全自動らしいけど。着陸は難易度が高くてまだプログラムには任せられないらしい。

--追記--

テスラモータースの事故は、横切っていたトレーラーに直進して追突ということののようだ。しかも制限速度違反で。自動追突防止装置は付いていたらしいのだが、まず制限速度も認識できない自動運転て怖いとおもった。

node.jsで’Hello World’してみた

初めてnode.jsを触ってみた。参考書に従ってインストールをしてHello worldしてみた。
node.jsの特徴は、

1. サーバーサイドで動くJavaScript
2. 非同期処理（I/Oの結果を待たずに並列で処理を行う）
3. シングルスレッド（マルチスレッドよりメモリ消費が少ない）
4. イベントドリブン（リクエストがあったときだけ処理を行う）
• ちょっとよくわからない常時起動してないってこと？
• あとで掘り下げて勉強する

それにより得られるメリットは、

1. 大量のリクエストをさばくことが可能
2. リアルタイム処理に向いている（イベントドリブンのため）
1. なんで？

node.jsのプログラムサンプル

"

//Webサーバーの定義

var http = require('http');

var server = http.createServer();

server.on('request',doRequest);

server.listen(1234);

console.log('Server running!');

//リクエスト処理

function doRequest(req,res){

 res.writeHead(200,{'Contnt-Type':'test/plain'});

 res.write('Hello World\n');

 res.end();

}

"

簡単すぎる。。上の10行でブラウザでhttp://localahot:1234/ でHello World!が表示される。

コマンドラインとGUIの狭間

当たり前なのかもしれないが、熟練者にとってはコマンドラインの方が圧倒的に早い。
最近は、ツールの入力補完も充実しているのでタイプミスも少ない。

しかし自分のような初学者だったり、手っ取り早くポチポチOKボタンを連打して環境を作り上げたい場合にはGUIがあればなあと思うことも多い。

自分は元々コンピューターの世界に入ったのはNECの汎用機からだったし、その後オフコンを使っていたりしたので、コマンドをタイプすることに大きな抵抗はない。

コマンド書いてバッチ処理は、いろいろメリットがあることもわかっている。しかし若い時はコマンドを（プログラミング言語も）覚えることは苦ではなかったが、もうおじさんになってきたので、コマンドの意味を覚えるのも一苦労。コマンドを意味を覚えるに当たって、マニュアルをにらみながらポチポチ打っていく根気が無くなってきたと思う。

一方GUIは、Windows3.1が最初に触ったGUIとなる。しかも昔でいう4GL開発（ボタンとかウィンドウをペタペタ画面上にはって、それぞれの部品（オブジェクト）に対してコードを書いていく。ちょっとしたカルチャーショックだった。

プログラムを書いていくのは仕方がないが、環境構築についてはもうちょっと楽にならないかなあと思う。思うような環境を作るためには、コマンドを何回も叩き、インストールを繰り返し、うまくいけばいいがトラブルが発生すると何が悪かったんだろうと、原因究明にすごく時間がかかったりする。ソフトゥエア間の依存関係が複雑になってきているからかなと思う。

またそれぞれのソフトゥエアのお作法というものがあり、それを覚えるのが大変だったりする。昔のようにCOBOL、JCL以上！という世界にちょっとだけ、戻りたい気もする。オールインワンでポチポチインストールすれば以上終わり、という商用製品に目がいったりする。当然今の方が断然自由度が高いが。今ではCOBOLでWEBアプリとか作れるのかな？明らかに向いてない気もするが。。

環境構築がうまくいかないのでちょっと愚痴ってみた。乗り越えなければならないハードルだけれども。

CoreOSを勉強した

遅ればせながらCoreOSを勉強した。

CoreOSとは、Linuxのディストリビューションの一つだが以下の特徴がある。

1. コンテナ（Dockerなど）を動かすために特化したLinux
2. そのため一般的な機能（コマンドとか）は最小限にされている。（ツールとか簡単に入れられない）
3. クラスタ機能を標準でもっている
4. 分散システムのためのツールを装備

なので、コンテナのためのOSなので、ここに巷に出回っているDockerイメージをぶちこめば、すぐに環境が構築できるはず。

開発環境構築でハマる（いきなり高い目標を掲げるのは悪い癖）

勉強のため、ちょっとしたプログラムを作りたいと思い取り掛かったが、ハマる。

やりたいこと

1. どこからでも環境にアクセスできるようにクラウド上に環境を作る。
2. ブラウザさえあれば作業できるようにWebベースのIDEを導入する。

やろうとしていること

1. クラウドは、Vultrを選択。これまでは、DegitalOcianを使ってきたが新たに使ってみることにした。理由は、Tokyoリージョンがあるため、アジアはシンガポールリージョンしかないDegitalOcianよりレスポンスが良いかなと考えた。（ただし出来合いのアプリケーションを一発で入れることができるのはDegitalOcian、インスタンスの作成とかスナップショットからのレストアもDegitalOcianのほうが気持ち早いかな）
2. ディストリはubuntuを選択。理由は使い慣れているから、CoreOSも使ってみたいけど。そこから覚え直すのかなあ。。
3. IDEはCloud9を選択。Amazonに買収されて話題だし、使い勝手が良いと評判。

１、２は超簡単。幾つか選択をしてボタン一発。SSHで接続する。useraddでユーザーを作ろうとするが、デフォルトで/homeにディレクトリ作ってくれなかったっけ？ディレクトリを作成。

３で、必要なもの。

1. node.js
2. python（2.7系列？）

node.jsのインストールはうまくいった。ubuntu16.04はpython3系列しかない？←いまここ

--追記--
やはり16.04からpythonは3系列がデフォルト。

-2016/7/26追記　ubuntu16.04にpython2.7を導入。
node.js + expressまで導入。

-2016/08/09追記
やはり思い直すし上記の環境は破棄することにする。

サーバレスアーキテクチャについて勉強した

最初にの言葉を知った時なんだろうと、？マークが３つぐらい頭に浮かんだ。

いろいろ調べていくにつれ以下のことがわかった。
※クラウドサービスを使う前提。

1. 一般的なWebのシステム構成としては、2層構造となる（アプリケーションサーバー（Webサーバー含む）、データストレージ）
2. しかしサーバーレスアーキテクチャでは、このうちのアプリケーションサーバー層が存在しない。
3. もう少し厳密にいうとアプリケーションサーバーは、（あたりまえだが）サーバーとして常駐し、リクエストを待ち続けている。よって常にCPU、メモリ等のリソースを消費し続けている。
4. サーバレスアーキテクチャによると、プログラムは常には起動していない。リクエストがあった時に起動され、リソースを消費する。
5. 代表的なサービスは、Amazon Lambda

※ただしサーバーがなくなったというよりは、サーバーの存在を意識する必要がなくなったという方がより正確らしい。

メリットは、以下のとおり

1. サーバーとして常に動いていないのでリソースを使わない（コストの削減）
2. スケーリングが楽（サーバレスを実現する仕組みのたまものだとも思うが、サーバー自体をリクエスト量に応じてスケールさせるにはそれなりの仕掛けを構築する必要がある）
3. サーバーがないのでサーバーの運用管理が不要（サーバーが死んでいないかを機にする必要はない）

デメリットは、

1. まだこれからの技術なのであまり複雑な処理には向かないかもしれない。

比較的、静的なリクエストの大量処理に向いているかもしれない。

ブロックチェーンについて勉強した。

話題のBitcoinと関連技術のブロックチェーンについて勉強した。
主としてブロックチェーン技術について記載する。

ブロックチェーンとは、

1. ネットワークを利用した改ざんが困難かつ、堅牢性（システム的に非常に障害に強い）の高い「台帳の仕組み」
2. なぜ改ざんが難しいか？データの変更の履歴をすべて保持するから（単純に変更履歴を持つと膨大なデータ量になるが、最新技術により過去履歴をそのまま保持するわけではないと理解（ハッシュデータとして保持））
3. 一回のデータ変更と一つ前のデータ変更履歴のかたまりをブロックと呼ぶ。
4. ブロックが連続してつながる（チェーン）ことによりデータの一貫性を保つ、よってブロックチェーンと呼ばれる。
5. なぜ改ざんが困難なのか2？改ざんを行うためには、チェーンのつながり全てを改ざんしなければならないから。
6. また各ブロックは、ネットワーク上に分散して保持されている為（いわゆるP2P）中央サーバー型のデータ保持が一つのサーバーをクラックし、改ざんすれば良いのに比べ、データの改ざんが非常に困難。
7. 各ダータ変更は分散されたコンピューター上で検証され（つまり複数の検証）正当性を担保する。
8. また各ブロックは公開鍵秘密鍵方式による暗号化技術をもって署名される。

よって、非常に堅牢かつ安全な台帳を構築することが可能となる。

ただし、欠点もありデータの検証には多大な計算が必要となる。その為の分散技術でもある。

ブロックチェーンの具体的な実装はBitcoinであるが、仮想通貨を安全に運用する為には、上記の技術がバックグラウンドとなっている。（チートによって、仮想通貨が無限増殖したりすると、信用を毀損する）

そしてこの技術が注目されている理由は、ありとあらゆる「台帳」にこの技術を用いることが可能な為である。ちょっと想像するだけでも在庫管理、株の取引、会計管理もろもろありそうである。特に金融機関からこの技術が注目されているらしい。

今日の疑問1 個々のデータの正当性は担保できるとして、データ全体の統計はどのようにとるのか？（例えば今日現在の全世界でのBitcoinの総額）

Dockerを勉強した（その2）

昨日書いたことに間違いがあったので、まずは訂正。


3．コンテナには、さまざまな依存関係のあるアプリケーション群を一つにパッケージングしたものである。（例えばWebサーバー、アプリケーションサーバー、データベースを一つにまとめたもの）

→といった使い方は、あまりしないらしい。Webサーバーで1コンテナ、アプリケーションサーバーで1コンテナというふうに分割して運用するのが普通らしい。

そして昨日の疑問、

疑問1：アプリケーション空間、ユーザー空間の仮想化とは、まだちゃんと理解できていない。どのレベルでDockerEngineは仮想化するのか

→独立したプロセス空間、ネットワーク空間を提供する。（アプリケーション側からは一見１つのOSとして見える。OSより下位レベルのシステムコールとかはできないんでしょうね）

疑問2：環境依存する部分は本当にないのかIPアドレス、MACアドレスとか。DockerEngineがそれを吸収するのか？あるいは環境情報は別途デプロイする必要があるのか？

→仮想ブリッジと仮想ネットワークインターフェースによってネットワーク差異を吸収する。（すごいぜ！）

その他
コンテナ自体の冗長化（クラスタリング）技術は、まだ発展途上にあるらしい（ほんのつい最近そういった技術が発表されつつある）
とすれば、大規模サービス（ブラウザゲームとか）は、OSレベルで冗長化して、その上にコンテナをいくつも載せていく構成になっていくのか？
自分は、これまでレガシーシステムの刷新を多く手がけてきたので、これら技術の基幹システムへの導入例は不勉強にして知らない。このような技術によって大企業の多くが悩んでいる迅速なサービスの提供が可能になる気がします。

Dockerを勉強した（その1）

Dockerについて全然わかっていないので、まずガバッと勉強することにした。
有識者の方には何言ってんだこいつと思われることもあるかもしれませんがご容赦を。

まず今日理解したこと。

1. Dockerとは、コンピューターの仮想環境を構築する仕組みの１種である。
2. Docker（という仕組み）の環境の一つ一つをコンテナと呼ぶ。
3. コンテナには、さまざまな依存関係のあるアプリケーション群を一つにパッケージングしたものである。（例えばWebサーバー、アプリケーションサーバー、データベースを一つにまとめたもの）
4. コンテナとは、OSを仮想化するわけではなく、アプリケーション実行環境の仮想化である。（今日の疑問1：アプリケーション空間、ユーザー空間の仮想化とは、まだちゃんと理解できていない。どのレベルでDockerEngineは仮想化するのか）
5. コンテナは環境依存しないので、開発環境で作成したアプリケーションをそのままデプロイすればそのまま動く（今日の疑問2：環境依存する部分は本当にないのかIPアドレス、MACアドレスとか。DockerEngineがそれを吸収するのか？あるいは環境情報は別途デプロイする必要があるのか？）

Dockerの利点

1. 上記と重複する部分があるが、開発環境と本番環境の差異（CPU、メモリ量、ディスク量などは当然差異がある。しかしそれらはスケーラブルであることを前提にした作りにしておけば良い？）がないはずなので、開発環境のアプリケーションを本番環境にそのままおけば動く（はず）

その他（感想とか）

1. コンテナ技術は、Docker以外にもあるが現在はDockerが主流。
2. 仮想化技術の進歩は目覚ましい。コンテナ以外にも新しい技術がたくさん生まれては消えていっている。過去に確かSun Microsystemsが夢見ていた、どこでもなんでも同じように動く世界がだんだん実現しようとしてきているのか？