遅刻の言い訳提案システム 稼働三日目 ～大失敗～

お疲れ様です。高橋です。

三日目を迎えた遅刻の言い訳提案システムですが、重大なバグがあり、今日は動作しませんでした。

赤っぽいのが寝坊数で、青が本来、提案した数なのですが、「1分毎に、直近1分以内の寝坊を検出」するところ、デバッグのために設定していた”100″分以内の寝坊を取得していたので、6:45の寝坊ツイートも検知する等、おかしなデータになってます。

これは序の口。もっと重大なバグがありました。

重大なバグ

なんと、重大級が2つもあります。

リプライを送る箇所をコメントアウトしてた

昨晩のデバッグの際にリプライを実行する箇所をコメントアウトしたままの状態でサーバに上げてました。

  $reply = '@' . $user_name. ' '. $ewake;
// $reply_json = $twObj -> post('statuses/update', ['status'=>$reply, 'in_reply_to_status_id'=>$tweet_id]);
 $created_at = date('Y-m-d H:i:s', strtotime($created_at));

なんか変数がおかしな事になってた

trueを入れてあげないといけないのに、「tue」を入れてました。なんだtueって。

// is overslept?
 if (mb_strpos($tweet, $search_key) ==false) {
   $isNebou = false;
 } else {
   $isNebou = tue;
 }

とりあえず修正し、明日再チャレンジです。

寝坊者の利用端末状況

とはいえ、別途仕込んでおいた利用端末の採取の箇所は成功してました。

利用端末状況

寝坊者の22.68%がAndroidユーザです。これだと、今までの提案数の22.68%で済むため、1時間300制限や15分100制限に引っかかること無く2時間連続で提案し続けることが出来ます。

端末別Metrics

また、利用端末と「お気に入り」「フォロー」「フォロワー」「ツイート」のaverageとmedianを出してみました。

Averageで見ると、iPhone寝坊者がAndroid寝坊者に比べて平均お気に入り数が1.6倍多く、平均フォロワー数は2.5倍多いのですが、Medianで見るとそれほど大差ありません。Averageがここまでブレるのは今日のデータに異常値がかなり混在しているためと思われます。要はiPhone寝坊者であろうとAndroid寝坊者であろうと、各metricsにそれほど大差は無い、って事です。

端末別の各Metrics相関

「お気に入り」「フォロー」「フォロワー」「ツイート」の4種類を相互にぶつけ、さらに端末で色分けしています。ここで見るべきは、端末の種類で傾向線に著しい差が発生しているかどうか、という点です。

これも外れ値が大きく傾向線に作用してしまっているので、あまり使えません。とりあえず明日もデータを採取し、検証してから、フィルタリングするかどうか決定します。

追加機能

ただのバグフィックスとデータ取りだけだと、つまんないので。ユーザ毎の提案回数をカウントしているので、3回以上だと「多すぎる」と指摘する事にしました。

  } else {
 if($count > 2) {
 $suffix = "今回で" . $count . "度目の提案となります。多すぎる傾向にあります。";
 } else {
 $suffix = "今回で" . $count . "度目の提案となります。";
 }
 }

以上、よろしくお願い致します。