Webカメラを買った
WEBカメラが大変老朽化したことに伴い時折認識しなかったり、色が著しくおかしくなったりするので買い換えることとした。
エレコム WEBカメラ 会議用カメラ マイク内蔵 200万画素 高解像度Full HD1920×1080ピクセル対応 オートフォーカス カメラシャッター付 ブラック WEBCAM-101BK
- 発売日: 2020/06/19
- メディア: Camera
で、買ったのはこちらのもの。
ELECOMの業務用モデルで保証もなにもなし。
元箱も段ボールに入ってるだけの簡素なもの。
しかし、Windows10の標準ドライバで問題なく動作し画質なども特に問題も感じないので問題はない。
YAMAHA AG03を購入してみた
今までの、Roland Tri-Captureに代わってYAMAHA AG03を購入しました。
まず、Tri-Captureを購入してから大分たっている。
記録によれば８年前の話だ。おかげで物理的な音量つまみが調子悪くなってきている。また、モニターアウトがとても悪くなっていた。
また、機能面でも昨今ではWeb会議が盛んであるがこれにも対応しているとは言いにくい。手軽なヘッドセットを刺すようなインタフェースがないのである。
そこで、別立てでBluetoothなんかでヘッドセットを用意するのだがこれだとTeamsにおいてデスクトップの音声共有が不可能になってしまう。
ヘッドセットのサウンドデバイスと実際にメインで使っているTri-Captureとではデバイスが異なるので設定ができないのである。
ヘッドセットとデスクトップの再生デバイスを同じデバイスに集約させたい。
それでいて、いままでやってきたループバックモードを備えたサウンドデバイスがあるものってことで、YAMAHA AG03がよいのではないかと思ったのです。
で、実際少し使ってみて思いがけずよかったのが、モニターアウトがスピーカーアウト、ヘッドフォンアウトそれぞれ独立して音量つまみがついていて調整できるということ。
スピーカーの音量を手元で操作できるというのは便利ですね。
また、通常のボーカルマイクでも音量いっぱい上げてコンプ効かせてあげれば十分な音量を確保できるということ。なかなか、この手のインターフェースだと通常の話し声程度の音量だと小さすぎるっていうのがあったのでこれもよい誤算でした。
というわけで、Web会議やらウェビナーなんかにおすすめ機材ですね。
もちろん、ハードウェアありのソフトウェアもありのDTMerというセグメントにもぴったり。
その両方とも使うよっていうのにまさにうってつけなんじゃないかなと思います。
ロギングについて
ぜひ１記事書いてください
— 高見知英 (@TakamiChie) 2020年11月2日
というわけで書く。
1、本当にエラーメッセージやらロギングの粒度がダメでエラーの本質がわからないパターン。
— くさば (@tomo_kusaba) 2020年11月2日
これにならないためにはどうしたらよいかについて。
ぶっちゃけ、Azure Application Insightsを使えるのならそれを使うのが一番よい。
不足なくログ取得が行えるし何よりもログ取得のためのコードをロジックのそこかしこにちりばめる必要がない。
あとで、ここのログが必要だったのにログ取得のコードが入ってなかったみたいなことがないのでよい。
以上の言語で記述されたアプリケーションで
以上の環境にホストされたものであれば検討Application Insightsの使用を検討すべきだと思う。
さて、ここからが本題になると思うのだが、諸般の都合でApplication InsightsやらCloud Watchなどのクラウドによるロギングができない場合は伝統的なロギングツールに頼ることが必要になると思う。
すなわち、.NETでいえば、log4netのような、Javaでいえばlog4jのようなツールである。
具体的なツールの使い方についてはここでは触れないがいずれもプロジェクトにツールを組み込み出力項目を設定ファイルなどで設定して実際のプログラムのなかでログを吐き出したい場所でログ出力メソッドを実行するものである。
log4net,log4jともに標準では同期実行しかサポートされていないのであまりに大量のログを出力しようとするとアプリケーションのパフォーマンスに影響がかなり出ることに注意が必要である。
出力項目について
- 日付・時刻情報
- 発生クラス・メソッド
- ログインID
- アクセス元IPアドレス
- ログ種別
- メッセージ情報
以上は最低限出力するようにしましょう。（Log4netのデフォルト＋α）他に、バッチでは、処理予定件数、処理実績件数なんかも出力して差異がないかログ出力させてもよいかもしれません。
ログインID、アクセス元IPアドレスはポリシーによりけりかなとも思います。
クラウドを使用できないWebアプリケーションというのは大抵イントラにある社内アプリなのでこういった情報をロギングするのには問題が少ないのではないかと思っています。
ログを取るタイミングについて
原則、メソッドの開始・終了時
開始時には引数を出力するとよい。
終了時には戻り値を出力するとよい。
但し、ループ内で呼ばれることが想定されるメソッドについては考慮が必要。→大量にログ出力されるとパフォーマンスに影響。
また、本当に意味があるログなのかを見極める。
ループ内で落ちたとき、例外メッセージやスタックトレースでエラー本質を見極めることができるかどうか検討など。
また、例外発生時には例外のメッセージ及びスタックトレースが出力されるようにしておくことが重要。
例外発生時のスタックトレース情報がないと何も問題がわからないのでこれは困ったことになります。例外が発生しうる箇所は必ず一旦Cacheしておくのがよいのかなと思います。
そこから、エラーハンドリングの都合によってはまた呼び出し元にスローしてみたりそこでちゃんとエラー処理したりってことを考えていけばよろしいのかなと。
おそらく、これだけのログが出力されていれば何か起きたときに何が起きたのか全くわからないということはないのでしょうか？？
