技術関連情報

ラボ環境にサーバ追加して以来しばらく放置していた。やりたい事があり、本日新しいプロジェクトを作成したらエラーが出力された。 npm ERR! ERESOLVE unable to resolve dependency tree npm ERR! npm ERR! While resolving: cli-demo1@0.0.0 npm ERR! Found: jasmine-core@3.7.1 npm ERR! node_modules/jasmine-core npm ERR! dev jasmine-core@"~3.7.0" from the root project npm ERR! npm ERR! Could not resolve dependency: npm ERR! peer jasmine-core@">=3.8" from karma-jasmine-html-reporter@1.7.0 npm ERR! node_modules/karma-jasmine-html-reporter npm ERR! dev karma-jasmine-html-reporter@"^1.5.0" from the root project npm ERR! npm ERR! Fix the upstream dependency conflict, or retry npm ERR! this command with --force, or --legacy-peer-deps npm ERR! to accept an incorrect (and potentially broken) dependency resolution. npm ERR! npm ERR! See /home/bar/.npm/eresolve-report.txt for a full report. package.jsonの下記を修正してnpm installした。エラーは解決したものの、こまごまと変更があったようで調査したいと思っている。日々環境作りをしている訳でもないため、このようなことは往々にして発生するものだ。以前よりは情報収集しやすくなったのは幸いな事だと考えるようにしている。情報を整理できたら少しづつ別のエントリに記載してゆきたい。 "devDependencies": { "@angular-devkit/build-angular": "~12.0.3", "@angular/cli": "~12.0.3", "@angular/compiler-cli": "~12.0.3", "@cypress/schematic": "^1.4.2", "@types/jasmine": "~3.7.0", "@types/node": "^12.11.1", "jasmine-core": "~3.7.0", "karma": "~6.3.0", "karma-chrome-launcher": "~3.1.0", "karma-coverage": "~2.0.3", "karma-jasmine": "~4.0.0", // karma-jasmine-html-reporter: "^1.5.0" "karma-jasmine-html-reporter": "~1.5.0", // ここを修正 "typescript": "~4.2.3", "cypress": "7.7.0" } ラボ環境のバージョン： Angular CLI: 12.0.5 Node: 16.3.0 Package Manager: npm 7.19.1 OS: linux x64 Angular: 12.0.5 ... animations, cli, common, compiler, compiler-cli, core, forms ... platform-browser, platform-browser-dynamic, router Package Version --------------------------------------------------------- @angular-devkit/architect 0.1200.5 @angular-devkit/build-angular 12.0.5 @angular-devkit/core 12.0.5 @angular-devkit/schematics 12.0.5 @schematics/angular 12.0.5 rxjs 6.6.7 typescript 4.2.4 やりたいことをそのままに構成を組むと、ラボ環境がリソース不足に陥るため次の打ち手を考えておきたい。諸々のツールも拡充したいため検討事項がそれなりにあることに気づけたのは本日の収穫だ。

Windowsのイベントログのエントリの対応をする前に、asctimeのフォーマットを修正したくなった。なぜならISO8601のフォーマットに馴染んでいるからだ。 asctimeをそのまま使用すると下記のような出力になる。secとmsecの間にあるカンマに違和感を禁じ得ない。 2021−06−26 00:00:00,123 開発環境： • Python 3.9.2 参考情報： • Python用ロギング機能 • Pythonロギング：時間形式でミリ秒を使用 • ロギングの環境設定 • RFC3339 LogRecordのアトリビュートにmsecsが存在するため、formatを指定しよう。 format: '%(asctime)s.%(msecs)d -%(levelname)s- : %(message)s' すると、ログの出力はこのようになり違和感なく眺められる。 2021-06-26 21:16:31.354 -INFO- MainThread : module:foo.py func:main line:17 all processes completed. これにタイムゾーンを付与したら良いだろう。datefmtで指定出来たはずだ。 datefmt: '%Y-%m-%dT%H:%M:%S%z' ところが結果はこうなる。formatの順序通りだ。異なるアトリビュートを結合したため当然の結果だ。不本意ながらlogging.Formatterをカスタマイズするしか手がなさそうだ。 2021-06-26 22:57:35+0900.582 Googleで検索すると、それなりに情報があった。awareかつJSTにするカスタマイズを施してそのまま流用した。シンプルなクラスだ。 class JSTDateFormatter(logging.Formatter): converter=datetime.fromtimestamp def formatTime(self, record, datefmt=None): jst = timezone(timedelta(hours=+9), 'JST') ct = self.converter(record.created, tz=jst) if datefmt: # %msをmsecに置換する処理 if '%ms' in datefmt: msec = '%03d' % record.msecs datefmt = datefmt.replace('%ms',msec) s = ct.strftime(datefmt) else: # datefmtがNoneの場合の処理 t = ct.strftime('%Y-%m-%dT%H:%M:%S') z = ct.strftime('%z') s = '%s.%03d%s' % (t, record.msecs, z) return s 以前のエントリにあるように、YAMLにloggingのコンフィグレーションを保存している。このためYAMLで上記のクラスをformattersのブロックで指定する場合の例を挙げよう。難しいことではない。 formatters: brief: (): log.JSTDateFormatter # ここがポイント format: '%(asctime)s -%(levelname)s- : %(message)s' datefmt: '%Y-%m-%dT%H:%M:%S.%ms%z' precise: (): log.JSTDateFormatter # ここがポイント format: '%(asctime)s -%(levelname)s- %(threadName)s : %(message)s' datefmt: '%Y-%m-%dT%H:%M:%S.%ms%z' log.JSTDateFormatterはlog.pyというモジュールのJSTDateFormatterを呼び出すという動作を特殊キーである '()' で実現している。呼び出し可能オブジェクトであるクラスを指定すれば素直に動いてくれる。 ちなみに、'%ms' とあるのはmsecに相当するフォーマットストリングがdatefmtになかったためカスタマイズしている。動作を確認しよう。 2021-06-26T23:16:31.353+0900 -INFO- MainThread : module:myapp.py func:__init__ line:16 MyApp completed. 見慣れたISO8601に則った書式だ。 補足するとformatに記載していないモジュール名、関数名、行数がメッセージに含まれるのはsys._getframeで抽出した情報をメッセージへ出力しているからだ。理由はloggingのラッパーのインスタンスメソッド内でログファイルへの出力を行っているため、何も施さずに出力するとラッパーのインスタンスメソッドが書き込んでいるということしか分からないのだ。下記のformatは役に立たないということだ。 format: '%(asctime)s -%(levelname)s- %(threadName)s [LineNo.: %(lineno)s] %(module)s : %(message)s' このためloggingのラッパークラスに含んでいる下記のインスタンスメソッドを、インスタンスを生成した側で実行して情報を収集している。 def get_stackinfo(self,msg:Type[Message]) -> Message: stack_frame = sys._getframe(1) if stack_frame is not None: msg.module = 'module:'+os.path.basename(stack_frame.f_code.co_filename) msg.caller = 'func:'+stack_frame.f_code.co_name msg.line = 'line:'+str(stack_frame.f_lineno) msg.message = ' '.join([msg.module,msg.caller, msg.line,msg.message]) return msg 同じようにモジュール内でロギング用の関数を呼び出してロギングすると似たような事象が発生する。このような事象を紐解いていくことは良い経験になると思われる。幾つかトラブルシューティングに取り組んでいると解決するための方法論が自ずと身に付くからだ。 まとめ： • logging.Formatterのカスタマイズは難しいものではない • 思惑通りの挙動ではない時、まずはマニュアルに目を通そう • 落ち着いてTracebackを読もう

ログの出力先としてイベントログを指定されることもあるため、いつものようにザックリと記載しておこう。他言語でイベントログのお作法を理解していれば、設計での決め事はPythonでも変わらない。関数なりクラスなり用意しておいて使い回すと良いだろう。 開発環境： • Python 3.9.4 参考情報： • Python for Windows Extensions • Report EventW Function • EventLog.WriteEntryメソッド まず、Pythonからイベントログへ書き込むために使用するイベントソースを定め、予め作成しよう。このサンプルではApplicationにPyEventというイベントソースを作成した。イベントソースが存在しない状態で書き込みを行うと下図のようなメッセージが出力されてしまう。 イベントソースを作成する際は、いつもPowerShellを使っている。 New-EventLog -LogName Application -Source PyEvent もちろん、「管理者として実行」しないとアクセス拒否される。エラーは下図のようなものだ。 正常終了は何も出力されない。イベントログの書き込みをしてみよう。まずはPowerShellで確認だ。 Write-EventLog -LogName Application -Source PyEvent -EventID 40001 -EntryType Information -Message 'Write-EventLogのテスト' 下記のコードでイベントログの書き込みを行う。イベントビューアーで確認しよう。 #! coding: SJIS import win32api import win32con import win32evtlog import win32security import win32evtlogutil process_handle = win32api.GetCurrentProcess() token = win32security.OpenProcessToken(process_handle, win32con.TOKEN_READ) security_id = win32security.GetTokenInformation(token, win32security.TokenUser)[0] event_source = "PyEVENT" # 予め用意したイベントソース名に合わせよう event_id = 65535 # 0-65535の範囲で指定可能だ category = 0 # カテゴリはint16 event_type = win32evtlog.EVENTLOG_ERROR_TYPE descr = ['ERROR：テストメッセージ', '詳細：テストメッセージ'] data = "Application\0Data".encode("ascii") win32evtlogutil.ReportEvent(event_source, event_id, \ eventCategory=category, eventType=event_type, strings=descr, \ data=data, sid=security_id) 補足すると、Typeは下記の選択肢が用意されている。 • EVENTLOG_SUCCESS • EVENTLOG_AUDIT_FAILURE • EVENTLOG_AUDIT_SUCCESS • EVENTLOG_ERROR_TYPE • EVENTLOG_INFORMATION_TYPE • EVENTLOG_WARNING_TYPE 下図のようにSyntax Errorに見舞われたら、sample.pyをSJISで保存し直して、ファイルの先頭行に「#! coding: SJIS」を忘れないようにしよう。もちろんUTF-8で統一してもエラー回避可能だ。 Windows OSに配置した場合、心得がない要員が編集する可能性も考慮してSJISにしておいた方が無難ではなかろうか。と、最近感じている。 まとめ： • ひとつの方法論に囚われず、環境に適したアプローチを選択しよう • 文字コードは忘れずに