行によって列の意味が異なる CSV のための Viewer(VSCode Extension)
行によって列の意味が異なる CSV の閲覧と編集を補助する VSCode Extension を作成しました。
使い方: miso.csv-map-viewer-vscode-ext/README.ja.md at main · hhyyg/miso.csv-map-viewer-vscode-ext · GitHub
"行によって列の意味が異なる CSV" とは、例えば以下のように、先頭の列の値によって列の意味が異なる CSV のことです。行によって列の数が異なる特徴があります。
JAHISTC03,2 1,山田太郎,2,20150325,,,,,,,ヤマダタロウ 3,FCユビキャップ(3ホン),,,1 3,FCボウスイワンタッチパッド S 6マイ,,,1 5,20181101,1 11,〇〇薬局,,4,,123-4567,東京都,012345678,1 51,皮フ科,,,,1 55,医師名,皮膚科,1 201,1,オロパタジン塩酸塩錠5mg「JG」,2,錠,4,4490025F2062,1 301,1,1日2回 朝夕食後服用,14,日分,1,1,,1 201,2,アンテベートクリーム0.05%,30,g,4,2646730N1054,1 201,2,ヘパリン類似物質油性クリーム0.3%「日医工」,50,g,4,3339950M1188,1 301,2,かゆい所に塗布,1,調剤,5,1,,1 311,2,1日2回 躯幹,1 311,2,混合,1
これはお薬手帳のデータですが*1 、このような CSVを閲覧や編集するとき、列の数を 1, 2, 3.... と数えて仕様書と見比べたり、値を編集するのが手間です。なので、列の意味を表示してくれる VSCode Extension を作成しました。
左下にカーソル位置の列の意味が表示されています↓
また、コマンドから全体の情報を出力できます↓
拡張機能を使う時は、あらかじめ CSV の仕様を JSON で定義する必要があります。今回のお薬手帳の例は、このように定義しました(一部のみ): https://gist.github.com/hhyyg/eec04d51b9c2dc940b45dc3c34f0021d
スタンドアロン(またはネイティブ)アプリと LaunchDarkly によるカナリアリリースの課題
概要:
スタンドアロンアプリ開発(Webアプリではなく)にて LaunchDarkly によるカナリアリリースを行っていますが、ある問題が発生しています。 いくつか策はありますが、一般論や似たような事例があるはずで、それを知りたいですが、手詰まりな状態です。
LaunchDarkly をどのように使っているか
スタンドアロンアプリにおいて、LaunchDarkly の短期の機能フラグを以下のメリットのために使います。
メリット:
流れ:
- フラグで一部ユーザーのみに開放する
- 改善を行う
- フラグで全ユーザーに開放する
- 安定稼働を見届ける
- フラグを参照しないバージョンをリリースする
- フラグを削除する
問題
Web アプリでは問題ないですが、スタンドアロンアプリの場合、以下の問題が生じます。
例:
- Ver 1.x.x フラグで一部ユーザーのみ開放する
- 改善を行う
- Ver 2.x.x をリリースしたとする
- リリースしたいタイミングで、フラグで全ユーザーに開放する
最後のステップ「フラグで全ユーザーに開放する」にて、Ver 1.x.x を使うユーザーにも機能が開放されることになります。Ver 1.x.x の時点で既に品質がよければ問題ありませんが、そうでなければ、品質が悪い機能が提供されることになります。
問題:
- 「LauchDarklyの短期の機能フラグで一部ユーザーに公開しつつ、改善を続け、任意のタイミングで全開放」という開発が行いにくい。
この問題は、以下の問題に類似しており、”古いバージョンを使うことによる問題点” の一種と思われます
- とあるバージョンにてバグの修正版をリリースしたが、まだアップデートしていない人にはバグ混入バージョンを提供していることになる
回避策
A 強制アップデート
強制アップデートにすれば、スタンドアロンでもほぼ Web アプリと同様に最新版のみを提供できることになり、上記の問題は発生しません。 ただし、強制アップデートを使えない事情があるため、この案は採用できないと仮定します。
B ベータテストと、カナリアリリースのための2つのフラグを使う
ベータテストのためのフラグ beta-flag
と、カナリアリリースのためのフラグ feature-flag
を用意します。
流れ:
- 一部ユーザーのみに提供するため、
beta-flag
がONであれば使える状態でリリースする - 全ユーザーに公開しても良い段階にする
- 全ユーザーに提供するため、
feature-flag
がONであれば使える状態でリリースする- このとき、
beta-flag
は 削除するなどで OFF にする
- このとき、
冒頭のメリットについて
- ベータテスト:リリース前に、一部ユーザーなどの一部のみに開放する
- → ベータテストのためのフラグを設ける
- カナリアリリース:異なるバージョンのアプリをデプロイしなくても、機能を提供できる
- → △ カナリアリリースのためのフラグを設けたバージョンをリリースする必要がある
C バージョンを参照する
フラグは、boolean だけではなく、文字列や JSON も設定可能なことから、3 種類の値を持つフラグを設けます。
- "ON"(常に有効)
- バージョンの値:例:"2.0.0"(2.0.0以上のみ有効であることを表す)
- "OFF"(常に無効)
スタンドアロンアプリ側で、フラグがバージョンの値であるときは、自身のバージョンの値と比較して ON、OFF かどうかを判断します。
流れ:
- 一部ユーザーのみに提供するため、1.x.x をリリースする。フラグのバージョンの値を "1.x.x" にする
- 全ユーザーに公開しても良い段階にする
- 2.x.x をリリースする
- 全ユーザーに提供するため、フラグのバージョン値を "2.x.x" にする。
- このとき、バージョン 1.x.x を使っているユーザーは使えない状態になる
- フラグを参照しないバージョンをリリースする
冒頭のメリットすべて得られるため、これが理想に思います。
参考サイト
- 7 Feature flag best practices - LaunchDarkly | LaunchDarkly
- Release Management Best Practices with Feature Flags | LaunchDarkly | LaunchDarkly
- Beta Testing using Feature Flags | LaunchDarkly
- Martin Fowler / Feature Toggles (aka Feature Flags)
言葉のメモ