在勤生活２９２７日目

　powershellの話。昨日の記事でもpowershellの開発について触れていたのですが、
本日ようやく【コツ】が掴めてきた、ような気がします(^^)。本来であればpowershellの統合開発環境であるpowershell iSEを使えばほぼ問題はないんでしょうけど、
正直powershell ISEと大半のスクリーンリーダーとの噛み合わせが良くないこともありorz、このあたりのことでわたくし随分悩んでいたんですけど、
ようやく【これで行こう！】というものが自分なりに固まってきたのかな、と思っている次第。まずコーディングを中心に作業する際は【jaws + powershell ISE】が良いのかなと、結局。
特にpowershellの長いコマンドレットを正確に記述するためには、正直powershell ISE等で働いているインテリジェンスが無いとだいぶしんどいですね、特にpowershellのコード記述に成れるまでは…。
一方、コードをある程度書き上げた後のスクリプトの実行を試す、作成したスクリプトのデバッグについてはエクスプローラからのスクリプト実行、簡単なコードの修正はメモ帳で、というのがスクリーンリーダーとの噛み合わせ、powershell ISEのコンソールパネルの内容をスクリーンリーダーで認識させることが結構しんどいことを考えると、この組み合わせが一番マシなのかな、という結論になり…。
そもそもjawsというスクリーンリーダーはだいぶ動きが重くて、正直なところ会社から支給されている低スペックPCではあんまり動かしたくないんですよね〰すぐ動きが固まるしorz。
ただこの組み合わせがベター、という結論になるのにもいくつか条件があって、特に【①エラーが起きた時に発生するエラーメッセージは必ずtry-catchで捕まえ、ログとしてテキストファイルへ出力させるような体制を構築しておく】というのと、
【②デバッグしたい変数の中身の確認を自身がメインで使っているスクリーンリーダーNVDAでも無理なく確認できるように、該当の変数の内容をログとしてテキストファイルへ容易に出力できるような体制を構築する】というのが絶対条件だと、個人的には考えております。
なのでようやくこの結論に辿り着いたわたくし、①と②については関数化してしまい、他のスクリプトを作る時もコピペで流用できるようにしました。恐らく今後もこの形はたくさん使うことになるでしょうし。
ってここまでしないとある程度まともにスクリプトの作成ができないのだから、さすがにう〰ん、って感じだよなぁ…orz。もっと本格的な、規模の大きいスクリプトを作らなければならないとなったら、
それこそVisual stadio codeの導入を考えないといけないのだろうか…。