今回は、４日間開催されるということもあり、楽天チケットの他にチケットぴあやローチケでも発売されました。
チケットぴあとローチケは余裕で取れてました。ローチケについては、画像認証突破後で座席確定ですが、そこでほったらかしにしているとタイムアウトになってしまうため、結果画面をキャプチャーすることができませんでした。
楽天チケットはというと、また画面遷移が変わっていたようで、まるで変化がありませんでした。
チケット売り切れ後に画面遷移を確認できるチャンスについても今回は逃してしまい、次回はデータ取りからやり直すことになりそうです。
今日の参戦は、結果は勝利でした。
そして、何よりも攻略法が分かりました。
当方が取れたのは14:16頃でした。このとき既に△になっていたのがログから確認できました。つまりまだまだ早く購入している人たちがいるということが分かりました。
乃木坂４６に詳しいユーザに確認したところ、次回のライブの日程は２月下旬頃とのことなので、そのときに購入してくれたユーザには攻略法を伝授します。
今回は、ユーザ視点に立ってBOTを動かすことを意識していたのですが、CyberSoleのようなブラウザ画面が無くて複数タスク作成が可能なBOTが好まれる理由が分かる気がしてきました。
AlertsJPとの接点が無かったときは、BOT初心者が多くて、如何に分かりやすいユーザビリティにするかということを意識していました。購入する前と、結果がブラウザと連動することで、何が起きているのかを簡単に表現するために、UIにブラウザを常に表示することが重要だと考えていました。
最近、AIOの画面レイアウトについて営業と打ち合わせする中で、CyberSoleの画面を見たときに、今どのような動作が行われているかは重要ではなく、それよりも複数タスクを簡単に作成できることに主眼が置かれていました。
数で勝負する場合は、このUIの方がセッティングが楽にできます。この観点も今まで作ってきたBOTには無い考え方ですが、今後開発していくサイトには数で勝負するサイトも中にはあると思います。
窓を何個も開くのは、自分で作っておきながらなんですが、ナンセンスだと思っているので、自分が納得の行くUIを作りたいと思います。
題名が決められない。
楽天のBoost機能は、確実に速くなるが、どんな状況でも速くなる訳ではなく、そのときの混雑状況に合わせた設定が必要になる。本来であれば、串ローテを行うことで、BANを回避したやり方をすれば設定を気にする必要はなくなる。
串ローテが必要な機能であることは理解しているが、入れることでどこまで改善されるのかが見えないため、楽天サイトに対して本当に必要なのか疑問に思うとことがある。
数を打つやり方かよいのか、その時間帯の混雑状況を計算した上で、適度な設定を自動で設定するというやり方がよいのか。
何れにしても、使ってもらってデータが集まらないことには判断付かないので、色々試して欲しい。
Yahoo!は大コケをしてしまったようで、申し訳なかった。改修後にリグレッションテストを実施していればこのようなことは起きないのだろうが、そこまでテストに時間を掛けることもできず、当日になって発覚してしまった。
残念な結果になってしまったことを踏まえて、ログイン処理については、念入りに対策・対応した。AlertsJPプレミアムメンバー専用機能のクイックタスクも入れていたため、３連休はほぼYahoo!ショッピングの対応に追われていた。
テストについても入念に行ったので、次回は今回のようなことにならないと断言したいところだ。
AlertsJP専用AIOの開発について。UI部分を作るのはそれなりに時間を要するため、なかなか重い腰が上がらない。とはいえ、C++でUIを作るには時代遅れな感じがするし、凝ろうとすればするほど工数が増えるため、今回は是が非でも最新言語でやりたい。
しかし、当方が使っているフレームワークは、国内ではレアな部類に入るため、開発出来る方がいるのかという問題もあるが、外注することにしようと思っている。画面案が固まり次第、次の手続きに入って行く予定。
最後に、乃木坂４６のライブチケットが11/10（日）に決まったということで、その日は長い戦いになるだろう。今度こそは、結果を残したい！
HTTPプロトコルの応答ステータスにおいて、Service Unavailableというのがあります。
以下は、 https://developer.mozilla.org/ja/docs/Web/HTTP/Status/503 を引用しています。
HyperText Transfer Protocol (HTTP) の
503 Service Unavailableサーバーエラーレスポンスコードで、サーバーがリクエストを処理する準備ができていないことを示します。
一般的な原因は、サーバーがメンテナンス中のために停止していることや、過負荷状態になっていることです。このレスポンスは、一時的な条件に使用する必要があり、Retry-AfterHTTP ヘッダーには、もし可能であれば、サービスの復旧に要する予想時間を含めるべきです。
メモ: このレスポンスと共に、問題を分かりやすく説明するページを送信する必要があります。
503 のステータスはしばしば一時的な状態であり、レスポンスは頻繁にキャッシュされるべきではないため、このレスポンスと共に送信されるキャッシュ関連のヘッダーは注意する必要があります。
最近関わった３つのサーバの全てが混雑時に５０３を返しています。楽天チケット、LivePocket、ASICS Tigerです。
上記３つのサーバは、発売時刻と同時に５０３のアクセス制限となるのですが、一定時間が経過すると、アクセス制限が解除されて、通常のアクセスができるようになります。
アクセス制限が掛かると、恐らく一律制限が掛かるため、持久戦の状態になります。サーバが処理することが可能なアクセス数になるまで制限をかけています。アクセス数がしきい値を下回ると、アクセス制限が解除されるという感じです。（あくまで私感です。）
このような仕様にするメリットは、比較的能力が低いサーバでも運用が可能になるという点があります。ユーザビリティは最悪ですけどね！！
週末はASICS Tigerのコラボ商品に参戦していました。
初めての参戦ということもあって、サーバの勝手が分かっておらず、リトライ処理が不十分だったのですが、ユーザがそれを補うマクロを作ってリストックしていましたｗｗｗ
ものの５分ぐらいで対応していて、いろんな状況に臨機応変に対応するところが流石です。
ただし、動画のような処理は、本来であればBOTが搭載すべき機能のため、今後の改善・対策内容に盛り込みます。
今日は長い戦いだった。今さっきまで状況確認のため、調査していました。
12:00発売にも関わらず、潮目が変わったのは、19:47。
以下は、楽天チケットBOTの動作ログである。
19:46:55.585(12840)[18757432 msec]request [https://rt.tstar.jp/cart/performances/125414]
19:46:55.645(12840)[18757492 msec]cartPerformances2Finished: Error transferring https://rt.tstar.jp/cart/performances/125414 – server replied: Service Temporarily Unavailable
19:46:55.645(12840)[18757492 msec]nothing purchase button… next timer start!
19:46:56.633(12840)[18758480 msec]request [https://rt.tstar.jp/cart/performances/125414]
19:46:56.698(12840)[18758545 msec]cartPerformances2Finished: Error transferring https://rt.tstar.jp/cart/performances/125414 – server replied: Service Temporarily Unavailable
19:46:56.698(12840)[18758545 msec]nothing purchase button… next timer start!
19:46:57.695(12840)[18759542 msec]request [https://rt.tstar.jp/cart/performances/125414]
19:47:03.065(12840)[18764912 msec]cartPerformances2Finished: Error transferring https://rt.tstar.jp/cart/performances/125414 – server replied: Service Temporarily Unavailable
19:47:03.065(12840)[18764912 msec]nothing purchase button… next timer start!
19:47:04.062(12840)[18765909 msec]request [https://rt.tstar.jp/cart/performances/125414]
19:47:04.126(12840)[18765973 msec]cartPerformances2Finished: Error transferring https://rt.tstar.jp/cart/performances/125414 – server replied: Service Temporarily Unavailable
19:47:04.126(12840)[18765973 msec]nothing purchase button… next timer start!
19:47:05.115(12840)[18766962 msec]request [https://rt.tstar.jp/cart/performances/125414]
19:47:05.321(12840)[18767168 msec]cartPerformances2Finished: NO_Error
19:47:05.321(12840)[18767168 msec]nothing purchase button… next timer start!
19:47:06.320(12840)[18768167 msec]request [https://rt.tstar.jp/cart/performances/125414]
19:47:06.508(12840)[18768355 msec]cartPerformances2Finished: NO_Error
19:47:06.509(12840)[18768356 msec]nothing purchase button… next timer start!
19:47:07.505(12840)[18769352 msec]request [https://rt.tstar.jp/cart/performances/125414]
19:47:07.717(12840)[18769564 msec]cartPerformances2Finished: NO_Error
19:47:07.717(12840)[18769564 msec]nothing purchase button… next timer start!
19:47:08.711(12840)[18770558 msec]request [https://rt.tstar.jp/cart/performances/125414]
19:47:13.575(12840)[18775422 msec]cartPerformances2Finished: NO_Error
19:47:13.576(12840)[18775423 msec]nothing purchase button… next timer start!
server replied: Service Temporarily Unavailable は５０３エラーのこと。
19:47は５０３エラーが無いため、何らかしらのチケットが出ていたことになる。
だが、今回はBOTが正しく動かなかった。さっきまでそれを調べていたのだが、分かったことは、購入画面遷移にreCAPTCHA画面が省かれていた。
これがあることを前提に作っていたので、BOTはreCAPTCHA画面が来るのをずっと待っていたのだ。
この販売方法もえげつないが、直前で画面遷移まで変えてくるとは、呆れるレベルだ。。。
次は冬になるのでしょうか？
BOTは、reCAPTCHAが出る場合でも出ない場合でも購入手続きできるように修正しました。なので、次は上手くいくはず！！
大阪公演のバックステージ席をデバッグしながら取得しようとしたところ、１２：３０ごろゲットしました。
１０分頃と２０分頃にも反応していたのですが、座席が４番目にあるのが分からずのがしていました。
そこで、座席の指定を上から何番目とするのではなく、座席名にてヒットさせるように修正します。
この仕様で明日は運用しますので、チケット取得代行センターにも連携します。
このチケットは必ずゲットできるチケットです！！
本日、楽天チケットにて、 欅坂46 の先着チケットが販売されました。
楽天チケットがいつの間にか変わっていて、自動で動かない状態になっていたため、デバッグしながら修正・確認していたら、あっさり取れました。
18:20頃だったんですが、リトライを繰り返しているうちに、カートに入っていました。
楽天チケットは、支払い方法の選択画面に来たところで購入確定のため、そこで止めておけば、１０分程度はチケットが確保されているため、入場者の名前入力も確実に行うことができます。
乃木坂４６にも対応したいところですが、既に先着チケットは完売しており、試すことができません。予め販売情報が分かれば即座に対応できるのですが、いつもこのBOTを触っている訳ではないため、変化を即座に知らせて貰えるようにするため、チケット取得代行センターに楽天チケットBOTを取り扱うようにして貰い、フィードバックして貰うことにしました。
昨日、チャットで横浜に住む童貞くんから駄々をこねられました。少し暇な時間があったので相手にしてあげたのですが、ユーザでもないのに、２ｃｈだかどこかの掲示板を代弁したいらしく金返せと喚いていました。まぁ、恐らくadidas BOTで撃沈したとブログに書いたことに過剰反応したのでしょう。
BOTが上手く動かなかった場合は、返金して欲しいと言われれば返金しています。しかし、明日サーバがどんな状態なのか知る由もなく、購入する側も分かっているからこそ購入してくれていると思います。ただ動かなかった場合は、なるべく早く動くように対応を心がけています。修正が小規模であれば無償対応することは謳っていますし、ずっと動き続けているBOTを今後も作っていきたいと考えています。
こういうことを言ってくる奴は、貧乏なやつなんでしょう。貧乏人は暇ですから。よく結婚できたなって言う時点で、結婚願望あってもできないぶーちゃんなんでしょう。輩で残念な奴とは救いようのないハゲかなにか。不特定多数のネットの世界でしかマウント取れないやつは、実際に会ったときのギャップが激しいのを経験しているから、おまえもちんちくりんなんだろーね。
こっちもあらゆる手を使ってお前の身元が判明したら、即裁判してやるからな。チャットの内容は全部記録残ってるからな。
今月中にYahoo!ショッピングBOTを作成予定です！！
今週末に、「 欅坂46 3rd YEAR ANNIVERSARY LIVE 」の発売があるために使用したいとの問い合わせを貰い、急遽mac版を用意しました。
欅坂 ライブのチケットは、まだ実績がないため、週末の動作確認を行おうと考えています。
操作方法についても一部変更しました。reCAPTCHAの自動突破に、Googleログインによる自動突破を追加しました。
楽天チケットの自動購入ツールの問い合わせがあったため、調査したところ乃木坂４６のチケットを扱っているとのことで、ファンの方は是非使って頂きたいと思い、開発を決めました。
機能としては、カートに確保するまでが一通り完成しており、あとはエラーケースや購入完了までの部分の作り込みのみという状況になっています。週末にテストを行ない、問題なければリリース予定です。
動画は、reCAPTCHAを自動で突破させるため、anti-captchaという第３者認証を使っています。進捗が６５％で少し待っているのは、anti-captchaからの応答を待っているためで、もう少し前からタイマー動作させておけば、anti-captchaの応答を待たずにスムーズに動作します。楽天サイトは、動作が軽いところが良いです。BOTもスムーズに動作しているように見せてくれます。
