クラウド的なアレ

仕事でRustを使うにあたり、crates.ioには公開しない方法で自作のライブラリを使用しようとしている。 少し整理してみると次のような環境。 * 自社内のGitリポジトリを使用 * コンパイル対象もその依存先のライブラリもそれぞれ自社Gitリポジトリにてホストされている * ビルド環境はJenkins CI上で稼働させているコンテナ できていなかったことは、Jenkins内でコンテナを作ろうとしていて、そのためにコンパイル対象のRustのプロジェクトの他に、依存しているプライベートのライブラリを取得するというところ。 次のようなエラーが出ている状況だった。 Compiling xxxxx_lib v0. 1.0 (/home/ubuntu/workspace/xxxx_tool/xxxx_loader) Checking cfg- if v0. 1.10 Checking bitreader v0. 3.2 Checking byteorder v1. 3.4 Checking num_enum v0. 5.0 error[E0463]: can 't find crate for `log` --> src/main.rs: 3 : 1 | 3 | extern crate log; | ^^^^^^^^^^^^^^^^^ can 't find crate error: aborting due to previous error For more information about this error, try `rustc --explain E0463`. そのときのmain.rsはこんな感じ。 #![cfg_attr(feature = "strict" , deny(warnings))] extern crate log; Cargo.tomlでの対象のライブラリへの依存指定はこんな感じ。 xxxxx_lib = { git = "https://xxxxx/xxxxx/xxxx.git" } 解決方法としては、JenkinsのCredentials managerから鍵を取ってきてコンパイル対象のプロジェクト

  Route 53 進化を理解するために、まずは古い方から見ていく。2016年の資料。 * パブリックホストゾーン（＝インターネット公開）とプライベートホストゾーン（＝VPC内のやつ）それぞれで利用可能。 * トラフィックルーティングと称して、従来型のDNSでの静的なルーティング（e.g. www.example.comにきたら1.1.1.1を応答）だけでなく、送信元が日本の場合は東京リージョンへ、そうでない場合はレイテンシーが最も小さいリージョンへ転送、のようなこともできる * 他にもヘルスチェックの結果に応じてルーティングを変えたり、エンドポイントごとに重み付けしてルーティングを変えたりできる * ヘルスチェックが誤って設定されている場合にはAWSに申し出て停止させることもできる（＝他人が自分のリソース環境にヘルスチェックをかけてきてるときの対処が可能） * 従来の無味乾燥なレコード設定の他、トラフィックフローを使用することでエディターで編集できる（画面キャプチャーを見る限り、Node-REDみたいな見た目） * 料金はホストゾーンごとに最初の25ホストゾーンは$0.50/月、トラフィックフローは$50/月、標準的なDNSクエリは10億クエリで$0.40 今まで、ドメインを購入したところのDNSを使うことが多くて、なんでDNSに登録するのに金かかるねん、って思ったけれど、標準的な内容だと小さな規模のうちは数ドル/月程度だから別に騒ぐような話じゃなかった。それよりも、その辺のDNSの機能に加えた付加価値がいくつもあって、そこで利便性を提供・儲けの機会を創出してるのがすごいなと思った。 続いて2019年の資料。 DNSサーバーとはそもそも何をするものか、の説明があって優しい。機能は次の4つ、の前に前提知識として、次の2つ。 * 反復問い合わせ：自らがネームサーバーを辿る際に行う問い合わせ * 再起的問い合わせ：問い合わせ先に反復問い合わせを依頼する問い合わせ 上記を踏まえて次の4機能。 * ネームサーバー / Name Server：保有している情報の範囲で名前問い合わせに答える * フルサービスリゾルバー / Full Service Resolver：反復問い合わせする、フルサービスリゾルバーが反復問い合わせを受け取った場合は反復問い合わせせずに保有している情

『ドメイン駆動設計入門　ボトムアップでわかる！ドメイン駆動設計の基本』という書籍も読んだ。 いろんな本を読むことで多角的にドメイン駆動設計を徐々に理解しようとしているのが現状。 この書籍からは、次の学びを得た。 値オブジェクトにすべきかどうかの判断基準として、筆者は「そこにルールが存在しているか」という点と「それ単体で取り扱いたいたいか」という点を重要視しています。 出典：ドメイン駆動設計入門　ボトムアップでわかる！ドメイン駆動設計の基本 Loc.895 それを取り巻く環境によってモデルに対する捉え方は変わります。値オブジェクトにも、エンティティにもなり得る概念があることを認識し、ソフトウェアにとって最適な表現方法がいずれになるのかは意識しておくと良いでしょう。 出典：ドメイン駆動設計入門　ボトムアップでわかる！ドメイン駆動設計の基本 Loc.1315 正直言って、まだエンティティと値オブジェクトの違いについてしっくりきていない。 最近やっていたゲームから比喩を得て理解しようとしたけれど、やっぱりぴったりははまらない。 そんで、じゃあまずは手を動かしてみるかと思って、例えば何かの在庫と購入にあたっての在庫引き当てができるみたいなものを想定して作ってみるか、とも思ったけれど、適当に作るのも意外と難しくて。 まずユースケースがわからないからApplication層の作りが曖昧になってしまって、そうなるとドメイン知識として何を持たせるとか、それはドメインのエンティティが持つべきじゃないからドメインサービスにしようとか、そういう発想につながらない。 仮の題材でやってくにしてもそれなりにしっかり練り込んでないとしんどいんだなというのは最低限理解した。 わからないなりに、IDDD（実践ドメイン駆動設計）のサンプルを眺めてそれぞれのつながりであるとか、ディレクトリ構成とかをまずは理解している。 まあ、こうやってつくりがわかったとして、それで実装できるようになっても、多くの人が揶揄する「軽量DDD」にすぎないのかもしれないと薄々わかっているのだけど、だとしてもわかるところから、入れるところから入っていかないと、いつまでも建物の外観を眺めてるだけで終わってしまうので。 ちなみに、細かいけど、GitHubのRepoの説明の中に貼ってあるこのリンクはDead Linkになってた。 &qu

  ドメイン駆動設計を開発に取り入れようとしたら、やっぱりこの原著は避けられないのだと、そう感覚が告げるので、読んだ。 正確には読もうとしたのはこれが3度目で、過去2回は序盤を読み下しているうちに関心がなくなってしまった。 今回は幸い、松岡さんの入門書（『ドメイン駆動設計 モデリング実装ガイド』）を読んだ後なので、多少は耐性がある状態から始められているのが幸い。 で、どうにか読み終えたけれど、特に後半2/3はやや読み飛ばし気味だったし、何度も寝落ちもした。 なので、本当に部分的なエッセンスしか得られなかったと思うけれど、ひとまず手元ですぐに使えそうとか、発見だと思えた部分はメモしている。 ドメインモデルとは特定の図ではなく、図が伝えようとしている考え方である。これはドメインエキスパートの頭の中にある単なる知識ではなく、その知識が厳密に構成され、選び抜かれて抽象化されたものなのだ。 出典：エリック・エヴァンスのドメイン駆動設計 p.2 常に覚えておいて欲しいのは、モデルは図ではないということである。図の目的は、モデルについてコミュニケーションし、説明するのを助けることにある。 出典：エリック・エヴァンスのドメイン駆動設計 p.36 これは読んでいてドメイン駆動設計を少し好きになる瞬間だった。ユースケースモデルと同じだと思う。 ユースケースモデル、と聞いて大抵の人が思い浮かべるのは棒人間と長い丸の中にあるユースケース、もしかしたらそのユースケースのコンテキストを示す四角い囲みもあるかもしれない。 ただ、どの書籍か忘れたけれど、ある書籍で「大事なのはこの図ではありません。ですので、ここで書いているユースケース名（＝長い丸）の中身を文章にしましょう。」と語れていたのを思い出す。実践が必ずしもできていないけれど、ユースケースモデルを書くときは必ずこれを思い出してる。 ドメインモデルというのも同じで、そういう意味で、データモデルと仕上がってきた図は近しいものになることもあるかもしれないけれど、明確にそれが示したいものが違うのだということがこの二文で表現されていると思う。 ユーザインタフェース（またはプレゼンテーション層）： ユーザに情報を表示して、ユーザのコマンドを解釈する責務を負う。外部アクタは人間のユーザではなく、別のコンピュータシステムのこともある。 アプリケーション層：

久しぶりに開発中心の案件を間近に控えているので、設計を適切に行えるようにDDDの知識を蓄えておこうと思う。 実際のところ、やろうと思いながら先延ばしにしていたのだけど、後押ししたのが、近頃同僚たちとした、RESTful APIにおける「リソース」とはなにか、という問題。 基本的にRESTful APIではエンドポイントはリソースにし、GETやPOST、PUT、DELETEなどによって操作することを実現できるように作る。 と言った時にそのリソースとは一体何であって何でないのか。 * リソース自体に明確な指針はなく、アプリの仕様や利便性から自由にできる、決まっているのはそれが名詞であるということだけ * どのような粒度でエンドポイントのリソースを定義するかは設計の腕の見せ所 * 将来の成長をどこまで織り込むかによってエンドポイントの名称の付け方などにも変化は生じる といった話が上がった。 それこそ、次のようなエンドポイントはありなのかなしなのか、も意見が分かれた。 /employees/$id/department /employees/$id/rank 基本的には、なしではない、が、できることならパラメーターによって応答フィールドの指定のような対応で済ませたい、がその場での結論だった。 この辺り、RFCなどにも何かしら良いまとめがあるわけではなさそうだったので、RESTful APIの世界よりももう少し広く、モデリングの対象となっている現実とのつながりの部分にフォーカスしないといけないのだと思った。 というわけで前置きが長くなったけれど、DDDを勉強していくことにする。 序盤で外してはいけない定義について書いている。 それでは、人々はなぜ、ソフトウェアを開発するのでしょうか? それは、ソフトウェアによって、ある領域に存在する特定の問題を解決するためと言えるでしょう。この「ソフトウェアで問題解決しようとする対象領域」を「ドメイン」と呼びます。 出典：ドメイン駆動設計 モデリング実装ガイド pp.10-11 つまり、DDDにおいてはドメインは問題解決しようとする対象領域、と。 問題解決のアプローチとしては、ドメインを定義して、モデルを作り、そのモデルの内容をソフトウェアに反映し、不足があればドメインを改善し、以下続く、という流れの様子。 実装との絡みで理解しやすかったのは

Discordで友人らと話している中で出てきて自分なりに整理できていると思ったので書く。 IPO（Input, Process, Output）のどれが足りないのかを把握するためのマインドとの紐付けの話。 * 何をしたいかわからない：インプット不足、誰かに話を聞いたり本を読んだりしてといった刺激のスイッチを探す * やりたいことがあるのにできてない：時間が足りないかあるいはやり方がわからないならヘルプを依頼する * 自分が何しているかわからない：書き出すなどの整理が必要なので紙なり記事なりに書き出してまとめる * 何もしたくない：休憩が必要な場合もある、そうではなくてやる気が出ず、しかしやらないといけないときにはエンジンを温める意味で、頭使わなくてもできる小さいタスクに分割して進捗を出してみる これを書いていると、Career DynamicsでEdgar Scheinが語っていた難しさの種類の話を思い出す。 難しいと感じる時は、次のどれかだと分類していた。 * 量が多くて難しい * 自身のポリシーや心情などに反していて難しい * 何をしたらいいか分からなくて難しい ここまで整理できれば、量が多くて難しいときはヘルプを頼むか時間をもらうかして単位時間あたりの量を減らすなどすればいい。上で言うところのやりたいことがあるのにできてない、に該当しそう。 自身のポリシー等々の問題の場合、それがどうしても超えられないなら他の人にお願いするしかない。これは上で言うところにはマッチしない新しいものと言えそう。 何をしたらいいかわからない場合は、情報をもっと入手したり書き出したりといったIn/Outの不足。これは、何をしたいかわからない・何をしているかわからない、という上のIn・Out部分に該当しそう。 何をしたらいいかわからない部分は整理されれば、他の難しさに分類されるか、あるいは状況がクリアになって難しさがなくなるはず。

チームでの活動時に、自社の上位マネジメントと活動状況を握れているかどうか、はチーム活動としても重要だし、人事上の評価としても重要になる、という話が上がった。 背景はお客様への提案活動の最中（＝Selling Phase）。 BANTというフレームワークを教えてもらった。 Budget: 予算は確保できそうか？ Authorization: 意思決定者と握れているか？ Needs: ニーズ（必要性）はあるのか？ Timeline: 今やらないといけない明確な理由ある？ BANTに沿って上位マネジメントに報告するとわかりやすい上、確かな仕事の取り回しをしていると周りから見て安心感があるとのこと。 その上で、状況が見えない場合のその依存先はどこなのか、どこにリスクがあるのか、さらにはそこに対してどんなアクションを取る予定かや必要な要件は何か、などを明確にするとなお良いとのこと。 もちろん、これだけに限らず、競合先との提案状況を比較してどうか、という部分も重要になる。 適当に検索してみると、どうやらこのフレームワークはIBMが作ったものらしい......60年前に。（！） The BANT Framework For Qualifying Prospects and Leads IBM created the BANT framework as a simple way to qualify the www.propellercrm.com Do We Need to Update the BANT Framework? The BANT framework may be decades old now, but its main princ www.copper.com

資料が長すぎてポイントでまとめるのが厳しかったので、特に気になった点のピックアップとそれ以外のちょっと気になったところを抜き出してる。 Lambdaのライフサイクル： 1. (ENIの作成, VPC利用時のみで10-30秒かかる) 2. コンテナの作成 3. デプロイパッケージのロード 4. デプロイパッケージの展開 5. ランタイム起動・初期化 6. 関数/メソッドの実行 7. コンテナの破棄 1〜5.（資料には1〜6.と書かれてるけど）の部分を再利用するのがウォームスタートで、コールドスタートは1から始める。 安定的にリクエストが発生している場合はコールドスタートはほぼ発生しないらしい。 また、コンテナを維持するためにポーリングすることは、多くの場合は無駄、とのこと。 制限事項は緩和可能なものと緩和不能なものがある。 AWS Lambda のクォータ - AWS Lambda AWS Lambda 関数および関連リソースの最大サイズ、制限、およびクォータ。 docs.aws.amazon.com Amazon API Gateway のクォータと重要な注意点 - Amazon API Gateway Amazon API Gateway のクォータと重要な注意事項を一覧表示します。 docs.aws.amazon.com Lambdaを使うには、次の3つの選択肢がある。 * 一から作成 * 設計図の使用（一般的なユースケース用のサンプルコードと設定） * Serverless Application Repositoryの参照 Custom Runtimeとして、Lambdaが公式には対応していない任意の言語をLambda関数で記述できるようになる。 AWSからOSSとしてC++やRustが使用可能。 その他、パートナーからPHP/Erlang/Elixir/COBOLなどが提供される予定。（COBOL！） ユースケースとしては、下記。 * Lambdaがサポートしている言語の新しいバージョンを待てない * Lambdaがサポートを打ち切った言語のバージョンを使いたい * Lambdaがサポートしてない言語を利用したい その他ポイントになりそうなところ： * コード実行時間に対する課金でコスト効率が良い（=EC2と比べてかな）と言う話は特徴として何度も出てくる