AtCoder用のツール利用方法
online-judge-tools、atcoder-cli のインストール
$ pip3 install online-judge-tools $ yarn global add atcoder-cli
online-judge-toolsとの連携確認
$ acc check-oj > online-judge-tools is available. found at:
online-judge-tools、atcoder-cli へのログイン
$ acc login > Username: *** > Login: *** $ oj login https://atcoder.jp/ > Username: *** > Login: ***
入出力サンプルのインストール
URLが「https://atcoder.jp/contests/practice/」の場合
acc new practice or acc add practive
入出力サンプルの実行（javascriptの場合）
$ pwd /Users/xxxx/atcoder/practice/a $ touch code.js # ファイルを編集する $ oj t -c "node ./code.js" -d ./tests/ [INFO] online-judge-tools 11.5.1 (+ online-judge-api-client 10.10.1) [INFO] 2 cases found [INFO] sample-1 [INFO] time: 0.404934 sec [SUCCESS] AC [INFO] sample-2 [INFO] time: 0.236824 sec [SUCCESS] AC [INFO] slowest: 0.404934 sec (for sample-1) [SUCCESS] test success: 2 cases
参考
最近買った本（2020年7月〜2020年9月）
ひとつひとつを腰を据えてもうすこししっかりと学びたい気もする。 理解した部分とそうでない部分、読み直すときにわかるようにもっと詳細にメモしておこう。
2020年9月
9/13 下記を購入
状況: 未読
9/5 下記を購入
状況: 全体をさらっと読んだ
2020年8月
8/14 下記を購入
状況: 全体をさらっと読んだ
- 作者:池田 聡
- 発売日: 2018/01/17
- メディア: 単行本（ソフトカバー）
8/14 下記を購入
状況: 導入部分のみ読む（Chapter 1〜3あたり）
ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本
- 作者:成瀬 允宣
- 発売日: 2020/02/13
- メディア: 単行本（ソフトカバー）
2020年7月
7/13 下記を購入
- 作者:アンドリュー・S・タネンバウム,デイビッド・S・ウエザロール
- 発売日: 2017/10/17
- メディア: Kindle版
7/13 下記を購入
状況: 導入部分を読んで難しそうだったので、入門書に切り替え
- 作者:Eric Evans
- 発売日: 2013/11/20
- メディア: Kindle版
7/4 下記を購入
状況: 1,3,4,5章を読んだり、写経したり。
目次: O'Reilly Japan - 初めてのGraphQL
初めてのGraphQL ―Webサービスを作って学ぶ新世代API
- 作者:Eve Porcello,Alex Banks
- 発売日: 2019/11/13
- メディア: 単行本（ソフトカバー）
7/4 下記を購入
状況: 1〜4章,5章(少し),11章(少し)を読んだ。まとめ中。
目次: O'Reilly Japan - プログラミングTypeScriptJavaScriptでつまづいたところは、昔購入した下記で復習（ちょっと内容古い）
プログラミングTypeScript ―スケールするJavaScriptアプリケーション開発
- 作者:Boris Cherny
- 発売日: 2020/03/16
- メディア: 単行本（ソフトカバー）
TypeScriptプロジェクトの作成
package.json生成
$ yarn init
package.jsonのdevDependenciesにtypescript追加
$ yarn add -D typescript
tsconfig.json生成
$ yarn tsc --init
ファイル生成
$ mkdir src
$ cd src
$ touch index.ts
$ echo 'console.log("Hello TypeScript");' > index.ts
コンパイル実行
$ yarn tsc > index.jsが生成
ファイル実行
$ node index.js > Hello TypeScript // 下記も実行できるが、TypeScript構文がある場合はエラーになる $ node index.ts > Hello TypeScript
ディレクトリの中身の表示
$ brew install tree $ tree . ├── node_modules │ └── typescript │ ├── AUTHORS.md │ ├── CODE_OF_CONDUCT.md │ ├── CopyrightNotice.txt │ ├── LICENSE.txt │ ├── README.md │ ├── ThirdPartyNoticeText.txt │ ├── bin │ │ ├── tsc │ │ └── tsserver │ ├── lib(省略) │ └── package.json ├── package.json ├── src │ └── index.ts ├── tsconfig.json └── yarn.lock
コンパイル実行＆ファイル実行は、下記のコマンドでも可能（コンパイル後のファイルは生成されない）
yarn add -D ts-node yarn ts-node ./src/index.ts
参考：2章 - TypeScript：全体像
プログラミングTypeScript ―スケールするJavaScriptアプリケーション開発
- 作者:Boris Cherny
- 発売日: 2020/03/16
- メディア: 単行本（ソフトカバー）
「システム設計のセオリー」を読んだ
2019年10月頃にタイトルの書籍を読んだ。 編集方法を変えたので再投稿。
読書目的
要件定義から設計・開発・保守まで一通り経験はしたけれど、進め方や成果物が現場によって様々で何が正解かわからないのでなんとかしたい。要件定義〜設計に関して全体像をしっかりと把握したい。
書籍の内容
目次
- 情報システムと設計
- 論理設計のはじめに
- データ設計のセオリー
- プロセス設計のセオリー
- 機能設計のセオリー
- ユーザビリティ設計のセオリー
- 設計のToBeを実装のAsIsへつなぐために
概要
情報システムの使命は「適切な時に適切な人が適切な情報をインプットすることにより、必要な時に必要な人へ必要な情報をアウトプットすること」であるという考えを念頭に置いて、設計の方法が記載されている。
論理設計は、要件定義（論理）→基本設計（論理）を行う工程、物理設計は、基本設計（物理）→詳細設計（物理）を行う工程であるとし、必要なインプット、アウトプット、具体的な手順について説明がされている。
以下に各設計でやること、作成する成果物（数が多いため主要なもののみ）について記載する。
データ設計
- 概念データモデル→論理データモデル→物理データモデル→コード定義
- 外部インタフェースの要件の明確化→外部インタフェースの概要→外部インタフェースの詳細→データ移行の設計
- データベースの実装
プロセス設計
- ToBe業務フローの概要→ToBe業務フローの詳細→AsIs業務フローの分析→業務プロセスの概要
- 画面のラフイメージ→業務プロセスの詳細
機能設計
- 画面・帳票の概要→バッチ処理の概要→論理CRUDマトリクス分析→サブシステム分割→物理CRUDマトリクス→サブシステム定義の詳細
- 機能の詳細→画面・帳票の詳細→バッチ処理の詳細→共通機能の詳細→実装準備
ユーザビリティ設計
読んだ感想
優れた設計を行うためには次の３つの成果物がとくに重要であると思った。 ビジネスの静的な側面と動的な側面、そしてその交差点をまとめたものだからである。
概念・論理データモデル
エンティティ同士の関連性をER図で表したもの。
業務フロー図
業務の流れをDFD等で表したもの。
CRUD図（業務プロセス×エンティティ）
業務プロセスとエンティティのCRUD（登録・参照・更新・削除）の対応関係をマトリクスで表したもの。 業務フロー図や概念データモデルがインプットになる。
今まで関わった仕事では、こういった成果物が既に完成されていることが殆どだったが、その重要性やポイントについて理解していなかったので、少しはましになったのかなと思う。
読んでいる途中で成果物同士の関連を忘れてしまうことがあったので、インプット、アウトプットの関係を記載した一覧（もしくは一枚絵）が欲しいなと思った。
なお、上流工程に関する書籍をもう2、3冊読む予定。
「なぜ、システム開発は必ずモメるのか？」を読んだ
2019年11月頃に読んだ。
当時残したメモと記憶を頼りに書いてみる。
目的
システム開発、とくに請負開発を行うにあたり、お客様（発注側）とどのように付き合っていけば良いのか知りたい。 なんとなく次のことが大事かなと考えている。
- 予算と納期、関係者の合意
- 各工程の進め方、成果物、完了条件
- 想定外が起きた場合の対処方法
- 要件の実現可能性の検討
- 要件の変更時の取り決め
書籍の内容
目次は次の通り。
- 要件定義
- プロジェクト計画と管理
- 設計
- プログラミング
- テスト
- 契約と仕事の完成
内容は物語形式で、IT紛争専門の弁護士である主人公を中心に話が進む。 システム開発に関わる様々なトラブルの場面で、過去にどのような裁判の判決が降ったか、トラブルを起こさないためには何が大事なのかが語られている。
読んだ感想
個別具体的には色々と注意点があるけれど「やるべきことをきちっとやろう。契約書に書かれたことが全てではないよ」ということに尽きると思った
以下、メモの中から重要そうなものをピックアップ。
要件定義
- パッケージ不適合に備えた代替案を用意する、フィットアンドギャップを実施する。
- メンバーのスキル不足があるときの評価とスキルアップ計画をユーザと共有する。
- 性能要件を条件付きで良いので早めに決める。要件を勝手に書き換えるベンダーは要注意。
- 最低限、要件と受入テストの項目を紐付ける。要件漏れを防げる。
- 要件定義が泥沼化した場合、味方になりそうな人を探し、一緒に解決する道を見つける。
- システム化の目的が抽象的な場合、方針を基に要件を考える。業務フロー図からシステム化対象範囲を決める方法、システム化の方針からシステム化対象を想像する方法の両方を使うとよい。
プロジェクト計画と管理
- ユーザ側のリスク抽出や解決はユーザ側の責任だが、そのガイドや解決策の提案はベンダー側の責任である。
- ユーザの威圧的な態度が原因であっても、メンバーのメンタル管理はベンダ側の責任である。
- その人しかできない作業に集中させる。思考の継続性を維持できるようにする。
- 引き継いだシステムをそのまま作るか、作り直すかは、定量的に比較した上で行う。フィジビリティ。
設計
- 非機能要件などの要件に不備がある場合は是正を促す必要がある。
- 設計書を著作物と認められるには創作的である必要がある。
テスト
- 受入テストのテストケースとテストデータのレビューを要件定義の直後や受入テスト前にユーザにしてもらう。抜け漏れ防止のため。
- システムの要件が固まった時点で、プロジェクト完了基準、つまり検修の条件を決めておくことが大事。
- 受入テストのテストケースが完了
- 保守用ドキュメントがある
- 保守開発とテスト用の環境がある
- 本番稼働後の体制が整っている
- 一般的にはシステムテストまではベンダ側、受入テストはユーザ側の責任。お互いの協力が必要。
- 検収書だけでは債務履行の理由にならない。
- テスト結果報告書が未提出で、それが正しく行われていることを証明できないなら不履行となる可能性がある。
- 検収後にバグが出て責任を求められたら対応計画や代替案提出などが必要。
契約と仕事の完成
- プロジェクト管理や変更管理に必要な費用は、プロジェクト全体の2〜3割程度。
- 下請けは元請けから開発規模の提示があっても自らの経験や実績に基づき独自の見積をすること。元請けはそれを妨げてはいけない。
- 契約前や受注前の作業はしない。管理作業についても契約書に記載すること。契約書に請負か準委任か記載すること。
記事作成にかかった時間：５０分
VS Codeでラムダのコードを書く（デプロイ編）
バケットを作る
「aws s3 mb s3://【バケット名】」コマンドより、バケットを作成する。
$ aws s3 mb s3://【バケット名】 make_bucket: 【バケット名】
バケット名は世界で一意にする必要があり、重複している場合は下記エラーが表示される。
$ aws s3 mb s3://【バケット名】 make_bucket failed: s3://【バケット名】 An error occurred (InvalidBucketName) when calling the CreateBucket operation: The specified bucket is not valid.
SAMプロジェクトのAWSへのデプロイ
- コマンドパレットより、「AWS:Deploy SAM Application」を選択して実行
- 「Which SAM template would you like to deploy to AWS?」:sam-project/template.yml
- 「Which AWS region would you like to deploy to?」:Asia Pasific (Tokyo)
- 「Enter the AWS S3 bucket to which your code should be deployed」:【バケット名】
- 「Enter the name to use for the deployed stack」:sam-project
Starting SAM Application deployment... Building SAM Application... Packaging SAM Application to S3 Bucket: 【バケット名】 with profile: default Deploying SAM Application to CloudFormation Stack: sam-project with profile: default Successfully deployed SAM Application to CloudFormation Stack: sam-project with profile: default
デプロイされたSAMプロジェクトの実行
- マネージメントコンソールのAPI Gatewayページへ遷移
- ステージを選んで、作成されたメソッドの「URL呼び出し」のURLをクリック 例）https://xxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod/hello
- {"message": "hello world"}が表示されることを確認
その他
SAMコマンドには今回実行したもの以外にも「sam local start-api」等があるが、どういう時に使うのかはわかっていないのでいつか理解したい。
AWS SAMのコマンドをまとめてみた - Qiita
