# 実践 Terraformを読んでTerraform勉強中 Vol.1

はじめに

こんばんは。

今回は以下の本を読んで勉強中です。

実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)

2019年9月と少し古めの本ですが、積本しちゃってたので読み進めております。

この本で使用されているterraformのバージョンは v0.12.5 なのですが、自分は最新のバージョンである v1.0.3 で進めています。

今回は第1章〜第2章をやりました。

というか、第1章は使用するAWSの設定と、terraformのインストールなので、メインは第2章です。

本題

上でも書きましたが、前提としてバージョンは以下です！ 本書でも紹介があった tfenv でインストールしております。

$ terraform --version
Terraform v1.0.3

今回使用した tfファイルの中身はこちら

provider "aws" {
    region = "us-east-1"
}

resource "aws_instance" "example" {
    ami           = "ami-0c2b8ca1dad447f8a"
    instance_type = "t3.nano"

    tags = {
        Name = "ExampleName"
    }
}

使用したコマンドは以下。

terraform init

リソース作成で使用されるpluginなどの諸々のファイルのダウンロードを行います。

terraform plan

実行計画が表示されます。 dry-run的な立ち位置なのでしょうか？

terraform apply

実際にデプロイされます。

基本は デプロイしていいかどうか 返事を求められますが -auto-approve をつけると即実行してくれます。

terraform destroy

デプロイされているものを削除します。

終わりに

めっちゃ簡単でしたがここまで...w

とりあえず触りは出来たのと、最新バージョンでも基本の基本は問題なさそうでした。

次からもっと深く触っていきます。

現場からは以上です。

現場で役立つシステム設計の原則を読書中 9〜10章

はじめに

こんばんは。

現在 現場で役立つシステム設計の原則 という本を読んでおります。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

前回

kojirooooocks.hatenablog.com

kojirooooocks.hatenablog.com

kojirooooocks.hatenablog.com

読んだ感想を備忘録で残しておきます。

今回は9, 10章です。

本題

9 章 オブジェクト指向の開発プロセス

開発の進め方はオブジェクト指向で変わったのか

ドメインモデルを中心にしたソフトウェア開発の進め方

ソースコードを第一級のドキュメントとして活用する

一貫して、ドキュメントはソースコードが担うということだった。

またすごいなと思ったのは、テストコードを文書化するという話だった。

テストはテストとしてしか捉えてなかったので、新たな目線で楽しかったが、そこまで出来るのかな...とは正直思った。

分析と設計が一体になった開発のやり方をマネジメントする

業務知識が乏しい技術者がいくらオブジェクト指向でプログラミングしても、業務アプリケーションとしての変更容易性は達成できません。

プラグラミングスキルのある人間は、能力的には業務要件を理解し設計に反映することに何も問題がありません。あとは、本人の意欲と、まわりの支援の問題です。

ちょっと出来るからって、丸投げ下げるの一番困る。

それで教えて下さいって言っても、なかなか時間取れずに、結局探りながら作るというのが何回かあったな。。。

10 章 オブジェクト指向設計の学び方と教え方

オブジェクト指向を学ぶハードル

オブジェクト指向は言葉で説明しても理解しづらい。そのためのおすすめの学び方が記載されていた。

具体的には以下

• 既存のコードを改善しながらオブジェクト指向設計を学ぶ
• やや極端なコーディング規則を使ってオブジェクト指向らしい設計を体で覚える

既存のコードを改善しながらオブジェクト指向設計を学ぶ

リファクタリングの本を参考に 具体的なリファクタリングをしながら学ぶ方法が書かれている

これ読んでないから読みたい。

リファクタリング 既存のコードを安全に改善する（第2版）

オブジェクト指向らしい設計を体で覚える

ThoughtWorks アンソロジー という本で紹介されている9つのルールを自分に課して体で覚える

ルールのひとつである すべてのエンティティを小さくする で紹介されていた、著者のガイドラインが衝撃だった。

このガイドラインも含め真似するのはむりっぽい...

でも、自分にとっての少しきつめなガイドラインは持っておいたほうがいいと思った。

ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション

オブジェクト指向の考え方を理解する

参考書籍が紹介されていた。

終わりに

短くなっちゃった。。 でも読み終わりました。

とても読みやすい書籍でした。

4〜7章は特に内容が濃いもので、もう一回くらい読み直したいなと思いました。

次は何の本読もうかな。

現場からは以上です。

現場で役立つシステム設計の原則を読書中 8章

はじめに

こんばんは。

現在 現場で役立つシステム設計の原則 という本を読んでおります。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

前回

kojirooooocks.hatenablog.com

kojirooooocks.hatenablog.com

読んだ感想を備忘録で残しておきます。

今回は8章です。

8〜10章を全部読んでこれで終わりにしようと思いましたが、8章が意外とボリューム大きかったので、8章だけにしました。

本題

8 章 アプリケーション間の連携

アプリケーションとアプリケーションをつなぐ

アプリケーション間の連携の種類が以下の4つ。

• ファイル転送
• データベース共有
• Web API
• メッセージング

それぞれのメリット・デメリットが述べられていた。

Web APIのしくみを理解する

迷いやすいPOSTとPUTの違いをわかりやすく説明してくれていた。

POSTは識別子を指定せずとも登録ができること

PUTは識別子を指定して登録ができること

識別子を指定するぶん結合が密になってしまう。なのでできるだけ登録・更新はPOSTで行うべき。

本によると PUTと同じ理由で DELETEもできればPOSTで行うべきということだった。

良いWeb APIとは何か

One Size Fit All = 「大は小を兼ねる」

いろんなパラメータを指定できて、様々な情報を取得できるAPI。

ただ、利用者側から見ると、それは良いAPIではなく 利用する側の負担が大きいAPI となる。

単純な取得に関しても、指定できるパラメータを理解しなければいけないし、様々な情報から必要な情報を選んだりする必要がある。

また、提供側もパラメータごとに条件分岐が出来るので、どちらにとっても幸せではなさそう。

微妙に異なる様々なニーズを一つのAPIで叶えようとしてしまった結果、出来上がってしまうパターンが多い。

Web API は以下の2通りの意味で使われている

• 利用する側でアプリケーションを組み立てるための部品のセット
• 利用する側でプログラミングせずに利用できる完成品

完成品 = Webサービス

部品 = Web API

ということだが、部品として粒度が大事になってくる。

小さい方がいろんな工夫ができ、かつ、実装も単純だと思う。ただ、小さいため、組み立ての難易度は高くなってくる。

良い Web APIとは、組み立ての多様性を維持しつつ、組み立ての負担が増えすぎない適切な大きさの部品を用意することです。

発展性に富んだAPI開発のやり方

• 登録と参照を分ける
• リソース(データのかたまり)の単位を分ける

この2つを常に意識することが良い Web APIの発見につながります。

例で提示してくれていた予約システムのAPIだが、自分はWebサービス的なAPIを選んで作ってしまっていた。

ただ、再度取得のAPIを投げるためのコストはこの場合考えないのだろうか?

そこだけ知りたい。

また、よくある /api/v1 みたいなバージョン管理も、APIを小さな部品として作っていれば、部品の追加と削除ですむので、バージョンを分ける必要がないとのこと。

これは、自分も思ってたので納得。

ドメインオブジェクトとWeb API

ドメインオブジェクトは、ロジックが軸にあり、APIから送られてくるデータは、データが軸にあるので、そのままズドンと変換はできない。

また、ドメインオブジェクトが期待しているデータがAPIからすべて送られてくるとも限らない。

そのような場合はRespons用のクラスを一枚噛ませれば良い。

また、単純なものであれば、そのまま変換しても良い。

大事なのは、ドメインオブジェクトの関心事がAPIによってぶれないこと。

複雑な連携に取り組む

マイクロサービスの説明や、メッセージングでの連携手法について詳しく説明されていた。

また、結構重要だなと思ったのは、APIのグルーピングが複雑な連携に取り組むためには必要というところ。

個別・共通・汎用みたいにグルーピングをし、それを管理し整理していく。

短期的にはコスト要因だけど、長い目で見ると関係者全員の利益になると本でも言われている。

終わりに

次は9〜10章を読みます。

次こそ終了っぽい。

現場からは以上です。

現場で役立つシステム設計の原則を読書中 5〜7章

はじめに

こんばんは。

現在 現場で役立つシステム設計の原則 という本を読んでおります。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

前回

kojirooooocks.hatenablog.com

読んだ感想を備忘録で残しておきます。

今回は5〜7章までです。

本題

5 章 アプリケーション機能を組み立てる

ドメインオブジェクトを使って機能を実現する

アプリケーション層(サービスクラス)の見通しが悪く習いなための重要なtipsは以下

• 業務ロジックは、サービスクラスに書かずにドメインオブジェクトに任せる(サービスクラスで判断/加工/計算しない)
• 画面の複雑さをそのままサービスクラスに持ち込まない
• データベースの入出力の都合からサービスクラスを独立させる

一番気をつけないといけないことは、足りない業務ロジックを安易にサービスクラスに書かないこと。

ドメインオブジェクトを追加・修正して足りない業務ロジックをドメインモデルに集約させること。

1つのドメインオブジェクトが複数のサービスクラス(複数の業務機能)から利用されているのは、コードの重複を防いでいる良い傾向です。 逆にドメインオブジェクトの変更が、業務的なつながりと異なるサービスクラスに影響が出た場合は、ドメインオブジェクトの設計に問題がありそうです。

1サービスクラス1ドメインオブジェクトみたいな実装を考えていると失敗するという感じ。

画面の多様な要求を小さく分けて整理する

これよくやっちゃう。

画面からの様々な要求に対して、小さな単位に分けてそれを組み合わせていくことが重要。

分ける基本として、登録系と参照系のサービスを分ける。

分けたサービスをドメインモデルの外で組み立ててしまうと 業務の手順 という業務知識がドメインモデルの外に 染み出してしまう

そのために、分けたサービスをつなぎ合わせて機能を組み立ててつかう、サービスクラスをドメインモデル内に作成する(本の例では Senario)

サービスを利用する側と、サービスを提供する側とで、サービス提供の約束ごとを決め、設計をシンプルに保つ技法を契約による設計と呼びます。

本の例では、口座の残高を更新する withdraw が実行されたさい、 残高更新が行えるかどうかを確認する canWithDraw を実行して falseの場合は Exceptionが投げられている。

サービスを提供する側の残高更新Senarioは、呼び出されるときは 残高更新が行えること が約束毎になっている。

データベースの都合から分離する

「記録」という業務の関心事を、INSERTというデータベース操作に、開発者が頭の中で変換してしまう結果、プログラムの記述から業務の意図が消えてしまいます。

この文刺さった。

たしかにINSERTやUPDATEをするときは、その操作に頭がいっていて、そのコードを業務の関心事として捉えていないかもしれない。

またリポジトリの説明でも良い文があった。

リポジトリは、INSERT文やSELECT文の実行に業務的な名前をつけただけの存在ではありません。 データベース操作の詳細を、サービスクラスに意識させない工夫です。

自分が以前、ドメインを意識して書いたコードを見てみると、データベース保存の都合に、振り回されているようなコードがあった。

サービスクラスにはそれは知らなくていいことだ。

勉強になった。

6 章 データベースの設計とドメインオブジェクト

テーブル設計が悪いとプログラムの変更が大変になる

データベース設計をすっきりさせる

テーブル設計や制約の話。

僕も以前20〜30カラムあるテーブルで、何の制約もなくすべてtext型というテーブルに対面したことがあり、絶望した経験ある。

データベースも最初の設計が大事。

コトに注目するデータベース操作

記録の変更を禁止する という考え方が面白かった。

• 元データ
• 取り消しデータ
• 新データ

という感じで3つの記録を残すようにすれば、変更は起きずすべてINSERTになる。

参照をわかりやすくする工夫

状態を更新するテーブルはコトの記録からいつでも再構築可能な二次的な導入データ

logテーブルとか作るけど、どちらかというと更新テーブルのほうが重要で捉えてたところがあるので、ちょっと考えを改めようと思った。

また 残高更新は同時でなくてよい というのも面白かった。

更新するテーブルは再構築可能な二次的なテーブルという捉え方をしていたら、たしかに、更新テーブルの更新に失敗したらコトの記録も巻き戻すというのはおかしいとわかった。

オブジェクトの設計とテーブルの設計

オブジェクトはオブジェクトらしく、テーブルはテーブルらしく

業務ロジックはオブジェクトで、事実の記録はテーブルで

自分も書いているときに、ドメインオブジェクトとテーブルが1:1でつながっているような設計になっちゃうときがある。

ただ、やはりそこは似ているだけであって同じものではないというところをわかってないとダメだし、違うものだというのを説明できないとだめだと思った。

7 章 画面とドメインオブジェクトの設計を連動させる

画面アプリケーションの開発の難しさ

利用者の関心事に焦点を当てると、画面デザインとドメインオブジェクトの設計は連動します。

この部分、意識できるようになって来ているなと自分では思っている。

もっと設計の実践を積んで行きたい。

画面の関心事を小さく分けて独立させる

注文時の 注文者情報 注文商品決済方法配送方法` などを Order::register() みたいに一つのクラスで処理していると、メソッドが膨らんでしまい、追加削除が大変になる。

注文者情報 ならそれだけの保存注文商品 ならそれだけの保存という感じで、それぞれで保存できるようなロジックにし、それを Order::register() で呼び出すようにすれば、変更がかかっても対象の保存クラスのみに抑えられる。

画面とオブジェクトを連動させる

ドメインオブジェクトをそのまま使って画面の表示するというということらしいが、ここまで出来ているプロジェクトってあるのだろうか...? ちょっと実際に見てみないと、イメージつかない...

画面(資格表現)とソフトウェア(論理構造)を関連付ける

ここで例として紹介されている書籍クラスと画面の関心事と一致させたクラスは、説明としてすごくわかりやすかった。

また、以下の文も自分的に響いた文だった。

画面デザインがごちゃごちゃしている場合は、ドメインオブジェクトの設計の方から、画面をより論理的にデザインする改善点を提供すべきです。 画面のデザインとドメインオブジェクトの設計の一致は、利用者/画面のデザイナ/ソフトウェア開発者が一緒になって検討すべきです。

デザインの部分は苦手で、正直任せていたところがあるので、逃げずにきちんと向かい合わないとと思った。

終わりに

次は8〜10章を読みます。

10章までなので次回で終わりです。

現場からは以上です。

現場で役立つシステム設計の原則を読書中 1〜4章

はじめに

こんばんは。

現在 現場で役立つシステム設計の原則 という本を読んでおります。

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

過去に1度読んだことがあったのですが、その際はザーッと読んだだけなのと、ほぼほぼ内容忘れてるので読み直しております。

1〜4章まで読んだので、それを読んで感じたことを残しておきます。

本題

1 章 小さくまとめてわかりやすくつくる

どのようにプログラムが複雑になっていくか、どのようにすれば、複雑さを回避できるかなどの簡単な説明が書いてありました。

本に書かれているコードも、そのコードに対して、どうしてこのようなコードだと良いのかという説明も、エンジニア初心者の方でもとてもわかり易いものでした。

プログラムの修正に3日かかるか、それとも半日で済むか。その違いを生むのが「設計」なのです。

という文には、ハッとさせられます。

2 章 場面分けのロジックを整理する

1章と同様にとてもわかり易いコードと説明で、場面・区分毎の複雑さを生まない設計を説明されていました。

1章との違いは、 interface を使用したより具体的な状況での設計を説明されています。

3 章 業務ロジックをわかりやすく整理する

前半は、コードの見通しが悪くなる原因が説明されています。

複数ある原因の中で個人的に読んでて面白かったのは、原因の一つとしてあげられている 共通機能ライブラリ の話でした。

初級者のときによく作ってしまう commonとかutilとかのライブラリですが、そこまでうまく運用できないよというのが例とともにわかりやすく説明されていました。

後半は、その対処法が説明されています。

主たる原因となるデータクラスと機能クラスを分ける手続き型の設計ではない別の考え方を示してくれています。

また、その設計のやり方を簡単に説明してくれています。

個人的にはこの章で出てきた以下の文がとても気分を楽にしてくれました。

オブジェクト指向の設計は、改善の繰り返しです。最初から良い設計が見つかるわけではありません。 コードを書いて動かしてみながら、ロジックの置き場所やクラス名/メソッド名の改善を続け、より良い設計を見つけていくのが、オブジェクト指向設計の基本です。

もちろんベースラインはありますが、最初からきれいなものは作れないんだよということは、心の余裕になります...w

4 章 ドメインモデルの考え方を設計する

3章の後半で説明されたコードの見通し悪化の解決策であるドメインモデルの考え方が詳細に説明されていました。

4章はだいぶ今までの章と比べてページ数も多くなっています。

なので更に分けて、感想を残しておこうと思います。

1. ドメインモデルの考え方を理解する

ドメインモデルはプログラミング言語で書いた「業務の用語集」であり「業務の説明書」です。ただし、単なる用語の羅列ではありません。それぞれの用語がどのように関連し、どのように相互に作用するかをパッケージ構成やクラスの参照関係で立体的に表現する手段です。

序盤に説明してくれているこの文書が一番なるほどときたところでした。

また、上記を実現するために、

1. 要求の聞き取り
2. 不明点を確かめるための会話
3. 図や表を使っての整理
4. 理解した結果を記録するための文書の作成

など、実際にプログラムを書く以外の行動が大事になってくるということです。

この辺は1, 2までをやってる人が多そうだなと思いました(自分は余裕があれば3までやるけど、大体2で終わっちゃうかも...)

詳細の聞き取りの後は、コードに落とし込むための思考(設計)を行います。

このときプログラム = 業務の説明となるためには、業務に使っている用語をクラス名にするということが有効のようです。

抽象的になりすぎないなるべく具体的な名前を採用するべきです。そのために最初の聞き取りが重要ということです。

データモデルとドメインモデルの違いにも触れています。

データを中心に捉えたデータモデルと、業務の関心事を中心に捉えたドメインモデルで、どのように考え方が違うか、どのような設計になってくるかを例とともに紹介しています。

2. ドメインモデルをどうやって作っていくか

パッケージ図 や 業務フロー図 などの図の説明と、それを利用したドメインモデルの作成方法が説明されています。

大事なのは 重要な部分から作っていく ところです。

重要な部分を見つける手段として上記の図が役に立つという感じです。

また特に重要だったのは ドメインオブジェクトを機能の一部として設計しない ということでした。

ある機能の一つとして作ってしまうと、それに関連する機能との依存が生まれてしまい、その機能の部品となってしまいます。

そうなってしまうと、もし修正が配流となった場合、調査・対応する影響範囲が広がってしまいます。

重要なのは以下。

どうやって機能を実現するかに注目するのではなく、ある特定の業務のデータとそのデータを使った判断/加工/処理の業務ロジックだけを切り出した独立したロジックを作ります。

3. ドメインオブジェクトの見つけ方

ドメインオブジェクトをみつけるために ヒト・モノ・コト に注目するということが説明されています。

何らかの商品の販売活動を例に詳細な説明をなされています。

4. 業務の関心事の基本パターンを覚えておく

基本となる4つのドメインオブジェクトと、4つの関心事のパターンを使って整理していくと、業務ロジックはアプリケーション側ではなくドメインモデル側に集まるようになるとされています。

また、それぞれの関心事のパターンの詳細が説明されています。

5. ドメインオブジェクトの設計を段階的に改善する

初期段階で設計したドメインオブジェクトを修正しなければいけなくなった際の対処方法が説明されています。

クラス名やドメソッド名の変更やロジックの移動、また、取りまとめ役のクラスの導入などです。

取りまとめ役のクラス = 最小単位の値オブジェクトを複数持ち扱いやすくしたクラスと言う意味です。

6. 業務の理解がドメインモデルを洗練させる

ドメインモデルの成長のために開発者自身の業務知識を増やすことが説明されています。

重要なのは、全てを理解することではなく 重要な言葉とそうではない言葉を理解すること と 言葉と言葉の関係性を見つけられること だそうです。

そのための方法として、その業務のエキスパートへのヒヤリングや、ヒヤリング結果の可視化を行うことが重要です。

また、手ぶらでヒヤリングしても十分な聞き取りが出来ない可能性もあり、その状況では業務知識は乏しいままになり、ドメインモデルの設計ができないままになってしまいます。そのためにはある程度対象業務の基礎知識を身につけるべきとも書かれていました。

具体的には業務マニュアルを読んだり、実際に画面をざっと触ってみたりなど、自分でできる範囲の箇所です。

終わりに

3年前くらいに読んだのですが、全く覚えてなかったですw

個人的には4-4の 業務の関心事の基本パターンを覚えておく はとても具体的にかつわかりやすく書かれていて、とても読み応えがありました。

実際にいまお仕事しているプログラムに当てはめて考えたりして、その時の思考が楽しかったです。

次は5〜7章を読みます。

現場からは以上です。

自宅の作業部屋をアップデートした

はじめに

こんばんは。

本日自宅の作業部屋をアップデートしました。

今までmbp onlyでやってて、たまに外部ディスプレイ使ってたのですが、メインを外部ディスプレイにしました。

今までの開発環境だと、目線が下に行ってとにかく姿勢が悪くて肩こり腰痛がひどかったので、目線を上げて背筋が伸びるようにしたかったためです。

本題

アップデートするために購入したものはこちら

エレコム USB Type-C ハブ ドッキングステーション 6-in-1 DST-C12SV/EC 100W PD対応 USB3.1 Type-C×1ポート USB3.0-A×2ポート 4K対応HDMI×1ポート SD/microSDスロット ケーブル長30cm Macbook Pro16まで充電/iPad Pro/Chromebook/Surface他対応

Magic Keyboard - 英語（US)

Apple Magic Trackpad 2 - シルバー

BUFFALO ツメの折れないLANケーブル カテゴリ6a ストレート フラットタイプ ブルー BSLS6AFU50BL

Anker PowerExpand USB-C & イーサネットアダプタ 1Gbps 高速イーサネット通信 MacBook iPad Pro 用

BoYata ノートパソコンスタンド PCスタンド タブレットスタンド 人間工学設計 無段階高さ調整可能 姿勢改善 折りたたみ式 滑り止め アルミ合金製 優れた放熱性 17インチまでのデバイスに対応

atolla USB Type C HDMI 変換 アダプター 4K高解像度映像出力[4K@60Hz / Thunderbolt 3互換 / 10cm HDMI USB タイプc 変換ケーブル] MacBook Pro/Air, iPad Pro, Google Chromebook, Surface Pro7, Huawei / Galaxy S20などUSB-Cデバイス対応

合計 30,000円くらいです。

最終的にこんな感じ。

終わりに

HDMI変換ケーブルが、ちゃんと刺さってないかな...?というのと、hubのケーブルが結構硬いくらいで、ほかは今日揃ったので特にレビューも何もないですｗ

普通に使えています。

明日から仕事頑張るぞ！

現場からは以上です。

phpstormでファイルの保存時に csfixerを実行する

はじめに

こんにちは。

簡単な設定の話です。

cs-fxierを自動で走らせたいなーと思ってて、色々調べた結果です。

ググると結構出てくるんですが、どれもバージョンが古いのかうまく設定できませんでしたので、自分が一番しっくりきた設定を残しておきます。

phpstormのバージョンは 2021.1.4 です。

本題

まず事前にプロジェクトに cs-fixerをinstallしておきます。

$ composer require --dev friendsofphp/php-cs-fixer
$  ./vendor/bin/php-cs-fixer --version
PHP CS Fixer 2.18.2 Remote Void by Fabien Potencier and Dariusz Ruminski‘

次に設定を開きます。

Preference > Tools > File Watchers

今ひとつ追加していますが、まさにこれです。

新規の場合は + で追加します。

FileType: PHP を指定します。

Scope: Project Files を指定します。僕はねんのため、 Module で対象を指定しています(必要ないのかな？)

Program: php-cs-fixerファイルまでのフルパスを指定します。

Arguments : 以下のようにします。

fix
--config=.php_cs.dist ファイルまでのフルパス
"$FilePath$"

configがない場合は --rules とかで指定する感じだと思います。

そして、 auto-save edited files to trigger the watcher のチェックを外します。

このチェックを外さないと、自動保存とcs-fixerの実行が素早く動くため、おそらく快適にプログラムを書けないと思います。

このチェックを外しておくと Ctrl+S で保存した際、または、AutoSave側の設定にも準じてfixerが動きますので、今の所快適に開発できています。

終わりに

この手の情報で出てきていたブログでは AutoSave側でコントロールしようとしていたのですが、自分の使用しているバージョンではうまく行かなかったので自分はこのアプローチになりました。

現場からは以上です。