忍者ブログ
   
グラフツールの不具合
2020/06/30 01:35 | Comments(3) | 創作について
今日の一言「申し訳ない」

まえがき

 グラフツールの野郎が、不具合をかましているらしい。

元記事

グラフツールリリースに関する元記事


 神の頭脳を、森羅万象で天網恢恢な思考を、些事で浪費してしまったことは許されざる背徳である。

事象

 前日までに書いた文字数のトータルと、当日までに書いた文字数のトータルを差し引いて、その数値をデータとして登録する(ブラウザのクッキー)。
 その後、当日までに書いた文字数を、前日までに書いた文字数として登録する(ブラウザのクッキー)。

 という、単純な仕組みなのであるが、どうやら、過去の文字数が、当日の文字数に置き換わってくれないようである。

 ブラウザのキャッシュのせいではないかと疑うも、スーパーリロードしてもダメだという。

 原因が浮かばない。

対応の検討

 これは、神のためにはやはりクッキーとかいう得体のしれないものを使うのではなく、しっかりとデータとして登録する仕組みにしたほうがよいだろう。
 データベースを構築するまでは必要ないと思われる。テキストデータ(CSV形式)とかでよさそうだ。

 どなたか、アドバイス求む。

 グラフの日付と、その日付に対応するデータ(文字数)と、前日までのトータル文字数と、作品名ぐらいのデータを保持するのは、どういった構造がよいだろうか。

(条件として)
・グラフの日付と、対応するデータは可変。どんどん増える。
・前日までの文字数は、1回だけ保持できればよい。作品タイトルは、1ファイルにつき1つでよい。

 ぱっと思いつくのは、1行目にメタ情報(作品名とか、前日までの文字数)を保持して、2行目以降は、可変の「日付」と「文字数データ」を、カンマ区切りで増やしていく感じか。
 そうしたとき、任意の期間で取り出すのはどうやるか、ちょっと難しい気がする。

あとがき

(かっこ書きである。とにかく、がしがし良き作品がこの世に生まれ出るための支援をするためのツールが、足をひっぱるなどなんと申し訳ないことか。寛大なる神は全データぶっとびしてもノアの洪水のごとく地を洗い流すことなくいらっしゃるが、これはセプクものである。すぐさま対処を考えたいところであるが、原因が分からない。であれば根本的に対応を考えるほうがよいだろう。しかし、平日は無理だろう。きっと自滅する。結局対応せずに力尽きることは神も望んでいないはずだ。であれば休日。しかし今週は珍しく少し予定が入っている……なんたることだ、こんなときに限って……!! しかし、なにとぞ、なにとぞお待ちいただきたい……)



拍手[1回]

PR

コメント

【感想】

やっぱそういうのって問題に発展しがちだよな。自分も仕事してた時に似たようなことやらかしてきたからなぁ・・・。気持ちわかります。やっぱ、無難にcsvなんじゃね??あと、クッキーからcsvに変更する際ってちゃんとデータ移行ってできるん??ってことを真剣に考えないといかんぜよ。既存のユーザいるんだし。あと、メンテナンス中はユーザに使用されたらまずいから使えないようにしないとだし、あと、データのバックアップも大事っす。

あと、csv形式にする場合、どのようにして人とファイルを結びつけるのかは面倒かもしれません。ログインしないと使えないようにする?とか。IDがわかれば登録できるっていう形にするとトラブルの元です。

今まではローカルのクッキーから生成ってしてたやん。それをcsvに変えるのはってこと。

あと、そういえばサーバにcsvファイルを保存せずにユーザーにcsvを作ってもらってサーバはそのデータをグラフにするだけみたいなことを言っていた気もする。ユーザと相談しながら決めてみたらいいんじゃないかと思う。

UIの方針とかも。


あれ???でも、クッキーってユーザ側にしかないから、いまのバグを修正するしかないのではwwwwwwwwwww


【データ構造について】

データの形式は

日付、トータル文字数
日付、トータル文字数
日付、トータル文字数
・・・

と続く形が無難だと思います。その日または前回からの文字数は差分計算でいいのではと思います。


トータル文字数、トータル文字数、・・・
というようなデータは処理しにくいし、人から見てもわからないのでデバックするとき大変だと思います。

あと、どのくらいの量のデータまでならユーザにストレスをかけることなく処理できるかについても検討したほうがいいと思います。自分でデータを生成して試験するとか。


【その他】

あと、デバックデータをどこかに出力したほうがいいと思います。
PHPをつかったことがないのでよくわかりませんが、もし、サーバ上にデバックログを残せるならそこに、無理ならhtml画面上にログ出力ページを設けてそれをコピペしてもらうなりできないのでしょうか。まぁ、想像なんですが・・・。



【ふぉいについて】
http://beal.hatenablog.com/entry/2020/06/27/232619

2273 - 983 = 1290

グラフ
6/25 1290
6/27 2273

6/27に書いた文字数は983
なので、その日書いた文字数を出すべきところをその日の合算を出す処理が誤って動いているように見えますね。
まぁ、ここら辺はすでに気が付いていて、それでもわからん、ということなのかもしれませんが、少しでも役に立ちたく。










posted by いみふat 2020/06/30 17:07 [ コメントを修正する ]
>あれ???でも、クッキーってユーザ側にしかないから、いまのバグを修正するしかないのではwwwwwwwwwww

1.ユーザのクッキーをユーザのPC内でcsvに変換

2.ユーザがcsvをページにアップロードにサーバ上のcsvとして取り込み

みたいな手順になるので結構大変かなと。

ユーザにごめんして、新しく作りましたという体ならなんでもOKかと。
posted by いみふat 2020/06/30 17:31 [ コメントを修正する ]
いみふさん

優秀なエンジニアキタコレ!!
って実は、だいぶカメラ目線でアドバイス求めてました。早速コメント頂いてありがとうございます!

>クッキーからcsvに変更する際ってちゃんとデータ移行ってできるん??ってことを真剣に考えないといかんぜよ。既存のユーザいるんだし。

素人ということで言い訳してしまいますが、この点考えられてませんでした……。
クッキーデータの構造は把握しているので、移行ツールなど別に作れば対応自体は可能に思いますので、こちらは検討しようと思います。
(想定ユーザ氏が1名で、先日こちらのアナウンス不足により過去データも消えてしまったとのことで、新規で作ろうかという発想でしたが、よく考えたら新規開発までの期間もあるので、データ移行は必須と思い至りました。思慮が浅かった)

>メンテナンス中はユーザに使用されたらまずいから使えないようにしないとだし、あと、データのバックアップも大事っす。

承知いたしました!


>あと、csv形式にする場合、どのようにして人とファイルを結びつけるのかは面倒かもしれません。ログインしないと使えないようにする?とか。IDがわかれば登録できるっていう形にするとトラブルの元です。

即座にこの点の指摘、流石過ぎます。私も今日吊革につかまりながら、そういえばクッキーで作ろうと思った理由の一つにログイン問題があったなと思い至りました。昨日は、「得体のしれないクッキー」と表現してましたが、ユーザのブラウザに保持できるということから使用者を識別できるってのはメリットだったなと。
ログイン情報(ユーザID・パス)は、もともとのサイトの方で保持しているので、ログインした状態でグラフツール起動(画面遷移)するような動きになるのかなと。
ただそうしたときに、さくっと今まではURL開いて文字数入力してグラフ作成、ってできていたのが、ログインするって動作が必要になるので、逆に手を煩わせてしまいそうなのがデメリットですね。

>サーバにcsvファイルを保存せずにユーザーにcsvを作ってもらってサーバはそのデータをグラフにするだけみたいなことを言っていた気もする。ユーザと相談しながら決めてみたらいいんじゃないかと思う。UIの方針とかも。
>>1.ユーザのクッキーをユーザのPC内でcsvに変換 2.ユーザがcsvをページにアップロードにサーバ上のcsvとして取り込み みたいな手順になるので結構大変かなと。

最初の実装したころ言ってた気がします。
ただ今考えると、ユーザ側にCSV管理してもらうってのはちょっと負担な気がします。

>クッキーってユーザ側にしかないから、いまのバグを修正するしかないのではwwwwwwwwwww

そうなんですよね。たぶん、「昨日までの文字数」を保持しているクッキーが更新されない、って現象のようなので、その原因特定・解消が本来できたらいいのですが……。



>【データ構造について】
>日付、トータル文字数
>日付、トータル文字数
>日付、トータル文字数
>・・・
>と続く形が無難だと思います。その日または前回からの文字数は差分計算でいいのではと思います。

めっちゃ参考になりました! CSV方針決定した場合、この方法採用させていただきます!

>デバックデータをどこかに出力したほうがいいと思います。

確かに。これができてれば原因特定もスムーズだったかもしれません。クッキーの仕組み(例外的な場合とか使用上の注意事項とか)をいまいち理解できていないのもよくないかも。

>2273 - 983 = 1290
>6/27に書いた文字数は983
なので、その日書いた文字数を出すべきところをその日の合算を出す処理が誤って動いているように見えますね。

ありがとうございます! おそらくそのあたりの処理だとは思いまして、コード情報も見直しましたが、コード上でバグは見つけられませんでした。
この3日間ぐらい、自分の環境で試しているのですが、再現しないんですよね……。

posted by endoat 2020/06/30 23:29 [ コメントを修正する ]

コメントを投稿する






Vodafone絵文字 i-mode絵文字 Ezweb絵文字 (絵文字)



<<ぎりぎりのところで続けるイラスト | HOME | コメント返信(電車)>>
忍者ブログ[PR]
アクセスランキング