にしし ふぁくとりー:西村文宏 個人サイト

全年3月9日の投稿[14件] - 今日のひとことログ

更新

■LOG 全年3月9日の投稿[14件]

にししふぁくとりーHOMEに掲載している「今日のひとこと」の過去ログ(掲載履歴)です。 RSS

No.3354 〔27文字〕

アタック25って今でもまだ放送が続いていたのか。(驚)

No.3353 〔22文字〕

もう3月上旬が終わるって、早すぎないか……?

No.3352 〔22文字〕

SpotifyとShopifyが紛らわしい。

No.3351 〔142文字〕

この意味での召喚という表現はオタク業界用語だと思っていたのだが、そうでもないのか。「等身大サイズのAIキャラクター召喚装置」という表現で記事が出ていた。まあ、CNETはIT系ニュースサイトだから、オタク系サイトと言って良いか。記事には導入費用は書かれていないが、いくらするのだろうか。

No.3350 〔509文字〕

車番認証で課金管理される有料駐車場を使ったのだが、出入口にゲートバーがない。入り放題・出放題な駐車場だったのだが、ちゃんと課金できているのだろうか? というか、ゲートバーがない以上、突破しようと思えば誰でも簡単だと思うのだが、無支払いが後から判明した場合にはどうするのだろう? 車番を使って警察に被害届でも一括して出すのだろうか? 出入口にゲートバーを設けると、バーを開閉する設備+駐車券の収受装置の設置とか設備費や維持費がかかるから、その費用と比較すると、「無支払いだった車に対して後から一括で被害届を出して回収する」という方針の方が安上がりなのだろうか。精算機では、自分の車のナンバー4桁を入力すると、撮影された自分の車の画像が出てきた。認識が正しいことを確認したら、料金が表示される仕組みだった。なかなかうまく撮影されていて感心した。念のために小銭を用意していたのだが、電子マネー(ICOCA)で払えたので小銭は不要だった。便利である。ETCみたいな仕組みで支払えたらもっと便利だったが、割引券(QRコード)の読み取りが必要なことを考えると、精算機の排除までは無理か。なお、駐車場のブランドは「タイムズ」だった。

No.3349 〔249文字〕

リソースモニターを眺めていたら、Delivery Optimizationがsvchost.exeを使ってdeploy.akamaitechnologies.comから318MB程度のファイルをダウンロードしていたのだが、何にどう使われるファイルを落としていたのかがよく分からん。もうちょっと詳しいログはどこかに記録されていないのだろうか? ユーザの与り知らないところで通信回線を使わないで頂きたい。せめて、「××から××の目的で××MBのファイルをダウンロードしたよ」的な通知を残してもらいたい。

No.3348 〔36文字〕

おはようございます。この時間帯(7時)に起きたのはものすごく久しぶりだ。

No.986 〔148文字〕

ああ、HTTPには429 Too Many Requestsというレスポンスもあるのか。503よりも429を返す方が適切かな。サーバ側の問題ではなく(アクセス頻度が高すぎるという)クライアント側の問題なのだし。このレスポンスコードをクローラが意図通りに解釈してくれるのかどうかは分からないけども。

No.985 〔545文字〕

直近の24時間で8,640回のリクエストが上限だと判定されると考えると、あと11時間くらいの間に2,600回くらいリクエストを送ってしまうと上限に達してしまう。1分あたりのリクエスト数を3.9回以下くらいに抑えないとマズそうだ。リクエストを送るのは何もクローラーだけではなく人間のアクセス者も居るので、とりあえずクローラーに対しては5回に4回の割合で503エラーを返すようにしてみた。これでたぶん概ね30秒に1回くらいしかクローラーからのリクエストは通さなくなるハズだ。書いたコードはとても単純で if(( time() % 5 ) != 0 ) のように現在秒を5で割って「余りが0ではなかったら」という条件で、 http_response_code( 503 ); と書いてHTTPステータスコード503(Service Temporarily Unavailable)を返しているだけだ。そこですぐにexit;でPHPスクリプトは終了させるのでAPIにリクエストは送られない。この判定は「キャッシュがなかった場合」に限って実行されるので、既に自前サーバ内にキャッシュデータがある場合にはそのデータが返される。だからクローラーからのアクセスを問答無用で5回に4回拒否するわけではない。📗

No.984 〔659文字〕

ググってみたところ、APIのリクエスト数上限に達した後は、Too Many Requestというエラーしか返ってこなくなるらしい。しかし、このエラーが返ってきた回数もリクエスト回数としてカウントされるっぽいようなことが書いてあって少々不安になった。「1日あたり8,640回」という制限が例えば『毎日午前0時にリセットされる』というような規則なら良いのだけど、『直前の24時間で8,640回を超えていたら拒否する』みたいなのだと、大量にリクエストを送り続けていると、いつまで経ってもデータが得られないことになりそうな気もした。検索エンジンのクローラーが6秒に1回くらいの割合でアクセスしてくるので、ユーザエージェント名でクローラーを決め打ちにして3回に2回の割合で「503 Service Temporarily Unavailable」エラーを返すようにしてみた。503なら、そのクロールが失敗してもクロールリストから削除されることはないだろうし。これで、6秒に1回アクセスがあっても、実際にリクエストを返すのは18秒に1回くらいになってくれる(はず)。ただ、自前サーバ内にキャッシュが存在する場合には拒否しないようにしたので、キャッシュが蓄積されてくれば、503を返す頻度は下がるハズだ。今日の午前4時頃から今までで6,000回くらいリクエストしているので、もっと頻度を下げておく方が安全かな……。別にクローラーに急いでクロールしてもらう必要は全然ないので、10回に9回は拒否するくらいにしてみた方が良いだろうか。📗

No.983 〔17文字〕

今日は、暑い。コートを着ていると。

No.982 〔213文字〕

ドル円レート、2月20日には1ドル112円まで円安が進んでいたのに、今日は1ドル102円。一気に円高方向に動いたなあ。105円よりも円高になったのは2018年3月以来っぽい。ドル円については日々上がったり下がったりだけども、オーストラリアドルと円の関係では2017年あたりの円安ピークから後は徐々に徐々にずっと円高方向に推移しっぱなしなのだが、これはどんな理由からなのだろうか。
20200309145221-nishishi.png
(グラフは3年間の推移。縦軸の単位は円。)

No.981 〔342文字〕

うーむ。新API(v5)は1日あたり8,640回くらいしかリクエストを受け付けてくれないのだが、検索ロボットのクロールがだいたい6秒に1回ペースで発生しているので、1日で14,400回くらいリクエストを送ってしまいそうだ。人間のユーザからの操作分に余裕がないどころの話ではない。1日の後半40%くらいでリクエストが拒否されることになってしまう。とりあえず、得られたデータは45日間ほど自前サーバ内にキャッシュしておくように作ったので、何日間か経てばAPIへ送るリクエスト数は落ち着いてくるのではないかと予想しているのだが。どうだろうか。しばらく観察するしかないか。旧API(v4)は1秒間に1回のリクエストを受け付けてくれていたので、1日86,400回まで送れたから充分だったのだが。

No.980 〔145文字〕

新型コロナウイルス感染者は、いつの間にか兵庫県下だけでも12人になっていた。兵庫県サイト内に発生状況ページができていて知った。感染してから判明するまでに結構な日数が掛かっているようだから、感染の後にも仕事には行っていたのだろう。避けようがなさそうだが、とりあえず満員な電車には乗りたくない。
2021年1月
12
3456789
10111213141516
17181920212223
24252627282930
31
2021年2月
123456
78910111213
14151617181920
21222324252627
28
2021年3月
123456
78910111213
14151617181920
21222324252627
28293031

Powered by てがろぐ Ver 3.5.1

--- 当サイト内を検索 ---