表示調整
閉じる
挿絵表示切替ボタン
▼配色
▼行間
▼文字サイズ
▼メニューバー
×閉じる

ブックマークに追加しました

設定
0/400
設定を保存しました
エラーが発生しました
※文字以内
ブックマークを解除しました。

エラーが発生しました。

エラーの原因がわからない場合はヘルプセンターをご確認ください。

ブックマーク機能を使うにはログインしてください。
総合ダンジョン管理術式『Solomon』保守サポート窓口 〜ミミックは家具だって言ってんだろ! マニュアル読め!〜  作者: score


この作品ページにはなろうチアーズプログラム参加に伴う広告が設置されています。詳細はこちら

116/253

115 仕様調査『回復の泉』4


 デバッグログやトレースログといったものは、主にデバッグモードで使う、状況確認のためのログレベルのログだ。


 Solomonにはいくつかのログレベルが存在する。ログレベルとは主にログの重要度を指す指標のことだ。

 例えば、Solomonの動作的に不具合が疑われる場合に確認するエラーログには、『Warning(注意喚起)』『Error(問題発生)』『Critical(重大な問題発生)』『Fatal(致命的な問題発生)』といったログレベルのログが存在する。

 逆に、通常の動作に伴うログとしては『Info(動作の状況報告とか)』レベルのログが存在し、これを追うことでSolomonの動作状況を確認できる。

 これらのログには、基本的に出力された時刻が記載されるため、例えば『Error』以上のログが出力された時刻の『Info』ログを確認すれば、その時刻にSolomonは何をしていたのかを確認できるというわけだ。


 翻って『Debug』ログや『Trace』ログとは、通常Solomonを利用している際には出力されないログレベルのログとなる。

 これらがどういう性質の物かと言えば、その名の通り、主にデバッグ等を行っているときに使うものだ。


 例えばとある機能の術式を起動した時に、通常時では『Info』レベルで『術式の起動』と『術式の終了』だけがログで出力されるとしよう。

 ここで『Debug』ログを有効にしておくと『術式の途中経過』などがログとして出力されるようになり、『Trace』ログまで有効にすれば、更に詳細に『術式に渡している値の情報』といったものまで出力されるようになる。

 この二つは、術式の動作中に何か問題が発生している場合などに、どの時点で予期せぬ動作をしているのか確認するための、デバッグ用のログレベルというわけだ。


 今回の件では、別に問題が発生しているといったことはないが、術式の流れを追うために『術式の途中経過』や『値の情報』なども欲しいので、デバッグモードを起動したらいの一番に有効化したいポイントであった。




「そんな便利な機能あるならもっと早く教えて下さいよ!」


 メガネから、出力されるログレベルの変更方法と同時に、ログの詳細を聞いたドラ子は憤懣やるかたない様子で言った。

 確かに、これらのログは不具合発生時の原因究明のために、便利なものだ。

 特に、顧客側で繰り返し同じ問題が発生するが、こちらで状況の再現ができない場合などに、顧客側でデバッグログやトレースログを有効にして貰うことで、状況の詳細を確認できる場合もあったりする。

 だが、これをドラ子が今まで知らなかったのは、別にいじめられていたとかそういうわけではない。

 もっと単純な理由だ。


「なるほど、つまりこれからはデバッグログが無いと先に進めないような、難しいチケットをどんどんやりたいってことだな、ドラ子?」

「すいません、勘弁してくだしあ」


 ドラ子は日和った。

 ドラ子が今までこれらのログの使い方を知らなかったのは、単純にこれらが無くても回答できるレベルのチケットしか回ってこなかったからであった。

 今回だって、継続する前は単純な仕様調査のレベルであったし、継続したあとも、Solomonの術式を完璧に把握している人間ならデバッグモードを使う必要はないお問い合わせであったわけだし。

 まぁ、Solomonを完璧に把握している人間はまずいないという問題はあるが。


「とりあえず、今日はログレベル変更と、あとはフックの設定方法だけ教えるから、それ以降は明日自分でなんとかしろ」

「そうやってすぐ先輩は私が知らないことを教えようとする」

「どういう文句の言い方なの?」


 ドラ子のやれやれ、といった様子の態度に『こいつ調子でてきたな』と内心イラっとするメガネであった。

 なお、フックの設定とはデバッグモード中に、術式の流れを一旦止めるポイントを設定することである。

 このフックを複数設定することで、ログでも出力されていない更に詳細な値を、その都度術式から直接確認したり、気になる箇所で止めて、そこから1プロセスごとに手動で術式を進行したりするわけだ。


「つまり、単純な流れとしては、デバッグログやトレースログで全体的な術式の推移を確認したあと、起動してる術式のめぼしい所にフックを設定して、あとは回復の泉フラグへの影響をより細かく見る、って感じだな。何か質問は?」


 丁寧にフックの設定方法まで教えた後、メガネはドラ子に尋ねる。

 ドラ子は「ありません」と答えようとして、少し考えた。


 今日の先輩はかなり優しさ寄りである。

 だから、今なら普段はちょっと躊躇するような何かを聞いても、うっかり教えてくれるのではないだろうか。

 いやいや、それよりは優しさに付け込んで、飯を食いたいと言ったらうっかり奢ってくれるのではないだろうか。

 問題に解決の兆しが見えたとあって、ドラ子は持ち前の強心臓を復活させ、そんなことを真剣に悩み始めた。

 控えめに言って人間としてどうかと思うが、ドラ子の精神性は人間のそれを凌駕する。

 貰えるものは貰える時に貰っておけという精神である。


「質問はあるのか?」

「ちょっと待って下さい。こういう時でないと聞けないことを精査しています」


 これ以上ない深刻な表情でドラ子は待ったをかけた。

 メガネは深いため息を吐いた。


「よし分かった。質問はなさそうだな」

「そんなー」


 そしてドラ子が答えを出す前に質問タイムは終了した。

 ロスタイムはなかった。


「とりあえず、これで問題はなさそうだから、あとは」

「あとは?」

「この死んだ魔物たちの片づけかな」

「ああ」


 メガネの眼鏡にちらりと回復の泉の現状の景色が映り、ドラ子はさっと目を逸らした。


「あ、明日になったら綺麗になってないですかね?」

「回復の泉の調査用ならこいつらナマモノだろ。一晩で溶けたりしねーよ」


 これが魔力形成で作られたモンスターなら死体の処理は簡単なのだ。

 Solomonには、魔力で作られたモンスターを魔力に戻す処理がデフォルトで備わっている。

 だが、実体のある死体として召喚されたとあっては、その処理の仕方も考えなければならない。

 何せここは、回復の泉しか存在しないダンジョン。

 屍肉を掃除してくれるモンスターなど存在しないのだから。


「そもそも何をどうしたら、こんなことになるんだよ」

「そんなこと私が分かるわけないじゃないですか」

「どうして犯人がそんなに堂々としてるんだ」



 それから、二人はああでもないこうでもないと言い合って、うずたかく積まれた死体を処理する最も冴えた賢いやり方を戦わせることになった。

 やれやはりスライムで溶かすのが賢い、とか、やれ屍肉食いと言ったらハイエナだとか、単純に酸の泉を増設したらどうかとか。


 今日は予期せぬ事態が重なって、普段より少し疲れていた二人だ。

 その表情は、今日で一番楽しそうだった。

 終電までは、まだ少し時間があるのだった。


その頃の蝙蝠さんは、奥さんからの鬼メッセに対して、自分がキャバクラに行っているわけでもガールバーに行っているわけでも浮気しているわけでもなく本当に仕事をしているのだと証明するために、ゴーレム部長とのツーショット写真を撮影しているところでした。




回答はもう少しだけかかりそうなので、今日中ではなく土曜日の更新に代えさせていただきます。

評価をするにはログインしてください。
ブックマークに追加
ブックマーク機能を使うにはログインしてください。
― 新着の感想 ―
[良い点] やっぱりドラ子も段々成長してるんだなぁ [気になる点] 何故蝙蝠さんには奥さんがいるのか………。 もしかして離婚が出来ない世界にお住まいですか() [一言] 死体処理はスライムが一番好きな…
[一言] 奥さん「まさか両方いけるなんて...」
感想一覧
+注意+

特に記載なき場合、掲載されている作品はすべてフィクションであり実在の人物・団体等とは一切関係ありません。
特に記載なき場合、掲載されている作品の著作権は作者にあります(一部作品除く)。
作者以外の方による作品の引用を超える無断転載は禁止しており、行った場合、著作権法の違反となります。

この作品はリンクフリーです。ご自由にリンク(紹介)してください。
この作品はスマートフォン対応です。スマートフォンかパソコンかを自動で判別し、適切なページを表示します。

↑ページトップへ