最近はコンテナにはまっております。Docker便利やね。

さて、今日は会社を休んでAWSソリューションアーキテクトのプロフェッショナルを受験してきましたが

案の定落ちてしまいました。というか、一回どんなもんかということで半額バウチャー使って落ちに行きました。

ちなみに勉強期間は２週間。受かる気なし。何点で落ちたんでしょうか。（半額バウチャー残り１個・・・）

受けて感じたのは、１８０分７５問はなかなか疲れる（笑）

集中力がもたんね。あと、日本語がわかりにくい。英語に切り替えて読んだ方が分かる問題が多々ある。

内容としては、EC2、S3、RDSとかはアソシエイトを取得してればそんなに勉強しなくてもいけるかも。

この辺が結構出たので要勉強。。。

・AWS Organizations、CostExplorerを使った料金管理

・ECS、Fargate（コンテナ周りの知識を問われた）

・「API Gateway→Lambda→DynamoDB」の構成を使った問題

　（アソシエイトの時はELB配下にEC2がぶら下がってる問題が多かった気がする）

・AWS Systems Manager 、Config、CroudTrailとか使った構成管理周り

・Recognition、Kinesis等を使った動画サービス系の問題（動画サービス作りがち）

・OpsWorkを使った構成管理

あとはSnowmobileとかHadoopとか、なんせ問題が多いし使ってるサービスもコアなところ突いてくる

今回は本も出てないので、とりあえずホワイトペーパーを和訳して読みまくるしかないのと

わからんところまじで触らないとホンマにわからん

とりあえず今回の敗戦記録が他の人にもぜひ伝わりますように。

（ブログはQuiitaではなくあえてアメブロで続けていこうと思います）

勉強方法ですが、とりあえず以下の参考書を３週して完全に覚えました。

https://book.impress.co.jp/books/1118101069

ホワイトペーパーはAWS Well-Architectedだけ読みましたが、あとは正直読んでません。

また、恥ずかしながら以下のサイトでゴールドプランに登録しました。

https://aws.koiwaclub.com/

結果的に思ったのは、アソシエイトに関してはそこまで勉強しなくても大丈夫だなと思いました。

最近はいろんな本も出ているので、比較的取りやすくなっているのかなと思っています。

一番効果的だったのはやはりハンズオンですね。

わからないところは軽く触ってみる。これが一番頭に入ってきました。

ということで次はプロフェッショナルを受験。

会社から9月末までに受けて合格せよという使命を受けておりますので

死ぬ気で勉強してみますか。

最近は仕事でAWSを触る機会があったので猛勉強中です。

勉強がてら、そっちの記事もいつか載せていければと。

そんな感じで今回はmacbook でApacheを使ってBasic認証の設定を練習してみました。

（今日は面倒なので画像もHTMLタグもなしで記事を書きます。）

やること

１：Apacheを起動してみる。

（ちなみにmacではApacheデフォルトインストールされてます。）

　　MacBook-Air:Documents admin$ sudo apachectl start

　　ブラウザで　http://localhost　につないで　It works!　が表示されればOK

２：http.confの設定を変える。

　とりあえずsudoで以下ファイルを変更

　MacBook-Air:Documents admin$ sudo vi /etc/apache2/httpd.conf

　どこを変えるかというとこの辺です。

    #

    # AllowOverride controls what directives may be placed in .htaccess files.

    # It can be "All", "None", or any combination of the keywords:

    #   AllowOverride FileInfo AuthConfig Limit

    #

    #    AllowOverride None

     AllowOverride All

AllowOverride None　を

AllowOverride All

に変えてあげます。（私はコメントアウトで念の為残しました。）

３：ドキュメントルートに移動

MacBook-Air:Documents admin$ cd /Library/WebServer/Documents/

こんなディレクトリにあるんですね。

４：.htaccess　ファイル作成

MacBook-Air:Documents admin$ touch .htaccess

viコマンドで中身を記述。

ファイルの中身↓

AuthUserFile /Library/WebServer/Documents/.htpasswd

AuthName "Input ID and Password"

AuthType Basic

require valid-user

４行です。

５：.htpasswdファイルを作成

以下コマンドを実行。

sudo htpasswd -b -c /Library/WebServer/Documents/.htpasswd userid pass

userid と pass　は任意のやつでOK

htpasswdコマンドのオプションは色々あるみたい。

とかとか、そんな感じです。

念の為Apache再起動

sudo apachectl restart

localhostにつないでユーザーIDとパスワードを求められたら設定完了

お疲れ様でした。

今日仕事してたら会社のファイルサーバにVisual Studio Codeなるものを見つけたので

家のパソコンにインストールしてみる

OSはWindows10です

以下のURLにつないでください
https://code.visualstudio.com/

こんな感じの画面が表示されるので

画面右上の「Download」ボタンを押下

なんせ以下の画面が表示されるので

必要なOSに応じてインストーラーを落としてみる

普通に「↓Windows」ってボタンを押したら落とせた

【落としたインストーラー】

VSCodeUserSetup-x64-1.27.1.exe

さっそくダブルクリック

同意して次へ次へ行ってインストール

設定何もかえてないです

できたけど全部英語なんじゃ

「View」→「Command　palette」を選択したらコマンド入力ができるので、「configure」と入力

そしたら「Configure display language」って出てくるので選択

C:\Users\○○\AppData\Roaming\Code\User\locale.json

のファイルを編集

{

    // Defines VS Code's display language.

    // See https://go.microsoft.com/fwlink/?LinkId=761051 for a list of supported languages.

    "locale":"en" // Changes will not take effect until VS Code has been restarted.

}

↑"locale":"en"を"locale":"ja"に変更して再起動

みたいな感じらしい

再起動しても日本語にならんかったのでまた調べてみよう

【追記】

単純に日本語化パッケージ入れればよかっただけ見たい。

ということでApache2、Mysql、PHPをインストールして動かしてみた。

結構普通に動かせるもんですね。とりあえずApache起動。

sudo service apache2 start

からのphpinfo（System情報に個人情報入っちゃってるわいな。）

/var/www/html/phpinfo.php → ファイル名的によくないらしい。また勉強します。

この画面見てると大学時代を思い出すなー。

さて、何を作ろうか。全く思いつかん。というかJQueryとRuby勉強したい。

JUnit、自分で使ったことないので勉強してみようかな。

ということで購入。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus) 3,564円 Amazon

でわでわ

完全に放置でした。三日坊主的な感じですが、なんとなく更新してみようかと。

というわけで、先日日経クロステックでWindows版Linuxという記事があったのでなんとなく試してみることにした。

http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00203/031200001/

Windows 10 Fall Creators Update以降、下記手順で有効化すれば使えるみたい。

詳細はURLを見てもらいたいですが、要はpowershellで以下のコマンドを実行すれば使えるようになります。

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

あとはMicrosoft StoreでLinuxディストリビューションをインストール。

僕はUbuntuで行きました。

で、そこから以下をインストールします。(僕がphp使いなので。。。)

【Apache】　# sudo apt-get install apache2

【PHP】　　　# sudo apt-get install php7.0　→時間かかる

【MySQL】　# sudo apt-get install mysql-server　→途中でrootのパスワードを入力する画面が出てきます

準備自体はいったんこんなかんじ。

次は実際にサンプルを動かしてみる。

この本がおすすめかも

はじめてのPHP、MySQL、Apache―この1冊でPHP、MySQL、Apacheのすべて... 15,373円 Amazon

デプロイについて全く触れていなかった

ということで今回はデプロイとは何かということを書いてみよう

前回（http://ameblo.jp/ochikoborese/entry-12168132518.html）書いた継続的インテグレーションの話につながります

そもそもデプロイとは

deploy：配置する、展開する

という意味を持ちます（TARGET1600が懐かしい）

前回書いた通り、ソースをコンパイルしてうんにゃらかんちゃらを自動化するということを説明しましたが

そのソースをコンパイルして本番環境へリリースする一貫の流れをデプロイといいます

で、デプロイをJenkinsで自動化する話をしましたが、デプロイのプロセスを自動化する実装のことを

デプロイメントパイプラインといいます

【開発→コミット→コンパイル（ビルド）→自動テスト→リリース→本番環境】

また、デプロイの自動化のことを継続的デリバリーともいいます

この仕組みを用意しておくことで、ノウハウさえ抑えていれば誰でもリリース作業ができるようになります

（私のプロジェクトではJenkinsを利用したオーケストレーションを実装してます）

ただし、本番環境へのリリースを実施するにはシステムの停止を伴う場合があります

本番環境を停止せずにリリースを実施する手法として

ゼロダウンタイムデプロイメントがあります

その手法の中でもブルーグリーンデプロイメントが主なやり方なのかなぁと思います

ブルーグリーンデプロイメントの考え方について、以下２つの環境の考え方があります

ブルー環境：最新バージョンの資材をリリースする環境

グリーン環境：現行バージョンの資材をリリースする環境

グリーン環境はサービスを起動したままの状態で利用者がシステムを使える状態にしておき

ブルー環境で最新資材のリリースやグリーン環境へリリースする前の動作確認を実施します

そうすることでサービスを止めずにリリース作業の実施を実現することができます

しかし、基盤系システムの上で業務系システムが動いている場合

業務系システムのブルー環境での動作確認は容易にできますが

基盤系システムのブルー環境での動作確認は難しくなる（業務系システムに影響を及ぼす）ので

業務系システムが動いていない基盤系システムのみの環境というものを作成する必要があります

なので、業務系システムの環境確保が優先されがちですが

実際には基盤系システムの環境確保を最優先しないといけません

という運用の観点も意識して、デプロイの仕組みを実装していく必要があります

そんなこんなでデプロイについて書いてみました

次は何を書こうかな

面白いものを見つけたら書いてみよーっと

でわでわ

前回まではソースの管理や自動化の話を書きましたが

今回はチケット管理についてです

システムを開発するにあたり付き物なのが障害ですね（障害対応しんどいです。。。）

ちなみに、ITILの観点で障害というと、問題とエラーの２つの観点があります

問題：障害の原因が未知のもの

エラー：障害の原因が既に判明しているもの

まぁこのへんも追々書いてみようかな

で

障害が発生したらまず原因を突き止めてどのように対策したらいいかを考えますよね

そうしたら、どの事象に対して誰が何をいつまでにするかを管理する

という作業が必然と発生します

最初はエクセルで管理していましたが

いかんせん表計算ソフトなのでやれることに限界が見えてきます

そこでチケット管理ツールの登場です

チケットとは、管理対象のタスク一つ一つの単位です

別にエクセルやテキストでも管理できるじゃんってなるかもしれませんが

チケット管理ツールを導入すると以下のメリットがあります

・何をしないといけないのか管理できる

・担当者のアサインができる

・タスクの一元管理・共有ができる

・タスクに対する期限の管理ができる

・タスクのステータスが管理できる

・タスクの検索が可能になる

・各タスクのレポートが作成できる

・GitやJenkinse等のツールと連動ができる　　...etc

そんな感じで、タスクの管理に拡張性を持たせることが可能になります

ここで勘違いして欲しくないのが、チケット管理は障害発生時にのみ利用するわけではないということです

バグ修正以外にも作業が発生した際にチケットを起票することで

そのプロジェクトチームで何をしないといけないのかを見える化することが目的です

チケットが起票されていないソースファイルの修正はGit上更新しない（コミットしない）とか

チーム内で運用ルールを作ることで品質向上にもつながってきます

ちなみに、メジャーどころではTracやRedminaがあります

【Trac】

https://trac.edgewall.org/

【Redmine】

http://redmine.jp/

両方ともオープンソースなので、ぜひ取り入れてみてください

個人的にはRedmineがおすすめです（プラグインが豊富）

GitHubとRedmineのようなバージョン管理とチケット管理を連動させると

ソースの変更内容と課題の紐づけが出来てバグの追跡がやりやすくなります

プロジェクト管理の品質向上にもつながるので、ぜひぜひ試してみてはいかがでしょうか

（このブログ、すごい表面的な内容しか書けてないですね

　詳しい人が見たら色々突っ込みを受けそうな気がしてます。。。）

んー、次は何を書こうかな

会社で初めてJenkinse先生を見た時に「なんだこのヒゲは」と衝撃を受けました

←彼がJenkinse先生です

ここでは自動化、継続的インテグレーションとJenkinseについて書いてみます

システム開発では色んなものが人の手を介しています

製造して毎回最新ソース持ってきてコンパイルを手動で実施して

結果ちゃんと通っているかを目視確認して

開発環境へ資材コピーして

単体試験もデグレ確認を実施して。。。。。

いけてない！！！いけてないよ！！！！！

もう同じこと毎回手でやってるなんてシステム開発する人間がやることじゃないよ！

というわけで

ソースファイルの最新化

↓

コンパイル、開発環境へのデプロイ、テスト（単体試験レベルまでかな。結合以降は人が目で見るべきだと思ってます）

↓

結果を集計

↓

メールで結果を通知

の一連の流れをジョブとして自動でやってくれるのが自動化ツールであり

Jenkinse先生です！

【jenkinse】

https://jenkins.io/

じゃあ継続的インテグレーションってなんだというところですが

インテグレーションを継続的に行うものなのです（分かりやすい）

で、インテグレーションって？これらです

・ソースコードを一箇所に集める

・必要に応じてコンパイルを実施

・DBの構築とデータロードを実行

・テストコードを基に試験を自動的に実施

というプロセスをインテグレーションといいます（違ってたらゴメンなさい）

これらのプロセスを継続的に行うことを継続的インテグレーションといいます（きっとアジャイルとか）

この継続的インテグレーションを実施することでどんなメリットがあるかというと

ソースに変更がかかったタイミングで、ソースコードがちゃんとコンパイルできるよねっていう担保を取ることができたり（これはGitとJenkinseの設定が必要）

変更していない箇所に影響がないことをテストコードを使って担保を取ることができます

そして何より、チームで開発する複雑なプロジェクトにおいて

スピード感のある開発ができるようになります

なぜなら、複数メンバーで作ったソースを毎回手で集めてビルドしてテストという行為は凄く時間がかかる作業になります（実際凄く大変）

それを毎回自動的に実施してくれるとなると相当な工数の削減につながります

なので、自動化ツールを取り入れてみんなで早く家に帰りましょう！

そんな感じで、自動化と継続的インテグレーションについてさらっと語ってみました

次はチケット管理について書いてみます

でわでわ

この業界に入ってから色々知って行ったのですが

今のご時世

「バージョン管理！」「自動化！」「デプロイ！」「チケット管理！」

な時代だということですね（なんのこっちゃね）

私、大学の時にjavaを勉強していたのですが

課題フォルダにあるファイルを更新した時に

間違えて上書きしてしまったりとか削除してしまったりとかで

友達の課題ファイルをコピーさせてもらうことが多々ありました（ん？）

バックアップが取れていないとファイルの戻しが大変だったり

このファイルはいつ時点のファイルなのか判断するのが難しいですよね

そこで出てくるのが「バージョン管理」です

メジャーなところでいうと以下の２つがありますね

【Subversion】（集中型と呼ばれます）

http://subversion.apache.org/packages.html

【Git】（分散型と呼ばれます）

https://git-scm.com/

他にもDBマイグレーションツールであるFlywayやdbdeploy等ありますが

興味があったら調べてみてください（また後日書いてみよう）

では、バージョン管理とは何かというと

文字通りファイルのバージョンを管理することを言います

変更対象のファイルに対して

「いつ」「誰が」「どんな変更をした」

という情報を履歴として持てる便利なファイル管理のシステムです

前回変更した内容との差分もしっかり残っていて

差分比較ツールでちゃんと差分も見える化できる素晴らしいシステムなわけです

【例：WinMerge】

http://www.geocities.co.jp/SiliconValley-SanJose/8165/winmerge.html

SVNとGitの違いについてはまた別で書こうと思ってますが（Gitのブランチの概念が複雑なため）

とにかく、今のシステム開発ではファイルをバージョン管理することでしっかり変更内容を記録し

資材の担保や問題が起きた時の原因究明に役立てていくことが主流となっています

とりあえずバージョン管理についてはざっくりこの辺で

次は自動化の話を書こうと思います

（このブログはどういう方向に進んでいくのだろう）

ちなみにこの本がおすすめです。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus) 2,894円 Amazon

でわでわ