目次
14日 しばらく日記書いてなかった
17日 イベント終わりました
18日 自宅電話回線その後
19日 遊びプログラム
20日 久しぶりのperl
24日 保険金おりた
なんか日記を書かないまま半月過ぎてしまい、長い間何も書かないのも気持ち悪いので、無理やり駄文を書く。
本当に駄文。身辺記程度なので読んで得になることは何もないです。
日記を書いていた理由はいろいろあるのだが、まぁ忙しかったからだ。
今年の５月末に、以前からやっていた仕事の契約を解消した。
そして、友人が起こしたベンチャー企業の仕事をフルタイムで請け負い始めた。
しかしまぁ、その頃はまだそれほど忙しくなかった。
会社の受注状況は悪くなかったが、それは「システムを使いたい」というものであり、プログラムの緊急改変などは不要だったから。
それが、夏ごろから「料金払うからカスタマイズしてほしい」という需要が増え始め、今月は同時に２件。
今週末、２カ所で使用される別々のシステムのカスタマイズを、同時並行で進めていた。
さすがに今週頭に完成し、昨夜までにデバッグも大体終わった。
今も最終チェックが行われているが、僕の仕事は「バグ報告待ち」になっている。
そこで、こんな日記を書いているわけだ。
友人の会社は、スマホを使ってアンケートに答えてもらい、リアルタイムに集計した結果をブラウザ画面にグラフ表示する、というシステムを作っている。
僕が参加し始めたのは２年半くらい前だったと思う。
システムはすでに完成していたのだけど、足りない部分も多く、保守する人がいないから手伝って、と頼まれたのだ。
時々頼まれては作業していたが、１年半ほど前に、その時友人がいた会社が「開発中止」を決定した。
この開発中止は、会社が方針を転換したためで、売り上げが悪いとかの理由ではなかった。
そこで、彼はシステムの権利を買い取って、１年ちょっと前に会社を興したのだった。
詳しいことは、その頃に書かれた、以下のインタビューを読んでもらうといいだろう。
この事業専門の会社にしたことで、いろいろな会社と提携しやすくなった。
「しがらみ」が無くなり、開発速度が増した。
いろいろな会社と提携して、使われる範囲も増えた。
時々「開発料金は払うので、カスタマイズをお願いしたい」という仕事も来る。
友人としては、機能をカスタマイズするとプログラムが複雑になり、保守に支障があるため「カスタマイズはしない」方針をとっている。
しかし、「画面の見た目を変える」というカスタマイズは受け付けている。
このカスタマイズは主に集計表示部分に行われる。集計部分の担当は僕だ。
この手の仕事が増えたこともあり、６月からは、僕もフルタイムで参加するようになった。
今週の末に、２カ所のイベントでカスタマイズしたシステムが使われる。
この２カ所は別々のイベントで、カスタマイズ内容も別だ。
こうしたイベントは、最終仕様が決まるのがぎりぎりになることが多い。
今月に入ってから２つのカスタマイズ内容が決まり、２週間で同時に２つを開発してきた、という状態。
これが、日記を書けなかった主な理由だ。
昨日までにテストしてバグはほぼなくなったことを確認し、今日は余裕があるので日記を書いた。
明日は実際の会場で最終テスト。
より大きなカスタマイズをした方は、現場でテストに立ち会う予定。（必要なら現地で最終調整を行う）
明後日は本番だけど、これは見に行かない。
本番では、もうプログラマの出番はないから。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先日書いた日記の続き。
しばらく日記書いてなかったもので、リハビリみたいなもので、どうでもいい身辺雑記書いてます。
現在一緒に仕事をしている会社、別に名前とか出してもよいとは言われているのだけど、この日記上では名前出していない。
その仕事先の名前（商品名でもある）で検索されて、中の人だとわかるのもなんとなく嫌なので。
（僕はその会社の手伝いをしているが、社員ではない。そんな人の話が会社の意見だと思われても困る）
でも、前回リンクした記事を読めば、何の仕事かはすぐわかる。
「このページを読んだ人が知っていてもいいが、商品情報を頼りにしてここに来ないで欲しい」ということだな。
で、土曜日の夜に、東京ビッグサイト…の「壁」に、映像作品を投影するコンテストが行われた。
いわゆるプロジェクションマッピングというやつです。
応募資格は学生だったのかな。
大学生や専門学校生。プロの映像作家はダメだけど、映像の専門校生はいい。
本番は土曜日だったのだけど、金曜日の通しリハーサルに立ち会った。
一応、本番終わるまではリハーサルの話とか書いちゃまずいだろ…と思っていたので、日記に書くのは本番が済んだ今日になった。
このコンテストでは、最終審査は審査員がやったのだけど、「一般審査」として、見た人は誰でも作品の点数をつけられた。
最終的に、平均点が高いところには「観客賞」が贈られる。
（結果、審査員が付けた「最優秀賞」と、「観客賞」は同じチームだったようだ。
僕は本番ではなくリハーサルで見ただけだけど、このチームは群を抜いて出来が良かった。納得の結果だ。）
一般審査の投票システムとして、一緒に仕事をしている会社のシステムが使われた。
ビッグサイトの壁面に QR コードを表示し、そこから誘導される WEB ページで「投票」すると、リアルタイムに点数が集計されるのだ。
壁面は非常に大きいし、見た人は誰でも投票できる。会場の広場で見ている人は当然、数百メートル離れたところの人だって参加可能だ。
そういう「ゆるい」審査なのだけど、そうした集計ができるシステムは、案外少ないのだ。
そして、集計結果は…点数は、リアルタイムには表示しない。それは、最終結果の発表までのお楽しみ。
その代わり、映像について感じたことを「すごい」「楽しい」「かっこいい」の三択で選んでもらっているので、その割合を表示する。
円グラフがリアルタイムに動いているものが、ビッグサイトの壁に表示される、というだけなのだけど、この部分のシステムを僕が担当しました。
これがね…前日リハーサルまで、実際の映像が見えないので、想像で作るしかなかったの。
文字が大きくないとつぶれちゃうんじゃないか、コントラストが強くないと見えないんじゃないか…って、想像で作り上げるしかない。
直前の日記に「必要なら現地で最終調整」と書いていたのはそのため。
表示してみたら、十分にきれいで何も調整は必要ありませんでした。
一応、円グラフを動かす部分は普段から使っていたプログラム。
でも、普段は円グラフの横に「凡例表」があり、そこにアンケートの内容などが書いてあった。
（グラフの領域には、1 2 3 という数字だけがあり、横に対応表があるわけです）
でも、今回はビッグサイトの三角形の外壁に表示したので、凡例表を出すことはできなかった。
グラフ内に直接文字を入れてほしい、と言われていました。
最初の段階から、「グラフが細くなると、文字重なっちゃうと思うよ？」と言っていたのですが、実際作ってみたら予想以上に深刻でした。
先に書いたように、プロジェクションだと細かな部分がつぶれやすいので、文字をできるだけ大きくしないといけない。
当然大きい方が重なりやすいわけだけど、その状態でも「割合を示す % 部分は読めるようにしたい」という要望がありました。
もう、事前に試行錯誤の連続。幸いなのは、選択肢が３つしかなかったこと。
選択肢が３つだから、「細い領域の両隣のうち、少なくとも一方は表示面積に余裕がある」と確定しています。
そこで、表示面積が細い場合（具体的には、角度にして60度以下になった場合）は、両隣のうち、より広い方にはみ出して文字を表示してもよいことにしました。
（具体的なアルゴリズムとしては、文字は表示領域の中央に出すのだが、60度以下の場合は、広い方にはみ出して60度あるものとした中心に表示を行う）
ただ、両側とも十分に広いばあには、今度逆に「片側に文字が寄る」表示は不自然。
そこで、こうした場合は広い方に寄せる処理をしない、とか、いくつかの場合分けを行います。
これでもまだ、１つの領域が 80% とかとってしまうような極端な状況では、文字同士がぶつかることがありました。
そこで、20% 以下になった場合には、文字サイズが小さくなっていくようにします。
20% 以上なら 100% の文字サイズで、10% 以下なら 80% 。間は滑らかにつなぎます。
これで、問題のないグラフ表示になりました。
この表示、評判良かったので今後も使えるようにしたい…と、仕事先の社長から言われてます。
でも、それなら３つ以上の選択肢でも使えるようにしないと。
今は、文字の表示中心が、円グラフの中心から等距離のところにあるのだけど、本当はこれも可変にしたい。
グラフ中央から「近い」「遠い」をうまく組み合わせれば、もっと文字を表示しても読めるはず。
ただ、そうなってくると文字同士の当たり判定を入れたいのだよね。
今のグラフ表示基礎ルーチンは僕が作ったものではなく、そこまで複雑なことができる作りになっていない。
もっというと、データが決まっていて「うまく表示する」目的なら、内部的に試行錯誤して最適配置を求められるのだけど、リアルタイムに移り変わるのを違和感なく表示するのは至難の業。
まぁ、そこがゲーム的で面白そうなチャレンジだと思ってる。
（試行錯誤させてもらう時間があればね）
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先月末に、電話回線契約のトラブル（？）の話を書いた。
簡単にまとめると以下のような話だ。
まず、ＮＴＴひかり電話を、アサヒネット光電話に変更する契約を８月末にした。
ところが契約内容の確認書類と、工事日以降サービスが若干変化する（サービス会社が変わるから）という案内が来ただけで、工事日の案内が来ない。
どこかで変更されたか確認しないとな…と思っていたら、１０月末になってアサヒネットからセールス電話がかかってきた。
ＮＴＴひかり電話を利用中の方に、アサヒネット光電話に変えませんか、というセールスだった。
すでに使ってます、と言ったら、システム情報を見て使っていないし、案内書類などを発行した形跡もない、というので、再契約した…
というもの。
その後、ふたたび契約内容などの案内の書類が届いた。以前もらったのと同じものだ。
しかし、次の書類が来ない。
以前は、契約内容の後に「工事日以降サービスが若干変化します」という２通目の書類が来たのだ。
肝心の工事日は書いてなかったのだけど。
なんだか、嫌な予感がする。
再契約の際、最速で１１月頭には切り替えられる、と言っていた。
先ほど、心配なのでアサヒネットのページを見に行き、契約内容を確認した。
９月８日から、光電話を使っていることになっていた。
…つまり、再契約のセールスの際に「使ってることになってない」と言っていたのが間違いで、ちゃんと最初の契約で利用開始できていたのだ。
再契約二通目の「工事のお知らせ」が来なかったのは、工事をしようにも、すでに工事すべきＮＴＴ回線がなかったからなのだろう。
そんなわけで、前回「大丈夫かよ。アサヒネット」と書いていたのだけど、大丈夫だった。
いや、使っているのにセールス電話かけてきて、契約した形跡もない、とか言っていたのだから大丈夫じゃないか。
ちなみに、２回目のセールスは「工事費用なども無料です」というキャンペーンだったので、追加で金をとられたりすることもない（はず）。
おまけ：
話は以上で終わりで、この下はアサヒネットを使っている人は読まない方がいい。不安になるから。
知り合いに、アサヒネットに詳しい人がいる。
以前からアサヒネットのサービスを多数利用していて、今もサーバーホスティングサービスを受けているのだ。
その人が、１年くらい前から「アサヒネットの技術力低下がシャレにならない」と言っていた。
たびたびサーバーが停止したり、回線トラブルでアクセス不能になったりする。
数分以内に復旧するのだけど、その知人は「アクセス不能」で、行っているサービスに大きな支障が出たことがあるという。
以前は技術力が高い会社だったのだが、どうも品質が落ちているらしい。
まぁ、アマゾンのクラウドとか、強大なライバルが出すぎてサービス維持が難しいのだろう。
その知人は、アサヒネットのサーバーに依存しないようにシステム改変作業中。
うちは回線借りているだけなので、それほど技術力低下を感じていなかったのだけど、サービスは確実に低下しているかも、と今回の件で痛感した。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
今日は一日仕事があいてしまったので、遊びプログラム。
まだ完成していないし、明日からは普通に仕事に戻るので、完成するかもわからない。
Twitter をエゴサーチしているが、ファミコンの画面についてのページを引用してくださった人がいた。
ファミコンでは 52色表示可能、という、表示できる色の一覧だな。
どうやら、その人は「ファミコンの表示」に興味があり、適当な画像をそれっぽくするフィルタを作っていたらしい。
Twitter のログを追って分かったことには、最初は「適当な54色」に減色してみたものの、どうも「それっぽい」画面にならないので、情報を探して僕のページを見つけたようだった。
どうも、当初は RGB 空間を適当に区切って 54色にしたようだ。
しかし、どこかで「RGB ではなく、NTSC の Y/C 空間で考えないといけないようだ」と、情報を探して僕のページに辿り着く。
そして、そこで
・既定の 52色
・16ドット以内で使えるのは、背景色含めて４色だけ
・その４色の組み合わせは、全画面内で４セットだけ
という厳しい条件を知り、「なんだかわからない」とツイートして終わっている。
さて、僕も以前から、ファミコン風画面フィルタは作ってみたかった。
ちょうどよい機会だから、「厳密にはしない」つもりで作ってみる。
とりあえず、52色減色から。
RGB を HSV に変換してからファミコンパレットに適用してみようと思ったのだけど、難しい。
H 信号を参考にして、「パレットの近いあたり」までは見つけられるとわかったので、その周辺を総当たりで「近い色」を探すようにしてみる。
とりあえず、ファミコン 52色への減色はこれでできた。
ディザをかけたりしないので、最適な画像変換ではないけれど。
つぎに、52色自由に使ってはならない、という制限をかけてみる。
使われる色を集計し、上位 12色しか使ってはならない、としてみたら、まだまだ綺麗な絵が出る。
では、６色まで落としてみよう。
というのも、グラディウス２のデモ画面で、ビッグバイパーの絵が６色で書かれているからだ。
…いい具合に「色合いが不自由」な感じが出て、ファミコンらしくなった。
つづいて、「16ドット以内に４色」という制限を作ってみる。
４色のうち１色は「背景色」なので、一番使われている色を背景色にすることにして、それ以外の色で 16ドット以内で使用頻度を集計する。
これで、上位３色＋背景色で描けば、それらしくなる。
…案外、きれいな絵が出てしまう。
いろんな絵で試すと、多少不自然なところも現れるが、この条件だけではまだ「ファミコンらしさ」が出ないようだ。
やっぱり、「全画面で３色セットを４つまで」の制限も入れないといけないだろうか。
ファミコン画面は 256x224 （縦方向は VRAM は 240 ドット分あるが、表示は 224ドット程度とすることが多い）として、16x16 ドットのタイルで区切ると、16x14 タイルになる。
それぞれを、背景色を除いた３色に減色したうえで、同じ色の組み合わせになった数を集計する。
そして、使われた数が「少ない」パレットを、使われた数の「多い」パレットに吸収する。
吸収する際は、３色のうち少なくとも２色が同じパレットに吸収することにした。
この際、使用された数もちゃんと吸収させる。
できる限り吸収を繰り返したうえで、改めて集計された使用数の順に並べ治す。
最終的に、上から４つのパレットを採用する。
そして、このパレットを使って画面を描くと…うん。いい感じに四角く色が化ける。
ファミコン時代にはよくあったよね。無理やり感のある絵。
しかし、四角い不自然さはあっても、まだファミコンにしてはきれいすぎるのだ。
それは、画面全体で、色以外は自由に絵を描けてしまっているから。
ファミコンは、8x8 ドットのキャラクターを並べて絵を作る。
このキャラクターは 256種類しか定義できないのに、画面全体は 896マスある。
だから、自由に絵を描くことはできないのだ。
色だけをファミコン風に変換しても、キャラクターの不自由さで違和感がある。
本当は、「似た部品」を探し出して、無理やり共通化することで不自然さを出していけばよいのだけど、そこまでやるのは結構面倒だ。
そこで、せめて「四角い塗りつぶし」を増やすことにする。
8x8 ドットの範囲内、64ドットのうち、52ドット以上同じ色だった場合には、思い切って 8x8 を塗りつぶしてしまう。
52ドットに根拠はない。色々試して、それくらいがなんとなくいい感じだった、というだけだ。
塗りつぶし部分は、絵としては「使いまわし」になるので、絵が自由に描けない不自由な雰囲気が出る。
とはいっても、これでも絵がある部分が 256マスには収まらないのだけど…
かなり塗りつぶしが多い絵でも、256以上のキャラクタを定義したことになってしまう。
まぁ、遊びプログラムなので、本日はここまで。
あまり満足いく結果が得られていないので、公開するにはまだ早いかな…
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
久しぶりに仕事で perl を使った。
現在仕事を受けている会社で、サーバートラブルがあった。
そこで、トラブルに遭遇したユーザーを特定したいという。
ここでのサーバートラブルは、「サーバーに接続できなかった」というトラブルだ。
そのため、サーバーには接続できなかった人を特定するログは残っていない。
しかし、リバースプロクシを入れてあったため、プロクシにはログが残っている。
ただ、このログは通常の WEB アクセスのログであり、ユーザーを特定できる情報が残っていない。
実は、問題のあったアクセスは POST アクセスなのだ。
そして、POST の body データとしてユーザーを特定できる情報が入っている。
body として送られるデータは一般的に大きいため、普通はログに残すような設定にしない。
つまりは、問題のある URL にアクセスした個人を特定したいのだが、その個人を特定する情報は記録されていない。
いや、まだ手はある。
知りたい URL アクセスには個人特定情報は入っていないが、その前に必ずアクセスする URL は GET アクセスで、この時は URL パラメータとして個人を特定できる情報があるのだ。
そして、これは「直前の URL」なので、おそらくは問題となる URL のアクセスの際にも、IPアドレスは変わっていないだろう。
ただ、IP アドレスは使いまわされる可能性がある。
IPアドレスだけで「同じユーザーのアクセス」と認定するのは危険で、user agent 情報も一緒に使うのが良いだろう。
まとめると、つまりこういうことだ。
・特定 URL にアクセスして、接続できなかった (status が 302だった）個人を特定したい。
・特定 URL アクセスには個人特定の情報はないので、直前の別 URL アクセスの際の情報を使用したい。
・２つの URL の間が「同じユーザー」であることは、IP アドレスと user agent の一致で確認。
さて、これを２万行ほどあるログに対して、処理したい。
トラブルの事後処理なので、できるだけ早急に。
あぁ、これは perl の出番だな、と瞬時に判断したが、perl 使うの久しぶり。
大丈夫だろうか、と思いながらスクリプトを書き始める。
結論から言えば、うっかりミスはあったが過去のノウハウは活きた。
WEB サーバーのログは、基本的にスペース区切りなので、情報を得たいときはスペースで分割する。
…という風に、処理慣れしていないプログラマなら思うだろう。
perl では、１行にスペース区切りで複数のデータが入っているときは、
split;
というたった一命令で分割処理が終了する。
以前、perl の命令は暗黙のデフォルトが多いという話を書いた。
本当は、split 命令は、「分割したいデータ」と「分割する文字」を与え、「分割した内容を受け取る変数」に代入を行う必要がある。
しかし、全部省略すると、$_ （通常は、現在注目している行）を連続したホワイトスペースで分割して、@_ （一時的な配列）に入れてくれる。とても便利。
なので、WEB サーバのログでも、split で分割したくなってしまうのだ。
でも、WEB サーバーのログの中には、「スペースが許容されている情報」が収められている。
サーバーにどのようなアクセスがあったか、という情報と、user agent は、内部にスペースが入るのだ。
そのため、スペースで区切ると、情報の途中で区切られてしまうし、分割後の「情報」の位置が安定しないしで、処理しづらいことこの上ない。
もちろん、ログ内で混乱が起きない工夫はあって、スペースを含む情報は " （ダブルクオート）で括られることになっている。
だから、ダブルクオートを見つけたらその内部をひと固まりとして処理するようなプログラムを書けば…
というのは、正攻法だけどひたすら面倒くさくて時間のかかる道。
発想を変えよう。最初に、" で区切ってしまえばいい。
アクセス情報と、user agent は " で括られているのだから、この段階で適切な位置にある情報が取得できる。
IP アドレスやアクセス時刻は、" で括られない情報なので、上記処理で手に入った断片を、さらにスペースで区切る。
これで、各種情報が手に入る。
過去に何度も WEB サーバーのログを処理していたので、こういう処理ノウハウはすぐに思い出した。
さて、まずは、「直前の GET アクセス」から個人を特定できる情報を拾い出そう。
これは、特定の URL を条件として、正規表現で拾い出してやれば終わりだ。
IP アドレス、user agent もすでに取得してあるので、この２つの組をキーとした連想配列に、個人特定情報を保存しておく。
つづいて、情報が欲しい「特定 URL にアクセスしたとき」の処理も作る。
この URL も、正規表現で拾い出せばよい。
ただ、この「特定 URL」は、一つではない。
末尾部分がサービスの違いを示す数値になっていて、一人のユーザーが複数の「数値の違う」URL にアクセスしている可能性もある。
そのため、URL の末尾に入る数値も一緒に記録してほしい、とのリクエストだった。
これは、正規表現の ( ) （グルーピング演算子）で取り出す。
ここでの正規表現は「データを得るためのもの」ではなく、if 文の実行条件を示す「比較」にすぎない。
しかし、「比較」でデータを取り出せてしまう、というのも perl の便利な部分だ。
条件はもう一つあった。この、特定 URL のアクセスが「302 エラーになった時」だ。
これも、ログにはステータスが入っているので、302 の時を条件に入れればよいだけ。
さて、無事条件に合うアクセスがあったら、時刻と URL 内部の数値と、個人特定できる情報を１行にまとめて出力してほしい、というリクエストだった。
個人特定情報は、先に書いたように、IP アドレスと user agent に紐づいた形で保存してある。
これを使えばいい。
時刻は、サーバーログに入っている形式と、求められている形式が少し違ったので、変換する。
ログに入っているのは [20/Nov/2019:15:30:28 +0900] という形式。
必要なのは、2019-11-20 15:30:28 という形式。
これも、正規表現でグルーピングを使えば必要な情報が得られるので、整形して出力するだけ。
出力は、２通り用意してほしいと頼まれていた。
まずは、エラーが出たすべてのアクセス。
もう一つは、エラーが出たことで繰り返しアクセスする人も多かったので、「同じ URL への同じ人のアクセスは、初回のみを記録して後は省略」したもの。
まずは、エラーが出たすべてのアクセスを出力し、ファイルに残す。
続いて、プログラムに少し追加。
URL と個人特定情報を組として、一度出力したら「1」を記録するようにした。
この記録があったら出力済み。事前に確認し、出力処理を飛ばすようにした。
これで出力した情報もファイル化する。
さて、ここまで整形した情報を得るまで、１時間程度。
久しぶりの perl としては、まずまずだろう。
しかし、データを送信してしばらくたって、先方から「おかしい可能性」を指摘される。
どうも、「同じ URL への同じ人のアクセス」を省略したほうのデータが、少なすぎるように思うというのだ。
しばらくプログラムを見てみるが、すぐに原因が特定できない。
「すべて」を出力したファイルに対し、unix コマンドの sort と uniq を駆使して「同じ URL への同じ人のアクセス」を省略したファイルを作ってみる。
明らかに数が違う。データ件数で、15 倍くらいの情報があった。
これ、連想配列のアクセス方法を間違えているためだった。
最近使っている、Javascript でも PHP でも、連想配列アクセスには [ ] を使う。
でも、perl は連想配列は { } だった。
完全に自分の頭から抜け落ちていた「常識」に気づくまで、１時間くらい。
これに気づいて修正したら、出力データ件数が増えた。
出力データを wc してみる。行数や語数を数える unix コマンドだ。
「すべてのデータ」出力は、改良前と後で同じ件数だが、出力データサイズが微妙に違う。
改良前と後のファイルを diff して違いを探す。
どうやら、件数は同じでも、個人特定情報の部分が違う。
改めてプログラムを見て、連想配列アクセスを間違えていたため、個人情報の紐づけが正しくなかった、と判明。
なので、先に作った全件データは誤り。新しい方が正しい。
この正しいデータをもとに、sort | uniq したデータと、プログラムで「同じ URL への同じ人のアクセス」を省略したファイルは、同じ件数・同じ出力サイズだった。
sort した関係で順番などが異なっているのだけど、別の方法で集計しても、プログラムの集計と同様になったことが確認されたので、このデータは正しいと判断。
ここまで、最初の依頼から２時間半ほど。
データを送って確認してもらい、おそらく正しいだろうという判断になった。
＃そもそも、確実に正しいか確かめる方法はない。
正しいデータがないから、こんなプログラムをしているのだもの。
…と、今日記を書いていて、ここで終わろうと思ったところ、ちょうどバグ報告が来た。
出力の中に、「個人特定情報」が入っていない行がある、とのことだった。
元になるアクセスログを開き、「報告すべきエラー行」を特定する。
それから、そのエラー報告に含めるための、「個人特定情報」を拾い出せる、事前の行を探し出す。
…ここで、ミスをした。
というのも、「個人情報」は当然ないので、バグ出力に含まれる情報で行を探したが、実は該当行が２行あったのだ。
しかし、僕は「時系列で上にあった行」だけを見つけて、その行を元に周囲を調べ始めてしまった。
どう考えてもデータはおかしくないので、自分のプログラムのミスだろうと探すこと３０分以上。
いろいろ確認してもおかしくないので、データに戻り、再度おかしいところを探す。
この作業中、やっと自分の過ちに気づく。
そして、２行目の該当行を元に、同じ IP アドレスでアクセスしている「事前の」行を調べると、存在しなかった。
事前アクセスがないので、「事前のアクセスから」情報を引っ張ってくることはできない。
プログラムには問題はなく、データの問題だった。
ここまで確認して、報告。
ついでに、事前データはないものの、「事後の」アクセスから個人を特定できたので、その情報も報告。
ひとまず作業終了となった。
昨日日記に書いた「遊びの」プログラムもそうなのだけど、こうしたパズル的なプログラム作業は、やっていて楽しい。
保守性とか読みやすさとか考えないで、ただ動くプログラムを書けばいいからね。
仕事なので時間制限もあったりするのだけど、それも踏まえて「最短時間で解決するにはどうすればいいか」というような段取りから考えるのが楽しいのだ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
一連の、台風19号被害の話。
１１月の頭に、見積もりは出ていた。
ある程度の金額は覚悟していたのだけど、予想よりも倍以上高い金額だった。
直接的な被害は、ウッドデッキ上のパーゴラが倒れただけだ。
それだけなら、それほど高くはないだろうと思っていた。
しかし、この際にウッドデッキの土台も損傷しているし、外壁も一部損傷している。
巻きぞいで雨樋も壊れたので、その修復も必要だ。
で、その程度の値段で自分で見積もっていたのだが、実際に工事するには、足場を組む必要があった。
壊れた雨樋は二階の屋根なのだから、当然足場がないと作業できないだろう。
すると、足場部材のレンタルに、足場屋さんの設置・撤去費用も掛かってくる。
なんだかんだで、びっくりするような金額だった。
でも、見積もりが出たので保険を請求していた。
この保険の申請が受理され、無事支払われた。
ただ、見積金額の全額が認められたわけではない。
パーゴラ上には藤の木が乗っていて、パーゴラと一緒に倒れたので修復しないといけない。
この「藤の木」は、住宅施設とは認められないため、保険金は支払われないそうだ。
一応、庭木が風害で倒れた場合の補償なども保険の補償内容に入っていたのだけど、それは倒れた場合の撤去費用や、小さな苗木を植える代金などのようだ。
大きな木が倒れたが修復可能なので修復する、という費用は想定外のようだった。
まぁ、藤の木はすでに修復済みなのだけど。
修復後に、見積もりに作業内容を入れてもらっていた。
（保険は、緊急を要する修復は行った後にその料金を請求することもできる契約だったので、作業後の見積もりでも問題はない。）
さて、お金の心配はいらなくなったが、工事業者の手が足りないため、実際に工事に入れるのは年明け以降だそうだ。
パーゴラの柱に物干し竿を通す金具をつけてあったので、現在洗濯物を屋外に干すこともできない。
もっとも、冬は家の中が乾燥しがちなので、加湿を兼ねて部屋干ししている。
工事が遅くなっても、冬の間に終わるのであれば問題はない。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |