以前このブログの生成のためにお手製の静的サイトジェネレーターを作ったという話をしました。

oEmbedにも対応させて最低限自分が欲しい機能を載せたものの、oEmbedの処理の都合上ページ単位で情報を取得する必要があるため、oEmbed処理するページが増えるほどHTML生成に時間がかかるというジレンマがありました。
oEmbed処理がなければ数秒で生成されるだけにちょっとこの時間がもったいない。というわけでキャッシュ処理を追加したのですが、せっかくコードをいじるのだからということでリファクタリングすると同時に dotnet tools対応などを行ってみました。

前回自宅キッチンのシンク下を修繕した話を投稿したのですが、このブログをホスティングしているAzure Static WebAppsにデプロイしようとしたところ、エラーが出てしまいました。

エラーを確認したところ、デプロイ可能なサイズを超過しているとのこと。
Azure Static WebAppsは250MBまでをサポートしており、写真を載せる際にウェブ用に圧縮せずにいたので超過した模様。

とりあえず手作業で画像を圧縮することで取り急ぎブログ記事の公開をすることができたのですが、いちいち画像サイズを気にして置くのも面倒くさい。

ウェブサイト構築中にちょっとはまったのでメモ。

Formタグの中にSubmitを行うボタンをおけない場合、 input="submit" のボタンをFormタグ内にhidden状態で記載し、Formの外のボタンを置きたい場所にラベルタグとfor属性を利用してボタンを設けるという方法がありますが、これだとEnter押下時にSubmitが走ってしまうという問題があったため、 HTMLFormElement.submit()を利用して回避。

ただ、これはMDNにも記載されている通りsubmitイベントが発生せず、制約検証も行われない問題が。

HTMLFormElement.reportValidity()

HTML5.1から HTMLFormElement.reportValidity() という制約検証を行うための機能が追加されてた模様。知らなかった・・・。

これを HTMLFormElement.submit() 実行前に呼び出して結果が true だった場合にだけsubmit処理させるようにしてやればOK。

reportValidity() はエラーが存在する場合、required などの制約検証に対するメッセージが該当のフォーム要素に表示されるそう。

似たようなもので checkValidity() があり、こちらは制約検証結果をtrueかfalseかで返すだけ。エラーメッセージは表示されないので、独自にメッセージを調整したい場合などには有用。

セルフランナーでの挙動なので通常環境で起きるかどうか検証してないのですが、とりあえずメモとして。

とある案件でNuGetパッケージが更新されず、GitHub上のリポジトリは更新されているライブラリを利用するため、Submoduleを利用してました。
最近NuGetパッケージも更新されるようになり、Submoduleを利用する必要性が薄れたため、Submoduleを削除してNuGetパッケージを利用するプルリクエストを作成し、メインブランチにマージを行いました。

このメインブランチに反映したものを別のブランチにもマージしてプッシュしたところ、下記のエラーが。

GitHub Actionsのワークフローでは、actions/checkout@v2 の処理中にSubmoduleの処理をしているのですが、ここでなぜか削除したはずのライブラリの取得でエラーになってる様子。

    steps:
    - uses: actions/checkout@v2
      with:
        submodules: recursive

セルフランナーのワーキングディレクトリを消してもらったりしてもうまくいかなかったのですが、最終的にメインブランチからマージして取得せず、rebaseする形で取り込むと問題なく動きました。
Submoduleの削除で.gitmoduleからライブラリのプロジェクト参照を消していたとしても、そのブランチのもととなる位置の段階でSubmoduleを参照している場合エラーとなる？

たまに使おうと思って度忘れしているのでメモ。

業務アプリで利用しているSDKを更新していてはまったので覚書。

タイトルがすべて。

Azure Functions v2がEOLとなり、FUNCTIONS_EXTENSION_VERSION の値を ~2.0 としていたアプリがありました。
当然EOL状態を放置することはできないため、v3に対応する修正を実施し、開発環境では正常に動くことを確認。
本番に向けステージング環境にデプロイ後、FUNCTIONS_EXTENSION_VERSION の値を ~3 に変更したうえでスワップを実施しました。

が、ここで本番環境でエラーが発生することが発覚し、急遽再スワップを実施して戻すことに。

この記事で作っていたMQTTHomeClient。
MQTT Brokerから受け取ったTopicから処理を分岐させるんですが、ここで呼び出すWakeOnLANの処理をプロジェクト内で実装しています。
どうせ私しか使わないんでべたべた書いてもいいんですが、勉強がてらMQTTのクライアントの機能拡張をDLL追加でできるように改良してみました。

まぁ参考サイトのコードをコピペｹﾞﾌﾝｹﾞﾌﾝ採用させてもらって、WakeOnLANの処理を外部プロジェクトのクラスライブラリ側に寄せただけです。

Interfaceを定義してやって、DLL側とプログラム側でInterfaceに沿った処理を突っ込むだけなので、割と簡単に実装できますね。いやまぁInterfaceの設計が多分一番大変なんでしょうけども。バージョンアップごとに変わっていったらプラグインの追従が死ぬので。

参考サイト

家で仕事をしているのですが、普段寝る前にはパソコンの電源を落としています。
朝起きて身支度をして、仕事部屋に行ってからパソコンの電源を入れて・・・よりはデスクの前に来た段階で電源が入っていてほしい。

というわけで、朝起きたときに枕もとのGoogle Assistantに「パソコン付けて」というだけで電源が入るようにしました。

個人的に作ってるアプリで必要だったので調べた成果。

MQTT BrokerはBeebottleを想定しつつ、一応汎用的に動くはず。

Beebottleの場合、アカウントIDにトークンを指定してください。

内部的にはMQTTのライブラリとして MQTTnet を使用しています。