2021-03-26

Azure Functions の設定が変わったり変わらなかったりする件

Azure C#

Azure Portalの構成で設定値を変更しても、すぐにその設定でFunctionsが動くとは限らないよ、というお話です

準備

関数

[FunctionName("QueueFunction")]
public static async Task Run([QueueTrigger("myqueue-items", Connection = "")]string myQueueItem, ExecutionContext context, ILogger log)
{
    var config = new ConfigurationBuilder()
        .SetBasePath(context.FunctionAppDirectory)
        .AddEnvironmentVariables()
        .Build();

    var setting = config["SETTING"];

    log.LogInformation($"Queue trigger function processed: {setting} ({context.InvocationId})");

    var client = new HttpClient();
    await client.GetAsync("https://localhost/heavyapi");
}

Visual StudioのテンプレートにQueueTriggerで動く関数を追加します

最後のclient.GetAsync()は10秒応答を返さないWebAPI作ってそれを呼び出すようにしておきました (重い処理やっているつもり)

設定

PortalのFunctionsの構成で

f:id:puni-o:20210326160814j:plain

こんな感じに設定しておけばログに設定値が出るはずですね

動かしてみる

Queueに何個か突っ込んでログを確認してみます

f:id:puni-o:20210326161001j:plain

App Insightsで見るとちゃんとログがでています

設定を変更しながら試してみる

Portalで設定変更
Functions再起動 (設定変更時に聞かれるので)
間髪入れずに20個くらいQueueに入れる

をSETTING=1から順番に試してみます

設定が反映されない？

SETTINGを 2 -> 3 にして再起動した後試したところこうなりました

f:id:puni-o:20210326161912j:plain

ログは時刻で降順で、上のスクショでは一番下と下から二番目の間に設定変更と再起動が入っています

一つ目のログは3が出ていて予想通りだったのですが、その上が2となっていて変更前の値をログに出しています

ずっと変更前の値というわけではなく、しばらくすると3が出るようになります

f:id:puni-o:20210326162215j:plain

まとめ

ということで Functionsの構成で指定したアプリケーション設定は再起動したからと言って即時反映されるわけではないようです。多分設定をキャッシュしているのかな？(調べる元気はないです

接続文字列的なの変えて再起動して確認したのにちゃんと変わっていない？とか思ったら少し待つといいと思います

今は Azure App Configurationを使う(のかな？)ので関係ないのかもしれませんけど

docs.microsoft.com

2021-03-18

ユピテルスイング練習機用 iOS/Androidアプリを更新しました

f:id:puni-o:20210318094308j:plain

更新は気が向いたときに少しやっていたのですが、今回はAppleさんにリジェクト食らったのでその辺を殴り書き

どういうアプリなのか、というのはこちらに書いてあります

puni-o.hatenablog.com

ざっくり書くとゴルフ用の俺用アプリを作った、って感じ

リリースしてから1.5年、使っているのは私だけだと思っていたのですがほかにも使ってくれている人が判明！使い続けてくれているのかは不明

ということで今回はランキングページを追加しました。ついでiOS版にはビデオ録画にリアルタイムエフェクトを入れて遊んだりもしました

ストアへ公開

Androidの方はサクッと完了です。アプリの更新時は多分ソフトで自動でチェックしてそのまま公開なんだとおもいます

iOS版リジェクト

iOS版も同じだと思っていたら

f:id:puni-o:20210318100733j:plain

リジェクトきました

リジェクトの理由

Guideline 5.2.1 - Legal - Intellectual Property

いろいろな人がこれにひっかかっているのでググるとほっこりします

私の場合は

ユピテルって入っているけど公式じゃないでしょ？ユピテルから訴えられたらどーすんの？ちゃんと公式からOKもらって。もしくはアプリと説明文からその辺消して (超意訳)

ということらしいっす。アプリの説明には最初から公式じゃないよって書いてあるんですけどね (ページトップ絵)。スマホの契約よりはわかりやすい注意書きだとおもったんだけど、これではダメみたいでした

対策

私の打てる手は3つです

公式のお墨付きをもらう

めんどう

実はアプリを作る前にサポートに「スマホアプリもっと使いやすくしないの？しないならBLEの通信仕様公開してみんなに作ってもらおうよ。作るよ？」的なメール送ったのですが、定型の自動返信すらありませんでした。ユピテル的にはゴルフ関係はハード売って終わり、なスタンスなんだろうなーという印象だったので、お墨付きもらうのはハードル高すぎです

公開やめる

めんどう

iPhoneに入れたアプリはTestFlightでも最長で90日間しか動かないので、90日に1回はTestFlightに新しいパッケージを上げないと突然使えなくなるのですごく面倒です。絶対更新忘れて使いたいときに起動できません (それが嫌でストアに公開したわけですし

説明文を変える

結局これしかないのですが、これも問題があります

日本のゴルフ人口が 19年現在で550万人 (ググった)
そのうち真面目に練習する人が2% (勘)
練習する人のうちユピテルのGST7-BLEを持っている人が0.1% (勘)
練習してGST7-BLEを持っている人のうちiPhoneユーザーが60%
練習してGST7-BLEを持っているiPhoneユーザーのうちデータを収集したい人が10% (勘)
練習してGST7-BLEを持っているiPhoneユーザーでデータを収集したい人のうち公式以外のアプリをApp Storeで探そうと思う人が10% (勘)

とすると、

5,500,000 × 0.02 × 0.001 × 0.6 × 0.1 × 0.1 = 0.66 人

このたった0.66人の人にリーチできるような説明文にはどうしても「ユピテル」「GST7-BLE」は必要です。必須です。これ以外のどんな単語で検索するんだよ。こんなのBotが定期巡回で見にくるだけだよ

とはいうもののどうしようもないですし、もともと俺用アプリですし、アプリの説明文変えて再提出して無事に公開されました

さいごに

GST7-BLEを持っているというレアな方は一度使ってみていただけないでしょうか・・

落ちもまとめもないですよ

2021-01-14

WPF ( .NET 5 ) でWindows Runtime API を呼ぶのは超簡単だった

C# WPF .NET

昨日のやつ

WPF ( .NET 5 ) でWindows Runtime API を呼ぶ、前にしなければいけないこと - プログラムの事とか

は大嘘でした、ごめんなさい、この方法ではAPIを呼び出そうとすると何らかのビルドエラーが発生しますね、その先に進めませんね

反省はするけど次回に生かせる可能性は低いです

ということで 2021/01/14現在で最新の環境で .NET 5 WPFでWindows Runtime APIを呼ぶ方法を改めて

プロジェクトファイルの編集

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0-windows10.0.19041.0</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

</Project>