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を取るだけだと関係ない箇所で大量に差分が出てきてしまい、面倒でした。
このツールでは、キーをソートしてから差分を見るため、内容が同じならば差分は出てこないようになっています。
Macでgitのcredential.helper=osxkeychainにアアアアアッてなって削除した話
きっかけ
メインとサブ二つGithubのアカウントを持ってて、 あるリポジトリでサブのアカウントでpushしようとしてもうまくいかない（Permission denied hogehoge to main-account になる。）
確認
originはhttpsで設定してある。 git config --local user.name等の設定はしてあり、 git logで見てみてもコミットログはきちんとサブアカウントのほうで行っている。
わからん……と
git config --list
でみてみると credential.helper=osxkeychainという記述がある。 いつ設定したかもう忘れているけどいつの間にか……これだ……
removeできない
git config --global credential.helper git config --global --unset credential.helper vim ~/.gitconfig
等を試してみても居座り続けるcredential.helper=osxkeychain……万策は尽きたかに思われた……
解決策
その時
これをみつけた。 この通り
git config --show-origin --get credential.helper
とすると file:/Applications/Xcode.app/Contents/Developer/usr/share/git-core/gitconfig osxkeychain と返ってきたので、 file:/Applications/Xcode.app/Contents/Developer/usr/share/git-core/gitconfigを編集してosxkeychainの設定部分を削除したらうまくいきましたとさ、めでたしめでたし
API Gateway+LambdaをCloudFormationでサクリとつくる
API Gateway + Lambda + CloudFormation
サーバーレス（サーバレス？ どっち？）でやるときにおなじみのこのサービス二つの組み合わせなのですが、 API Gateway周りの設定がけっこう面倒なんですよね…… なので一回テンプレートとしてCloudFormationでつくっておくと拡張性もあって便利便利という話です。
今回は単純に、/helloにGETするとHello WorldするAPIを作ります。
構成
CloudFormationで定義するリソース一覧です。 中にはコンソール上でポチポチやっているとAWSが裏で自動でつくってくれるものもあるので、リストにすると結構長くなります。
API Gateway
- Rest API（API Gatewayの基本構成単位。コンソール上でAPI Gatewayのトップページにいってまず作るやつ）
- Stage（ステージ）
- Model（リクエストなどの構造を表す）
- Resource（リソース。パス（/hello等）をここで定義）
- Method（リソースごとのメソッドの定義）
- UsagePlan（使用量やクオータなどの定義）
- Deployment（デプロイ）
Lambda
IAM
- Role（Lambda Functionに割り当てるIAM Role）
CloudFormationテンプレート
これをCloudFormationの新規スタックとして作成し、 できたAPI GatewayのリソースURL（https://foobar.execute-api.ap-northeast-1.amazonaws.com/dev/hello）にアクセスすると「Hello World」と表示されるはずです。
最小構成なので、適宜必要なリソースを加えることで望みの構成ができるかと思います。 （APIキーを追加したい場合はAPIKeyとUsagePlanKeyを加えるなど）
