コンデンサマイクを購入しました

在宅勤務が長引き Web 会議にもなれてきた頃、１日の会議の数が増加してきました。 これまでイヤフォン型のマイクを使ってたのですが会議が長時間に渡ると耳が痛くなるのでコンデンサマイクを購入しました。

購入したもの

購入したのはこちら↓↓↓

【Amazon限定ブランド】888M マランツプロ USBコンデンサーマイク 在宅勤務 生放送・録音・ポッドキャスト MPM1000U

これを選択した理由としてはこちら。

• レビュー数が多く、Amazon 以外のレビューがそれなりにある
• デバイスの相性不一致で失敗してもギリ妥協できる金額

開封の儀

また、合わせてポップガードとマイクスタンドを購入しました。

KC グースネック 卓上マイクスタンド 固定型 ブラック MDS-4/BK

GRANPRO ポップガード ポップブロッカー マイクフィルタ ノイズ防止

設置してみた

設置するとこのように。

今回購入したマイクスタンドは MDS-4/BK という蛇腹型のものになっており、折りたたみ式と比較して短い反面、かなり自由に曲げることが可能です。 私のデスクでは大型モニタを使っているため、折りたたみ式スタンドではちょっと邪魔になるかも？と思い、このスタンドにしたのです。

おかげでこのようにモニタの下部からマイクを通すことができました。

使用感

よく使用するコミュニケーションツールは Microsoft Teams と Zoom ですが、どちらも使う分には全く問題ありません。 相手にどのように聞こえているかまではわからないですが、声が小さく聞こえたりこもったりということはないようです。 また、毎日 USB を抜き差ししていますが特に接触不良なども起きてません。

全体的にとても満足な結果となっています。

管理

コンデンサマイクは精密機械なので管理方法どうしたら良いのかな～、とググってたら本来はデジケーターを使うようです。 が、流石にそこまでお金は掛けられないのでもうちょっと簡易な方法を取りました。

CanDo で見つけたポーチにマイクを入れて、ダイソーで見つけたパスタケースにポーチごと入れてます。 また、湿気対策としてシリカゲルも一緒に入れてます。

乾燥剤 シリカゲル 日常に使える便利な除湿剤（シリカゲル5g×30個）チャック■SA5g 30個チ■

唯一面倒なのは業務開始前にマイクを接続して、業務終了後に切断・ケースに戻す作業でしょうか。まぁ、仕方ないと割り切っています。

---

在宅勤務用にコンデンサマイクをお探しの方はご参考にしてみてください。

Azure DevOps拡張機能で自作アプリを呼び出せるかどうか試してみた

Azure DevOps 拡張機能は PowerShell を使用して開発することができますが、ちょっと PowerShell 力が足りないときに .NET 使いたいなーと思うことがありました。 しかし、リファレンス上では .NET アプリを使う方法については記載されていません。なので、未対応なのかと思いましたが「ひょっとして、PowerShell から自作した .NET アプリを呼び出すことができるのではないか？」と思い、少し試すことにしました。

結論

結論から言うと「制限はあるものの Azure DevOps の拡張機能で自作アプリ（アセンブリ）を呼び出すことは可能」でした。 制限については後ほど説明します。 また、今回は Azure Pipelines タスクの拡張機能として作成しています。 もしかすると Web ページを表示するようなタイプの拡張機能だと、この方法では実現できない可能性はあります（未検証）。

開発環境

• Visual Studio Code
• C# / .NET Core 3.1
• PowerShell

自作アプリは .NET Core 3.1 で作成したコンソールアプリです。 このコンソールアプリを PowerShell で呼び出すような想定で作りました。

フォルダ構成

今回のフォルダ構成は細かいファイル配置は省いて次のようになっています。

/CallDotNetExample
│  .gitignore
│  package-lock.json
│  package.json
│  vss-extension.json
│  
├─console
│  │  console.csproj
│  └  Program.cs
│                      
└─src
    │  Startup.ps1
    │  task.json
    │  
    ├─dotnet
    │      console.exe
    │      console.pdb
    │      
    ├─node_modules
    │      
    │          
    └─ps_modules
        └─VstsTaskSdk

重要なのはconsole/Program.cs, src/Starup.ps1, dotnetフォルダです。

console/Program.csは、自作したコンソールアプリです。src/Startup.ps1から呼び出されることを想定しています。 src/Startup.ps1は、自作したコンソールアプリを呼び出します。この PowerShell は、Azure DevOps 拡張機能が実行された際に最初に呼ばれるエントリポイントです。 dotnetフォルダは、ビルドした自作コンソールアプリの出力先フォルダです。src/Startup.ps1は、このフォルダ配下にあるアセンブリを実行するようにしています。

実装したコード

それぞれのコードは以下のようになっています。

using System;

namespace console
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                Console.WriteLine("Hello World from dotnet console app!");
                System.IO.File.WriteAllText(System.IO.Path.Combine(Environment.CurrentDirectory, "example.txt"), "Hello World from dotnet console app!");
            }
            catch (System.Exception e)
            {
                Console.WriteLine(e.Message);
            }
        }
    }
}

[CmdletBinding()]
param()

try {
    $samplestring = Get-VstsInput -Name "samplestring"

    Write-Host "Hello world from Starup.ps1."

    Start-Process -FilePath "${PSScriptRoot}\dotnet\console.exe" -Wait -NoNewWindow
    
} finally {
    Trace-VstsLeavingInvocation $MyInvocation
}

Start-Processで-Waitにしているのは、自作コンソールアプリを呼び出したあとに処理を待つため。 そして、-NoNewWindowにしないとコンソール出力の結果が Azure Pipelines のログに出力されないためです。

実行結果

これを実行すると次のようになりました。 期待したとおり、PowerShell の Hello world と C# の Hello world が出力されています。

制限

今回調査した限りだと次のような制限事項があります。

アップロードサイズ

Azure DevOps 拡張機能ではパッケージしたファイルのサイズに制限があります。 試しに .NET アプリをシングルファイルにしてアップロードしようとしたところ以下のようなメッセージが表示されました。

Upload Error

The extension package size 'XXX bytes' exceeds the maximum package size '26214400 bytes'

なので、アップロード可能なサイズは26.2 MBまで。 Hello world だけのアプリをシングルファイルで生成しても 30 MB 程度はあったので、.NET のシングルファイル生成によるパッケージは不可能です。

また、アップロードファイルのサイズについて、削減する方法をまとめてくれているブログがありました。といってもこっちは正規の方法（Node.js + TypeScript）で作られているようなので、本記事とは関係は薄いです。

levelup.gitconnected.com

環境依存

上記にも関連しますが、シングルファイル生成によるパッケージが不可能ということは、拡張機能で呼び出す .NET アプリが環境に依存してしまうということです。 Azure Pipelines の特性上、Microsoft がホスティングしている環境上で実行される場合は .NET のフレームワークバージョンに制限があります。というより LTS でない古いバージョンは使えません（例えば、現状では .NET Core 3.0 などは Microsoft がホスティングしている環境にはインストールされていない）。 この対策としてシングルファイル生成によるパッケージングができればどの環境でも動作できるのでは？と考えましたが、結果は上記のとおりでした。

他の対策は「常に .NET アプリ側を常に最新バージョンに対応させる」か、「プライベートホストを使って環境を固定する」かでしょうか。 どちらが良いかはプロダクトによるでしょうが、いずれにしろコストは掛かります。 このコストと C# / .NET が使えるメリットは考慮しておく必要があります。

検証していないこと

管理者権限で実行する

多分無理ですが、管理者権限でアプリを実行することは検証していません。 うろ覚えですが、たしか Azure DevOps 拡張機能自体、管理者権限では実行されなかったと記憶しているのでアプリ側も同じく不可能かと。

といっても管理者権限で実行したいようなケースは無いとは思いますが。

どこまでの機能が使えるか

少なくとも拡張機能の実行フォルダにファイルを出力することはできます。 しかし、それ以外の機能、例えば HttpClient で Web API を呼び出すなどのようなことが可能かどうかまでは検証できていません。 OSS ライブラリを使う場合、ものによっては Azure DevOps 側で制限がかけられる機能を使っている可能性もゼロではありません。 アプリによってはここがボトルネックになることが多いでしょうから予め検証は必要です。

まとめ

実現可能とはいえ、普通なら PowerShell でいいじゃんと多くの人が思うでしょうから、あまりにもニッチな需要かもしれません。 制限事項もあるので使い所も難しいケースもあるでしょう。 それでも使い慣れた言語が使えるというのはそれ単体では絶大なメリットだと思うので、どうしても…という場合には選択肢に追加しても良さそうです。

Azure Functionsで自作したカスタムコネクタをPower Automateで使おうとしたらハマった事象と原因と回避策について

随分とタイトルの示す範囲が大きくなりましたが、そういうことです。

やろうとしていたことは「Azure Functionsで作成した関数アプリをPower Automateで使う」という至ってシンプルなものでした。 しかし、いざ実践してみると期待した通りに動作しなかったため、しばらく悩み続けてなんとか解消した話です。

事象

Azure Functionsで作成した関数アプリをカスタムコネクタを使って呼び出すようにしました。 新規にフローを作成してカスタムコネクタのアクションを実行すると失敗し、次のようなメッセージが表示されました。

ResponseSwaggerSchemaValidationFailure. API 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' が、種類 'OpenApiConnection' のワークフロー操作 '<API名>' について無効な応答を返しました。エラーの詳細: 'API 操作 '<API名>' では、プロパティ 'body' の種類を 'Object' にする必要がありますが、種類が 'String' です。'

内容的には json の応答を Object から String にしろと言うことのようです。

---

2020/11/16 追記 （コメント頂きましたので修正）

内容的にはカスタムコネクタでは Object が来る想定だったけど String が来たよ、ということのようです。

---

ちなみにAzure Functionsでは、作成した関数の応答は json で返していました。

ただし、この現象が発生するのは実際のフローのみで、カスタムコネクタの[テスト]タブで実行した場合や、HTTP アクションで同じ URL 呼び出しを行っても同じ現象は発生しませんでした。

似たような事象が発生していないか Power Automate で探したところ、ドンピシャなスレッドがありました。が、質問した方はカスタムコネクタを修正して対応したようです。（良いのかな…）

Error in Power Automate Flow When Using Custom Connector -requires the property 'body' to be of type 'String' but is of type 'Object'

原因

色々試した結果、原因はAzure Functions側にあることがわかりました。 応答する際に json にシリアライズしたのは良いのですが、json 文字列を body に設定してしまっていました。

はい、つまり完全に私のしょーもないミスが原因ですね。

具体的には次のようなコードになっていました。

[FunctionName("function")]
public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req, ILogger log)
{
    ...省略
    var json = Newtonsoft.Json.JsonConvert.SerializeObject(result, _settings);

    return new OkObjectResult(json);
}

このまま関数を呼び出すと応答結果のContent-Typeは、text/plainになってしまいます。 要はこれをapplication/jsonにすれば良いわけですね。

対策

今回のケースでは応答は json で返し、シリアライズする際の書式設定はNewtonsoft.Json.JsonSerializerSettingsで設定していたため、Microsoft.AspNetCore.Mvc.JsonResultで応答する手法を取りました。 この方法にたどり着くまでに twitter 上でしばてぃさん(@shibatea365)に何度もアドバイスいただきました。感謝の極みです😂

さて、変更後のコードはこのようになります。

[FunctionName("function")]
public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req, ILogger log)
{
    ...省略
    return new JsonResult(response, _settings);
}

なお、JsonResultを使う場合はMicrosoft.AspNetCore.Mvc.NewtonsoftJsonパッケージを追加する必要があります。 また、csprojファイルに<FrameworkReference Include="Microsoft.AspNetCore.App" />を追加しないと以下のような事象が発生するそうなのでご注意を。

MethodNotFound when trying to call JsonResult ctor with JsonSerializerSettings #1907

これを実行するとContent-Typeはapplication/jsonになり、Power Autoamte のフローも成功します。

最後に

本当にしょうもなことが原因で何日もハマってしまいました… Azure Functionsについてはまだまだ初学者であったとは言え、今回のような事象はユニットテストでレスポンス ヘッダーまでテストして入れば検知できたはずです（やってませんでした！）。 ちょっと手を抜いた結果がこれです。 手を抜くの絶対ダメ！！！

（生活）スマートホーム デバイスで生活が快適になりました

先日の Amazon プライムデーセールで Alexa とスマートホーム デバイスを購入したのですが、あまりに便利だったので紹介します。

購入したもの

【Amazon App-to-App対応 Alexa認定】シンプルスマートリモコン EZCON (日本発ブランド・今ある家電をスマホで操作

【Amazon Alexa認定】ゴウサンド(Gosund) スマートプラグ Wi-Fiスマートコンセント コンセントタイマー 遠隔操作 Alexa/Google Home/Echo 対応 音声コントロール ハブ不要 1個

FREDI スマート電源タップ WIFI接続スマートプラグ 遠隔操作可能 USB電源タップ 雷ガード 省エネ電源プラグ 一括スイッチ付き 4+2(ACコンセント4個口+USBポート2個口) コ一ド長2m 合記1400Wまで 【Echo/Alexa/Google Homeに対応】

EZCON は Amazon Alexa とセットで購入しました。 また、余談ですが FREDI スマート電源タップ は2020年11月1日まで50%OFFクーポンがあります。クーポンコード「DEN102013」（早期終了するかも）。

私の家にはすでに Google Home が２台あったのですが、新たに Alexa が追加されました。

EZCON は Alexa から操作できますが、Google Home には対応していないため操作できません。 Gosund スマートプラグ Wi-Fiスマートコンセント と FREDI スマート電源タップ は Alexa と Google Home どちらでも操作できます（というよりもアプリの Smart Life が対応している）。

EZCONの設定方法

事前に EZCON アプリをインストールしておきましょう。

EZCON

• LinkJapan Inc.
• ライフスタイル
• 無料
• 

apps.apple.com

とても簡単です。が、いちいち文章で説明するよりもこちらの動画を見るほうが良いでしょう。 例えば証明のリモコンを登録するような場合はこの動画のように設定します。

play.google.com

照明の登録方法

一つ注意が必要なのが EZCON が Wi-Fi の 2.4GHz にしか対応していないことです。 5GHz では使えないので事前に確認する必要があります。

スマートプラグ／スマート電源タップの設定方法

こちらは Smart Life アプリから設定します。

Smart Life - Smart Living

• Yu xiang
• ライフスタイル
• 無料
• 

apps.apple.com

play.google.com

接続する機器によって設定方法が若干異なるのですが、付属の取扱説明書を読めばOKです。 また、FREDI スマート電源タップ は１口づつ ON/OFF を切り替えられるため、例えばヒーターやサーキュレータを別々の口に接続しておいて独立して切り替えが可能となっています。 これがめちゃくちゃ便利！

スマートフォンからリモコンとして使う

EZCON

EZCON アプリは設定が完了するとこんな感じになります。 部屋ごとにタブが別れていて登録デバイスを一覧で見ることができます。

スマートタブでは音声認識やタイマーによる自動設定も可能になっています。

Smart Life

Smart Life も EZCON と同じようにデバイスの一覧が表示されます。 EZCON との違いとして"ワンクリック実行"というものがあります。 これは特定のデバイス制御を一括で実行できる機能で、一度設定すればプラグに接続したヒーターを付けたり、すべてのプラグを OFF にしたりといったことが可能です。

こちらはスマート プラグの画面です。シンプルに ON/OFF のみです。

このスマート プラグを使うまで知らなかったのですが、使用電力量を計測してくれる機能もあります。 ↓↓↓こんな感じで現在使用している電力量と合計量を見ることができます。

これを利用したら家中のコンセントにスマートプラグを接続して使用電力量の可視化もできそうですね。

こちらはスマート電源タップの画面です。 電源タップはすべての電源を一括で ON/OFF するボタンとそれぞれの口ごとに ON/OFF 切り替えることができます。 ボタン名はデフォルトでは"スイッチn"ですが、これはタップして別名に変更することができます。 私の場合は下２つをサーキュレーターとヒータに割り当てています。

１点残念部分として電源タップ側には電力使用量を計測する仕組みはありません。 スマートプラグが¥1,600ほど、電源タップが¥4,000ほどと考えるとあってほしい機能ですが…

スマートスピーカーと連携して使う

Google Home と Alexa でそれぞれアプリで連携できるようにしました。

Google Homeアプリ

Google Home アプリはスマートスピーカーや Chrome Cat もまとめて確認できます。 数が多くなってくるとごちゃごちゃしそうなので、アイコンや色を変えたりとかできるといいですがそうはなっていません。

ルーティンで特定のフレーズからデバイスを操作できるようにしておけば、帰宅時や外出時にまとめてデバイスを制御することができます。

Alexa

Alexa は最初に部屋（グループ）を選択するため Google Home と違ってシンプルです。 ただし、１タップ分の操作が増えるのと、この時点では何のデバイスがどこの部屋にあるのかは分かりません。新しくデバイスを追加したときとか、家族で共有するときとかは戸惑うかも？

Alexa も Google Home と同じく、特定フレーズからデバイス制御が可能です。 Google Home との違いは Alexa だと EZCON も操作できる、というところです。

スマートスピーカーが２種類あるので、両方に同じフレーズで同じデバイスを操作できるようにしました。 個人的には Google Home の方が好きなのですが、ここは妥協しています…。

生活シーンで使う

我が家では今年娘が誕生して毎日育児に追われているのですが、このスマートホーム デバイスが大変役に立ちます。

例えば外出するときはどうしてもやることが多くてバタバタしますが、「Alexa、いってきます」というだけで家中の各種家電が一斉に OFF になります。 エアコンや照明など、リモコンが複数あるとどうしても置き場所を探しますが、音声による操作なら抱っこひもを使った場合でもベビーカーの場合でも大変楽です。 他にも、これからの季節はヒーターやホットカーペットを使う家庭もあるでしょうし、そういったところにスマートホーム デバイスがあれば、まとめて切り替えができるので使い勝手が良さそうですね。

あとは帰宅時に前もって電源を ON にすることで、寒い日でも帰宅直後からエアコンで十分に温まった部屋で過ごすことなどもできます。

そして、個人的に最も使ってよかったところが-子供をあやして寝かしつけたあと、照明を OFF にするのですが、アプリから操作することによってリモコンを探す手間などが省けます。 また、スマホが手元になかったり抱っこしているときなどはスマートスピーカーから操作することもできます。 フレーズを登録しておいて、照明の OFF と同時に安眠できるような音楽を再生するのもいいでしょう。 リビングでくつろいでいるときに子供が起きたりしたらすぐさま駆けつけることになりますが、別の部屋にいてもつけっぱなしにしていたヒーターを OFF にしたりすることもできます。

まだ使ったことは無いのですが、Smart Life だと気温の変化や GPS で特定の場所に移動したことをトリガーとしてデバイスの制御が可能になっていたりもします。 寒くなってきたら暖房、熱くなってきたら冷房を着けるといった具合です。

こういった機能をうまく使えば今以上に生活が楽になりそうですね。

他のスマートホームデバイスの選択肢

スマートホーム デバイスと言ってもその種類はそこそこあります。 パッと見はそれぞれの差異が分かりづらいのですが、特に注意したいのが「デバイスの制御に使用するアプリ」と「連動可能なスマートスピーカー」です。

上記でもすでに紹介していますが、リモコンとプラグで操作するためのアプリは異なります。 私が調べた限りですが、プラグもメーカーによって使えるアプリが異なる場合があります。 例えば Meross というメーカーでは同じく Meross というアプリでしか操作できません。

せっかく家電をまとめて操作できるようになったのにアプリを複数使用するのでは本末転倒になってしまいます。 使うアプリの種類はせいぜい２種類が限度でしょう。 デバイス購入の前に口コミなどから利用可能なアプリを調べておくのが良いでしょう。

次に連動可能なスマートスピーカーですが、上記の EZCON なんかがそうです。 こちらのリモコンは Alexa とのセット販売＆タイムセールによる大幅割引だったので、Google Home と連携できなくても妥協できますが、リモコンも決して安くはないです（定価 ¥3,980 くらい）。 EZCON はまだ Nature なんかの高性能リモコンよりも安価ですが、それでも手持ちのスマートスピーカーと連携できなくて困る可能性もあります。

スマートスピーカーとの連携は必要だ！という方はこのあたりも注意しないといけません。

---

使ってみると想像以上にできることが多くて最初は戸惑いますが、これは一度経験したら手放せなくなるタイプの UX です。 スマートホーム デバイスは他にも多種多様なものがあるので、自宅に適したものを探してみてください。 （個人的には LED 電球とか気になりますね…これ使って子供と遊べそうですし、ナイトライト代わりにもなりそう。）

（Power Automate）OData フィルタで日時を指定する方法について

先日、Power Automate で OData のフィルタを指定する際に日時を条件に設定する必要がありましたが、その指定方法にハマったのでメモしておきます。

ちなみに OData は Microsoft Graph API の操作を行うためのクエリ言語です。

docs.microsoft.com

環境

• SharePoint
• Power Automate

やろうとしたことは「SharePoint のイベントリストに登録したデータから特定の期間のデータを取得する」というものです。

例えば以下のようなイベントが登録されているものとします。

ここから、2020年10月10日～2020年10月12日までのイベントを取得するイメージです。

まずはフローを実行する

イベントを取得する場合は SharePoint の"複数の項目の取得"から取得します。 なお、イベントはリスト名の候補には出てこないのでカスタム入力する必要があります。

問題はこの"フィルター クエリ"の箇所です。 まずは、フィルター クエリを指定せずに実行した結果の JSON を見てみましょう（不要な部分は省略しています）。

{
   "statusCode":200,
   "headers":{
        //省略
   },
   "body":{
      "value":[
         {
            "@odata.etag":"\"1\"",
            "ItemInternalId":"2",
            "ID":2,
            "Title":"テスト10月10日",
            "EventDate":"2020-10-10T00:00:00Z",
            "EndDate":"2020-10-10T23:59:00Z",
            "EventType":0,
            "Modified":"2020-10-10T07:08:30Z",
            "Created":"2020-10-10T07:08:30Z",
            // 省略
         },
         {
            "@odata.etag":"\"1\"",
            "ItemInternalId":"3",
            "ID":3,
            "Title":"Test記念日",
            "EventDate":"2020-10-12T00:00:00Z",
            "EndDate":"2020-10-12T23:59:00Z",
            "EventType":0,
            "Modified":"2020-10-10T07:09:02Z",
            "Created":"2020-10-10T07:09:02Z",
            // 省略
      ]
   }
}

これを見るとEventDateが開始日時、EndDateが終了日時であることが分かります。 なので、今回の要件を満たすにはフィルター クエリには「2020年10月10日 <= 開始日時 <= 2020年10月12日」を指定すれば良いですね。

ちなみになんでフィルター クエリなのか？というとこっちのほうが実行時間が短いからです（多分）。 例えば、フィルター クエリを指定せずに全データを取得してから Apply to each で必要な期間だけ取得することもできますが、データ量が増えてくるとどうしても時間がかかります。 特に Power Automate は。 この時必要になる時間は（正確には検証していませんが）フィルター クエリを指定したほうが短いです。 Apply to each を使う場合、データを削除しない限りは実行時間が短くなることは無いので、この方法を採用しています。

フィルター クエリを設定する

ドキュメントを見ると次のような論理演算子がサポートされています。

• eq: 等しい
• ne: 等しくない
• lt: より小さい
• gt: より大きい
• le: 以下
• ge: 以上
• and: かつ
• or: または
• in: 含まれる
• not: 否定

上記のフィルター条件を指定する場合、は次のようになります。

EventDate ge 2020-10-10T00:00:00Z and EventDate le 2020-10-12T00:00:00Z

では実行しましょう。

はい。失敗しますね。

エラー詳細には次のようなメッセージが出力されると思います。

式 "EventDate ge 2020-10-10T00:00:00Z and EventDate le 2020-10-12T00:00:00Z" が無効です。 Creating query failed.
clientRequestId: <id>
serviceRequestId: <id>

この問題を修正するには次のようにフィルター クエリを修正します。

EventDate ge '2020-10-10T00:00:00Z' and EventDate le '2020-10-12T00:00:00Z'

変わった箇所は、日時を ' （シングルクォーテーション）でくくっているところです。 これを実行するとフローは成功します。

スケジュールを指定して実行している場合は以下のように変数に日時を保存しておいてフィルターを指定するのが良いと思います。

formatDateTime(variables('FromDateTime'), 'yyyy-MM-ddT00:00:00Z')

---

SharePoint などでリストから特定の情報をフィルタすることはよくあると思います。 日時が含まれるケースは少ないかもしれませんが、そういった場合こそハマりがちなので参考にして頂ければ。