起動済みのEC2インスタンスでSystems Managerのセッションマネージャーを使えるようにする
dev.classmethod.jp dev.classmethod.jp
こちらの記事を読んで、今すでに動かしているEC2インスタンスでセッションマネージャーを使えるようにしました。
参考にしたのは↓のドキュメントです。
1. IAMロールの付与
対象のEC2インスタンスにはIAMロールがなかったので、IAMロールを作成して付与しました。
CloudFormationで管理しているので、IAM::InstanceProfileとIAM::Roleを作成し、EC2のIamInstanceProfileに作成したInstanceProfileを設定しました。
IAMロールにはAmazonEC2RoleforSSM（マネージドポリシー）のみを設定しました。
2. SSM Agentのアップデート
EC2インスタンスのOSはAmazon Linux2なので、すでにSSM Agentは入っていたのですが、バージョンが2.2.9とかだったのでこれだとセッションマネージャーが使えません。 なので
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
を実行し、SSM Agentインストーラーをダウンロードして実行しました。
3. コンソールから実行
上記の手順を踏むと、AWSコンソールのセッションマネージャーから『セッションを実行する』で対象のインスタンスを選択し実行できるようになりました。
Coursera Software Architecture Week2 Learning Objectives-1
Abstract Data Type and Object-Oriented
どのプログラミング言語を選ぶかは、システムの実装に大きな影響を及ぼす。システムに適したプログラミング言語を選ぶことが大切である。
オブジェクト指向の言語を選ぶことは、オブジェクト指向の原則、設計、デザイン原則を選ぶことである。
オブジェクト指向の設計原則には、抽象化（実装の詳細には立ち入らない）、カプセル化（機能とデータをオブジェクトにつめこむ）、分解（問題を小さなパーツに分ける）、一般化（問題の共通部分をくくりだす）。
また、オブジェクト指向のデザインパターンのカテゴリーには、作成、構造、振る舞いがある。作成カテゴリーは、オブジェクトをどのように作成するか。構造カテゴリーは、クラスとサブクラスの間の相互作用。振る舞いカテゴリーは、クラスがどのように単独でもしくはグループで動作するかを説明する。
オブジェクト指向のアーキテクチャスタイルは、データに注目する。
このようなやり方が合うシステムもあるが、例えば科学計算のような問題では、パフォーマンスの点でオブジェクト指向のアプローチが適切でない場合もある。問題に適したやり方を選ぶことが大切である。
--- 今日はここまで ---
Coursera Software Architecture Week1 UML Architecture Diagram - 3
UML Deployment Diagram
ソフトウェアを実際に実行するには、本体のコードだけでなくライブラリ、実行ファイル、インストーラー、設定ファイルなど様々なものが必要になる。
そのデプロイの詳細を図に表すものがUML Deployment Diagramである。
UML Deployment Diagramには、ハードウェアやOSも含まれる。
UML Deployment Diagramには二種類ある。一つはSpecification Level Diagram、もうひとつはInstance Level Diagram。
Specification Level Diagramは、マシン名のようなデプロイの詳細には踏み込まない。全体を見るためのもの。
Instance Level Diagramは、より詳細を記述するもの。これは特にdevelopment, staging, productionの違いを明確にするために使われることが多い。
Deployment Diagramでは、システムの動作に特に必要なものだけを書く。あまり詳細に書きすぎると、見る人が混乱する。
アーティファクト、ライブラリ、マシン、デバイス、主要なコンポーネントは必要だが、ソフトウェアのクラスなど、詳細すぎるものは省く。
UML Activity Diagram
UML Activity Diagramは、システムの中での一つのアクティビティからもうひとつのアクティビティまでのフローを表すもの。
システムの動的なふるまいをとらえるためにある。
アクティビティとは、システムによるアクションのこと。
フローには、始点アクティビティ、終点アクティビティ、中間アクティビティ、コンディションノードがある。
複数のフローが同時に進行するときは、並行フローを使う。
Activity Diagramによって、高い視点からシステムのフローを確認することができる。
-- 今日はここまで --
Coursera Software Architecture Week1 UML Architecture Diagram - 2
# Kruchten's 4 + 1 view model
アーキテクチャの設計のときには、いくつかの観点から見ることが必要。
その『いくつかの観点』が、Kruchten's 4 + 1 view modelとしてまとめられている。
## Logical View
ソフトウェアにどのような機能があるのか？ という観点。
UML Diagramによって表現することができる。
これによって、クラスやデータがどのようにお互い作用するのかわかりやすくなる。
## Process View
ソフトウェアがどのように実行されるのか、どのように他のシステムと作用するのか、という観点。
機能の実行順序やパフォーマンス、スケーラビリティなど。
UML Sequence Diagram、UML Activity Diagramが理解の助けになる。
# Development View
どの言語を使用するのか、どのような実装とするのか、という観点。
スケジュールなどのようなコーディング以外の開発についての部分も含まれる。
# Physical View
ソフトウェアが実行される物理的な環境からの観点。
UML Deployment Diagramで一部を表すことができる。
# Scenario
ユーザーに対して何が必要か？ がわかっていないと、アーキテクチャを決めることはできない。
なので、ユースケースやタスクのようなシナリオが必要になる。
# UML Component Diagram
コンポーネントとは：システムの中で、独立していて、カプセル化されたもの
コンポーネントは他のコンポーネントのためにインターフェースを提供していて、それを使ってコンポーネント同士が結びつく。
それを図で表したのがUML Component Diagram。
ここではコンポーネントの内部の実装ではなく、コンポーネント同士がどのように作用するかが関心になっている。
UML Component Diagramによって、システムの狙いやデザインを確認することができる。
# UML Package Diagram
パッケージとは：関連する複数の要素をまとめたもの。データ、クラス、ユーザータスクをもち、名前空間が割り当てられる。
Package Diagramはこのパッケージがどのような要素をもっているか、パッケージ同士どのようにつながっているかを示したもの。
-- 今日はここまで --
Coursera Software Architecture Week1 UML Architecture Diagram - 1
概要
CourseraのSoftware Architectureコースをはじめました。 やったことを簡単に記録していく記事です。 （ほんとはこれシリーズになってて、この前のコースのObject-Oriented DesignとDesign Patternもやったんだけどちゃんと記録に残してない）
Week1
Overview
Week1はだいたいそうなのだけれども、このコース全体の概観、つまり - Software Architectureとは何か？ - どういう手順で学んでいくか？ - 現役の開発者へのインタビュー が最初にある。
Software Architectureはシステム全体が『どんな要素があるか』『どんな機能があるか』『それらがお互いどう関係しているか』を表すもの。
Software Architectureを作るためには、『何のためのシステムか』『誰が使うのか』『何が大切な要素か』『どんな環境で動くのか』を考えに入れる必要がある。
正しいSoftware Architectureがあれば、開発チームは認識を共通化し、システムの将来像や開発プロセスについてよりよい考え方ができるし、システム自体の質も向上する。
また、プロジェクトマネージャー、クライアント、エンドユーザーにもそれぞれ利点がある。
--- 今日はここまで ---
puppeteer on DockerでE2Eテストを書いた
要約
puppeteerでE2Eテストを書いたのでその記録です
動機
ショッピング機能のあるサイトを作成しているのですが、UIのちょっとした変更のたびに手動で購入プロセスを踏んでテストするのがとても面倒で自動化したいなと思ったのがきっかけです
選定
もともとつくりかけのnightwatchを使ったコード片が存在していましたが、seleniumがうまく起動しない問題などが存在していました。 またポータブルな形でやりたいな〜と思っていたので、puppeteerをDocker上で動かすことができるということを聞き、いっちょ使ってみっか〜と始めてみました。
コード
こちら です
コード詳細
Dockerfile
puppeteerのドキュメントにあったDockerfileに、以下の変更を加えました - mocha, chai, dotenvの追加->既存のテストはmocha, chaiを使っているので、同じ操作感でE2Eもテストしたかったため。dotenvはパスワード等の設定のため
テストコード
testディレクトリの中のexample.jsがメインコードです。test/PageObjectsディレクトリ内に各ページ用のクラスを配置しておき、それらを呼び出してテストを行います。このようにしたのは、ページの変更は頻繁に行われるため、ページ実装に対応する層としてページ用のクラスを置き、メインコードではテストシナリオを担当させるためです。
test/example.js
今回のテスト対象のページはベーシック認証がかかっていたため、最初のうちはpage.setExtraHTTPHeadersを使用してAuthorizationヘッダーを付与していました。しかしこれを使うと、puppeteerから送るすべてのHTTPリクエストに対してこのヘッダーを付与してしまうため、対象ドメインを含むURLに対してのリクエスト時にだけAuthorizationヘッダーを送るようにしているのが19〜24行目です。
テスト部分は通常のmochaと同じようにdescribe, itを使って書き、非同期処理になるため中にdoneを入れています。
test/PageObjects/Item.js
こちらでは実際にページを表示し、表示された内容を返したりフォームに書き込みをしたりボタンをクリックしたりさせています。 async, awaitが使えるので楽に書くことができます。
Yaml比較ツールを作った
サマリー
Yaml比較ツールを作りました
仕組み
Yamlをまずオブジェクト化し、そのオブジェクトをキーでソートします（子の要素についてもソートします） その後オブジェクトを再度Yamlにし、比較します
構成
Vue.js + 一部JQuery(差分表示のdiff2htmlのため) Yamlのソートや差分の表示など、すべての処理をブラウザ上で行います。バックエンドでは何も処理を行っていません。 ホスティングはおなじみNetlify
これをつくったきっかけ
API Gatewayを使っているのですが、コンソールからエクスポートできるAPI GatewayのSwagger定義ファイルが、 エクスポートするタイミングによってキーや値の位置がずれているのです。 そのため、API Gateway更新後にSwaggerファイルで差分を確認しようとしても、 単純にdiffを取るだけだと関係ない箇所で大量に差分が出てきてしまい、面倒でした。
このツールでは、キーをソートしてから差分を見るため、内容が同じならば差分は出てこないようになっています。
