miso_soup3 Blog

主に ASP.NET 関連について書いています。

行によって列の意味が異なる CSV のための Viewer（VSCode Extension）

行によって列の意味が異なる CSV の閲覧と編集を補助する VSCode Extension を作成しました。

marketplace.visualstudio.com

使い方: 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,オロパタジン塩酸塩錠５ｍｇ「ＪＧ」,2,錠,4,4490025F2062,1
301,1,１日２回　朝夕食後服用,14,日分,1,1,,1
201,2,アンテベートクリーム０．０５％,30,ｇ,4,2646730N1054,1
201,2,ヘパリン類似物質油性クリーム０．３％「日医工」,50,ｇ,4,3339950M1188,1
301,2,かゆい所に塗布,1,調剤,5,1,,1
311,2,１日２回　躯幹,1
311,2,混合,1

これはお薬手帳のデータですが*1 、このような CSVを閲覧や編集するとき、列の数を 1, 2, 3.... と数えて仕様書と見比べたり、値を編集するのが手間です。なので、列の意味を表示してくれる VSCode Extension を作成しました。

左下にカーソル位置の列の意味が表示されています↓

f:id:miso_soup3:20210430222459g:plain

また、コマンドから全体の情報を出力できます↓

f:id:miso_soup3:20210430222735p:plain

拡張機能を使う時は、あらかじめ CSV の仕様を JSON で定義する必要があります。今回のお薬手帳の例は、このように定義しました（一部のみ）： https://gist.github.com/hhyyg/eec04d51b9c2dc940b45dc3c34f0021d

*1:例の CSV はお薬手帳のデータで、仕様はこちらにて公開されています：JAHIS電子版お薬手帳データフォーマット仕様書Ver.2.3 | 一般社団法人保健医療福祉情報システム工業会 自分はアプリでお薬手帳を管理しており、アプリのエクスポート機能から CSV ファイルを入手しました。また、自分の個人情報を公開したくないため一部情報を変更しています

スタンドアロン（またはネイティブ）アプリと LaunchDarkly によるカナリアリリースの課題

LaunchDarkly

概要：

スタンドアロンアプリ開発（Webアプリではなく）にて LaunchDarkly によるカナリアリリースを行っていますが、ある問題が発生しています。 いくつか策はありますが、一般論や似たような事例があるはずで、それを知りたいですが、手詰まりな状態です。

LaunchDarkly をどのように使っているか

スタンドアロンアプリにおいて、LaunchDarkly の短期の機能フラグを以下のメリットのために使います。

メリット：

  1. ベータテスト：リリース前に、一部ユーザーなどの一部のみに開放する
  2. カナリアリリース：異なるバージョンのアプリをデプロイしなくても、機能を提供できる

流れ：

  1. フラグで一部ユーザーのみに開放する
  2. 改善を行う
  3. フラグで全ユーザーに開放する
  4. 安定稼働を見届ける
  5. フラグを参照しないバージョンをリリースする
  6. フラグを削除する

問題

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 にする

冒頭のメリットについて

  1. ベータテスト：リリース前に、一部ユーザーなどの一部のみに開放する
  2. カナリアリリース：異なるバージョンのアプリをデプロイしなくても、機能を提供できる
    • → △ カナリアリリースのためのフラグを設けたバージョンをリリースする必要がある
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 を使っているユーザーは使えない状態になる
  • フラグを参照しないバージョンをリリースする

冒頭のメリットすべて得られるため、これが理想に思います。

参考サイト

言葉のメモ

  • フラグ
    • 短期的なフラグと、永続的なフラグ
  • リリース管理
    • カナリアリリース：一部のユーザーのみが利用できるようにリリースすること
      • リング展開
        • パーセンテージベースの展開
      • ベータテスト：全ての人にリリースする前に、顧客のフィードバックを得る